RDBMS イベント ジェネレータ

RDBMS イベント

この節では、RDBMS イベントの概要を示し、データ ソースおよび RDBMS イベントの作成とチャネル ルールの定義を開始する前に考慮すべき事項について説明します。

ここでは、以下のトピックについて説明します。

• RDBMS イベント
• サポートされるイベント タイプ
• 一般的な情報
• アーキテクチャの概要

 

---

RDBMS イベント

イベントとは、RDBMS から送信される、非同期で一方向のメッセージです。イベントは、特定の関連イベントがトリガされるたびに XML ドキュメントまたは XML を Java 文字列またはシリアライズされた CachedRowSet として RDBMS からポストします。イベントには RDBMS のテーブルで発生した Select、Insert、Update、Delete の各操作に関するデータを保持できます。

サポートされるイベント タイプ

RDBMS イベント ジェネレータでは、以下のイベント タイプがサポートされます。

• トリガ — トリガ イベントは、データベース テーブルで発生する Insert、Update、または Delete イベントを通知する。
• クエリ/Post クエリ — クエリ/Post クエリは、データベース テーブルに対して指定された Select クエリに基づき、該当するレコードを通知し、送信された各イベントに対して Post クエリで指定された SQL を実行する。

一般的な情報

データ ソースおよび RDBMS イベントの作成とチャネル ルールの定義を開始する前に、以下の点を考慮してください。

• 1 テーブルあたり最大 3 つのトリガ タイプ イベント (Insert、Delete、Update の各イベントを 1 つずつ) をコンフィグレーションできる。
• トリガ タイプ イベントはテーブル上でのみテストされており、ビュー、シノニムなどではテストされていない。
• イベント ジェネレータの動作には、デフォルト JMS 接続ファクトリが必要。
• RDBMS イベント ジェネレータでは、エラーや警告などのメッセージ ログがサーバのドメイン ディレクトリの rdbmsEG.log ファイルに記録される。RDBMS イベント ジェネレータの問題を解決するには、このファイルを参照してください。
• トリガ タイプ イベントを操作する場合、チャネル ルールがコンフィグレーションされていれば、トリガはイベント タイプ (Insert/Delete/Update) 行をチャネル ルールの定義時に指定したテーブルから他のテーブルにコピーし続ける。イベントをパブリッシュしている最中にチャネル ルールを削除すると、データが消失する場合があります。データの消失を防ぐには、イベントのパブリッシュを停止した場合、およびチャネル ルールの定義時に指定したテーブルにイベント アクティビティが存在しない場合にチャネル ルールの定義を削除します。

[クエリ/Post クエリ] イベント タイプのコンフィグレーションでは、以下の点に注意してください。

• Post クエリが [no-op] (処理なし) または SQL (選択した行が削除されない) の場合
• 最初の x 行が必ずパブリッシュされる (x はポーリングあたりの最大行数)。
• Sybase ではポーリングあたりの最大行数は無視され、各ポーリングの SELECT クエリに一致するすべての行が返される。
• DB2 および Informix では、automatic-delete は使用できない。
• 適切な DELETE Post クエリを指定する必要がある。
• Post クエリは SELECT クエリで返される各行に対して実行される。
• 行の Post クエリはメッセージ ブローカにパブリッシュした後に実行される。
• Post クエリが 「DELETE FROM USER_TBL」のようにあいまいで、SELECT クエリが「SELECT FIRST_NAME, LAST_NAME WHERE STATUS=`TEMP'」の場合、最初の 1 行がパブリッシュされた後、すべての行が削除される。
• Post クエリの @ プレフィックス変数は、プリペアド ステートメントのバインド変数と同様の役割を果たす。

 

---

アーキテクチャの概要

RDBMS イベント ジェネレータは RDBMS アダプタのイベント機能に代わる機能です (RDBMS Adapter Service 機能は RDBMS イベント ジェネレータの一部ではありません)。この節では、RDBMS イベント ジェネレータ アーキテクチャの概要を示し、RDBMS イベント ジェネレータが RDBMS アダプタより優れている点について説明します。

RDBMS イベント ジェネレータと RDBMS アダプタの主な相違点は、トリガ タイプ イベントのアーキテクチャにあります。[クエリ/Post クエリ] タイプのイベントは同じです。

トリガ タイプ イベントの場合、RDBMS アダプタはシングル スレッドで動作し、テーブル行はシングル スレッドでポーリングおよびパブリッシュされます。パブリッシュにかかる時間がポーリング間隔より長い場合、その後のポーリングは遅延します。これは実質的にシングル スレッド方式であるため、最大スループットが制限されます。これに対して、RDBMS イベント ジェネレータはマルチスレッド方式です。ポーリングとパブリッシュはそれぞれ別のプロセスで実行されます。この方法では、パブリッシュを処理するスレッドの一部で遅延が生じても、ポーリングを続行し、空いたスレッドで新規行をパブリッシュできます。また、処理スレッド数およびパブリッシュするスレッド数をデータベース テーブルの rate-of-activity と一致させることができます。

次の例では、Insert トリガ タイプ イベントでこのポーリングの利点を示します。2 つのスレッドでそれぞれ 50 行を処理およびパブリッシュするのに 10 秒かかります。スループットは (50 x 2)/10 = 10 行/秒 (10 x 60 x 60 = 36,000 行/時) です。常時使用される処理スレッドを最大限に利用し、一貫したスループットを得るには、ポーリング間隔を 7 ～ 8 秒に設定します。10 行/秒のスループットを常に確保するには、このトリガ イベントがコンフィグレーションされているデータベース テーブルに対して 7 ～ 8 秒おきに 100 行以上を挿入する必要があります。

上記の例は、イベントをコンフィグレーションするうえでの基本ルールにすぎません。実際の数値はアプリケーション サーバのハードウェア、データベース ハードウェア、パブリッシュするデータ型、パブリッシュするカラム数、アプリケーション サーバの実行キュー サイズなどの要因によって異なります。

クラスタ

クラスタでは、ポーリングは各管理対象ノードによりラウンドロビン方式で実行されます。ポーリングされた行の処理およびパブリッシュのロード バランスもラウンドロビン方式で行われます。接続プールとデータ ソースはクラスタ全体を対象にする必要があります。RDBMS イベント ジェネレータをクラスタにデプロイする方法の詳細については、『WebLogic Integration ソリューションのデプロイメント』の「イベント ジェネレータ リソース」を参照してください。