X/Open 分散トランザクション処理のモデル

X/Open 分散トランザクション処理 (DTP) のモデルには、分散トランザクションの処理方法を制御する、いくつかの互いに関連するコンポーネントが含まれます。

それらのコンポーネントには、以下のものが含まれます。

  • アプリケーション・プログラム (AP)
  • トランザクション・マネージャー (TM)
  • リソース・マネージャー (RM)

図 1 は、このモデルを示しており、これらのコンポーネント間の関係を示しています。

図1: X/Open 分散トランザクション処理 (DTP) モデル
アプリケーション・プログラム、リソース・マネージャー、およびトランザクション・マネージャーの間の相互作用。

アプリケーション・プログラム (AP)

アプリケーション・プログラム (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 モニターからは、以下のタイプのトランザクションが可能です。

  • XA 以外のトランザクション

    これらのトランザクションには、TM に対して定義されていない RM が関係しているため、 TM の 2 フェーズ・コミット・プロトコルの下では調整されません。 アプリケーションで XA インターフェースをサポートしていない RM にアクセスする必要がある場合は、 この調整が必要になります。 TP モニターは、 単にアプリケーションの効率的なスケジューリングと負荷バランス調整を提供するだけです。 TM は XA 処理のために RM を明示的に「オープン」することはないため、 RM はこのアプリケーションを、 非 DTP 環境で実行される他のアプリケーションと同じようにして処理します。

  • グローバル・トランザクション

    これらのトランザクションは、TM に対して定義されている RM が関係しているため、 TM の 2 フェーズ・コミットによって制御されます。 グローバル・トランザクションとは、1 つまたは複数の RM が関係する作業単位のことです。 トランザクション・ブランチ とは、 TM と RM との間のグローバル・トランザクションをサポートする部分のことです。 TM によって調整されるアプリケーション・プロセスが複数の RM にアクセスする場合は、 1 つのグローバル・トランザクションに複数のトランザクション・ブランチが存在します。

    個々のアプリケーション・プロセスが、TM の調整下にありながら、 あたかも別々のグローバル・トランザクションに属しているかのように複数の RM にアクセスする場合は、 疎結合のグローバル・トランザクションが存在しています。 個々のアプリケーション・プロセスごとに、 RM 内にそれぞれ固有のトランザクション・ブランチがあります。 いずれかの AP、TM、または RM によりコミットまたはロールバックが要求されると、 トランザクション・ブランチはすべて完了します。 分岐間でリソース・デッドロックが発生しないように担当するのは、アプリケーションです。 (SYNCPOINT(TWOPHASE) オプションを指定して作成されたアプリケーションに対して Db2 トランザクション・マネージャーが実行するトランザクション調整は、 大まかにいってこの疎結合のグローバル・トランザクションと同等であることに注意してください。)

    複数のアプリケーション・プロセスが RM 内の同じトランザクション・ブランチの下で作業を分担している場合は、 密結合グローバル・トランザクションが存在しています。 これら 2 つのアプリケーション・プロセスは、RM からは単一のエンティティーと見なされます。 RM では、トランザクション・ブランチの中でリソースのデッドロックが発生しないようにする必要があります。

トランザクション・マネージャー (TM)

トランザクション・マネージャー (TM) は、 トランザクションに ID を割り当て、進行状況を監視し、 トランザクションの完了と障害時の処理を実行します。 トランザクション・ブランチ ID (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_commitxa_rollback の どちらを実行するよう RM に通知するべきかを判断します。 管理者のヒューリスティック操作により、 RM が未確定トランザクションの分岐をすでにコミットまたはロールバックしていた場合、 TM はその RM に対して xa_forget 呼び出しを発行して、 再同期操作を完了します。

ユーザー・アプリケーションからコミットまたはロールバック要求を出すときは、 関係するすべての RM 間のコミットまたはロールバックの調整を TM が行えるようにするため、 TP モニターまたは TM で提供されている API を使用する必要があります。 例えば、 WebSphere® アプリケーションがトランザクションをコミットする要求を発行すると、 WebSphere XA TM は、 xa_endxa_preparexa_commit、または xa_rollback などの XA 呼び出しを発行して、RM にトランザクションのコミットまたはロールバックを要求します。 RM が 1 つしか関係していない場合、 または分岐が読み取り専用であるという応答が RM から返ってきた場合には、 TM は 2 フェーズ・コミットではなく 1 フェーズ・コミットを使用できます。

リソース・マネージャー (RM)

リソース・マネージャー (RM) は、 データベースなどの共有リソースへのアクセスを提供するものです。

Db2 システムは、データベースのリソース・マネージャーとして、 XA 準拠の TM によって調整されているグローバル・トランザクション に参加できます。 XA インターフェースによって必要とされるものとして、データベース・マネージャーには db2xa_switch が用意されています。これは、XA スイッチ構造体を TM に戻すために使う xa_switch_t 型の外部 C 変数です。 このデータ構造体には、 TM が呼び出すさまざまな XA ルーチンのアドレスと RM の操作特性とが入れられます。

RM が個々のグローバル・トランザクションへの参加を登録する方法には、 静的登録動的登録 の 2 つがあります。

  • 静的登録の場合、特定の RM がトランザクションで使用中かどうかに関係なく、 サーバー・アプリケーションに定義されているすべての RM に対して、 TM は xa_startxa_end、 および xa_prepare の 一連の呼び出しを (各トランザクションごとに) 発行する必要があります。 すべての RM がすべてのトランザクションに関係しているわけではない場合、 これは非効率であり、定義されている RM の数に比例して、 効率は低下します。
  • 動的登録 (Db2 で使用される) は、柔軟で効率の良いものです。 RM は、リソース要求を受信した場合に限り、 ax_reg を使用して TM に登録します。 この方法だと、RM が 1 つしか定義されていない場合、またはすべての RM が すべてのトランザクションで使用されている場合であっても、 TM での ax_reg 呼び出しと xa_start 呼び出しのパスが類似しているため、パフォーマンス上不利な点はありません。

XA インターフェースでは、TM と RM との間の双方向通信が提供されます。 これは、2 つの DTP ソフトウェア・コンポーネントの間のシステム・レベルのインターフェースであり、 アプリケーション開発者がコーディングする普通のアプリケーション・プログラム・インターフェースではありません。 ただし、アプリケーション開発者は、 DTP ソフトウェア・コンポーネントに関連したプログラミング上の制限事項に通じている必要があります。

XA インターフェースは一定ですが、XA 準拠の各 TM では、 RM が製品固有の方法で組み込まれている場合があります。 ご使用の Db2 製品をリソース・マネージャーとして特定のトランザクション・マネージャーに組み込む方法については、 該当する TM 製品の資料を参照してください。