Part1　トランザクション管理とは何か

TPモニターの歴史とアプリケーションサーバー

　ここで，簡単にトランザクション管理の歴史を振り返っておきましょう。

　多くのユーザーからのトランザクション要求が短時間に集中するオンライン処理では，それぞれのトランザクションを，矛盾なく，高い信頼性を保ったまま，高速に処理しなければなりません。この目的のために開発されたトランザクション管理用ソフトを「TPモニター」(またはトランザクション・モニター）と呼びます。

　TPモニターの歴史は古く，上で述べたDTPモデルが規定される以前から，メインフレーム用の製品が存在しました。例えば，1969年に米IBMは，TPモニター「CICS(Customer Information Control System)」の提供を始めました。

　当時は，企業向けアプリケーションのほとんどはメインフレームOS上に構築されており，アプリケーションレベルで，プロジェクトごとに個別にトランザクション管理を実装するのが一般的でした。しかしIBMのCICSの登場をきっかけに，他のメインフレームベンダーも，それぞれのOS上のTPモニターを提供し始め，TPモニターの普及が加速しました。ただし，当時のTPモニターの機能やAPIは，ベンダー独自の仕様に基づいて実装されていました。

　その後，メインフレームからオープンへという流れの中で，オープンな分散環境でミッションクリティカルなシステムを実装するために，UNIX上のTPモニターとして「Tuxedo（タキシード）」，「Encina」，「TOP END」などが登場しました。このうちTuxedoは，先に述べたDTPモデル（XAインタフェース，TXインタフェース）の「リファレンス実装」として，仕様の策定に大きく貢献しました。Tuxedoは，「UNIX上でAT&Tの社内業務システムを開発するプロジェクト」が起源となって発展した製品で，1983年にAT&Tベル研究所で開発がスタートし，1989年に商用のTPモニター製品として出荷が開始されました。

　現在，各社から提供されているほとんどのリソースマネージャ（RDBMSやメッセージングシステム）はXAインタフェースをサポートしています。また，オープン環境用のほとんどのTPモニター（トランザクションマネージャ）も，XAインタフェースとTXインタフェースに対応しています。企業アプリケーションの開発者は，こうしたDTPモデルに準拠したTPモニターとリソースマネージャを利用することで，リソースの種類に依存せずにビジネスロジックに特化した開発が可能になります。

　なお，Javaを利用したアプリケーション開発では，Java EE（Java Platform,Enterprise Edition）アプリケーションサーバーが，トランザクションマネージャの役割を担います。Java EEでは，上で述べたDTPモデルをベースにした分散トランザクション用APIである「JTA (Java Transaction API)」を規定しています（図3）。

図3●JTA (Java Transaction API)

JTAは，(1)アプリケーションが明示的にトランザクション境界を設定するためのインタフェース（ javax.transaction.UserTransaction ），(2)アプリケーションサーバーがトランザクション境界の設定のためにトランザクションマネージャと通信するインタフェース（javax.transaction.TransactionManager），(3)トランザクションマネージャがXAに準拠したリソースマネージャと連係するためのインタフェース（javax.transaction.xa.XAResource）などを定めている。

[画像のクリックで拡大表示]

2フェーズコミットとは

　最後に，2フェーズコミットについて説明しましょう。2フェーズコミットは，複数のリソースマネージャにまたがるトランザクション(グローバルトランザクション）のトランザクション特性(ACID）を保証するための仕組みです。

　2フェーズコミットには，第1フェーズ（準備フェーズ）と第2フェーズ（コミットフェーズ）という2つのフェーズが存在します。DTPモデルの場合，以下のような流れになります。

　まず，アプリケーションからトランザクションマネージャに発行されるcommit要求により，2フェーズコミットが開始されます。トランザクションマネージャは，各リソースマネージャにxa_prepare要求を発行し，リソースマネージャが更新処理をコミット（終了）できる状態かどうかを確認します。コミットできる状態であれば，トランザクションマネージャにxa_okを返します。すべてのリソースマネージャからxa_okを受け取ったトランザクションは，トランザクション識別子(Xid）と関連するリソースマネージャの一覧情報を含んだ「トランザクション・ログ」をディスクに書き込みます。ここまでが準備フェーズです。

　準備フェーズが終わったら，トランザクションマネージャが各リソースマネージャにxa_commit要求を発行し，リソースマネージャが実際に更新処理をコミットします。すべてのリソースマネージャから終了の応答(xa_ok)を受け取ることにより，グローバルトランザクションは正常終了となります。

　リソースマネージャは，トランザクションマネージャからのxa_commit要求を受け取るまで，更新の準備状態のままデータをロックし続けます(図4）。この間，ほかのトランザクションはそのデータを更新できません。

図4●XAインタフェースを使った２フェーズコミット（正常終了の場合）

[画像のクリックで拡大表示]

　リソースマネージャが一つしかない場合や，複数のリソースマネージャの中で更新処理が必要なリソースマネージャが一つしかない場合（それ以外のリソースマネージャがすべて読み込みのみ＝Read Onlyの場合），トランザクションマネージャは，xa_prepare要求を省略した「1フェーズコミット」を実行します。つまり，準備フェーズを省いて，コミットフェーズだけを実行します。なお，「Read Onlyの1フェーズコミット」やトランザクション・ログのアクセスロジックなど最適化に関する機能は，トランザクションマネージャの実装に依存します。

　実社会でも，「仮」状態を作るとスムーズに物事が進むことがあります。例えば，会社で会議を行なっている最中に次回の日時を選定するとしましょう。その場にいないA氏（次回のテーマでは重要人物）がいる場合，参加者の都合がいい候補日時を「仮」に選んでおいて，後でA氏のスケジュールを確認後に「本」決定する手順になるでしょう。

　2フェーズコミットでも，「仮決め」(準備フェーズ）のときは，リソースのデータを変更したり，削除したりしません。もし「仮決め」をせずに，RDBMSなどのリソースマネージャのデータを実際にコミット（変更や削除）してしまうと，その後，他のリソースマネージャのコミットが失敗したときに，リソースマネージャ間でデータの「不整合」が起こってしまいます。これを防ぐために，「仮決め」のフェーズを設けているわけです。