X/Open 分散トランザクション処理 (DTP) のモデルには、 次のような互いに関連する 3 つの構成要素があります。
図 43 は、このモデルと 3 つの構成要素の相互関係を示しています。
図 43. X/Open 分散トランザクション処理 (DTP) のモデル
![]() |
アプリケーション・プログラム (AP) は、トランザクション境界を定義し、 トランザクションを構成するアプリケーション固有のアクションを定義します。
たとえば、CICS アプリケーション・プログラムでデータベース や CICS 一時データ待ち行列などのリソース・マネージャー (RM) にアクセスし、 プログラミング論理を使用してデータを操作できます。 それぞれのアクセス要求は、その RM に固有の関数呼び出しによって、 適切なリソース・マネージャーに渡されます。 DB2 の場合、このような呼び出しは、各 SQL ステートメントごとに DB2 事前コンパイラーが生成した関数呼び出し、 または、プログラマーが API を使用して直接コーディングしたデータベース呼び出しとすることができます。
トランザクション・マネージャー (TM) 製品には、通常、 ユーザーのアプリケーションを実行するためのトランザクション処理 (TP) モニターが含まれています。 TP モニターには、アプリケーションがトランザクションを開始および終了したり、 アプリケーションのスケジューリングを実行したり、 そのアプリケーションを実行する多くのユーザーの間で負荷バランス調整を実行するための API が用意されています。 分散トランザクション処理 (DTP) 環境のアプリケーション・プログラムは、 実際にはユーザー・アプリケーションと TP モニターの組み合わせです。
効率的なオンライン・トランザクション処理 (OLTP) 環境を容易にするため、 TP モニターは起動時に複数のサーバー・プロセスを事前に割り当て、 スケジューリングを実行して、多数のユーザー・トランザクション間でこれらのプロセスを再使用します。 これによって、 より少ない数のサーバー・プロセスおよびそれらに対応する RM プロセスを使って より多くの並行ユーザーをサポートすることが可能になり、 システム・リソースの節約になります。 これらのプロセスを再使用すれば、ユーザー・トランザクションまたはプログラムごとに、 TM と RM でのプロセスを起動する場合のオーバーヘッドを回避することもできます。 (1 つのプログラムで 1 つまたは複数のトランザクションが呼び出されます。) このことは、TM および RM にとってはこれらのサーバー・プロセスが実際の 「ユーザー・プロセス」になるということも意味します。 このことは、機密保護管理やアプリケーション・プログラミングにも関係します。 詳しくは、機密保護についての考慮事項を参照してください。
TP モニターからは、以下のタイプのトランザクションが可能です。
これらのトランザクションには、TM に対して定義されていない RM が関係しているため、 TM の 2 フェーズ・コミット・プロトコルの下では調整されません。 アプリケーションで XA インターフェースをサポートしていない RM にアクセスする必要がある場合は、 この調整が必要になります。 TP モニターは、 単にアプリケーションの効率的なスケジューリングと負荷バランス調整を提供するだけです。 TM は XA 処理のために RM を明示的に「オープン」することはないため、 RM はこのアプリケーションを、 非 DTP 環境で実行される他のアプリケーションと同じようにして処理します。
これらのトランザクションは、TM に対して定義されている RM が関係しているため、 TM の 2 フェーズ・コミットによって制御されます。 大域トランザクションとは、1 つまたは複数の RM が関係する作業単位のことです。 トランザクション分岐 とは、 TM と RM との間の大域トランザクションをサポートする部分のことです。 TM によって調整される 1 つまたは複数のアプリケーション・プロセスによって複数の RM がアクセスされる場合は、 1 つの大域トランザクションに複数のトランザクション分岐が存在するようになる可能性があります。
個々のアプリケーション・プロセスが、TM の調整下にありながら、 あたかも別々の大域トランザクションに属しているかのように複数の RM にアクセスする場合は、 疎結合の大域トランザクションが存在しています。 個々のアプリケーション・プロセスごとに、 RM 内にそれぞれ固有のトランザクション分岐があります。 いずれかの AP、TM、または RM によりコミットまたはロールバックが要求されると、 トランザクション分岐はすべて完了します。 分岐間でリソース・デッドロックが発生しないようにするのは、 アプリケーション側の責任です。 (SYNCPOINT(TWOPHASE) オプションを指定して作成されたアプリケーション に対して DB2 トランザクション・マネージャーが実行するトランザクション調整は、 大まかにいってこの疎結合の大域トランザクションと同等であることに注意してください。 複数のデータベースの更新を参照してください。)
複数のアプリケーション・プロセスが RM 内の同じトランザクション分岐の下で作業を分担している場合は、 密結合大域トランザクションが存在しています。 これら 2 つのアプリケーション・プロセスは、RM からは単一の実体とみなされます。 RM では、トランザクション分岐の中でリソースのデッドロックが発生しないようにする必要があります。
トランザクション・マネージャー (TM) は、 トランザクションに識別子を割り当て、進行状況を監視し、 トランザクションの完了と障害時の処理を実行します。 トランザクション分岐識別子 (XID と呼ばれるもの) は TM によって割り当てられ、 大域トランザクションと RM 内部の固有の分岐の両方を識別するものとなります。 これは、TM のログと RM のログの間の相関トークンです。 XID は、2 フェーズ・コミットまたはロールバックのさいに、 システム始動時の再同期化 操作 (resync ともいう) を行ったり、 または必要に応じて、 管理者が発見的手法 の操作 (手動介入 ともいう) を実行する場合に必要です。
TP モニターを始動すると、 TP モニターは一連のアプリケーション・サーバーによって定義されているすべての RM をオープンするよう TM に要請します。 TM は RM に対して xa_open 呼び出しを渡し、 RM が DTP 処理のために初期設定されるようにします。 TM は、この始動プロシージャーの一環として再同期化を実行し、 すべての未確定トランザクション を回復します。 未確定トランザクションとは、 不確かな状態のままになっている大域トランザクションのことです。 これが発生するのは、 2 フェーズ・コミット・プロトコルの最初のフェーズ (つまり準備フェーズ) が正常完了した後に、 TM (または少なくとも 1 つの RM) が使用不能になるときです。 RM のログが再度使用可能になって TM が自身のログと RM のログとを 整理調整するまで、RM はトランザクションの分岐に対して コミットとロールバックのどちらを実行すればよいのかを識別できません。 再同期操作を実行するため、 TM は個々の RM に対して xa_recover 呼び出しを 1 回または複数回発行して、 すべての未確定トランザクションを識別します。 TM は、それらの応答と自身のログ情報とを比較して、 トランザクションに関して xa_commit と xa_rollback の どちらを実行するよう RM に通知すべきかを判断します。 管理者の発見的手法の操作により、 RM が未確定トランザクションの分岐をすでにコミットまたはロールバックしていた場合、 TM はその RM に対して xa_forget 呼び出しを発行して、再同期操作を完了します。
ユーザー・アプリケーションからコミットまたはロールバック要求を出すときは、 関係するすべての RM 間のコミットまたはロールバックの調整を TM が行えるようにするため、 TP モニターまたは TM で提供されている API を使用する必要があります。 たとえば、 CICS アプリケーションが CICS SYNCPOINT 要求を発行してトランザクションをコミットすると、 今度は CICS XA の TM (Encina Server に実装されている) が、 xa_end、 xa_prepare、 xa_commit、または xa_rollback などの XA 呼び出しを発行して、 トランザクションをコミットまたはロールバックするよう RM に要求します。 RM が 1 つしか関係していない場合、 または分岐が読み取り専用であるという応答が RM から返ってきた場合には、 TM は 2 フェーズ・コミットではなく 1 フェーズ・コミットを使用できます。
リソース・マネージャー (RM) は、データベースなどの共有リソースへのアクセスを提供するものです。
DB2 は、データベースのリソース・マネージャーとして、 XA 準拠の TM によって調整されている大域トランザクション に参加できます。 XA インターフェースに必要なものとして、データベース・マネージャーには、 XA スイッチ構造体を TM に戻すために使う xa_switch_t 型の外部 C 変数 db2xa_switch が用意されています。 このデータ構造体には、 TM が呼び出すさまざまな XA ルーチンのアドレスと RM の操作特性とが入れられます。 データベース・マネージャーでサポートされている XA 関数については、サポートされている XA 関数を参照してください。
RM が個々の大域トランザクションへの参加を登録する方法には、 静的登録 と動的登録 の 2 つがあります。
XA インターフェースでは、TM と RM との間の 2 方向通信が提供されます。 これは、2 つの DTP ソフトウェア構成要素の間のシステム・レベルのインターフェースであり、 アプリケーション開発者がコーディングする普通のアプリケーション・プログラム・インターフェースではありません。 ただし、アプリケーション開発者は、 DTP 構成要素に関連したプログラミング上の制限事項に通じている必要があります。 X/Open XA インターフェース・プログラミングの考慮事項については、 アプリケーション開発の手引き を参照してください。
XA インターフェースは一定ですが、XA 準拠の各 TM では、 RM が製品特有の方法で組み込まれている場合があります。 ご使用の DB2 製品をリソース・マネージャーとして特定のトランザクション・マネージャーに組み込む方法については、 該当する TM 製品の資料を参照してください。 一般的な TP モニターに関する組み込み情報は、 DB2 UDB を使用するよう XA トランザクション・マネージャーを構成するを参照してください。