メッセージ・フローは、以下の構成部分から 構成されると考えることができます。
フローがメッセージを処理するときのイベントの順序は、 以下のように考えることができます。
ただし、このイベントの順序では、テーブルのアクセスと出力メッセージの書き込みを 区別していません。通常、フローは 何らかの種類の出力メッセージを生成すると考えられますが、このこととデータベース・テーブルの更新の間に 実質的な区別はありません。いずれの場合も、システム内のデータの 状態に何らかの変更が加えられます。
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
線は、システム内のデータを時系列で表します。時点 1 では、メッセージが到着し、 入力キューから取り出されます。時点 2、3、4、および 5 では、データベース・テーブルが 更新されるかキューに書き込まれます。これらの状態の変更を x 記号で 示します。最後に、時点 6 で出力メッセージが送信され、 システムが静止します。これらのイベントの間、データの状態は変化しません。 これを = 記号で示します。
システムで障害が発生したときの影響について考えてみます。障害 (ブローカーが 稼働しているマシンのプラグが抜けるなど) が発生した場合、 障害前にテーブルおよびキューの状態に加えられた変更は補完されますが、障害後に変更が加えられた場合その変更は 一切補完されません。このような状態はとうてい 受け入れられるものではありません (当座預金から抵当貸付口座への支払いが当座預金テーブルで行われたが、 抵当貸付口座テーブルには加算されていないなど)。
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
線は、システム内の追加データを時系列で表します。時点 1 では、メッセージが到着し、 入力キューから取り出されます。それ以前にシステムには追加データはありません。 これを - 記号で示します。この時点の後、状態は、 メッセージがキューから取り出され、必要な場合に書き戻せる状態であることを 表します。時点 2、3、4、および 5 では、データベース・テーブルが 更新されるかキューに書き込まれます。追加データの状態が再度変化し、 必要な場合はテーブルおよびキューに対する変更を 元に戻せるようになります。最後に、時点 6 で出力メッセージが送信されてシステムが静止し、 再度システムに追加データがない状態になります。これらのイベントの間、 追加データの状態は変化しません。 これを = 記号で示します。時点 1 から 6 までの間に 障害が発生した場合は、追加データを使用してシステムのデータの元の状態が復元されます。 結果として、どの出力キューにも書き込まれず、どのテーブルも変更されず、入力メッセージは 入力キューから取り出されません。障害が発生しなかった場合は、 時点 6 で変更内容が永続的なものとなり、その後に障害が発生して取り消し操作が実行されても 元に戻されなくなります。
この操作モードを整合トランザクション・モードといいます。トランザクションの 正常終了をコミットといいます。異常終了を ロールバックといいます。(これを実現する仕組みについて詳しくは、 セクション『XYZ』を参照してください。この動作はデフォルトではなく、すべてのデータベースまたは キューイング・システムがサポートするわけではないことに注意してください。)
整合トランザクション操作モードの重要な機能は、 障害がいつどこで発生するかにかかわらず、特定の入力メッセージに関連したキューおよび テーブルに対する変更がすべて行われるか一切行われないかのいずれかになることであり、 このことが主な利点です。しかし、あらゆる場合に適しているわけではありません。そのような 2 つの 単純な例を以下に示します。
MAIN -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1st AUX --------------x======x========x------ 3 6 7
上の線は、以前と同じメイン・トランザクションを表します。トランザクションは 抽象的な用語ですが、実世界では、必要な場合に元の状態に復元する必要がある 追加のデータに相当します。下の線は 補助トランザクションを表します。時点 3 では、テーブル (またはキュー) が 更新されます。時点 6 でも再度行われます。時点 7 では、 補助トランザクションで実行する必要があるすべての変更が完了し、 変更内容をコミットします。
時点 7 より前にフローで障害が発生した場合、トランザクションは両方ともロールバックされるため、 システムの状態は変更されません。時点 7 より後かつ時点 9 より前に 障害が発生した場合は、補助トランザクションがコミットされます (既にコミットされています) が、 メイン・トランザクションはロールバックされます。時点 9 まで障害が発生しなかった場合は、 障害が発生しなかったことになり、トランザクションは両方ともコミットされます。
補助トランザクションは 1 つだけに制限されることも、コミットのみに 制限されることもありません。データベース・テーブルに対する多くの更新を実行でき、 それらをコミットまたはロールバックできます。その後、 さらに同じデータベース・テーブルや別のデータベース・テーブルを変更してから、 それらの変更内容をコミットまたはロールバックできます。
使用する各データベースは専用の補助トランザクションを持つことができるため、 別のデータベース・インスタンスに属する (データ・ソース名が異なる) テーブルをフローが更新する場合には、 データベースごとに 1 つの補助トランザクションを作成します。 これらは、個別にコミットまたはロールバックできます (実際には個別に行わなければなりません)。操作が 完了したときに (時点 9)、コミットもロールバックもされていない更新はすべて、 処理が成功したか失敗したか (例外が入力ノードに達したかどうか) に応じて ブローカーによって自動的にコミットまたは ロールバックされます。
DB2 on AIX などの一部のデータベース・タイプでは、整合トランザクションと非整合トランザクションの両方を 同じデータベース・インスタンスで使用することができません。このような場合は、 別個のデータベース・インスタンスを作成する必要があります。整合トランザクションに 1 つのデータベース・インスタンスを構成し、 非整合トランザクションにもう 1 つ構成します。
補助データベース・トランザクションは、ESQL COMMIT および ROLLBACK ステートメントを 使用してコミットまたはロールバックします。メイン・トランザクション外の操作は、 使用する個々のデータベース・ステートメント (INSERT ステートメントや UPDATE ステートメントなど) に UNCOORDINATED を 指定することによって行います。
すべてのキューイング・システムが上記のデータベースの機能を持つわけではありません。 MQ の場合、キューに対する個々の各非整合読み取りまたは書き込みは、 暗黙のうちにコミットされます。このため、2 つのメッセージを書き込んだ後に両方ともコミットするか 両方ともロールバックするかを決定することはできません。これは下位システムによる 制限であり、WebSphere Message Broker では対処できません。このように、COMMIT ステートメント および ROLLBACK ステートメントはデータベースでのみ機能します。
上記の説明ではフローについてのみ説明し、ノードについては触れていません。 フローをノードに分割する仕組みは、原則的にトランザクションに関する説明と 直接関係しません。任意の数のノードが、 メイン・トランザクションおよび任意の数の補助トランザクションに対する更新を何の制限もなく 自由に実行できます。処理の内容は影響しますが、方法は影響しません。しかし、実際には、 他のデータ・ソース (VSAM、キュー) の機能には限度があるため、 データベースでの操作にしか該当しません。