集約フロー内の例外およびデータベース・デッドロックの処理

集約フローを使用する場合、例外またはデータベースのデッドロックが生じることがあります。 このトピックでは、この対処方法について説明します。

始める前に:

このタスクを実行するには、以下のタスクを完了している必要があります。

例外の処理

AggregateReply ノードのダウンストリームでエラーが検出される場合、ブローカーは例外をスローします。 また、メッセージ・フロー内の別のノードも、ESQL THROW ステートメントを使用して例外をスローします。 いずれの場合にも、例外がスローされた場合、それは以下の 2 つの場所のどちらかでキャッチされます。

  • 応答が到着する入力ノード
  • AggregateReply ノード

下の表では、イベントと、AggregateReply ノードのダウンストリームにスローされた例外に生じる事柄をリストしています。

イベント 伝搬されるメッセージ 出力ターミナル 例外がキャッチされる場所
予期された応答が入力ノードに到着し、AggregateReply ノードの In ターミナルに渡される。 これが集約の完成に必要な最後の応答。 すべての応答を含む集約された応答メッセージ Out Input ノード
予期しない応答が入力ノードに到着し、AggregateReply ノードに渡される。 これが有効な応答として認識されず、 「Unknown Message Timeout (不明なメッセージ・タイムアウト)」プロパティーが 0 に設定されている。 受け取られたメッセージ Unknown Input ノード
集約のすべての応答がまだ到着していないのでタイムアウトが生じる。 受け取ったすべての応答を含む集約された応答メッセージ Timeout AggregateReply ノード
保持されたメッセージが有効な応答と認識されなかったために、不明タイムアウトが生じる。 保持されたメッセージ Unknown AggregateReply ノード
最後の応答が到着したとき以外に、集約の完成したことが判明した。 すべての応答を含む集約された応答メッセージ Out AggregateReply ノード

集約フローで生じるエラーを処理する場合、 メッセージ・フローのそれぞれのノードのインスタンスすべてにおいて、 これらの例外をキャッチする必要があります。 これを行うには、次のようにします。

  1. 「ブローカー・アプリケーション開発 (Broker Application Development)」パースペクティブに切り替えます。
  2. 作業するメッセージ・フローを開きます。
  3. これらの例外を自分で処理したい場合、 それぞれの入力および AggregateReply ノードの catch ターミナルを、 発生したエラーを処理するノードのシーケンスに接続します。

    エラー処理に対する統合アプローチを行うには、これらのノードすべての catch ターミナルをノードの単一シーケンスに接続するか、または 1 つの一貫した方法でエラーを処理するサブフローを作成し、それをそれぞれの catch ターミナルに接続します。

  4. ブローカーにデフォルトのエラー処理を使用してこれらの例外を処理させる場合には、これらのノードの catch ターミナルを接続しないでください。
AggregateReply ノードの catch ターミナルを接続し、 このターミナルを介して伝搬されるメッセージを後で処理するために検索できる宛先に出力したい場合は、 トランスポート固有の処理を行うために Compute ノードを catch フローに組み込む必要があります。 例えば、メッセージを MQOutput ノードから WebSphere MQ キューに書き込みたい場合は、MQMD ヘッダーを追加する必要があります。

以下の ESQL の例は、 MQMD ヘッダーを追加して、AggregateReply ノードが受信する応答を渡す方法を示しています。

-- Add MQMD
SET OutputRoot.MQMD.Version = 2;
.
-- Include consolidated replies in the output message
SET OutputRoot.XML.Data.Parsed = InputRoot.ComIbmAggregateReplyBody;
.

例外についての情報を出力メッセージで伝搬したい場合は、 Compute ノードの 「計算モード (Compute Mode)」プロパティーに Exception を含む値を設定する必要もあります。

データベース・デッドロックの処理

AggregateRequest および AggregateReply ノードは、 テーブル BAGGREGATE 内の集約された要求処理に関連した情報の書き込みおよび読み取りのために、 ブローカー・データベースにアクセスします。 デッドロックは、複数のリソースが同時にデータベース・テーブルにアクセスしようとするときに生じることがあります。

データベースのデッドロックを回避するには、以下のようにします。

  1. 分散システム上の Sybase または DB2 for z/OS を使用してブローカー・データベースを作成する場合、 デフォルトのロック設定はページ・ロックです。 これを設定すると、集約フロー内にデッドロックが生じることがあります。 データベースの作成時またはその後で、集約メッセージ・フローをホストするブローカーのブローカー・データベースを構成する場合、潜在的なデッドロックを回避するために行ロックを使用可能にしてください。
  2. 分散システム上の DB2 を使用してブローカー・データベースを作成する場合、DB2 の次のキーロック機能が使用可能になっている場合、ブローカーにデッドロックが発生することがあります。 デッドロック状態はブローカーによって報告され、 SQL State 40001 のイベント・ログ・メッセージ BIP2322 が作成されます。

    この問題が生じる場合には、 DB2 コマンド・ウィンドウで次のように入力して次のキーロックを使用不可にします。

    db2set DB2_RR_TO_RS=YES

    このコマンドが完了したら、DB2 データベース・マネージャーを再始動してください。 このコマンドは、このデータベースの操作には他の影響はありません。

別のデータベースを使用している場合、これらのデッドロックは生じません。

関連概念
メッセージ・フロー
メッセージ・フローの集約

関連タスク
集約フローの構成
集約ファンアウト・フローの作成
集約ファンイン・フローの作成
ファンアウトおよびファンイン集約フローの関連付け
集約のタイムアウトの設定
複数の AggregateControl ノードの使用
メッセージ・フローのエラー処理
メッセージ・フローの設計
メッセージ・フローの作成
メッセージ・フローの内容の定義

関連資料
AggregateControl ノード
AggregateReply ノード
AggregateRequest ノード