メッセージ・フローは、以下の要素から構成できます。
メッセージ・フローがメッセージを処理するときのイベントの一般的な順序は、以下のとおりです。
ただし、このイベントの順序では、テーブルのアクセスと出力メッセージの書き込みを 区別していません。通常、フローは何らかの種類の出力メッセージを生成する場合が多いものの、このこととデータベース・テーブルの更新の間に実質的な区別はありません。どちらの場合も、システム中のデータの状態は変化します。
=====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 では、メッセージが到着し、 入力キューから取り出されます。時点 1 以前にシステムには追加データはありません。この図ではこれを - 記号で示します。時点 1 の後、状態は、メッセージがキューから取り出され、必要な場合にキューに書き戻せる状態であることを表します。時点 2、3、4、および 5 では、データがデータベース・テーブルの更新に使用されるかキューに書き込まれます。追加データの状態が再度変化し、必要な場合はテーブルおよびキューに対する変更を元に戻せるようになります。時点 6 で出力メッセージが送信されてシステムが非アクティブになり、再度システムに追加データがない状態になります。これらのイベントの間、追加データの状態は変化しません。これを = 記号で示します。時点 1 から時点 6 までの間に障害が発生した場合は、追加データを使用してシステムのデータの元の状態が復元されます。したがって、実際にはどのデータも出力キューに書き込まれず、どのテーブルも更新されず、入力メッセージは入力キューから取り出されません。障害が発生しなかった場合は、 時点 6 で変更内容が永続的なものとなります (その後に障害が発生して取り消し操作が実行されても変更内容は元に戻されなくなります)。
上記の操作モードを整合トランザクション・モードといいます。トランザクションの正常終了をコミットといいます。異常終了をロールバックといいます。
整合トランザクション操作モードの重要な機能は、障害がいつどこで発生するかにかかわらず、特定の入力メッセージに関連したキューおよびテーブルに対する変更がすべて行われるか一切行われないかのいずれかになることです。しかし、以下の例で示されているように、この動作は常に適切とは限りません。
MAIN -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1st AUX --------------x======x========x------ 3 6 7
MAIN の線はメイン・トランザクションを表します。このトランザクションには、必要な場合に元の状態に復元する必要がある追加のデータが含まれます。1st AUX の線は補助トランザクションを表します。時点 3 でテーブルまたはキューに対する更新が行われ、時点 6 でも再度行われます。時点 7 では、メッセージ・フローは、補助トランザクションで実行する必要があるすべての変更が完了したと判断し、変更内容をコミットします。
時点 7 より前にメッセージ・フローで障害が発生した場合、トランザクションは両方ともロールバックされるため、システムの状態は変更されません。時点 7 より後かつ時点 9 より前に障害が発生した場合は、補助トランザクションが既にコミットされていますが、メイン・トランザクションはロールバックされます。時点 9 まで障害が発生しなかった場合は、トランザクションは両方ともコミットされます。
複数の補助トランザクションを使用し、コミットまたはロールバックできる多数の更新をデータベース・テーブルに加えることができます。その後、さらに同じデータベース・テーブルや別のデータベース・テーブルを変更してから、 それらの変更内容をコミットまたはロールバックできます。
使用する各データベースは専用の補助トランザクションを持つことができるため、別のデータベース・インスタンスに属する (データ・ソース名が異なる) テーブルをメッセージ・フローが更新する場合には、データベースごとに 1 つの補助トランザクションを作成します。これらのトランザクションは個別にコミットまたはロールバックしなければなりません。操作が完了したときに (上記の例では時点 9)、コミットもロールバックもされていない更新はすべて、処理が成功したか失敗したかに応じてブローカーによって自動的にコミットまたはロールバックされます。
DB2 on AIX などの一部のデータベース・タイプでは、整合トランザクションと非整合トランザクションの両方を同じデータベース・インスタンスで使用することができません。このような場合には、別のデータベース・インスタンスを作成しなければなりません。整合トランザクションに 1 つのデータベース・インスタンスを構成し、非整合トランザクションにもう 1 つのインスタンスを構成してください。
補助データベース・トランザクションのコミットとロールバックには、ESQL COMMIT ステートメントと ROLLBACK ステートメントを使用します。メイン・トランザクション外の操作は、個々のデータベース・ステートメント (INSERT ステートメントや UPDATE ステートメントなど) に UNCOORDINATED キーワードを指定することによって行います。
すべてのキューイング・システムが上記のデータベースの機能を持つわけではありません。 WebSphere MQ の場合、キューに対する個々の各非整合読み取りまたは書き込み操作は暗黙のうちにコミット・アクションが行われるので、2 つのメッセージを挿入してから両方のコミットまたは両方のロールバックを決定することはできません。このように、COMMIT ステートメントおよび ROLLBACK ステートメントはデータベースでのみ機能します。
上記の説明では、メッセージ・フローについては言及されていますがノードについては言及されていません。メッセージ・フローをノードに分割する方法は、トランザクションには影響しません。データベースに対する操作の場合、任意の数のノードが、メイン・トランザクションおよび任意の数の補助トランザクションに対する更新を何の制限もなく実行できます。