WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

メッセージ・フローのトランザクション

トランザクションは、アプリケーション・プログラムによって実行される一連の更新を示していて、これらの更新はまとめて管理する必要があります。 更新は 1 つ以上のシステムに対して実行される場合があります。 プログラムによって実行される更新は、プログラムを実行する環境によって制御され、すべてが完了するか、まったく完了しないかのいずれかです。 トランザクションのこのプロパティーは、「整合性」と呼ばれます。 トランザクションは、原子性分離、および耐久性 といった他のプロパティーを持つ場合があります。

WebSphere® Message Broker はトランザクションをサポートし、メッセージ・フローによって処理されるすべてのデータには関連するトランザクションがあります。 入力データがフロー内の入力ノードで受信されると、メッセージ・フロー・トランザクションはブローカーによって開始されます。 このトランザクションは、フローがそのメッセージを出して完了した場合はコミットされ、エラーが発生した場合はロールバックされます。

フローに複数の入力ノードが含まれている場合は、 入力データを受信すると、入力ノードごとに 1 つのトランザクションが開始されます。 トランザクションは、ユーザー定義の入力ノードを含め、すべてのタイプの入力ノードに対して開始されます。

メッセージ・フローに組み込んだノードは、各ノードで定義した機能に応じて、メッセージの特定の処理を提供します。 ノードが実行する処理には内部作業が含まれ、それらの中には、ノード・プロパティーを構成することによって、影響を与えることができるものもあります。 一部のノードは、メッセージ・フローまたはブローカーの外部のシステムに影響を与える可能性のある追加タスクを実行します。

データベースなどの外部システムが、コミットおよびロールバックの概念をサポートし、ブローカー・トランザクションに参加できる場合、ノードが実行する作業がフロー・トランザクションに含まれるようにノードを構成することができます。 ノードによっては、トランザクションをサポートする外部システムで実行された作業が、即時にコミットされるか、メッセージ・フロー・トランザクションの完了時にコミットされるかを指定することもできます。

メッセージ・フローが対話できるリソースの多くが、 例えば、データベース、WebSphere MQ メッセージおよびキュー、および JMS メッセージなどの、整合されたトランザクションに参加できるリソース・マネージャーによって制御されます。 その他のリソース・マネージャーは、例えば、HTTP プロトコルおよびファイル・システムなどのトランザクション・サポートを提供しません。

コミットまたはロールバック

リソースがトランザクションに参加できる場合は、リソースが実行する作業が、メッセージ・フロー完了時にのみ、またはノード完了時にコミットまたはロールバックされるようにリソースを構成できます。 データベースおよび WebSphere MQ キューは、このような方法で使用できるリソースの例です。 リソースにトランザクション動作がない場合、リソースが実行する作業はすべて即時にコミットされます。 例えば、 ファイルおよび HTTP 接続はトランザクションをサポートしません。

メッセージ・フローによって行われる更新は、フローが入力メッセージを正常に処理したときにコミットされます。 次の条件が両方とも満たされた場合に更新はロールバックされます。

分散システムでは、メッセージ・フロー・トランザクションは、デフォルトではブローカーによって管理されます。 これらのトランザクションは、「ブローカー整合トランザクション」または「部分整合トランザクション」と呼ばれます。 フローが処理を終了した際に制御が入力ノードに戻ると、ノードは実行された操作をコミットまたはロールバックします。ただし、自身のコミットおよびロールバックを実行するように構成された個別のノード、 またはこのオプションをサポートしていない個別のノードは除きます。

複数のリソースがメッセージ・フローによってアクセスされると、エラーが発生し、すべてのリソースが、実行されたすべての作業をコミットできなくなる可能性があります。 ブローカーは例外を出し、関係するトランスポートによって決定された方法で例外処理を処理します。 例えば、WebSphere MQ キューから読み取られたメッセージは、それらのキューに復元され、障害メッセージが、メッセージを実行依頼したアプリケーションに HTTP 経由で送信されます (HTTP にはロールバックの概念がないため)。 これらのアクションのために、リソースの状況の整合性がなくなる可能性があります。

データおよび操作が整合性を保つことが重要で、すべての操作がコミットされるか、1 つ以上の操作が失敗したときはロールバックされることが重要な場合は、メッセージ・フローのアクティビティーを調整することができます。 調整は、リソース・マネージャーとの対話に XA プロトコルを使用する外部トランザクション・マネージャーによって提供されます。 トランザクション・マネージャーは、メッセージ・フローが正常に、またはエラーを出して終了した際に入力ノードによって呼び出されます。 入力ノードおよびブローカーではなく、トランザクション・マネージャーが、関連するリソース・マネージャーと対話して、リソースごとに正しいアクションを開始します。 トランザクション・マネージャーによってこのように制御されるトランザクションは、「グローバル整合トランザクション」と呼ばれます。

z/OS® では、トランザクションが常にグローバルに整合されます。 このオプションのために選択または構成する必要はありません。

ブローカーのトランザクション・モデルについて詳しくは、トランザクション・モデルを参照してください。

トランザクション・マネージャーの役割

メッセージ・フローが実行するアクションの結果は、メッセージ・フローがすべてのアクションで成功した場合、部分整合トランザクションおよびグローバル整合トランザクションのいずれの場合でも同じです。 グローバル整合トランザクションの利点は、すべてのアクションを確実にコミットさせるか、まったくコミットさせないようにすることができる点です。

2 フェーズ・コミット・ストラテジーを操作する 外部トランザクション・マネージャーは、1 つ以上の外部リソース・マネージャーが、コミット処理中に一時的に選択できなくなるケースをサポートしています。 障害の際に発生する可能性のあるこの短い期間は、ビジネス環境にとって高コストとなる場合があります。外部トランザクション・マネージャーは、この障害期間の発生を防ぐのに役立ちます。 したがって、 外部トランザクション・マネージャーを組み込むかどうかは、パフォーマンス・オーバーヘッドにも関係し、メッセージ・フローの設計時に行うのではなく、管理上の決定です。

外部トランザクション・マネージャーを使用すれば、 メッセージ損失が防止されるわけではありません。トランザクション整合を使用する場合でも、可能な限り、潜在的なエラーを処理するメッセージ・フローを構成およびコーディングする必要があります。

メッセージ・フローがグローバルに整合されるように構成するためには、サポート済みのトランザクション・マネージャーに対してリソース・マネージャーが定義されるように環境をセットアップする必要があります。

この構成では、 トランザクション・マネージャーの設定変更、およびリソース・マネージャーの参加が必要な場合があります。

データベース・アクセスのモードおよびロック

同じメッセージ・フローの中に、「自動」のトランザクション状況のノードと、「コミット」のトランザクション状況のノードを含める場合、両方のノードが同じ外部データベースに対して操作を行うときは、別個の ODBC 接続を使用する必要があります。 1 つの接続をメッセージ・フローが完了するまでコミットしないノード用にセットアップし、もう一方の接続を即座にコミットするノード用にセットアップします。

Linux platformUNIX platformWindows platformz/OS 以外のシステムでは、このモードの操作をサポートしないリレーショナル・データベースが存在する可能性もあります。

同じデータ・ソースに複数の ODBC 接続を定義すると、データベース・ロックの問題が発生することがあります。 特に、「自動」のトランザクション状況のノードが、データベース・オブジェクト (表など) をロックする操作 (INSERT または UPDATE など) を実行し、後続のノードが別の ODBC 接続を使ってこのデータベース・オブジェクトへのアクセスを試みると、無限ロック (デッドロック) が生じます。

2 番目のノードは、最初のノードが獲得したロックが解放されるのを待ちますが、最初のノードは、メッセージ・フローが完了するまで、操作をコミットすることも、ロックを解放することもありません。 ただし、最初のノードによって保持されているデータベース・ロックの解放を 2 番目のノードが待っているため、フローは完了できません。

このような状況を DBMS のデッドロック自動回避ルーチンで検出することはできません。 というのは、2 つの操作はブローカーを使って間接的に干渉し合っているからです。

このタイプのロックの問題を回避するには、以下の 2 つのオプションのいずれかを使用できます。

特定の操作によってロックされるデータベース・オブジェクトについて、およびデータベースのロック・タイムアウト・パラメーターを構成する方法については、ご使用のデータベース製品の資料をご覧ください。

メッセージ・フロー内のトランザクションの例

以下の例は、グローバルに整合されたトランザクションの使用法を示すと共に、データベース更新が整合された場合のメッセージ・フロー (メイン・フロー) と、整合されない場合のメッセージ・フロー (エラー・フロー) の相違を示します。

サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:21


概念トピック概念トピック | バージョン 8.0.0.5 | ac00645_