データの一部が変更されたときに、できれば JMS 経由で PostgreSQL サーバーに通知を送信させたいと考えていますが、他の Pub-Sub メカニズムまたはコールバックも考慮しています。
これが可能であれば、何かアイデアはありますか？
この種の機能を複製する利用可能な Java アドオン パッケージはありますか?
4918 次
5 に答える
8
編集: PostgreSQLがJava のストアド プロシージャをサポートしているとの連絡を受けました。つまり、次のアプローチが実現可能になります。
基本的に、私が行く方法は、監視したいものにトリガーを設定し、そこからストアド プロシージャを呼び出すことです。ストアド プロシージャは、DB サーバーの外部と通信する必要があります。ポートでリッスンしている同じサーバー上のプロセスへのソケット接続を開く、Java でこのような SP を作成したことがあります。最悪の場合は、ファイルを書き込んで、そのファイルを監視する imon のようなものを用意するか、独自の exec() シェルでプログラムを起動することができます...そのようなものです。
于 2009-11-20T15:58:42.483 に答える
4
もちろん、Java 言語のストアド プロシージャを作成して PostgreSQL に配置することもできます。しかし、メッセージング スキームが完全に機能していることを確認するまで、シンプルでデバッグ可能な状態にしておくのはどうでしょうか? もし私がこれをしていたら（私は実際に似たようなことをしています）、私がすることは次のとおりです。
(1) ペイロードの列と JMS メッセージのその他の情報を含む「送信メッセージ」テーブルを作成します。各行にタイムスタンプ列を配置します。
(2) メッセージを生成する各アイテムのデータベース トリガーを記述します。トリガーで「送信メッセージ」テーブルに行を挿入します。
(3) (1) と (2) の単体テスト。メッセージを生成するデータベース内のものを変更するときに、送信メッセージ テーブルの内容を確認します。
(4) このアウトバウンド・メッセージ・テーブルを照会し、行ごとに JMS メッセージを送信してから DELETE する、単純だが高性能な Java JDBC クライアント・プログラムを自分で作成してください。メッセージの順序を維持するために、クエリ内の行をタイムスタンプで並べ替えます。高いパフォーマンスを得るには、PreparedStatement オブジェクトとヒープ管理のその他の側面を適切に処理する必要があります。
(5) 単体テスト (4) は、メッセージを生成する変更がデータベースに発生している間に数回実行します。
(6) 単一の永続的な JDBC 接続を使用しながら、(6) の操作を 1 分間に数回繰り返すようにこのプログラムをセットアップします。小さなテーブルまたは空のテーブルへのクエリはそれほど高価ではないため、テーブル サーバーがダウンすることはありません。
(7) システム全体のセットアップをテストします。
(8) crontab または起動スクリプトから Java プログラムを起動する方法を理解します。
これらすべてが機能するようになると、機能するメッセージング/通知システムがシステム統合の準備が整います。さらに重要なことは、Java メッセージ発信ソフトウェアに何をさせたいかを正確に知ることができるということです。起動して実行した後、メッセージの待ち時間またはデータベースのオーバーヘッドが大きな問題であることが判明した場合は、Java プログラムをストアド プロシージャに移行できます。
Apache ActiveMQ パッケージに組み込まれている PERL およびその他の言語用のメッセージ発信バインディングがあることにも注意してください。そのため、メッセージ発信エージェントの実装方法についていくつかの選択肢があります。
このアプローチには、たまたま 2 つの利点があります。postgreSQL の独特のストアド プロシージャ スキームに大きく依存していないことと、外部通信に依存するコードをテーブル サーバーに配置していないことです。
幸運を。
于 2009-11-27T23:19:20.230 に答える
2
PL/Javaを Postgresにインストールし、関心のあるデータに対してストアド プロシージャ ベースのトリガーを作成し、呼び出されたときに JMS を呼び出します。PL/Java のドキュメントでは、トリガー + ストアド プロシージャの部分がかなりうまくカバーされています。
トリガー コードから JMS を使用したことはありませんが、実行できない理由はないと確信しています。これは標準の Java コードであり、ドキュメントを簡単に再確認しても何も示されなかったからです。疑わしい。
もう 1 つの可能性は、perl、python、または postgres ストアド プロシージャ開発に使用できるその他の言語を使用して、プロキシ サービスを介して JMS を呼び出すことです。JMS に標準のワイヤ プロトコルがないのと同様に、変換を行うプロキシ サービスを作成する必要があります。
于 2009-11-25T23:08:53.470 に答える
1
JDBC 経由で LISTEN/NOTIFY にアクセスできない場合は、おそらく、LOCKステートメントを介してロングポーリング HTTP コメットのようなメカニズムを実装するか、単純な "SELECT ... FOR UPDATE" および "SELECT ... FOR SHARE" などを実装できます。他のトランザクションをブロックするトランザクション内からの同様のクエリ。
メッセージ作成側は、たとえば、トランザクションを開始し、「SELECT ... FOR UPDATE」を実行し、何かが変更されるか、タイマーが期限切れになるまで (Java コードで) 待機し (たとえば、30 秒程度)、ロックされた行を更新して、データ（他の場所？）が利用可能な場合、トランザクションをコミットして他のブロックを解除します。次に、「SELECT ... FOR UPDATE」を使用してすぐに新しいトランザクションを繰り返します。
メッセージを読む当事者は、他の場所で開始された「SELECT ... FOR UPDATE」がアクティブな間、ブロックする「SELECT ... FOR SHARE」を実行します。メッセージ書き込みパーティのトランザクションが終了すると、メッセージの可用性またはメッセージ データ自体の表示が返されます。
PostgreSQL がパーティーを公平にキューに入れ、ライブロックがメッセージを読むパーティーを継続的にブロックするリスクがないことを願っています。
于 2009-11-25T22:47:48.947 に答える