整合されるメッセージ・フローは、単一トランザクション内で実行します。
トランザクションは、入力ノードがメッセージを受信した時点で開始し、すべての処理が完了した時点で、コミットまたはロールバックすることができます。
また、データベースと対話するノードによってデータベース・エラーを処理する方法も制御できます。
メッセージ・フローのアクションがグローバルに調整される (つまり、処理をすべて正常に完了するか、さもなければ何も処理を行わない) ようにするには、そのアクションが構成で必ずサポートされるようにします。
メッセージ・フロー・トランザクションのグローバル整合についての詳細は、
トランザクション・モデルを参照してください。
以下の例は、グローバルに整合されたトランザクションの使用法を示すとともに、データベース更新が整合された場合のメッセージ・フロー (メイン・フロー) と、整合されない場合のメッセージ・フロー (エラー・フロー) の相違を示します。
サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。
グローバル整合のためにメッセージ・フローを構成するには、以下のようにします。
- Message Brokers Toolkit で、「ブローカー・アプリケーション開発」パースペクティブに切り替えます。
- 構成するメッセージ・フローを開きます。
- 以下のノードがそのメッセージ・フローで使用されている場合は、「トランザクション」プロパティーを設定します。
- Compute ノード
- Database ノード
- DataDelete ノード
- DataInsert ノード
- DataUpdate ノード
- Filter ノード
- Mapping ノード
- Warehouse ノード
「トランザクション」プロパティーには、次の値を設定できます。
- 自動
- メッセージ・フローの処理が完了したら、ノードが実行した更新、削除、または追加がすべてコミットあるいはロールバックされます。
メッセージ・フローが正常に完了した場合は、すべての変更をコミットします。
メッセージ・フローが正常に完了しなかった場合は、すべての変更をロールバックします。
メッセージ・フローによるすべての処理を整合したい場合には、この値を選択する必要があります。
- コミット
- メッセージ・フローのデプロイ先システムに応じて、異なるアクションが取られます。
同じメッセージ・フローの中に、
「自動」のトランザクション特性のノードと、
「コミット」のトランザクション特性のノードを混在させる場合、両方のノードが同じ外部データベースに対して操作を行うのであれば、別個の ODBC 接続を使用します。
一方の接続はメッセージ・フローが完了するまでコミットしないノード用、もう一方の接続は即座にコミットするノード用です。
別々の ODBC 接続を使用しないと、即座にコミットするノードは、それより前の
「自動」ノードが実行した操作まで、すべてコミットしてしまいます。
注: z/OS 以外のシステム上では、このモードの操作をサポートするリレーショナル・データベースもあれば、サポートしないものもあります。
複数の ODBC 接続を定義すると、データベース・ロックの問題が起こることがあります。
特に、「自動」のトランザクション特性のノードが、データベース・オブジェクト (表など) をロックする操作 (INSERT または UPDATE など) を実行した場合、後続のノードが別の ODBC 接続を使ってこのデータベース・オブジェクトへのアクセスを試みると、無限ロック (デッドロック) が生じます。
2 番目のノードは、最初のノードが獲得したロックが解放されるのを待ちますが、最初のノードは、メッセージ・フローが完了するまで、操作をコミットすることも、ロックを解放することもありません。しかし、この場合にメッセージ・フローが完了することは決してありません。というのは、2 番目のノードが、最初のノードのデータベース・ロックが解放されるのを待っているからです。
このような状況を DBMS のデッドロック自動回避ルーチンで検出することはできません。
というのは、2 つの操作はブローカーを使って間接的に干渉し合っているからです。
このタイプのロックの問題を回避する 2 とおりの方法があります。
- コミットされていない (「自動の」) 操作が、別の ODBC 接続を使う後続の操作がアクセスしなければならないデータベース・オブジェクトをロックしないように、メッセージ・フローを設計する。
- 一定時間が経過したらロックを獲得しようとしても失敗するように、データベースのロック・タイムアウト・パラメーターを構成する。
ロック・タイムアウトが原因でデータベースの操作が失敗したら、例外がスローされ、ブローカーはこれを通常の方法で処理します。
特定の操作によってロックされるデータベース・オブジェクトについて、およびデータベースのロック・タイムアウト・パラメーターを構成する方法については、ご使用のデータベース製品の資料をご覧ください。
- 以下のノードがこのメッセージ・フロー内にある場合は、そのノードに対して「 トランザクション・モード」プロパティーを設定します。
- MQInput ノード
- MQOutput ノード
- MQReply ノード
- SCADAInput ノード
- JMSInput ノード
- JMSOutput ノード
以下の表は、入出力ノードの特定のプロパティー設定に対応して行われるアクションの要約を示しています。
メッセージ持続性 a |
Input ノード・トランザクション・モード |
MQOutput またはMQReply ノード・トランザクション・モード |
メッセージ・フローがグローバルに整合されるかどうか |
はい |
はい |
自動 |
はい |
いいえ |
はい |
自動 |
はい |
はい |
いいえ |
自動 |
いいえ |
いいえ |
いいえ |
自動 |
いいえ |
はい |
自動 |
自動 |
はい |
いいえ |
自動 |
自動 |
いいえ |
任意 b |
任意 b |
はい |
はい |
任意 b |
任意 b |
いいえ |
いいえ |
注: - 持続性は、WebSphere MQ
Enterprise Transport、WebSphere MQ Mobile Transport、および WebSphere MQ
Telemetry Transport プロトコルを介して受信されるメッセージについてのみ関係があります。
- MQOutput または MQReply ノード・プロパティー設定は、ここで設定されている値を指定変更します。
- JMSInput および JMSOutput ノードのトランザクション・モード設定は、上記の表とは異なる設定になります。JMSInput ノードおよびJMSOutput ノードを参照してください。
それぞれの入力ノードのデフォルトは はい です。
これはつまり、着信メッセージは同期点下で処理されるということです。
さらに、出力ノードに送信されたメッセージは、同期点下で配送されます。
出力ノードが MQOutput または MQReply ノードである場合には、どちらも「トランザクション・モード」プロパティーがあるので、この動作は変更することができます。
入力ノード上の「トランザクション・モード」プロパティーを「自動」に設定した場合には、着信メッセージが永続と定義されている場合にのみ、同期点下で処理されます。MQOutput ノードに送信されたメッセージは、MQOutput ノードで「トランザクション・モード」プロパティーの設定を明示的に変更しない限り、同期点下で配信されます。
- データベースにアクセスするそれぞれのノードごとに、「警告をエラーとして扱う」および「データベース・エラーで例外をスローする」プロパティーを設定し、それぞれのノードでデータベースの警告とエラーを処理する方法を指定します。 これらのプロパティーの選択や、ノードの failure ターミナルに接続する方法も、データベースの更新がコミットされるか、ロールバックされるかに影響します。
- ブローカー・アーカイブにメッセージ・フローを追加します。
- ブローカー・アーカイブ・エディター・ビューの下の「構成」タブを選択して、メッセージ・フローを選択します。 これは、ブローカー・アーカイブ内のメッセージ・フローの構成可能プロパティーを表示します。
「coordinatedTransaction」を選択して、メッセージ・フローをグローバルに整合するよう構成します。
z/OS では、トランザクションが常にグローバルに整合されます。
メッセージ・フローの coordinatedTransaction プロパティーの設定は、無視されます。
整合は常に RRS によって提供されます。
これで、メッセージ・フローをブローカーにデプロイできます。
メッセージ・フローをデプロイする前に、ブローカー環境 (ブローカーのキュー・マネージャーを含む) およびデータベースがグローバル整合のために正しく構成されていることを確認してください。
ブローカー環境とデータベースがグローバル整合のために正しく構成されていない場合には、メッセージ・フロー・トランザクションはグローバルに整合されません。