JP2010157202A - 分散トランザクション回復システムおよび方法 - Google Patents

Abstract

【課題】分散コンピューティング環境におけるトランザクション回復を改善すること。
【解決手段】一構成では、本発明は、分散コンピューティング環境におけるトランザクション回復のためのシステムを含む。システムは、トランザクションログサーバと、アプリケーションサーバと、リソースサーバとを含む。トランザクションログサーバは、共用トランザクションログを保存する。アプリケーションサーバは、分散トランザクションアプリケーションを実施し、分散トランザクションアプリケーションを使用してトランザクションを実行する場合に共用トランザクションログにアクセスする。リソースサーバは、データを保存し、トランザクションに従ってデータにアクセスするためにアプリケーションサーバとともに動作する。アプリケーションサーバの１つが故障した場合、それまでは故障アプリケーションサーバによってアクセスされていた共用トランザクションログ部分に対する責任を別のアプリケーションサーバが引き受ける。
【選択図】図4

Description

本発明は、トランザクション回復性(transactional recoverability)に関し、詳細には、分散コンピューティング環境におけるトランザクション回復性に関する。

本明細書で別段の指摘がない限り、本セクションで説明される手法は、本出願の特許請求の範囲の先行技術ではなく、本セクションに含まれることによって先行技術であると認められることはない。

今日の多くの企業では、企業アプリケーションは、企業の内部または外部に存在する多数の分散リソースを利用している。これらのリソースは、データベース、メッセージングシステムとすることができ、または外の世界にサービスを提供するアプリケーションとすることさえできる。

多くのシナリオでは、そのようなシステムにおける更新は、トランザクション方式で行われることが望ましい。これは基本的に、更新がACID基準(原子性(atomicity)、一貫性(consistency)、隔離性(isolation)、永続性(durability))に準拠しなければならないことを意味する。原子性は、分散リソースにおける変更がすべてのリソースで実行されるか、さもなければどのリソースでも実行されないことを意味する。一貫性は、トランザクションが終了したときに、これらのリソース間の整合性制約が有効でなければならないことを意味する。隔離性は、トランザクションの外部のどの操作も中間状態を見るべきではないことを意味する。永続性は、トランザクションが正常終了したならば、それは持続し、元に戻されることがないことを意味する。

これらの基準は今日、企業内で一般的なほぼすべてのリソースによって満たされている。単一のトランザクションにおいて、１つの口座から金銭を引き出し、それを別の口座に預け入れることを求められる、データベース管理システム(DBMS)には、上で概略を述べたACID規則に従って、これを完全に行うことを期待することができる。DBMS自体は、トランザクションを完全に管理しており、トランザクションマネージャでもあり、トランザクションマネージャによって管理されるリソースでもある。

トランザクションが多数のリソースにまたがらなければならない場合、状況は根本的に変化する。アプリケーションサーバは、トランザクションマネージャとなり、すべてのリソースは、このトランザクションマネージャに従属するようになる。トランザクションの全体的な状態は今では、関与するすべてのリソースマネージャにわたって分散しているので、トランザクション全体が一貫性をもたない時間がいくらか存在する。

この非一貫性は、回避できるようなものではなく、分散システムの性質そのもののうちにある。そのため、トランザクション作業またはその部分を実行しているシステムがクラッシュした場合、非一貫性が持続する。1つのリソースの変更は完了したが、第2のリソースについては未完了の時点で、アプリケーションサーバがクラッシュした場合を、そのような状況の一例とすることができる。

これらの問題を克服するため、トランザクション回復戦略を使用することができる。トランザクションに関与するシステムが再び利用可能になった場合、アプリケーションサーバ内のトランザクション回復機能は、トランザクションをトリガしたアプリケーションに約束したことを覚えている。アプリケーションサーバは、トランザクションの各リソース部分の結果についてリソースを照合し、一貫性のある状態を達成しようと試みる。一貫性のある状態を達成できない場合、アプリケーションサーバは、関与するリソース間におけるこの非一貫性についてオペレータに通知する。そこで、少なくとも問題が識別される。

トランザクション回復性機能がないと、分散トランザクションが使用されている場合、顧客データは誤ったものになる可能性が非常に高い。それがJava(登録商標)アプリケーションサーバの現行アーキテクチャにおいて見られる状況である。Java Transaction Processingという書籍で説明されているように、「アプリケーションサーバのなかには(今日では、これは概ね、企業品質のサーバではなく、実験的またはオープンソースプロジェクトに当てはまる)、回復機能を提供しないものがあり、トランザクションを必要とする多数の回復可能リソースと対話するアプリケーションにそれらを使用すべきではない」。Mark Little他、Java Transaction Processing (Prentice Hall PTR 2004)を参照されたい。

トランザクション回復の実施は、アプリケーションサーバにとって根本的な変更である。新しい回復機能を作成し、使用することができる。加えて、リソースを実施する方法を変更することもできる。これは、サーバ内のJava(登録商標)メッセージングシステムプロバイダ、トランザクションマネージャ、JDBC(Java(登録商標)データベースコネクティビティ) DB(データベース)プールサービス、およびJavaコネクタコンテナなど、他のシステムに対するさらなる修正を必要とすることもある。

アプリケーションサーバと、それと一緒に(アプリケーションサーバの一部であった)トランザクションマネージャが、ともにクラッシュした場合、トランザクションに関与したリソースは、単独でとり残される。まだ保留中のトランザクションが存在しているので、リソースのこの孤立は危険であり、ある時間の後、リソースは、それが関与したトランザクションの一部をコミットするか、それともロールバックするかを決定する。この決定は、トランザクションマネージャの当初の意向に従うこともあり、または従わないこともあり、いわゆる発見的決定(heuristic decision)である。そのため、可能である限り、発見的決定は回避されなければならない。

分散コンピューティング環境は一般に、多くの層(tier)を含み、各層は、1つまたは複数のコンピューティング装置を有する。例えば、2層アーキテクチャは、クライアント層と、サーバ層を含むことができ、各層には、多数のクライアント装置および多数のサーバ装置が含まれる。3層アーキテクチャは、クライアント層と、アプリケーションサーバ層と、データベースサーバ層を含むことができる(さらに各層には、多数のコンピューティング装置が含まれる)。

アプリケーションサーバ層は、アプリケーションサーバクラスタと呼ばれることもある。アプリケーションサーバクラスタは、分散リソースにわたってトランザクションを実行することができる多くのサーバノードから成ることができる。アプリケーションサーバは、Java(登録商標) Enterprise Edition、Microsoft .NET(商標)環境などのコンピューティング環境を実施することができる。

データベースサーバ層は、リソース層と呼ばれることもある。アプリケーションサーバ上に存在するアプリケーションは、トランザクション方式で(リソース層の)異なるリソースを使用することができる。リソースの例は、データベースシステム、メッセージングシステム、および企業情報システムである。

トランザクションを制御するアプリケーションサーバの部分は、トランザクションマネージャ(TM)と呼ばれる。これらの分散リソースにわたるトランザクションを組織化するためにTMが使用するセマンティクスは、オープングループ(Open Group)のDTP(分散トランザクション処理) XA仕様によって記述することができる。

TMは、サーバ上に存在するアプリケーションに代わってトランザクションを管理する。これは、すべてのリソースを一貫性のある状態に保つ責任がTMにあることを意味する。トランザクションの全体的な状態は、関与するすべてのリソースマネージャにわたって分散しているので、トランザクション全体が一貫性をもたない時間がいくらか存在する。

この非一貫性は、回避できるようなものではなく、分散システムの性質そのもののうちにある。そのため、トランザクション作業(またはその部分)を実行しているシステムがクラッシュした場合、非一貫性が持続する。1つのリソースの変更は完了したが、第2のリソースについては未完了の時点で、アプリケーションサーバノードがクラッシュした場合を、そのような状況の一例とすることができる。アプリケーションサーバノードの1つまたは複数がクラッシュした場合、分散トランザクションは、不完全な状態に留まることがある。

そのようなトランザクションのあらゆる関与者がクラッシュし得るので、コミットまたはロールバックの決定を、各関与者が永続的ストアに書き込むことが必要である。このストアは、トランザクションログ(TLOG)と呼ばれる。

トランザクション処理は、オープングループのDTP XA仕様に従って行うことができる。この仕様は、トランザクションの完了を、準備フェーズとコミットフェーズの2つのフェーズに分割する。

2つの関与者が関わるトランザクション完了シーケンスが以下で説明される。リソース1は、リソースアダプタ1を用いてアプリケーションサーバに接続され、リソース2は、リソースアダプタ2を用いて接続される。各関与者は、独自のTLOGを有する。したがって、全体として、TMによって維持される1つと、それぞれのリソースマネージャによって制御されるさらに2つの、3つのTLOGが存在する。

トランザクション完了プロセスは以下のようになる。
1. アプリケーションが、トランザクションをコミットするようアプリケーションサーバに求める。
2. アプリケーションサーバは、トランザクションを完了すべきことをTMに通知する。
3. TMは、トランザクション完了の第１フェーズを開始する。TMは、トランザクションを準備するよう第１リソースマネージャ(RM)に求める。
4. 第１RMはコミットすることができ、この意向を独自のトランザクションログに書き込むことができると仮定する。第１RMは、準備コールから戻り、TMに成功を伝える。
5. 第2のRMについても同じことが行われる。
6. TMは準備成功のリターンコードのみを受け取ると仮定するので、TMは、完了トランザクションのコミットを決定する。TMは、RMに働きかける前に、コミットの決定を独自のTLOGに書き込む。書き込み操作後、TMは、書き込み直後にクラッシュしたとしても、このトランザクションをコミットしようと試みる。
7. 第１RMは、コミットするよう求められる。通常、第１RMは、準備時間中にTMに与えた約束を履行して、何の問題もなくコミットすべきである。
8. 第2のRMは、コミットするよう求められる。

準備コールが行われる以前の問題は、重大なものではない。ある時間の後、各関与者はトランザクションを放棄し、それが最終的に、一貫性のある状態を再びもたらす。

Java Transaction Processing (Prentice Hall PTR 2004) Weikum and Vossum、Transaction Information Systems、Chapter 19、Distributed Transaction Recovery (Academic Press 2002)

準備以後の問題は、より重大である。ステップ7以後であるが、ステップ8以前であるアプリケーションサーバクラッシュを、一例とすることができる。これは、そのトランザクションブランチをすでにコミットしたリソースマネージャ1と、準備状態にまだ留まっているリソースマネージャ2をもたらす。

この状況が持続した場合、リソースマネージャ2は、(ある時間の後)そのトランザクションブランチの結果について自ら決定する。リソースマネージャ2は、発見的決定を行う。多くの既存のリソースマネージャは、そのブランチをロールバックすることを決定する。これが行われた場合、トランザクション全体は一貫性をもたない。DTP XA仕様は、これを「発見的混合トランザクション結果(heuristic mixed transaction outcome)」と呼んでいる。

さらに、完了プロセスは、特にリソースマネージャが低速である場合に、しばらく時間が掛かることがある。低速なRM1を想定すると、2PC(2フェーズコミット)プロトコルの第2のフェーズ中に障害が発生した場合、トランザクション全体は一貫性をもたない。アプリケーションサーバの多くの現行の実施では、この非一貫性は見過ごされ、そのため、顧客データが誤ったものになり得る可能性がかなり高い。

既存のアプリケーションサーバは、その場合、回復サービスを使用して、これらの分散トランザクションの回復を試みる。

本発明の構成は、分散コンピューティング環境におけるトランザクション回復を改善する。一構成では、本発明は、分散コンピューティング環境におけるトランザクション回復のためのシステムを含む。システムは、トランザクションログサーバと、アプリケーションサーバと、リソースサーバとを含む。トランザクションログサーバは、共用トランザクションログを保存する。アプリケーションサーバは、分散トランザクションアプリケーションを実施し、分散トランザクションアプリケーションを使用してトランザクションを実行する場合に共用トランザクションログにアクセスする。リソースサーバは、データを保存し、トランザクションに従ってデータにアクセスするためにアプリケーションサーバとともに動作する。アプリケーションサーバの1つが故障した場合、それまでは故障アプリケーションサーバによってアクセスされていた共用トランザクションログ部分に対する責任を別のアプリケーションサーバが引き受ける。

一構成によれば、コンピュータプログラムが、分散コンピューティング環境におけるトランザクション回復を制御する。コンピュータプログラムは、上述されたように機能する、トランザクションログサーバと、アプリケーションサーバと、リソースサーバとを制御する。

一構成によれば、方法が、分散コンピューティング環境におけるトランザクション回復を制御する。方法は、上述されたように機能する、トランザクションログサーバと、アプリケーションサーバと、リソースサーバとを制御する。

以下の詳細な説明および添付の図面は、本発明の本質および利点についてのより良い理解を提供する。

本発明の一実施形態による、分散コンピューティング環境のブロック図である。 図１の分散コンピューティング環境の構成要素のいくつかをより詳細に示すブロック図である。 本発明の一実施形態による、2つのアプリケーションサーバと、トランザクションログサーバについてより詳細に示すブロック図である。 本発明の一実施形態による、分散コンピューティング環境にけるトランザクション回復の方法のフローチャートである。 本発明の一実施形態による、すべてのリソースマネージャが正常に準備を終えた時点を説明するアクティビティ図のフローチャートである。 本発明の一実施形態による、トランザクションマネージャがリターンコードをどのように処理するかについて略述するアクティビティ図のフローチャートである。 本発明の一実施形態による、1つの使用事例を示す図である。 本発明の一実施形態による、1つの使用事例を示す図である。 本発明の一実施形態による、1つの使用事例を示す図である。 本発明の一実施形態による、1つの使用事例を示す図である。 本発明の実施形態を実施するためのコンピュータシステムおよびネットワークの一例のブロック図である。

トランザクション回復のための技法が本明細書で説明される。以下の説明では、説明目的で、数多くの例および具体的な細部が、本発明の完全な理解を提供するために説明される。しかし、特許請求の範囲によって確定される本発明が、これらの例における特徴の一部または全部を単独で、または以下で説明される他の特徴と組み合わせて含み得ること、本明細書で説明される特徴および概念の修正物および均等物をさらに含み得ることが当業者には明らかであろう。

本発明の一実施形態は、単独の回復サービス手法を使用しない。代わりに、保留トランザクションを並列的に回復できる多数の回復サービスが適所に存在できる。これらの回復サービス間の衝突を回避するため、トランザクションログをいくつかの論理部分に分割することができ、各部分は多くても1つの回復サービスによってしか利用できない。

これは、より迅速な回復(最低負荷のノード上に存在する回復サービスが、親喪失トランザクションログを引き受ける競争に勝利する)と、より高いスループット(親喪失トランザクションログがいくつか存在する場合、それらは異なるノード上の異なる回復サービスによって並列的に処理される)をもたらす。

本発明の一実施形態は、生存中アプリケーションサーバノードのいずれかが、単独の回復ノードとしてクラスタの1つのメンバに専従することなく、これらの保留トランザクションを即座に回復できるアーキテクチャを定義する。

各アプリケーションサーバノードは、各々の開始時に新しい(論理)トランザクションログを生成する。このノードがクラッシュした場合、生存中ノード上にある回復サービスが、親喪失トランザクションログを引き受ける競争を行い、それに含まれるトランザクションを回復する。

したがって、トランザクションを並列的に回復できるいくつかの回復サービスが適所に並列的に存在できる。

本発明の一実施形態は、以下の特徴のうちの1つまたは複数を有することができる。1つの特徴は、アプリケーションサーバノードがクラッシュした場合、トランザクションの回復を迅速に行うことができることである。これは、発見的リソースマネージャ決定のリスクを増大させるどのような遅延をも回避するのに役立つ。これは、クラッシュノードの再開を待つのではなく、別の生存中アプリケーションサーバノード上で回復を実行することからもたらされる。別の特徴は、リソースマネージャが(おそらくはネットワーク停止またはリソースマネージャのクラッシュのために)一時的にトランザクション処理を実行できなくなった場合に、どのような保留トランザクションブランチでも可能な限り迅速に解決するために、トランザクションマネージャが、このリソースマネージャと連絡を取ろうと継続的に試みることができることである。即座の回復および保留トランザクションの解決というタスクはともに、本発明の一実施形態によれば、保留トランザクションリスト(PTL: Pending Transaction List)プロセッサと呼ばれることがある同じアプリケーションサーバサービスによって対処することができる。PTLプロセッサの動作を詳細に説明する前に、いくつかの背景が提供される。

図1は、本発明の一実施形態による、分散コンピューティング環境100のブロック図である。分散コンピューティング環境100は、クライアント層102と、アプリケーション層104と、データベース層106の、3つの層を有する。代替実施形態では、より多数または少数の層が存在してよく、説明に便利な一般的ケースを提供するので3つの層が示されている。

ネットワーク108は、層および特定の層内のコンピューティング装置を接続する。ネットワーク108は、2つの参照ブロックとして示されているが、そのような提示は、3つの層が与えられた場合の図説を目的としている。ネットワーク108がサブネットワーク(例えば、第１ローカルエリアネットワーク、第2のローカルエリアネットワーク、インターネットなど)を含んでよいこと、または他のネットワーク(図示されず)に接続できることを理解されたい。

クライアント層102は、1つまたは複数のクライアントコンピュータ112を含む。3つのクライアントコンピュータ112a、112b、112cが示されている。一般に、クライアントコンピュータ112は、ユーザインタフェースを提供し、分散コンピューティング環境100と対話するユーザの能力を増強する。

アプリケーション層104は、1つまたは複数のアプリケーションサーバ114を含む。3つのアプリケーションサーバ114a、114b、114cが示されている。一般に、アプリケーションサーバ114は、データアクセスのためにデータベース層106と、データの提示のためにクライアント層102と対話するアプリケーションプログラムを実行する。

データベース層106は、1つまたは複数のリソースサーバ116を含む。データベースサーバ116aと、メッセージングサーバ116bと、企業情報サーバ116cの、3つのリソースサーバ116が示されている。一般に、リソースサーバ116は、アプリケーションサーバ114によってアクセスされるデータを管理する。

一実施形態によれば、分散コンピューティング環境100は、Java(登録商標) Enterprise Edition環境に従って動作する。例えば、クライアントコンピュータ112は、アプリケーションサーバ114とJava(登録商標)フォーマットで情報を交換するウェブブラウザを実施することができる。アプリケーションサーバ114は、リソースサーバ116によって実行されるSQL(構造化問い合わせ言語)ステートメントを生成することができる。

トランザクションログサーバ120は、共用トランザクションログを維持し、以下でより詳細に説明される。

図2は、分散コンピューティング環境100のいくつかの構成要素をより詳細に示すブロック図である。アプリケーションサーバ114dと、リソースサーバ116d、116eと、ネットワーク108aと、トランザクションログサーバ120aが示されている。(図2の構成要素は、類似のラベルを有する図1の構成要素に対応している)。

一例として、アプリケーションサーバ114dは、株取引コンピュータプログラムを実施することができる。リソースサーバ116dは、ユーザの仲介口座に対応するデータを保存し、リソースサーバ116eは、ユーザの銀行口座に対応するデータを保存する。

トランザクションログサーバ120aは、共用トランザクションログ130を保存する。一実施形態によれば、トランザクションログサーバ120aは、データベースサーバであり、共用トランザクションログ130は、データベースサーバ(例えば、データベース管理システムすなわちDBMS)によって保存されるデータベース内のデータ構造である。一実施形態によれば、トランザクションログサーバ120aは、ファイルシステムサーバであり、共用トランザクションログ130は、ファイルシステムサーバによって保存されるデータファイルである。ファイルシステムサーバは、NAS(ネットワーク接続ストレージ)装置またはSAN(ストレージエリアネットワーク)装置などの記憶装置とすることができる。共用トランザクションログ130は、TLOG 130とも呼ばれることがある。

アプリケーションサーバ114dは、トランザクションマネージャ132と、PTLプロセッサ134とを含む。トランザクションマネージャ132は、アプリケーションサーバ114dによって実行されるトランザクションを管理する。例えば、上で説明された仲介業務の例を参照すると、トランザクションマネージャ132は、株購入取引の一連のステップ、例えば、銀行口座サーバと通信して、購入金額をロック(lock)するステップと、仲介サーバと通信して、購入する株の数量をロックするステップと、株購入がロックされた銀行口座サーバと通信して、銀行口座サーバが購入者の口座から仲介業者の口座へ金銭を移転できるようにするステップと、金銭が移転された仲介サーバと通信して、仲介サーバが仲介業者の口座から購入者の口座へ株を移転できるようにするステップを管理する。

(回復サービスとも呼ばれる)PTLプロセッサ134は、非集中化方式で2つの能力を組み合わせる。1つの能力は、アプリケーションサーバ114dの直近の始動以降に(PTLプロセッサ134が実施される)アプリケーションサーバ114d上で生成された保留トランザクションの回復である。別の能力は、クラッシュした他のアプリケーションサーバ114の遣り残しである保留トランザクションの回復である。

各アプリケーションサーバ114上で、1つのPTLプロセッサ134が実施される。1つのPTLプロセッサ134が他のPTLプロセッサと異なる必要はなく、例えば、環境全体のために機能するシングルトンPTLプロセッサは必要ではない。

一例として、アプリケーション層104内のノードのクラスタ(例えば、図1のアプリケーションサーバ114を参照)は、始動されているノード「a、b、c、d」から成ると仮定する。各ノードは保留トランザクションを有すると仮定する。すべてのノードの最初の始まりとしてこのように定めた場合、各ノードの各PTLプロセッサは、各PTLプロセッサが実施されているノードから発生したトランザクションだけの面倒をみている。

略記法「a:a(1)」は、ノード「a」のラン番号「1」の間に発生した保留トランザクションを「ノードa」が解決しようと試みている状況を表す。したがって、上記の状況は、「a:a(1)、b:b(1)、c:c(1)、d:d(1)」である。

ノードaがクラッシュし、いくつかの保留トランザクションを有すると仮定する。残りのノードのいずれかが、これらのトランザクションを引き継ぐことができる。ノードbが最も迅速であると仮定する。したがって、状況は今では、「b:b(1)+a(1)、c:c(1)、d:d(1)」となる。

今度はノードbがクラッシュすると仮定する。再びノードcとノードdが競争する。ノードbが解決しようと試みていた保留トランザクションをノードcとノードdが部分的に引き継ぐことも可能であり、そうなる可能性は非常に高い。1つの結果は、「c:c(1)+b(1)、d:d(1)+a(1)」となり得る。

ノードaが再起動された場合、ノードaは、必ずしも以前のランのトランザクションまで面倒をみる必要はない。これは、いくつかの他のノードがすでにそれらの面倒をみている可能性が非常に高いからである。そのため、状況は、「a:a(2)、c:c(1)+b(1)、d:d(1)+a(1)」となる。

この結果、TLOGは、異なるオーナを有することができる異なる部分に論理的に区分化することができる。TLOG用の下位永続性レイヤとしてファイルシステムまたはDBMSを使用できるようにするので、これは2つの選択肢によって達成することができる。1つの選択肢は、ファイルシステムベースのTLOGである。ノードの各開始において新しい物理ファイルを生成する。ノードが別のノードのTLOGを引き継ぐことができるように、ファイルシステムはノード間で共用されてもよい。別の選択肢は、DBMSベースのTLOGである。すべてのノードに対してただ1組の共用テーブルしか存在しなくてよい。データベーススキーマは、DBMSが異なるノードおよび異なるノード起動のエントリを区別できるようにする。

図3は、本発明の一実施形態による、2つのアプリケーションサーバ114e、114fと、トランザクションログサーバ120bについてより詳細に示すブロック図である。アプリケーションサーバ114eは、ノードm 302aと、トランザクションマネージャ132aと、PTLプロセッサコントローラ304aと、TL獲得フラグ(grab TL flag)306aと、保留トランザクションリスト308aと、PTLプロセッサ134aとを含む。アプリケーションサーバ114fは、ノードm+1 302bと、トランザクションマネージャ132bと、PTLプロセッサコントローラ304bと、TL獲得フラグ306bと、保留トランザクションリスト308bと、PTLプロセッサ134bとを含む。ノード302aおよび302bは、アプリケーションコンピュータプログラムのインスタンスと見なすことができる。

トランザクションログサーバ120bは、6つのトランザクションログ320a、320b、320c、322a、322b、322cを含む。トランザクションログ320a、320b、320c、322a、322b、322cは、別個の論理エンティティとして示されている。論理トランザクションログ320a、320b、320c、322a、322b、322cは、トランザクションログサーバ120bによって、ファイルまたはデータベース構造などの単一の物理データ構造に物理的に保存することができる。トランザクションログ320a、320b、320cは、アプリケーションサーバ114eに関連付けられ、トランザクションログ322a、322b、322cは、アプリケーションサーバ114fに関連付けられている。

図3に示されるように、2つのアプリケーションサーバノード302aおよび302b(mおよびm+1)は、異なる物理ボックス(アプリケーションサーバ114eおよび114f)上に存在すると仮定する。トランザクション処理は、トランザクションマネージャ132a、132bによって行われる。PTLプロセッサコントローラ304a、304bは、それぞれのTM 132a、132bの部分であるが、各々、独自のスレッドにおいて動作する。

PTLプロセッサ134aに関する1つの注目すべきデータ構造は、保留トランザクションリスト(PTL)308aである。保留トランザクションリスト308aは、メモリ内構造とすることができる。保留トランザクションリスト308aは、解決される必要のあるトランザクションのリストを含む。

リソース最適化のため、PTL 308a内にエントリが存在しない場合、PTLプロセッサ134aは停止させることができる。これは、PTLプロセッサ134aのライフサイクルを制御するPTLプロセッサコントローラ304a内でPTLプロセッサ134aが動作しているところとして、図3に示されている。

PTLエントリの追加に至り得る2つの道が存在する。
1. TM 132aが問題のあるトランザクション(例えば、2PCコミットプロトコルの第2のフェーズ中に障害を起こしたトランザクション)に遭遇した場合、TM 132aは、このトランザクションをPTL 308aに追加し、アプリケーション要求へのサービスを続行する。
2. クラスタノードの1つ302bがクラッシュした場合、クラスタインフラストラクチャは、他のすべてのクラスタノードの「トランザクションログ獲得」フラグを真に設定する。(例えば、唯一の他のノード302aしか示されていないので、TL獲得フラグ306aがこれに相当する)。これが、他のすべてのPTLプロセッサ(例えば、唯一の他のノード302aしか示されていないので、PTLプロセッサ134aがこれに相当する)に、親喪失トランザクションログへの排他的アクセスを獲得し、それらの内容をそれぞれのPTL(やはり、唯一の他のノードしかないので、PTL308aがこれに相当する)にコピーしようと試みるサイクルを開始するよう命令する。

トランザクションログ130(図1を参照)は、異なる論理トランザクションログエンティティ(例えば、320a、320b、320c、322a、322b、322c)から成る。1つの論理TLog(例えば、320a)は、ただ1つのPTLプロセッサ(例えば、134a)またはTM(例えば、132a)をオーナとして有することができる。図3では、以下の状況が説明されている。
・ ノードm 302aのTM 132aが、このノードm 302aの直近の起動時に生成されたTLog n 320aに書き込む。ラベル「n」は、ラン識別子（run identifier）と呼ばれることがある。
・ ノードm 302aのPTLプロセッサ134aは、このノードの直近のランおよびそれ以前の2つのランからトランザクションを解決する。これは、ノードm 302aのTLog n-1 320bおよびn-2 320cへの読み取り/書き込みアクセスとして示されている。
・ ノードm 302aのPTLプロセッサ134aは、node m+1 302bの直近のランからトランザクションを解決する。これは、ノードm+1 302bのTLog n-1 322bへの読み取り/書き込みアクセス矢印によって示されている。
・ ノードm+1 302bのTM 132bが、直近の起動時に新たに生成されたノードm+1 302bのTLog n 322aに書き込む。
・ ノードm+1 302bのPTLプロセッサ134bは現在、直近のラン以前のランからトランザクションを解決する。これは、ノードm+1 302bのTLog n-2 322cへの矢印によって示されている。

特定の論理トランザクションログ(例えば、320c)のすべてのトランザクションが解決された場合、それはPTLプロセッサ(例えば、134a)によって削除される。設定可能なタイムアウト(典型的には1日など)が存在してもよく、それ以降、回復不可能なトランザクションは放棄される。そのため、ある時間が経過すると、旧いTLog(例えば、320c)は消滅する。

図4は、本発明の一実施形態による、分散コンピューティング環境におけるトランザクション回復の方法400のフローチャートである。方法400は、分散コンピューティング環境100(図1を参照)によって実施することができる。

ステップ402において、共用トランザクションログが保存される。

ステップ404において、分散トランザクションアプリケーションを使用してトランザクションを実行する場合に共用トランザクションログがアクセスされる。分散トランザクションアプリケーションは、多くのアプリケーションサーバによって実施される。

ステップ406において、トランザクションに従ってデータがアクセスされる。データアクセスは、2PC(2フェーズコミット)手順に従って実行することができる。

ステップ408において、アプリケーションサーバの1つが故障した場合、それまでは故障アプリケーションサーバによってアクセスされていた共用トランザクションログ部分に対する責任を別のアプリケーションサーバ(アクティブアプリケーションサーバと呼ばれる)が引き受ける。ただ1つのアプリケーションサーバだけが共用トランザクションログの特定の部分に対して責任を負うことができるので、一般に、最低負荷のアプリケーションサーバが、最も迅速に故障に反応して、アクティブアプリケーションサーバとなり、故障アプリケーションサーバのトランザクションログエントリに対する責任を引き継ぐ。

詳細な実施形態例
以下のセクションは、上述された構造およびプロセスに関するさらなる詳細を提供する。付加的な詳細についての背景を提供するために、説明が重複することもある。

1. 概要
アプリケーションサーバにはトランザクションおよびそれらの回復の面倒をみる4つの注目すべき構成要素が存在する。これらは、トランザクションマネージャ(TM)と、トランザクションログ(TLOG)と、保留トランザクションリスト(PTL)と、PTLプロセッサ(PP)とを含む(例えば図3を参照)。

トランザクションマネージャ(例えば図3の132a)は、SAP AGのNetWeaver Java Serverの一部として実施することができる。TMはトランザクションを調整する。一実施形態によれば、TMはマルチスレッド化され、それはトランザクションが常にアプリケーションのスレッドにおいて開始されることを意味する。トランザクションをコミットすることを決定した場合、TMは、このトランザクションのためのエントリを永続的トランザクションログ(TLOG)に書き込む。これは、関与するどのリソースマネージャ(RM)に対してもいかなるコミットコールも実行されないうちに行われる。そのため、TMは、コミット操作の結果ではなく、コミットの意向をログに記録する。

トランザクションのためのエントリがTLOG内に存在しない場合、それはTMがトランザクションをロールバックすることを決定したことを意味する。一実施形態では、TLOGを更新するこの方法は、「推定アボート(Presumed-Abort)」戦略に従って実行することができる。Weikum and Vossum、Transaction Information Systems、Chapter 19、Distributed Transaction Recovery (Academic Press 2002)を参照されたい。

いくつかのエラー状態は、TMが2フェーズコミットトランザクションを即座に一貫性のある状態にすることを不可能にする。これらの状況の詳細な説明については、リソースマネージャエラーについての以下のセクションを読まれたい。そのような場合、TMは、もはやアプリケーションスレッドをブロックせず、トランザクションを保留トランザクションのリスト(PTL)に引き渡す。

TLOG(例えば図3の320a)は、トランザクションをコミットするというTMの決定を保存する。それはシステムDBMSまたはファイルシステムに保存することができる。一実施形態によれば、TMの開始のたびに、新しい論理TLOGが生成される。ファイルシステムでは、これが多くの物理TLOGをもたらすことがある。

一実施形態によれば、PTL(例えば図3の308a)はメモリ内構造である。それは、関与する1つまたは複数のRMが問題(例えば故障)を有するために、現在は解決できないトランザクションを含む。PTL内のエントリは、トランザクションがコミットされなければならないこと、またはロールバックされなければならないことを意味することができる。加えて、各エントリは、各トランザクションブランチの状態を追跡し、そのため、どのRMがどのような結果を返したか、また現在までどのRMと正常に連絡が取れていないかが常に明らかである。

PTLプロセッサ(例えば図3の134a)は、PTL内のトランザクションを解決しようと試みる。PTLプロセッサは、PTL内のすべてのエントリにわたってループすることによってこれを行う。PTLプロセッサおよびTMは、同一の方法でトランザクションを処理する。これは、後で説明されるすべてのRMエラーハンドリングが、TMとPPとで完全に同じであることを意味する。唯一の相違は、PTLハンドリングが、アプリケーション要求のスレッドではなく、独自のスレッドにおいて行われることである。

加えて、PPは、外部トランザクションログからトランザクションを読み込む可能性を有する。そのため、PTLは、多くのTLOGを指し示すエントリを含むことができる。

2. トランザクションマネージャ
トランザクションマネージャは、2PCプロトコルの異なるフェーズ中にリソースマネージャ(RM)が提供できる複雑なリターンコードを処理しなければならない。XAリソースインタフェースを実施する異なるリソースマネージャが、ある状況においてどのリターンコードを選択すべきかについて異なる解釈をもつことができる一実施形態では、さらなる複雑さが追加される。その上、トランザクションに関する異なる仕様は、時として曖昧または不完全である。

これに対処するため、一実施形態は、リターンコードに関する限り、解釈の拠り所として公式なオープングループXA仕様を実施する。これは、(一実施形態によれば)TMが、JSR-000907 Java(登録商標)トランザクションAPI仕様で言及されておらず、オープングループXA仕様でのみ言及されているリターンコードさえも処理することを意味する。これらのリターンコードがJava(登録商標)文書で言及されていなくても、いくつかのJava(登録商標)リソースマネージャは既存のC/C++リソースマネージャ実施を包むシン(thin) Java(登録商標) ラッパに過ぎないので、我々は現実世界ではそれらが発生すると予期している。

2.1 準備フェーズ前のリソースマネージャエラー
準備フェーズ前は、エラーハンドリングは、準備後ほど複雑ではない。互いに連絡を失っていても、関与するすべての当事者がトランザクションの各自の部分をロールバックするので、非一貫性は比較的短時間しか存続しないことが期待できる。それにも関わらず、そのフェーズ中のJTA XAResourceインタフェースの異なる動作について精査の必要がある。

動作: start (Xid xid, int flags)
一実施形態によれば、接続は常にトランザクションに固定されるべきである。そのため、使用されるフラグの唯一の値はTMNOFLAGSである。一代替実施形態によれば、接続は、end(TMSUSPEND)およびstart(TMJOIN)を用いて、中断および再開することができる。これは、より少ない接続の使用をもたらすが、パフォーマンスにマイナスの影響を与えることもある。さらなるリスクは、いくつかのRMが適切なトランザクション中断メカニズムを実施できないことである。

動作: end (Xid xid, int flags)
一実施形態によれば、TMSUCCESSのみが使用される。一代替実施形態によれば、TMがロールバックを決定した場合にend(TMFAIL)をコールすることが最適化となる。これは、関与するRM上でのさらなるロールバックコールを不要にする。すべてのRMがこの最適化をサポートするかどうかが明らかでなく、僅かな比率のトランザクションしかロールバックされないので、いくつかの実施では、代替実施形態は望ましくないことがある。

リターンコードがXA_OK以外のものである場合、完了トランザクションはロールバックされる。(より正確には、Javaでは、XA_OKではないXAリターンコードは例外に変換される)。リターンコードがXA_RB*である場合、完了トランザクションはロールバックされるが、このコードを返したRMではロールバックコールは発行されない。

動作: prepare (Xid xid)
一実施形態によれば、RMがRDONLYを返した場合、それは即座にトランザクションから除外される。このブランチのためのエントリはTLOGに書き込まれない。RDONLY結果は、コミットに対する賛意表明(vote)ではなく、ロールバックに対する賛意表明でもない。

XA_RB*が返された場合、トランザクションはロールバックするが、これらの特定のRM上ではロールバックはコールされない。それらはロールバックに賛意を表明して、すでにロールバックを実行している。すべての準備コールが成功した場合、TMはトランザクションをコミットすることを決定する。

動作: commit(Xid xid, boolean onePhase)
一実施形態によれば、onePhaseが真に設定された場合、トランザクションはローカルトランザクションのように扱われる。そのため、TLOGへの書き込みは行われない。onePhaseが偽に設定された場合、非常に複雑なエラー結果を有する本格的な2PCトランザクションを我々は有する。以下のセクションは、これらの可能なエラーがどのように扱われるかについてより詳細に説明している。

2.2 コミットフェーズ中のリソースマネージャエラー
一実施形態によれば、コミットフェーズ中、TMは、トランザクションに参加しているすべてのRMに呼び掛け、それらにコミットするよう求める。一実施形態によれば、これは、並列方式ではなく、順次方式で行われる。一代替実施形態によれば、より短いトランザクション待ち時間をもたらすために並列手法が使用できるが、並列手法は、異なるRMコミットリターン結果を同期させるための付加的なオーバヘッドを伴う。TMアーキテクチャの背後の1つの注目すべき側面は、トランザクションスループットは最大に達し、トランザクション待ち時間は最小に達しないことである。

図5は、本発明の一実施形態による、すべてのRMが正常に準備を終えた時点を説明するアクティビティ図のフローチャート500である。TMは、トランザクションをコミットすることを決定し、その後、各参加RMに対してコミットをコールする。RMは準備フェーズ中に交わした約束を履行できず、TMにXA_OKを返さなかったと仮定する。RMが提供した具体的なエラーコードに応じて、異なるアクションが取られる。TMは、トランザクションに参加する各RMにわたってループし、そのため、図5で説明される実行フローが各RMに対して適用される。時々、図5は、forgetがRMに対してコールされることを示している。一実施形態によれば、これは即座には行われず、完了トランザクションが終了した後で行われる。

ステップ501において、XA_RB*またはXA_RMERRが真である場合、プロセスはステップ502に進み、それ以外の場合、プロセスはステップ506に進む。XA_RB*は、様々なリターンコードXA_RBROLLBACK、XA_RBCOMMFAIL、XA_RBDEADLOCK、XA_RBINTEGRITY、XA_RBOTHER、XA_RBPROTO、XA_RBTIMEOUT、およびXA_RBTRANSIENTのすべてを表す。TMの挙動に関して、詳細なXA_RB*理由は関係がない。XA仕様は次にように要約している。「[XA_RB*]:リソースマネージャはトランザクションブランチのためになされた作業をコミットしなかった。リターン時、リソースマネージャはブランチの作業をロールバックし、保持していたすべてのリソースを解放した」。これは基本的に、トランザクションがロールバックされ、RMはすでにそれについて忘れたことを意味している。

XA_RMERRに関して、XA仕様は次のように述べている。「トランザクションブランチのために実行された作業のコミット中にエラーが発生し、ブランチの作業がロールバックされた。他のリソースマネージャはこのブランチのための各自の作業を正常にコミットする可能性があるので、このエラーを返すことは、トランザクションマネージャに破局的イベントを通知することであることに留意されたい。このエラーは、リソースマネージャが、いかにしてもブランチをコミットできず、ブランチのリソースを準備状態に保持できないと結論を下した場合にのみ返されるべきである。さもなければ、[XA_RETRY]が返されるべきである」。

そのため、トランザクションブランチがロールバックされ、トランザクションがもはや保留状態にはないことを我々は確信することができる。

ステップ502において、故障RMがトランザクションにおける第１RMである場合、TMは、トランザクション全体をコミットすることについて意向を変更する(そしてステップ503に進む)。代わりに、TMは他のRMも同様にロールバックしようと試み、そのため、トランザクション終了後は、再び一貫性のある状態が得られる(ステップ503を参照)。さもなければ、処理はステップ504に進む。

ステップ503において、TMはトランザクションをロールバックすることを決定する。TMの意向のこの変更についての更新はTLOGには書き込まれない。TLOG内にはTMがコミットの決定を行ったことを意味するエントリがすでに存在しているので、これは驚きに思えるかもしれない。しかし、ロールバックを試みている最中にクラッシュが発生したとしても、PTLプロセッサは、TMと同じロジックを実施するので、TMと同じことを行う。これは、PTLプロセッサがTLOG内でトランザクションを見つけることを意味する。PTLプロセッサは、それをコミットしようと試み、第１RMがロールバックされたことを見出し、それが完了トランザクションをロールバックする決定をもたらす。その後、処理はステップ505に進む。

ステップ504において、TMは、第１トランザクションブランチではない1つのトランザクションブランチがロールバックされたことを確実に知っている。そのため、トランザクションが一貫性をもっていないことをTMが確実に知っていることを意味する、発見的混合状況が存在している。TMは、他のRMをコミットしようと試みる。TMは、管理者にSevereエラーを報告することができ、HeuristicMixedExceptionをスローすることができる。

ステップ505において、今ではトランザクション全体がロールバックされるよう標識付けられているので、TMは、トランザクションに参加するすべてのRMをロールバックする。トランザクションはまだ一貫性をもっているので、管理者は警告だけを受け取る。最後に、TMは、RollBackExceptionをスローする。

ステップ506において、XA_HEURRBが真である場合、処理はステップ507に進み、それ以外の場合、処理はステップ514に進む。

XA_HEURRBに関して、XA仕様は次のように述べている。「発見的決定のため、指定されたトランザクションブランチのためになされた作業がロールバックされた」。この場合、RMは、ステップ511においてトランザクションについて忘れることを許可されない限り、トランザクションが終了しているとしても、このトランザクションを覚えているが、そのことを除いて、これはステップ501の状況と完全に同一である。XA仕様はxa_commit関数の一部として次のように述べている。「リソースマネージャが*xidに関連付けられた作業をすでに発見的に完了した場合、この関数は、リソースマネージャがトランザクションブランチをどのように完了したかを単に報告する。リソースマネージャは、トランザクションマネージャがxa_forget()をコールするまで、発見的に完了したブランチについて忘れることはできない」。

処理がステップ509および510からステップ511に進むことを除いて、ステップ507〜510は、それぞれステップ502〜505と同様である。

ステップ511において、xa_forget()をコールすることが設定可能でない限り、処理はステップ512に進む。原則的に、TMがRMにこのブランチについて忘れることを要求するかどうかについて設定可能であるべきである。この発見的トランザクションDBMS状態をどのように使用すべきか知っている熟練したDBMS管理者が存在する場合、ブランチを忘れるタスクは、DBMS管理者に引き渡されるべきである。管理されていない環境の場合、TMが、このトランザクションブランチについてのRMのメモリを削除すべきである。

ステップ512において、例外が存在しない限り、処理はステップ513に進む。forget中に例外が存在する場合、RMはこのブランチについて忘れたとしてもよく、または忘れていないとしてもよい。これはトランザクションの一貫性に影響をもたないので、TMは、後でRMに対してforgetをコールしようと再び試みることはない。

ステップ513において、ステップ512は深刻な問題をもたらさないので、ステップ512のコンティンジェンシの代わりに、関心のある管理者がforget中の問題を見出すことができるように、エラーがトレースに記録される。

ステップ514において、RMがXA_HEURMIXを返した場合、処理はステップ515に進み、さもなければ、処理はステップ516に進む。

ステップ515において、RMがXA_HEURMIXを返した場合、それは別のトランザクションマネージャである可能性がきわめて高いが、DBMSでもおそらく混合結果を報告できる。トランザクション全体は今では発見的に混合されており、そのため、我々は他のRMをコミットしようと試み、HeuristicMixedExceptionをスローする。その後、我々はXA_HEURRBの場合(ステップ511など)と同様のXA forgetロジックに進む。

ステップ516において、XA_HEURHAZが真である場合、処理はステップ517に進み、さもなければ、処理はステップ518に進む。

ステップ517において、発見的ハザード状況に遭遇した場合、RMは、トランザクションブランチの状態が分からない。これは、一時的状況であることもあり、または永続的状況であることもある。

一実施形態によれば、XA_HEURHAZは、永続的リターンコードとして扱われる。例外に関して、JTAは、RollbackException、HeuristicMixedException, HeuristicRollbackException、SecurityException、IllegalStateException、およびSystemExceptionだけが分かる。一実施形態によれば、HeuristicMixedExceptionは、SAP独自仕様のSAPHeuristicHazardExceptionによって拡張され、それをスローする。これは、ex.getCause()を用いて例外を捕らえるアプリケーションに、反応する可能性を与える。

XA_HEURHAZが一過性のものと見なされる一実施形態によれば、トランザクションは、コミットされることを目的として、「保留トランザクションリスト(PTL)」に移転される。PTLエントリはその上、トランザクションに関与する異なるブランチの結果についての情報も含む。PTLプロセッサは、後の時点におけるPTLの実行の面倒をみる。このリストを所有するプロセスが死んだ場合、このリスト内の非永続的エントリも同様に失われる。PTLプロセッサは回復時にTLOG中にこのトランザクションを再び見つけるので、これはどのような問題も引き起こさない。そのため、トランザクションが忘れられることはない。

ステップ518において、XA_RETRYまたはXA_RMFAILが真である場合、処理はステップ519に進み、さもなければ、処理はステップ520に進む。

ステップ519において、TMは、コミットのためにトランザクションをPTLに追加し、管理者にハザード状態を報告する。

XA_RETRYに関して、DTP仕様は次のように述べている。「リソースマネージャは、この時点ではトランザクションブランチをコミットすることができない。この値は、ブロッキング状態が存在し、TMNOWAITが設定された場合に返すことができる。しかし、TMNOWAITが設定されていない場合(例えば、必要な安定記憶が現在利用不可能な場合)であっても、この値を返すことができることに留意されたい。この値は、TMONEPHASEがフラグに設定されている場合は返すことができない。*xidのために保持されているすべてのリソースは、コミットが可能になるまで準備状態に留まる。トランザクションマネージャは、後の時点でxa_commit()を再発行すべきである」。

XAER_RMFAILに関して、DTP仕様は次のように述べている。「リソースマネージャを利用不可能にするエラーが発生した」。

要約すると、TMは、もはや制御のスレッドを遅延させず、後の時点でこのブランチをコミットしようと試みる。そのため、ブランチはコミットの意向をもってPTLに追加される。一実施形態によれば、スローされた例外は、JTA HeuristicMixedExceptionを拡張したSAP独自仕様のSAPHeuristicHazardExceptionである。JTA例外が拡張される理由は、一貫性のないトランザクション(発見的ハザード)が存在する可能性がある場合と、または一貫性のないトランザクション(発見的混合)が確かに存在する場合とでは相違が存在するからである。この相違は、XA仕様には見られたが、JTA仕様では失われた。

ステップ520において、TMがこのアクティビティに達した場合、トランザクションハンドリング中に何か深刻なことが悪化しており、それはRM内、TM内、または両者の間の障害とすることができる。その上、人の管理者が、トランザクション状態に干渉した可能性もある。可能な事柄のリスト(DTP XA仕様から取られた引用資料)をここに示す。
・ 「[XAER_NOTA] 指定されたXIDがリソースマネージャに知られていない」。これは管理者がこの保留トランザクションを人的にコミットまたはロールバックすると決定した場合とすることができる。
・ 「[XAER_INVAL] 無効な引数が指定された」。これはRMまたはRM XAドライバ内のエラーを指し示す。
・「[XAER_PROTO] ルーチンが不適切なコンテキストで呼び出された」。これはTM実施におけるエラーを指し示す。
・ 「[XAER_ASYNC] TMASYNCがフラグに設定され、未解決の非同期動作の最大数が超過されたか、またはTMUSEASYNCがリソースマネージャのxa_switch_t構造のフラグ要素に設定されていない」。Java(登録商標)は、非同期トランザクションの概念をサポートしないので、これはRMまたはRM XAドライバ内のエラーを指し示す。
・ リターンコードが他のものである場合、それはDTP XA仕様では言及されていないコードである。これは起こってはならない。

2.3 ロールバックフェーズ中のリソースマネージャエラー
ブランチの1つが準備フェーズ中のロールバックに賛意を表明した場合、TMは、完了トランザクションをロールバックしようと試みる。そうするため、一実施形態によれば、TMは、順次方式ですべての参加RMにわたってループする。これらのRMの1つがエラーを返した場合、それによってTMが他のRMをロールバックし続けることを止めることはない。XA_OK以外のすべてはエラーとみなされ、それはXAリターンコードまたは別の例外とすることができる。

図6は、本発明の一実施形態による、TMが可能なXAリターンコードの各々をどのように処理するかについて略述するアクティビティ図のフローチャート600である。

ステップ601において、XA_RB*が真である場合、処理はステップ602に進み、さもなければ、処理はステップ603に進む。XA_RB*は、様々なリターンコードXA_RBROLLBACK、XA_RBCOMMFAIL、XA_RBDEADLOCK、XA_RBINTEGRITY、XA_RBOTHER、XA_RBPROTO、XA_RBTIMEOUT、およびXA_RBTRANSIENTのすべてを表す。

ステップ602において、TMの挙動に関して、詳細なXA_RB*理由は関係がない。XA仕様は次にように要約している。「[XA_RB*]:リソースマネージャはトランザクションブランチの作業をロールバックし、保持していたすべてのリソースを解放した。ブランチがすでにロールバックオンリ(rollback-only)と標識付けされている場合、これらの値が一般に返される」。これは基本的に、トランザクションがロールバックされ、RMはすでにそれについて忘れたことを意味している。いくつかのRMが準備中にロールバックに賛意を表明した場合、それらにとってはこれが通常の挙動となり得る。我々は管理者に警告を通知する。

ステップ603において、XA_HEURRBが真である場合、処理はステップ604に進み、さもなければ、処理はステップ605に進む。

ステップ604において、TMがそうするよう命じていなくても、RMはすでに発見的にロールバックしている。XA仕様は次のように述べている。「発見的決定のため、指定されたトランザクションブランチのためになされた作業がロールバックされた。リソースマネージャは、正常に*xidを準備した場合にのみ、この値を返すことができる」。いずれにしろTMがロールバックを望んだので、これはトランザクションの一貫性をもたない状態をもたらさない。TMは、HeuristicRollbackExceptionをスローし、このRMの発見的決定について管理者に通知する。その後、処理はステップ607に進む。

ステップ605において、XA_HEURCOMまたはXA_HEURMIXが真である場合、処理はステップ606に進み、さもなければ、処理はステップ610に進む。

ステップ606において、HEUR_COMに関して、XA仕様は次のように述べている。「発見的決定のため、指定されたトランザクションブランチのためになされた作業がコミットされた。リソースマネージャは、正常に*xidを準備した場合にのみ、この値を返すことができる」。HEUR_MIXに関して、XA仕様は次のように述べている。「発見的決定のため、指定されたトランザクションブランチのためになされた作業が部分的にコミットされ、部分的にロールバックされた。リソースマネージャは、正常に*xidを準備した場合にのみ、この値を返すことができる」。

要約すると、トランザクションは今では確かに一貫性のない状態にあるので、TMは、HeuristicMixedExceptionをスローし、それについて管理者に通知する。その後、処理はステップ607に進む。

ステップ607において、発見的リターンコードがRMによって返される場合は常に、TMは、このリソースに対してxa_forgetをコールすることができる。これを行うべきかどうかは、管理者が設定することができる。その後、処理はステップ609に進む。

ステップ608において、forget中に例外が存在する場合(ステップ609を参照)、RMはこのブランチについて忘れたとしてもよく、または忘れていないとしてもよい。これはトランザクションの一貫性に影響をもたないので、TMは、後でRMに対してforgetをコールしようと再び試みることはない。その代わりに、関心のある管理者がforget中の問題を見出すことができるように、エラーがトレースに記録される。

ステップ609において、forget中に例外が存在する場合、処理はステップ608に進み、さもなければ、処理は停止する。

ステップ610において、XA_HEURHAZが真である場合、処理はステップ611に進み、さもなければ、処理はステップ612に進む。

ステップ611において、発見的ハザード状況に遭遇した場合、RMは、トランザクションブランチの状態が分からない。これは、一時的状況であることもあり、または永続的状況であることもある。一実施形態によれば、XA_HEURHAZは、永続的リターンコードと仮定される。例外に関して、JTAは、RollbackException、HeuristicMixedException, HeuristicRollbackException、SecurityException、IllegalStateException、およびSystemExceptionだけが分かる。一実施形態によれば、HeuristicMixedExceptionは、SAP独自仕様のSAPHeuristicHazardExceptionによって拡張され、それがスローされる。これは、ex.getCause()を用いて例外を捕らえるアプリケーションに、反応する可能性を与える。

XA_HEURHAZが一過性のものと見なされる一実施形態によれば、トランザクションは、ロールバックされることを目的として、「保留トランザクションリスト(PTL)」に移転される。PTLエントリはその上、トランザクションに関与する異なるブランチの結果についての情報も含む。PTLプロセッサは、後の時点におけるPTLの実行の面倒をみる。このリストを所有するプロセスが死んだ場合、このリスト内のこのエントリも同様に失われる。PTLプロセッサは回復時にTLOG中にこのトランザクションを見つけはしないが、それをRMに対するrecover()コールの結果として識別するので、これはどのような問題も引き起こさない。推定アボート戦略の結果として、PTLプロセッサは、完了トランザクションをロールバックすることを決定する。

ステップ612において、XA_RMFAILが真である場合、処理はステップ613に進み、さもなければ、処理はステップ614に進む。

ステップ613において、XA_RMFAILに関して、XA仕様は次のように述べている。「リソースマネージャを利用不可能にするエラーが発生した」。この状態は一時的であり得るので、TMは、このトランザクションをロールバックの決定が意図されたエントリとしてPTLに入れる。エントリが失われた場合、次の回復シーケンスが再びこのブランチを報告するので、ロールバックが忘れられることはあり得ない。

ステップ614において、XA_RMERRが真である場合、処理はステップ615に進み、さもなければ、処理はステップ616に進む。

ステップ615において、XA_RMERRに関して、XA仕様は次のように述べている。「トランザクションブランチをロールバックする際にエラーが発生した。制御のすべてのアクセススレッドがブランチの状態を通知されている限り、このエラーを返したときにブランチについて忘れるかどうかはリソースマネージャの自由である」。

この状況はどういうわけか例外的であり、XA仕様の作成者にあまり巧みには設計されていない。それはRMにおける破局的状況においてのみ発生する。TMは、トランザクションブランチの結果について、何を発見的ハザード状況として扱い得るかが分からない。ここで複雑さを追加するものは、さらにRMがこのトランザクションについて忘れた可能性があることをTMに伝えるという事実である。これは、後の時点でのRMのrecoverメソッドのコールが、もはやこのトランザクションを返さないことがあることを意味する。基本的にこれは、RMが準備したトランザクションを覚えているという約束を破ることを意味する。

一実施形態は、これのための特別なロジックを実施しない。RMがそのトランザクションを忘れた場合、TMがそれについてできることは多くない。RMがすでに忘れたかどうかが明らかでないので、管理者によって設定されているならば、我々はRM上でforgetをコールしようと試みる。我々はSAPHeuristicHazardExceptionを返す。

ステップ616において、TMがこのアクティビティに達した場合、トランザクションハンドリング中に何か深刻なことが悪化しており、それはRM内、TM内、または両者の間の障害とすることができる。その上、人の管理者が、トランザクション状態に干渉した可能性もある。可能な事柄のリスト(DTP XA仕様から取られた引用資料)をここに示す。
・ 「[XAER_NOTA] 指定されたXIDがリソースマネージャに知られていない」。これは管理者がこの保留トランザクションを人的にコミットまたはロールバックすると決定した場合とすることができる。
・ 「[XAER_INVAL] 無効な引数が指定された」。これはRMまたはRM XAドライバ内のエラーを指し示す。
・ 「[XAER_PROTO] ルーチンが不適切なコンテキストで呼び出された」。これはTM実施におけるエラーを指し示す。
・ 「[XAER_ASYNC] TMASYNCがフラグに設定され、未解決の非同期動作の最大数が超過されたか、またはTMUSEASYNCがリソースマネージャのxa_switch_t構造のフラグ要素に設定されていない」。Java(登録商標)は、非同期トランザクションの概念をサポートしないので、これはRMまたはRM XAドライバ内のエラーを指し示す。
・ リターンコードが他のものである場合、それはDTP XA仕様では言及されていないコードである。これは起こってはならない。

2.4 XAリソース再生成
アプリケーションサーバ内のPTLプロセッサは、回復時にXAリソースマネージャを再生成するタスクを有する。このジョブに必要とされるすべての情報は、一実施形態によれば、トランザクションログに保存される。これは、セキュリティ証明書と、リソースマネージャ固有の他のプロパティを含む。

(一代替実施形態は、関与するすべてのXA RMを見出すために、配備されたすべてのアプリケーションを調べる。実際には、すべてのアプリケーションをスキャンするにはPTLプロセッサ起動時に相当なCPUリソースを必要とするので、これは時間を浪費する)。

非代替実施形態の1つの示唆は、RMセキュリティ証明書または他のプロパティの変更がPTLプロセッサに何の影響ももたないことである。PTLプロセッサは常に、トランザクションが開始されたときに有効だったのと同じ証明書およびRMプロパティを用いてトランザクションを完了しようと試みる。

PTLプロセッサ自体は、RMをどのように再生成するかについて知る必要はない。PTLプロセッサは、このタスクをRMコンテナに委任することができ、RMコンテナ、そのような要求のために独特なインタフェースを実施する。現在、3つの異なる種類のRMタイプが存在する。
・ 汎用Javaコネクタリソース-特にアウトバウンドリソースアダプタ: コネクタコンテナ(別名、コネクタサービス)は、これらのRMのライフサイクルに責任を負う。これはコンフィグレーションデータの配備および管理を含む。
・ データソース:データソースコンテナ(別名、DBPoolサービス)は、システムデータソースに責任をもち、すべてのカスタムデータソースの配備、コンフィグレーション、およびライフサイクルに責任を負う。データソースは、JDBC(Java(登録商標)データベースコネクティビティ)コネクタUI(ユーザインタフェース)を介して、またはdata-source.xmlリソースファイルの配備を通して生成することができる。その上、javax.sql.DataSourceインタフェースを提示するJavaコネクタリソースアダプタを配備することも可能であるが、この種のRMは、DBPoolサービスによっては管理されず、コネクタサービスによって管理される。DBPoolサービスは、その上、データソースエイリアスの管理も担当するが、これらのエイリアスは、本当のデータソースオブジェクトへの参照に過ぎない。他のRMコンテナに関しても同様に、同じエイリアス概念が存在する。
・ JMS(Java(登録商標)メッセージングサービス)キュー/トピックコネクションファクトリ。JMSコンテナ(別名、JMSコネクタサービス)は、これらのリソースの管理に責任を負う。JMSファクトリのコンフィグレーションデータは、JMSプロバイダからではなく、JMSコネクタサービスから取得される。

コネクション管理の観点からは、DBPoolサービスおよびJMSコネクタサービスは、Java(登録商標)コネクタコンテナのように振舞う。しかし、実際には、それらは異なる配備手法および異なるコンフィグレーションUIを有するので、アプリケーションサーバのJava(登録商標)コネクタコンテナとはっきりと区別される。

PTLプロセッサの観点からは、すべてのRMコンテナは同じである。それらはXAリソースファクトリのように振舞う。XAリソースファクトリは開始されると直ちに、自身をTMに登録する。そのため、PTLプロセッサは、TMに問い合わせを行い、XA生成要求にサービスするために、必要なXAリソースファクトリがすでに利用可能であるかどうかを見出すことができる。

2.5 トランザクションサブシステムの組織化
アプリケーションサーバのトランザクション挙動は、いくつかのトランザクションサブシステムの対話の結果である。すべてのシステムが一緒になって、トランザクションハンドリングおよび回復を組織化する。

2.5.1 トランザクションログ-高レベルビュー
トランザクションログは、データベースまたはファイルシステム内に配置することができる。ファイルシステムが選択された場合、共用ファイルシステムとすることが我々に強く推奨される。ファイルシステムが共用されていなくても、トランザクション回復は機能するが、オンザフライ回復能力はもたない。次のセクションは、それについてより詳細に説明する。

各クラスタノードは、1つのトランザクションマネージャを有する。このトランザクションマネージャは、各開始時に新しいトランザクションログを生成する。ログがDBMS内に存在する場合、すべてのログエントリは同じテーブルを共用するが、様々な開始および様々なノードからのエントリを区別することも可能である。

ファイルシステムの場合、各ログは別個のファイルである。TMがこのTLOGのオーナであり、排他的アクセスを有する。図3において、このログはTLog n(例えば、320a)と呼ばれている。

2.5.2 トランザクションログ-相殺エントリ
何の問題もなく実行している場合、TMはTLOGにエントリを追加している。もちろん、典型的なトランザクションは、非常に短時間だけアクティブであり、その後は削除することができ、それについての記憶を維持する必要はない。

これらの削除操作は、一実施形態によれば、即座にではなく、時期を遅らせて(lazily)実行される。さもなければ、TLOGへの書き込み操作は2倍になる。

トランザクションが終了すると、それは削除対象リストに追加される。TMにはそのようなリストがいくつか存在することができる。各TLOGに1つ存在することができる。
・ TMは直近の起動時に生成したTLOGのための削除対象リストを有する。TMはトランザクションを終了させると、それをこのリストに追加する。
・ PTLプロセッサは、以前の起動に由来するTLOG上で機能することができる。PTLプロセッサは、これらのTLOGの各々のための削除対象リストを維持する。
・ PTLプロセッサは、その上、TMが問題のあるトランザクションをPTLに送った場合、現在アクティブなTLOGのトランザクション上で機能することができる。そのため、PTLプロセッサは、アクティブTLOGの対象リストにも同様にエントリを追加する。

削除対象リストは、メモリ内構造である。削除対象リストが一定のサイズ(例えば、1000エントリ)に達すると、これらの1000エントリはTLOGから削除される。これは、DBMSベースのTLOGとファイルシステムベースのTLOGとでは異なる仕方で行われる。
・ TLOGがDBMSベースである場合、レコードは単一のDELETE SQLステートメントを用いて削除される。
・ TLOGがファイルシステムベースである場合、TLOGに追加される1つまたは複数の相殺削除ステートメントが存在する。これらのエントリは、例えば「501から1012までのトランザクションを削除する」といった範囲を使用する。トランザクションを識別する唯一の番号は、トランザクションシリアル番号である。完了XIDは必要とされない。

2.5.3 PTLプロセッサおよびPTLプロセッサコントローラ
PTLプロセッサは、保留トランザクションを一貫性のある状態にする責任を負う。現在いくつかの利用不可能なRMが存在する場合、このタスクは時間が掛かることがあり、継続的なリトライの試みを必要とする。そのため、PTLプロセッサは、それ独自のスレッドで動作する。

PTLは、XID、記録の全般的な意向(トランザクションをロールバックすべきか、またはコミットすべきか)、および各ブランチのステータス(ブランチはすでにコミットされた、ロールバックされた、またはそのステータスが不明である)についての情報を含む。

なすべき作業が存在しない場合(空のPTL)、PTLプロセッサは自身を停止させ、スレッドがプールに戻される。PTLプロセッサの完全なライフサイクルは、PTLプロセッサコントローラによって制御される。このコントローラは、PTLをホストし、PTLプロセッサが動作しておらず、PTL内にエントリが存在する場合、PTLプロセッサを開始させる。

基本的に、保留トランザクションの面倒をみることと、親喪失トランザクションログのオーナになり、その中のトランザクションを回復することという、PTLプロセッサがしなければならない2つの事柄が存在する。

保留トランザクションの面倒をみる
TMは、即座に処理できないトランザクションに関する問題に遭遇した場合、トランザクションをPTLに追加し、呼元アプリケーションに例外を返す。

PTLプロセッサがPTL内のエントリにうまく対処し終えた場合、PTLプロセッサはエントリを削除し、このトランザクションを削除対象リストに入れる。このリスト内のトランザクションエントリは、TLOGから時期を遅らせて削除される(上を参照)。作業の正常終了はその上、PTLプロセッサが最終的にトランザクションを放棄するように(おそらく失敗した試みの1日後)、トランザクションがトランザクション放棄タイムアウトを超えたことを意味することができる。

親喪失トランザクションログのオーナになる
PTLプロセッサは、最初のエントリから最後のエントリまでPTLを継続的にループする。最初のエントリから再び開始する場合、「トランザクションログ獲得フラグ」が設定されているかどうかをチェックする。

設定されており、以前に開始した際のトランザクションログが存在する場合、PTLプロセッサは、それらに責任を負うようになろうと試みる。成功して、TLOGを獲得した場合、PTLプロセッサは、TLOGを読み込む。TMは、直近の起動時にTMが生成したものではないTLOGには、どのような関心ももたないことを思い出されたい。

TLOGがファイルベースである場合、ログの読み込みは、2フェーズ手法で行うことができる。すでに言及されたように、以前のエントリを相殺するTLOG内のトランザクションに対する削除ステートメントが存在することがある。そのため、PTLプロセッサは最初に、TLOGのすべてのエントリをメモリ内ステージング領域に読み込む。この領域は、各TLOGレコードとともに大きくなり、TLOG内に削除ステートメントが見出された場合に再び小さくなる。PTLプロセッサがTLOG内の各エントリの読み込みを完了した場合、TLOGはその特定のTLOGの最近のエントリと、おそらくは、直近のクラッシュまたはシャットダウン時に保留されたいくらかの単一トランザクションのみを有する。

その後、第2のフェーズにおいて、このステージング領域のすべてのエントリが処理済になり、即座に解決され得ないエントリのいくつかはPTLに移転される。

ログがDBMSベースである場合、ステージング領域は必要とされない。DBMSログは、ファイルシステムの場合のステージング領域のように扱われる。そのため、ステージング領域またはDBMSベースのTLOGの処理は、以下のように行われる。
○ 最初に、PTLプロセッサ(PP)は、このTLOGに属するRMエントリを読み、それらに対してrecoverをコールする。
○ このPPがあるRMにうまく対処し終えた場合、PPは、その結果をメモリ内回復結果リストに保存する。1つのRMが利用可能でない場合、PPは、このRMに関するNULLエントリを回復結果リストに保存する。NULLエントリは空リストではない。空リストは、RMが利用可能であり、保留トランザクションをもたないことを意味する。
○ recoverコールのこの初期シーケンスの後、PPは、ステージング領域内のエントリを1つずつ処理する。PPは、エントリのXIDと、このトランザクションに関与したRMのすべてのIdを再構成する。
このXIDは、回復結果リスト内のすべてのXIDと比較される。いくつかの可能な結果が存在する。
* TLOGエントリのXIDが回復結果リストのいずれにも存在しない。これはRMのいずれにも保留トランザクションが存在しないことを意味する。そのため、トランザクションを単純に忘れることができる。トランザクションはこのTLOGの削除対象リストに追加される。
* 関与するRMの1つのRMエントリがヌルであるのは、RMが現在アクセス可能でないことを意味する。そのため、この時点では、特定のトランザクションがこの現在利用不可能なRMにおいてまだ保留中かどうかを決定することはできない。そのため、トランザクションはPTLに追加される。
* XIDが、関与するRMの回復結果リストの一部または全部に存在する。そのため、PTLプロセッサは、これらの保留RMに対してこのXIDを解決しようと試みる。それが成功した場合、トランザクションは終了し、削除対象リストに追加される。成功しなかった場合、トランザクションはPTLに追加される。
○ このTLOGに属するが、このTLOGの部分ではないXIDが回復結果リスト内に存在する場合、PPは、これらのRMにおいてブランチをロールバックする(これは推定アボート戦略である)。
○ 現在利用不可能なRMのPTLにもはやエントリが存在しなくても、PTLプロセッサが、このRMに対してrecoverをコールしようと試みることに気を配らなければならない。この現在利用不可能なRMにはロールバックされる必要があるトランザクションがまだ存在することが可能である。

PTLプロセッサは、TLOGが完全に終了され、削除され得たかどうかを追跡しなければならない。そのため、PTLプロセッサは、特定のTLOGからのトランザクションがいくつPTLに存在するかを示すカウンタをTLOG毎に維持する。このカウンタがゼロに達した場合、PTLプロセッサは、関連するTLOGをファイルシステムまたは関連DBMSテーブルから削除する。

2.5.4 PTL処理におけるシングルトンパターン: TLOG獲得競争
PTLプロセッサは、他のマシン上の他のTMに由来するトランザクションログも含む、すべてのトランザクションログのロケーションを知っている。ファイルシステムベースのログの場合、このロケーションは、単なる共用フォルダである。PTLプロセッサコントローラ内の「トランザクションログ獲得フラグ」が真に設定された場合、PTLプロセッサは、すべての利用可能なトランザクションログを獲得しようと試みる。これを行う際、PTLプロセッサは、他のノード上に存在するPTLプロセッサと競争する。各トランザクションログは、ただ1つのオーナを有する。これは、トランザクション回復に関連して一般に見出され得るクラスタにおけるシングルトンパターンを実施する。

図3では、ノードm+1上に存在するTMによって生成されたTLOGを獲得したノードm上のPTLプロセッサを見ることができる。PTLプロセッサが別のノードのTMによって生成された親喪失TLOGの面倒をみている場合も不都合な点はない。そのため、一実施形態は、どのようなTM-PTLプロセッサ間アフィニティロジック(TM to PTL Processor affinity logic)も実施しない。

PTL内の最初のエントリから再開する場合、PTLプロセッサはその「トランザクションログ獲得」フラグの状態をチェックするだけなので、クラスタノード間に少なくともいくらかの負荷平衡が存在する。

要約すると、「トランザクションログ獲得フラグ」を真に設定することは、回復を開始することを意味する。しかし、誰がこのフラグの設定に責任を負うのか？
・ PPコントローラがクラスタノード喪失イベントに同意(subscribe to)する。ノードが失われた場合、フラグがスイッチオンされる。これがトリガとなって、すべてのノード上のすべてのPTLプロセッサは、親喪失ログを獲得しようとする。ここで問題となるのは、通常のシャットダウンも同様にこのイベントをトリガすることであり、そのため、PPコントローラは、フラグを真に設定する前にシャットダウンがローカルノード上で開始されないよう保証しなければならない。
・ クラスタノード喪失イベントに依存したくない場合、追加的にjava.util.timerを使用して、事前定義された時間設定可能な時間間隔でフラグを真に設定することが可能である。
略述されたように、PTLプロセッサはTLOG獲得競争を行っている。単一のTLOGが決して2つのオーナをもたないことはどのように保証されるのか？
・ ファイルシステムベースのログの場合、同期は容易である。PTLプロセッサは、一致するFileChannelに対してtryLockメソッドをコールする。それがロックを獲得すると、それ以外のものは失敗する。ノードがクラッシュした場合、オペレーティングシステムがファイルからロックを解除する。
・ TLOGがDBMS内に存在する場合、TLOGテーブルが存在する。各論理TLOGに対して、1つのレコードがテーブル内に存在する。このレコードは、オーナと、時間リース(time-lease)カラムを含む。PPがTLOGを所有する場合、PPは、このテーブル内に、自身をオーナとして指定し、TLOGを所有する期限であるGMT時刻の時間を供給する、リースエントリを作成する。TLOGを保有し続けることを望む場合、PPは、リース時間が終る前に、このエントリを更新(renew)しなければならない。別のPPが期限切れのTLOGオーナエントリを発見した場合、そのPPは、オーナが死んだものと見なす。ここで問題なのは、このリースベースの手法が待ち時間を導入することである。
○ TMがTLOGのオーナであり、10設定可能量(例えば、10分)の間、それを保有する。
○ TMがクラッシュし、ノード喪失イベントが発行される。
○ 別のノード上のPPがログをスキャンし、このログがまだ保有されていることを知る。そのため通常の場合、現在ではTLOGの面倒をみるオーナはもはや存在しないが、PPはそれの責任を負うようになろうとは試みない。これはオンザフライ回復を遅延させる。
○ 一実施形態による1つの解決策は、クラッシュノードのIdをPPコントローラが知ることである。そのため、クラッシュノードがTLOGのオーナである場合、リースはもはや有効とすることができない。この実施形態の1つの難点は、クラッシュノードがすでに再開されており、そのため、現実にはTLOGが、新しいTLOG、またはクラッシュノードのPPがすでに面倒をみているTLOGである場合である。

2.5.5 ノード起動
トランザクションコンポーネントの組織化を説明するため、ここにクラスタ起動中に実行される一連の事柄を示す。
・ 最初にノード上のTMが開始する。TMは、新しいトランザクションログを生成し、それを排他的に使用する。
・ その後、「TL獲得フラグ」フラグが真に設定される。これがこのノード上でPTLプロセッサを開始させる。
・ PTLプロセッサが、獲得できた第１親喪失トランザクションログをオープンする。PTLプロセッサは、このログ内で使用されていたすべてのRMを読み込む。RM情報は通常のTLOG内に混合されておらず、特別なエンティティとして(実際には別個のファイルまたは別個のテーブルとして)利用可能であるので、これは簡単である。
・ PTLプロセッサが、RMを再生成するのに必要とされるXAResourceファクトリのリストを生成する。例えば、5つのデータソースと、3つのJCA(J2EEコネクタアーキテクチャ)アダプタが存在することができ、そのため、1つのJDBC XAResourceファクトリと、1つのJCA XAResourceファクトリが必要とされる結果となる。
・ この時間の間、サーバも同様に、サーバインフラストラクチャに属するXAResourceファクトリを独立に開始する。XAResourceファクトリが要求を受け取る準備ができている場合、XAResourceファクトリは自身をTMに登録する。そのため、TMはすべての利用可能なXAResourceファクトリを知る。
・ PTLプロセッサは、TMを用いて、すべての必要なXAResourceファクトリがすでに開始されているかどうかをチェックする。開始されていない場合、PTLプロセッサはしばらく待ってから、再度試みる。必ずしもすべてのRMが起動していなくても、すでにいくつかのトランザクションを回復することは可能である(後で本文書中で説明される)。
・ PTLプロセッサは、XAResourceファクトリを使用して、関与するすべてのRMを再生成する。
・ PTLプロセッサは、すべてのRMに対してrecoverをコールし、結果をメモリ内に保存する。
・ PTLプロセッサは、TLOG内の各エントリを読み込み、recoverの結果と比較し、PTLにデータ投入を行う。
・ PTLプロセッサは、次のTLOGをオープンしようと試み、上記の最後のステップを繰り返す。

分かるように、各ノード起動は、回復シーケンスを開始する。このため、TLOGが非共用ファイルシステム上に存在していても、トランザクション回復が行われる。回復はオンザフライではなく、クラッシュノードの次の起動中に行われる。

オンザフライ回復はほぼ即座に行われるので、もちろん、オンザフライ回復が推奨される。回復がより迅速に行われるほど、RMの発見的決定の確率は低くなる。

2.6 トランザクションタイムアウト
2.6.1 準備前のXAトランザクションタイムアウト
JTAを使用してトランザクションタイムアウトを定義するのに異なる可能性が存在する。そのうちの1つは、現在のjavax.transaction.UserTransactionインスタンスに対してbeginをコールする前に、同じインスタンスに対してsetTransactionTimeoutメソッドをコールすることである。

分散トランザクションの場合、このタイムアウトは、トランザクションがその間に準備状態に達しなければならないタイムスパンである。タイムアウトがプログラム的に定義されていない場合、システムワイドなデフォルトを採用することができる。加えて、システムデフォルトをオーバライドするリソースマネージャレベルのタイムアウトを定義することも可能であるべきである。例外的に遅いRMの場合は、そのようにモデル化することができる。

TMは、XAResource.startをコールする前に、XAResource.setTransactionTimeout()をコールすることによって、このタイムアウトを関与するRMに伝播させる(定義されたいずれかのタイムアウトが存在する場合のみ)。

2.6.2 XAトランザクション放棄時間
トランザクションが準備状態に達した場合、トランザクションは、XAトランザクション放棄時間の範囲内で完了されなければならない。このタイムアウトは、システムワイドな設定として設定され、典型的なデフォルト値は20時間である。TMがこの時間内にトランザクションを一貫性のある状態にすることができない場合、TMは、その特定のトランザクションを放棄し、発見的結果を有するトランザクションを記録する(トランザクションステータスはHEURHAZである可能性がきわめて高い)。

3. XID構造およびトランザクションログバージョン
3.1 序論
XIDは、トランザクションブランチを標識付けるためにTMがRMに渡す識別子である。RMは、このXID下の作業のその回復可能な部分を実行する。システムがクラッシュした場合、TMは後の時点でRMにその保留トランザクションについて尋ねる。RMはXIDを返すので、TMは、TMがこのXIDの発行元であるかどうか、後でこのトランザクションの回復に責任を負うかどうかを認識できなければならない。

XA仕様は、XIDの異なる部分の長さおよび内容についていくらかの自由をTMの実装者に与える。その部分は、フォーマットIDと、グローバルトランザクションIDと、ブランチ修飾子である。

3.2 トランザクションログの一意識別情報
PTLプロセッサは、1組のトランザクションログに属するトランザクションを回復することに責任を負う。これらのトランザクションログは、TMの以前の開始に由来することができる。しかし、同様に、現在生成されるトランザクションログも、PTLプロセッサが面倒をみなければならないある1組のトランザクションを定義する。では、プロセッサは、それが責任を負う1組のTLOGにRM内の保留トランザクションが属するかどうかをどのようにして決定できるのか？ 答えは簡単である。
・ 最初に、PTLプロセッサは、フォーマットIDが「SAP1」であるかどうかをチェックする。そうである場合、PTLプロセッサは、トランザクションを生成したのがSAP NW(NetWeaver) JS(Javascript) TMであることを知る。
・ その後、PTLプロセッサは、XIDに符号化されたTLOGバージョンが、PTLプロセッサが現在責任を負うTLOGバージョンのXIDと等しいかどうかを比較する。TLOGバージョンは、以下の部分、すなわち、システムIDと、ノードIDと、TM起動時間から成る。システムIDは、システムを識別する。ノードIDは、クラスタ内のノードを一意的に識別する。インスタンスIDは、このIDにすでに混合されており、別個に追加される必要はない。TM起動時間は、GMT時刻のTMの起動日付/時間である。粒度はミリ秒である。1ミリ秒以内にTMを2回起動することは不可能であると見なされている。代替実施形態は、これらのパラメータを調整することができる。

3.3 XID構造
XID構造の異なる部分は、フォーマットIDと、拡張グローバルトランザクションIDと、ブランチ修飾子を含む。フォーマットIDは、(一実施形態によれば)「SAP1」である。「1」は、代替実施形態では、バージョン情報で置き換えることができる。ブランチ修飾子は、TLOG内でRMを一意的に識別する。

拡張グローバルトランザクションIDは、グローバルトランザクションIDと、ブランチ反復子を含む。ブランチ反復子は、Java(登録商標)EEのres-sharing-scopeが共用不可能に設定されるという稀な状況で使用されることがある。

グローバルトランザクションIDは、TLOGバージョンと、トランザクションシーケンス番号と、トランザクション生成時間と、トランザクション放棄時間と、TX名識別子を含む。TLOGバージョンは、トランザクションログインスタンスを識別する。トランザクションシーケンス番号は、TLOG内でトランザクションを一意的に識別する。トランザクション生成時間は、TMによってトランザクションが生成されたGMT時刻の日付および時間である。トランザクション放棄時間は、トランザクションが放棄される日付および時間である。TX名識別子は、使用されたトランザクション名の一意識別子である。

基本的に、トランザクションシステムの適切な機能のために必要とされるアトリビュートと、ピギーパックされ、特定のトランザクションについての追加情報を与えるアトリビュートの、2種類のアトリビュートを区別することができる。推定アボート戦略のため、時としてXIDは、トランザクションの回復中にTMが有する唯一の情報であることを思い出されたい。TMがトランザクションをロールバックすることを決定したため、TLOGエントリは存在しないが、RMがrecoverコールの結果としてXIDを返した場合がこれである。

ここで異なるアトリビュートの目的についての説明を示す。

3.3.1 トランザクションシーケンス番号
この番号は、TLOG内でトランザクションを一意的に識別する。TLOGがDBMSデータである場合、シーケンス番号は、インデックスカラムである。番号は、TMが起動する場合にゼロから開始し、止まることなく増加する。毎秒10000個のトランザクションが存在する場合、8バイトの長さは、数百万年の耐用時間をサポートするのに十分である。番号間のギャップが許される。

3.3.2 トランザクション生成時間
このアトリビュートは、もっぱら情報用である。TMがトランザクションを生成した場合にGMT時刻の時間が設定される。トランザクション生成時間は、問題の根本原因を識別するためにログのどの部分に目を通すべきかについてのヒントをデータベース管理者に与えるので、トランザクションが問題を有する理由を彼らが見出すのに役立てることができる。

3.3.3 トランザクション放棄時間
フォーマットはGMTであり、このアトリビュートは、トランザクションが生成された場合に設定される。後でこの時間を見つけた場合、PTLプロセッサは、いつトランザクションを放棄できるかを知る。これは関与するRMのたとえ一部にしろ、または全部に連絡が付かない場合である。現在時間が放棄時間より後である場合、トランザクションを放棄すること、トランザクションのためにPTLプロセッサが有しているすべてのメモリを消去することは、PTLプロセッサの自由である。

3.3.4 トランザクション名識別子
完了トランザクション名をGTRIDに保存することは、XIDを破裂させる。それの代わりに、トランザクション名テーブル内のエントリを指し示す僅か4バイトの整数値が保存される。

3.3.5 ブランチ反復子
いくつかのJava EE仕様は、リソース参照を定義することを可能にする。これは、res-sharing-scope要素の定義を含む。ブランチ反復子は、与えられたリソースマネージャ接続ファクトリ参照を通して獲得された接続が共用できるかどうかを指定する。この要素の値は、指定された場合、以下の2つのうちの一方、すなわち、共用可能または共用不可能でなければならない。デフォルト値は共用可能である。ここでEJB配備ディスクリプタからの一例を示す。
<resource-ref>
<res-ref-name>jdbc/CustomerDBMS</res-ref-name>
<res-type>javax.sgl.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>

このアトリビュートを共用不可能に設定するのは、ほぼすべての状況下で悪い考えである。それは接続共用が許可されず、結局はアプリケーションが同じRMへのいくつかの物理接続を有するようになることを意味する。実際の例を示す。
・ トランザクションが、tx4711というXIDを与えられてTMによって開始される。
・ アプリケーションが、RMへの新しい接続を取得する。この接続に対して、関連付けられたXAリソースインスタンスが常に存在する。このインスタンスをXAResource1と呼ぶことにする。TMが、接続をXID 4711と関連付ける。
XAResource1.start(tx4711);
・ 今度は、アプリケーションが、同じRMへの第2の接続を生成する。この接続に関連付けられたXAリソースをXAResource2と呼ぶことにする。通常、TMは以下のコードを発行する。
XAResource2.start(tx4711);

残念なことに、XAResource1とXAResource2は同じRMを指し示しているので、これはうまくいかない。RMは、このグローバルトランザクションIDを与えてトランザクションを開始したTMがすでに存在すると苦情を言う。これら2つの接続の背後にいるTMが同じであることをRMは知らないので、この苦情には正当な根拠がある。RMは、それにアクセスする2つのTMが存在し、おそらく一方が後の時点でトランザクションをコミットするように要求し、他方がトランザクションをロールバックするように要求するであろうことを仮定しなければならない。そのため、RMは、同じXIDに影響(infect)される2つの物理接続を許容することができない。

これを克服する1つの可能性は、これらの接続に異なるグローバルトランザクションIDを使用することである。まさにこの目的が、1バイト長のブランチ反復子を提供する。最初の接続は、ブランチ反復子0を取得し、同じRMへの次の接続は、1だけ増やされたブランチ反復子を取得する。以降も同様である。これは、単一のトランザクション内の接続の数を、1つのRMから256までに制限し、それを超えると、例外がスローされる。

RMにとって、2つのトランザクションは、互いにまったく関係しない。そのため、リソース共用が共用不可能に設定された場合、単一のRM内であっても2PCセマンティクスが存在する。

TMにとって、それはまだ単一のトランザクションであり、TMがコミットすると決定した場合、TLOG内にはただ1つのレコードが存在する。

3.3.6 拡張グローバルトランザクションID
グローバルトランザクションIDは、アプリケーションサーバ内、例えば、TMおよびPP内でのトランザクションの表現である。このIDはその上、TLOG内でトランザクションを識別する。

外部RMは、このグローバルトランザクションIDを見ないが、グローバルトランザクションIDとブランチ反復子の組合せは見る。両方のアトリビュートは一緒に、拡張グローバルトランザクションIDを形成する。

4. トランザクションログ構造
4.1 トランザクションログのエンティティ
トランザクションログは、トランザクション回復を達成するために必要とされる異なるエンティティを保存する。これらのエンティティは、TLOGエンティティと、TLOGエントリエンティティと、トランザクション名エンティティと、RMエンティティと、メモリ内エンティティを含む。

4.1.1 TLOGエンティティ
TLOGエンティティは、各論理トランザクションログに対して1つのインスタンスを有する(DBMSの場合は1つのレコードに変換される)。TLOGのオーナは、このインスタンスを更新し、オーナアトリビュートにオーナの識別情報を、保有の有効期限までleasedUntilアトリビュートにGMT時刻を供給することによって、完全なログを保有することができる。その時間の後、TLOGは誰からも利用可能と見なされる。

オーナは、オーナの役割(TMまたはPP)とクラスタノードIDの組合せである。

ファイルシステムの場合、このエンティティは必要なしとすることができる。ファイル名がバージョン識別子として機能し、ロッキングはOSによって制御される。

4.1.2 TLOGエントリエンティティ
TMは、トランザクションを識別するグローバルトランザクションIDを生成する。このトランザクションに参加するすべてのRMはブランチであり、TMによって割り当てられたブランチIDを取得する。このブランチIDは、TMの全ライフタイムにわたって、すなわち、TMの起動からシャットダウンまで同じであり続ける。それまでTMに知られていなかった新しいRMをトランザクションが使用する場合、TMは、このRMをRMエンティティに追加する。ブランチIDの生成は、単にTMの内部カウンタを増加させることによって行うことができる。

以下の理由で、ブランチIDがTLOGエンティティに保存される。
・ RM a、b、cを含むトランザクションtx1が存在するとする。
・ PTLプロセッサは、完全なログにはRM a、b、c、dが含まれることを知っている。
・ そのため、回復シーケンスの開始時に、PTLプロセッサは、RM a、b、c、dに対してrecoverをコールする。しかし、RM dは一時的または永続的故障のために現在利用可能ではない。
・ RM dの利用不可能性にも関わらず、PTLプロセッサは、RM dが含まれていなかったことを確実に知っているので、tx1を回復することができる。

TLOGがファイルベースである場合、例えば、java.util.zip.CRC32など、チェックサムをachエントリの最後に追加すべきである。そのため、有効なレコードを有しているか、それとも停止しつつあるTMの断片を有しているかが明らかである。

4.1.3 トランザクション名エンティティ
SAP TMは、人間に可読のトランザクション名を指定することを加えて可能にする。これは、回復サービスが後で問題を管理者に報告する必要がある場合に役立てることができる。「Xid 4711が発見的結果を有した」と報告する代わりに、メッセージを「トランザクション『注文記帳』が発見的結果を有する」とすることができる。トランザクション名は、「注文＃12345」のようにトランザクションインスタンスに固有とすべきではなく、トランザクション分類子により近いものである。

トランザクション名の別の利点は、モニタリングがより有意味となり得ることである。トランザクションスループットおよび障害は、トランザクション名によって掘り下げることができる。

TMは、いずれかのRMに対して最初の準備コールを行う前に、トランザクション名エンティティに書き込む。TLOG自体においては、グローバルトランザクションIDの部分である短いtransactionNameIdだけが保存される。アプリケーションがトランザクション名を使用しない場合、レコードは書き込まれない。

トランザクション名には1つのリスクが存在する。アプリケーションがトランザクションインスタンス固有の名前を使用する場合、TMは、TLOGを更新するのに加えて、トランザクション毎にこのエンティティへの書き込み操作を行うことになる。これは書き込み操作の回数を2倍にする。その上、トランザクション名テーブルが無制限に増大する。

そのため、一実施形態によれば、例えば1000など、トランザクション名の最大数に設定可能な制限を設けることができる。その数を超えると、新しいトランザクション名は無視される。代替として、内部トランザクション名キャッシュに対してLRU(最長時間未使用)戦略を実施することができる。多数のトランザクション名を許容することに明らかな利点は存在しないので、制限は過剰(overkill)であってもよい。

4.1.4 RMエンティティ
すでに言及されたように、TMは、ライフタイム中にTMによって使用されたすべてのRMについて永続的エンティティを生成する。この情報は、回復時にXAリソースマネージャを再生成するのに十分でなければならない。これは、XAResourceFactoryIdが保存され、このタイプのXAResourceを生成できるリソースファクトリを指し示すことを暗示する。ファクトリはその上、再生成タスクを実行するために、名前と、プロパティと、証明書を取得する。TLOGがファイルシステムベースである場合、RMエンティティはそれ自体がファイルになる。RMエンティティは証明書を保存するので、それは暗号化される。

RMエンティティは、TLOGエントリが咀嚼(digest)される前に、PTLプロセッサによって読み込まれる。recoverコールがRMエンティティ内のすべてのRMに対して行われ、その後、TLOGエントリが処理されて、PTLにデータ投入を行う。

4.1.5 メモリ内エンティティ、RMにおけるトランザクション表現、およびエンティティライフサイクル
永続的エンティティに加えて、トランザクションのメモリ内表現と、RMにおけるトランザクションの表現が存在する。以下のシーケンスは、異なるエンティティにどのようにデータが投入されるかについて説明する。
・ 最初に、TMがグローバルトランザクションIDを生成する。
・ アプリケーションは、任意選択的にトランザクション名をトランザクションに割り当てることができる。アプリケーションは、最初のRMが接触される前にそれを行うべきである。
・ TMは、トランザクション名を内部トランザクション名キャッシュと比較することによって、トランザクション名がすでに知られているかどうかをチェックする。知られている場合、TMは、トランザクション名識別子としてキャッシュ内の位置を利用する。知られていない場合、TMは、トランザクション名を内部キャッシュに追加し、トランザクション名識別子を割り当て、トランザクション名をトランザクション名エンティティに書き込む。(このステップは、最初のxa_start()が行われるまで遅延させることができる)。

4.2 トランザクションログライフサイクル
各分散トランザクションがトランザクションログに追加される。トランザクションが完了した場合、もはやメモリを維持する必要はなく、そのため、その特定のトランザクションは、削除対象とすることができる。ディスク/DBMSへの書き込み操作を削減するため、この削除は時期を遅らせて行われるべきである。この遅延手法(lazy approach)は、ログ内にすでに完了したトランザクションが存在するという結果をもたらし得る。PTLプロセッサ全体は、これが問題を引き起こさないように設計される。回復時、PTLプロセッサは、ログ内で完了トランザクションを発見し、どのRMも一致するXidを返さなかったことを見出す。そのため、PTLプロセッサは、このトランザクションをもはや何の関心も引かないものと仮定する。

4.2.1 DBMSベースのトランザクションログ
TMは、完了トランザクションを追跡記録するメモリ内データ構造を有する。事前定義されたエントリ数(例えば100)を超えると、TMは、
DELETE FROM TLOG_ENTRIES WHERE XID IN (Xid1, Xid2, ..., Xid 100)
によってTLOGエントリテーブルに対して単一の削除操作を実行する。

PTLプロセッサは、同様の方法でエントリの削除を行う。PTLへのデータ投入を終えた場合、PTLプロセッサは、TLOG内に存在するが、もはやアクティブではないすべてのXidを知っている。PTLプロセッサは、上に示したのと同様なSQL削除操作を発行する。

TMが通常のシャットダウンシーケンスに遭遇し、もはやアクティブトランザクションが存在しない場合、完了トランザクションログに相当するTLOGテーブル内のレコードをさらに削除するかどうかはTMの自由である。

回復サービスがあるトランザクションログについてもはや保留トランザクションをもたない場合、回復サービスは、このトランザクションログに相当するTLOGテーブル内のレコードを削除するによって、完了トランザクションログをさらに削除する。

4.2.2 ファイルシステムベースのトランザクションログ
TLOGがファイルシステムに基づく場合、新しいファイルのオーバフローに対処しなければならない。TMは、すべてのアクティブトランザクションおよび保留トランザクションについて知っているので、以下のオーバフロー手順は、ファイルが事前定義された設定可能なエントリ数(例えば1000)に達した場合に行われる。
・ 新しいトランザクションログファイルが生成される。
・ 新しいRMログファイルが生成される。
・ すべてのアクティブトランザクションおよび保留トランザクションが新しいログファイルにコピーされる。
・ これらのアクティブトランザクションおよび保留トランザクションによって使用されるすべてのRMが新しいRMログにコピーされる。
・ 旧いファイルを指し示すすべての内部データ構造が新しいファイルを指し示すように更新される。
・ 旧いファイル(TLOGおよびRMログ)が削除される。

回復サービスは、どの個々のエントリも削除しない。しかし、回復サービスは、あるトランザクションログに属する最後の保留エントリを終えたかどうかをチェックする。終えた場合、回復サービスは、最後の保留エントリが属するTLOGおよびRMログを削除する。典型的には約1日であるトランザクション放棄時間が存在するので、完了トランザクションログは、最後のエントリが追加された後、1日より長く生存することはできない。

5. 介在トランザクションマネージャ(Interposed Transaction Manager)
大部分の利用シナリオでは、アプリケーションサーバは、そのトランザクションの完全な制御下にある。これに対する注目すべき例外は、リリース1.5以降のJavaコネクタアーキテクチャによって引き起こされる。この仕様では、リソースアダプタがインポートトランザクションをアプリケーションサーバに伝播でき、アプリケーションサーバおよびそれ以降の参加者が作業をインポートトランザクションの部分として行うことができることが定義される。

この契約は、リソースアダプタが、企業情報システム(EIS)によって開始されたトランザクション完了およびクラッシュ回復コールを流し入れる(flow-in)ことを可能にする。

そのため、アプリケーションサーバは外部トランザクションマネージャに対して通常のRMとして機能すると要約される。これを達成するため、アプリケーションサーバは、介在TMをホストする。介在TMは、RMライクなインタフェースを外部TMに提供し、内部RMを通常のTMのように調整する。

着信トランザクションのXIDは、介在TMによって発行される内部Xidにマッピングされる。これら2つの間のマッピングは、遅くとも準備時において存続していなければならない。

5.1 介在トランザクションマネージャのトランザクションタイムアウト
5.1.1 RMトランザクション放棄時間
JCA仕様は、JCAアダプタが同じトランザクションの部分としていくつかのインバウンド要求を行えるようにする。各要求について、アダプタは、要求の部分としてトランザクションタイムアウトを設定することができる。アダプタは、ExecutionContextを生成し、それに対してsetTransactionTimeoutメソッドをコールすることによって、これを達成する。ExecutionContextは、アダプタが生成したワーク(Work)インスタンスと一緒に、アプリケーションサーバのワークマネージャに送られる。

介在TMは、トランザクションを開始した最初の要求のトランザクションタイムアウトだけを使用する。介在TMは、フォローアップ要求を含む完了トランザクションに許容されるタイムスパンとしてこの時間を解釈する。このタイムアウトおよび現在のシステム時刻に基づいて、介在TMは、それ以後は自由にトランザクションを放棄できるGMT時刻の絶対時間を計算する。

すでに準備状態に達した分散トランザクションの場合、トランザクションを放棄することは、発見的決定を行うことに変換されるので、このタイムアウトの影響はかなり劇的である。

JCAアダプタがタイムアウトを定義しない場合、デフォルトタイムアウトが利用される。これは、システムワイドに定義され、またはアダプタの配備ディスクリプタ内に定義される。

5.1.2 準備前のRMトランザクションタイムアウト
トランザクションブランチは、準備に達する前に、すでにタイムアウトすることができる。準備前のトランザクションブランチのロールバックは、完了トランザクションの発見的結果を決してもたらすべきではない。そのため一般に、準備前のトランザクションタイムアウトはトランザクション放棄タイムアウトより短いことが期待される。Javaコネクタ仕様はそのようなタイムアウトを定義しないので、一実施形態によれば、SAP独自仕様のタイムアウトが設定される。そのような定義は、システムワイドな設定またはアダプタ固有の設定とすることができる。

5.2 介在TMのトランザクションログ
介在TMは、以下の情報を含む別個のトランザクションログを有する。
・ 外部TMの着信Xid。
・ 外部XidにマッピングされるアプリケーションサーバTMの内部Xid。
・ GMT時刻のトランザクション放棄時間。
・ トランザクションに参加するRMの、それらの賛意表明を含む識別情報。
・ 発見的に完了された場合の完了トランザクションの結果(HEURRB、HEURCOM、HEURMIX、HEURHAZ)。

トランザクション放棄時間が経過した後、TMは、トランザクションを発見的にロールバックしようと試みる。この操作の結果は、トランザクションログに保存され、そのため、次回に外部TMがトランザクションを継続しようと試みるとき、または介在TMに対してrecoverをコールするときにそれを報告することができる。介在TMは、外部RMがそれに対してforgetをコールするまで、発見的に完了されたトランザクションについてのエントリを維持する。

5.3 クラスタ内の介在トランザクションマネージャ
多くのJava(登録商標) EE仕様のように、Java(登録商標)コネクタアーキテクチャは、クラスタ環境においてフェイルオーバおよび負荷分散に対処しない。アプリケーションのロジックと、企業情報システム(EIS)がアプリケーションに送信するメッセージの内容に応じて、2つの場合を区別することができる。
・ メッセージはすべてのクラスタノード上で処理される必要がある。株式の市場価格のクラスタノード内部表現を更新する株式相場メッセージをその一例とすることができる。
・ メッセージはクラスタ内の単一のノードだけが受信できる。新規顧客レコードを生成する要求をDBMSで受信する「新規顧客」イベントを一例とすることができる。

どちらの場合も、一実施形態によってサポートされる。コネクタ仕様は、メッセージドリブンビーン(Message Driven bean)をEISから来るメッセージの消費者とするよう命じる。そのため、メッセージの並列配信をスイッチオンにする方法は、MDB[メッセージドリブンビーン]のDD[データ記述]内で「topic-on-all-nodes」を真に設定することである(この設定におけるトピックという用語は、ヒストリカル決定の結果ではなくJMSを指すので、誤解を招くかもしれない)。

別の問題は、EISが、異なるクラスタノード上のEIS固有アダプタからの着信接続を、同じ論理EISアダプタとして認識するかどうかである。ここでの注意事項(side mark)として、接続要求は常に、EISからではなくアダプタから発信される。挙動はEISおよび固有アダプタにのみ依存する。やはり、2つの場合を区別することができる。
・ EISはすべての着信接続が論理的に同一であると仮定する。これは、おそらくピータ(アダプタ)がトーマス(EIS)にモバイル電話を使用して電話を掛ける状況と比較することができる。モバイル電話の蓄電池が空になったために接続が切断され、そのため、ピータは再び、今度はオフィスの電話を使用して電話を掛ける。自分が先程と同じピータであることをピータが明らかにしたので、トーマスはピータと話し続けることができる。
・ EISはすべての着信接続が異なると仮定する。上で与えられた例では、トーマスの電話に示された着信発呼者idが異なるので、トーマスは、オフィスの電話を使用して自分に電話を掛けているピータは異なるピータであると主張する。

図7A〜図7Dは、本発明の一実施形態による、4つの使用事例を説明する。

図7Aでは、topic-on-all-nodesが真に設定され、EISは、両ノードが論理的に1つであると仮定して、それらと話しをする。EISは一方のノードにメッセージを送信し、別のノード上でトランザクションを準備し、最終的にどこか他の場所でコミットすることが可能である。

この挙動をサポートするため、深刻なボトルネックとなり得るクラスタワイドなトランザクションレジストリが必要とされる。そのため、本発明の一実施形態によれば、このシナリオをサポートしないという決定が下された。

図7Bでは、図7Aとの相違は、EISがノードは異なると考えることである。この結果として、トランザクションは厳格にノードに局所化されたものとなる。1つのノードがクラッシュした場合、そのノードが再び起動するまで、EISがrecoverをコールすることは不可能である。このシナリオは一実施形態によってサポートされる。

図7Cでは、topic-on-all-nodesが偽に設定される。ノード1がクラッシュした場合、アプリケーションサーバのフェイルオーバサポートに基づいて、メッセージ処理は自動的にノード2にシフトされる。言及しておくべきこととして、自動フェイルバックは存在しない。ノード1が再び起動したとしても、EISから来るメッセージをノード1が消費することはもうない。一実施形態はこのシナリオをサポートするが、いくつかの副作用を伴う。トランザクションが開始したがフェイルオーバ前に終了しなかった場合、以下の規則が適用される。
・ トランザクションがまだ準備状態前だった場合、トランザクションは関与するバックエンドRMによって自動的にロールバックされる。さもなければ、共用トランザクションレジストリが必要とされる。
・ トランザクションが準備後である場合、介在TMのトランザクションログ内にエントリが存在する。ノード2は、ノード1上で開始されたトランザクションのためのcommit/rollback/recover要求を受信する。これを可能にするため、介在TMのトランザクションログが共用されなければならない。

図7Dでは、topic-on-all-nodesが偽に設定される。ノード1のクラッシュ後、ノード2内のアダプタがEISへの接続を確立する。EISは、ノード2上のアダプタをクラッシュアダプタに関係するものとは認識しない。そのため、EISは、フェイルオーバ時間前に開始されたどのトランザクションも続行しようとは試みない。一実施形態はこのシナリオを実施するが、それは発見的トランザクション結果をもたらすので、文書にはサポートされないと記載されることがある。

6. トランザクションログ書き込みアクセラレータ
2フェーズコミットトランザクション処理は、その物理I/Oのため、非XAスタイル処理と比べて非常に重い。その大部分は、単一のトランザクション内で必要とされる複数のディスクフォース(disk force)が存在するという事実による。一例として、関与する2つのRDMBSが存在し、すべてが同じディスクに書き込む、トランザクションを考える。
・ 準備時には、両RMが2つのディスクフォースを有する。各RMに1つ、合計で2つ。
・ コミットを決定した場合、TMはTLOGに書き込む。別のディスクフォース。
・ 両RMがコミットする。別の2つディスクフォース。
・ 後でTLOGエントリは除去されるが、これは再度のフォーシングなしに行われる。

そのため、ローカルトランザクションが使用される場合、単一のディスクフォースの代わりに、結局は合計で5つのディスクフォースになる。ディスクフォースのために必要とされる時間量は、利用可能なディスクに応じて、5から50ミリ秒の間となることが予測できる。トランザクションペイロードが小さい場合、ディスク同期がトランザクションハンドリングにおける支配的な部分になり得るので、高速である必要がある。

一実施形態は、TLOGに対する更新を一緒にグループ化して、それをファイルシステムまたはDBMSに対する単一の操作の部分として実行することによって、スループットを高める。実際には、これは、同期が完了するまで、TMにアクセスするアプリケーションスレッドのグループが遅延させられることを意味するが、それは、TMにアクセスするアプリケーションスレッドはすべて単一の同期操作に一緒にグループ化されるためである。
・ 臨界スループットより下では、TLOGに対する更新を一緒にグループ化しても意味はない。ログへの各更新は、アプリケーションスレッド自体によって実行される。そのため、同期操作当たりのTLOGに対する更新の回数は1である。
・ 臨界スループットより上では、I/Oがボトルネックになる。ディスクまたはDBMSが処理できるより多くの、TLOGへの追加を望むアプリケーションスレッドが存在する。これは、システムが達成できる最大スループットに深刻な限界を導入する。

この問題を克服するため、異なるアプリケーションスレッドの更新は一緒にグループ化され、TLOGに対する単一の同期動作として実行される。TMのトランザクションスループットが高まる場合、ますます多くのTLOGに対する更新が一緒にグループ化される。

その後、一実施形態によれば、TM実施は2つのモードをサポートする。
・ 低スループットモード:アプリケーションスレッド内でのTLOG更新。
・ TLOGバッチモード: TLOG更新は別個のスレッドで行われる。

ここでの課題の1つは、いつTLOGバッチモードに切り替えるのが有利かを決定することであり、言い換えると、臨界スループット数をどのように定めるかである。この数はハードウェアに依存する。一実施形態は、以下を試みることによってこのマジック数を見出す自己適応メカニズムを実施する。
・ TLOGバッチモードでは、各アプリケーションスレッドは、そのTLOG更新をバッファに追加する。
・ 別個のスレッドがバッファの内容を取得し、それをTLOGに書き込む。スレッドが書き込みを完了した場合、バッファに追加した多くのアプリケーションスレッドによってすでにバッファが満たされていることをスレッドは見出す。スレッドは再びバッファを取得し、待機しているアプリケーションスレッドを解放する。以降も同様である。
・ スレッドが戻って来て、バッファ内で待機しているエントリが存在しないこと、または1つしか存在しないことを知った場合、スレッドが本当は必要とされていないことをスレッドは知る。グループ化の要求は存在しない。スレッドはEmptyCycleカウンタを1だけ増加させる。
・ バッファが2つ以上のエントリで満たされているのをスレッドが見出した場合、スレッドはNonEmptyCycleを1だけ増加させ、EmptyCycleカウンタをゼロに設定し戻す。
・ EmptyCycleカウンタが事前定義されたエンプティサイクルの最大数(例えば100)を超えた場合、スレッドは低スループットモードに切り替え、自らを非活動化する。これはTLOGバッチサブシステムの出口基準である。バッチサブシステムが直ちには自らを非活動化しない理由は、ヒステリシス挙動(hysteresis behavior)を実施するためである。トランザクションシステムが臨界スループット周辺にある場合、トランザクションシステムは、TLOGバッチと低スループットモードの間を絶えず往復することはなく、低トランザクション要求を有するより長いタイムスパンが存在する場合に限る。

TMがTLOGバッチモードをいつオフに切り替えるかが明らかになった後では、問題はそれをいつオンに切り替えるかである。このために、NonEmptyCycleカウンタが使用できる。NonEmptyCycleカウンタが小さい場合、それはTLOGバッチサブシステムがすべきことを本当は多くもたないことを意味する。言い換えると、あまりに最初のうちからそれをオンに切り替えても無意味である。

他方、TMは現在のトランザクションスループットを知っている。これはトランザクションの総数をカウントし、それらが要した時間でそれらを除算することによって達成される(例えば、全100トランザクションまたは全10秒、スループットが計算される)。

そのため、NonEmptyCycleが低い場合、現在のトランザクションレートより下では、バッチモードをオンに切り替えても意味はないという結論を引き出すことができる。これは臨界スループット数についての新しい推測を定める。現在のトランザクションレートが臨界スループット数より上の場合、TMは再びTLOGバッチモードをオンに切り替える。何回かの繰り返しの後、臨界スループット値は、現在のハードウェア機器に適合したレートに達する。

図8は、本発明の実施形態を実施するためのコンピュータシステムおよびネットワークの一例1400のブロック図である。コンピュータシステム1410は、情報を伝達するためのバス1405または他の通信機構と、情報を処理するための、バス1405と結合されたプロセッサ1401とを含む。コンピュータシステム1410は、上述された技法を実行するための情報および命令を始めとする、プロセッサ1401によって実行される情報および命令を保存するための、バス1405に結合されたメモリ1402も含む。このメモリは、プロセッサ1401によって実行される命令の実行中に、一時変数または他の中間情報を保存するためにも使用することができる。このメモリの可能な実装は、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、またはその両方とすることができるが、それらに限定されない。情報および命令を保存するために記憶装置1403も提供される。記憶装置の一般的形態は、例えば、ハードドライブ、磁気ディスク、光ディスク、CD-ROM、DVD、フラッシュメモリ、USBメモリカード、またはコンピュータが読み取ることができる他の任意の媒体を含む。記憶装置1403は、例えば、上述の技法を実行し、または構成を実施するための、ソースコード、バイナリコード、またはソフトウェアファイルを含むことができる。

コンピュータシステム1410は、情報をコンピュータユーザに表示するために、ブラウン管(CRT)または液晶表示(LCD)などのディスプレイ1412にバス1405を介して結合することができる。キーボードおよび/またはマウスなどの入力装置1411は、ユーザからプロセッサ1401に情報およびコマンド選択を伝達するために、バス1405に結合される。これらの構成要素の組合せは、ユーザがシステムと通信できるようにする。いくつかのシステムでは、バス1405は、多数の専用バスに分割することができる。

コンピュータシステム1410は、バス1405と結合されるネットワークインタフェース1404も含む。ネットワークインタフェース1404は、コンピュータシステム1410とローカルネットワーク1420の間の双方向データ通信を提供することができる。ネットワークインタフェース1404は、例えば、電話線を介したデータ通信接続を提供するデジタル加入者線(DSL)またはモデムとすることができる。ネットワークインタフェースの別の例は、互換性のあるLANへのデータ通信接続を提供するローカルエリアネットワーク(LAN)カードである。別の例には無線リンクもある。そのような実施のいずれにおいても、ネットワークインタフェース1404は、様々なタイプの情報を表すデジタルデータストリームを搬送する電気、電磁気、または光信号を送受信する。

コンピュータシステム1410は、メッセージまたは他のインタフェースアクションを始めとする情報を、ネットワークインタフェース1404を介して、イントラネットまたはインターネット1430に送受信することができる。インターネットの例では、ソフトウェアコンポーネントまたはサービスは、ネットワーク全域にわたる多数の異なるコンピュータシステム1410またはサーバ1431、1432、1433、1434、1435上に存在することができる。サーバ1431は、アクションまたはメッセージを、1つの構成要素から、インターネット1430、ローカルネットワーク1420、およびネットワークインタフェース1404を介して、コンピュータシステム1410上の構成要素に送信することができる。

コンピュータシステムおよびネットワーク1400は、クライアントサーバ方式で構成することができる。クライアント1415は、コンピュータシステム1410の構成要素に類似した構成要素を含むことができる。

より具体的には、コンピュータシステム1410は、アプリケーションサーバ(例えば図2の114d)を実施することができる。

上述の説明は、本発明の態様がどのように実施できるかについての例とともに、本発明の様々な実施形態を説明している。上述の例および実施形態は、当該実施形態に限られたものと見なされるべきではなく、以下の特許請求の範囲によって確定される本発明の柔軟性および利点を説明するために提示されている。上述の開示および以下の特許請求の範囲に基づいて、他の構成、実施形態、実装、および均等物が、当業者には明らかであり、それらは、特許請求の範囲によって確定される本発明の主旨および範囲から逸脱することなく利用することができる。

100 分散コンピューティング環境
102 クライアント層
104 アプリケーション層
106 データベース層
108 ネットワーク
112 クライアント
114 アプリケーションサーバ
116 リソースサーバ
120 トランザクションログサーバ
130 共用トランザクションログ
132 トランザクションマネージャ
134 PTLプロセッサ
302 ノード
304 PTLプロセッサコントローラ
306 TL獲得フラグ
308 保留トランザクションリスト
320 トランザクションログ
322 トランザクションログ
1400 コンピュータシステムおよびネットワーク
1410 コンピュータシステム
1401 プロセッサ
1402 メモリ
1403 記憶装置
1404 ネットワークインタフェース
1411 入力装置
1412 ディスプレイ
1415 クライアント
1420 ローカルネットワーク
1430 インターネット
1431 サーバ
1432 サーバ
1433 サーバ
1434 サーバ
1435 サーバ

Claims (18)

1. 分散コンピューティング環境におけるトランザクション回復のためのシステムであって、
   共用トランザクションログを保存するトランザクションログサーバと、
   分散トランザクションアプリケーションを実施し、前記分散トランザクションアプリケーションを使用してトランザクションを実行する場合に前記共用トランザクションログにアクセスする、複数のアプリケーションサーバと、
   データを保存し、前記トランザクションに従って前記データにアクセスするために前記複数のアプリケーションサーバとともに動作する、複数のリソースサーバと、を備え、
   前記複数のアプリケーションサーバ、前記複数のリソースサーバ、および前記トランザクションログサーバが、ネットワークを介して接続された複数のハードウェア装置によって実施され、
   前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが故障アプリケーションサーバになった場合、それまでは前記故障アプリケーションサーバによってアクセスされていた前記共用トランザクションログ部分に対する責任をアクティブアプリケーションサーバが引き受ける、システム。
2. 前記トランザクションログサーバが、ファイルシステムおよびデータベース管理システムの一方を含む、請求項1に記載のシステム。
3. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
   前記トランザクションを実行するトランザクションマネージャと、
   前記共用トランザクションログにアクセスする保留トランザクションリストプロセッサと、
   を備える、請求項1に記載のシステム。
4. 前記複数のアプリケーションサーバのうちの第1アプリケーションサーバが、
   前記第1アプリケーションサーバに対応する前記共用トランザクションログの第1部分にアクセスし、それまでは前記故障アプリケーションサーバによってアクセスされていた前記共用トランザクションログの前記部分にアクセスする、保留トランザクションリストプロセッサ
   を備える、請求項1に記載のシステム。
5. 前記共用トランザクションログが、複数の論理トランザクションログを含み、前記複数の論理トランザクションログの各々が、前記複数のアプリケーションサーバの対応する1つ、および対応するラン識別子に関連付けられる、請求項1に記載のシステム。
6. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
   複数の保留トランザクションを保存する保留トランザクションリストと、
   前記共用トランザクションログおよび前記保留トランザクションリストにアクセスする保留トランザクションリストプロセッサと、
   を備える、請求項1に記載のシステム。
7. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
   前記共用トランザクションログから削除されるエントリを保存する削除対象リストと、
   トランザクションマネージャが完了トランザクションを完了したときに前記完了トランザクションを前記共用トランザクションログから前記削除対象リストに追加し、前記削除対象リストが定められたサイズに達したときに前記共用トランザクションログからの前記削除対象リスト内の前記エントリを削除する、トランザクションマネージャと、
   を備える、請求項1に記載のシステム。
8. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
   前記共用トランザクションログに対するグループ更新を実行するトランザクションマネージャ
   を備える、請求項1に記載のシステム。
9. 分散コンピューティング環境におけるトランザクション回復のコンピュータ実施方法であって、
   トランザクションログサーバを用いて共用トランザクションログを保存するステップと、
   複数のアプリケーションサーバを用いて分散トランザクションアプリケーションを実施するステップであって、前記分散トランザクションアプリケーションを使用してトランザクションを実行する場合に前記分散トランザクションアプリケーションが前記共用トランザクションログにアクセスする、実施するステップと、
   複数のリソースサーバを用いてデータを保存するステップであって、前記トランザクションに従って前記データにアクセスするために前記複数のリソースサーバが前記複数のアプリケーションサーバとともに動作する、保存するステップと、を含み、
   前記複数のアプリケーションサーバ、前記複数のリソースサーバ、および前記トランザクションログサーバが、ネットワークを介して接続された複数のハードウェア装置によって実施され、
   前記複数のアプリケーションサーバのうちの１つのアプリケーションサーバが故障アプリケーションサーバになった場合、それまでは前記故障アプリケーションサーバによってアクセスされていた前記共用トランザクションログ部分に対する責任をアクティブアプリケーションサーバが引き受ける、コンピュータ実施方法。
10. 前記共用トランザクションログが、複数の論理トランザクションログを含み、前記複数の論理トランザクションログの各々が、前記複数のアプリケーションサーバの対応する1つ、および対応するラン識別子に関連付けられる、請求項9に記載のコンピュータ実施方法。
11. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
    複数の保留トランザクションを保存する保留トランザクションリストと、
    前記共用トランザクションログおよび前記保留トランザクションリストにアクセスする保留トランザクションリストプロセッサと、
    を備える、請求項9に記載のコンピュータ実施方法。
12. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
    前記共用トランザクションログから削除されるエントリを保存する削除対象リストと、
    トランザクションマネージャが完了トランザクションを完了したときに前記完了トランザクションを前記共用トランザクションログから前記削除対象リストに追加し、前記削除対象リストが定められたサイズに達したときに前記共用トランザクションログからの前記削除対象リスト内の前記エントリを削除する、トランザクションマネージャと、
    を備える、請求項9に記載のコンピュータ実施方法。
13. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
    前記共用トランザクションログに対するグループ更新を実行するトランザクションマネージャ
    を備える、請求項9に記載のコンピュータ実施方法。
14. 複数の有形な記憶媒体上で実施されるコンピュータプログラムであって、
    トランザクションログサーバによって保存される共用トランザクションログと、
    トランザクションを実行する場合に前記共用トランザクションログにアクセスする、複数のアプリケーションサーバによって保存される分散トランザクションアプリケーションと、
    前記トランザクションに従って前記分散トランザクションアプリケーションによってアクセスされる、複数のリソースサーバによって保存されるデータと、を含み、
    前記複数のアプリケーションサーバ、前記複数のリソースサーバ、および前記トランザクションログサーバが、ネットワークを介して接続された複数のハードウェア装置によって実施され、
    前記複数のアプリケーションサーバのうちの１つのアプリケーションサーバが故障アプリケーションサーバになった場合、それまでは前記故障アプリケーションサーバによってアクセスされていた前記共用トランザクションログ部分に対する責任をアクティブアプリケーションサーバが引き受ける、コンピュータプログラム。
15. 前記共用トランザクションログが、複数の論理トランザクションログを含み、前記複数の論理トランザクションログの各々が、前記複数のアプリケーションサーバの対応する1つ、および対応するラン識別子に関連付けられる、請求項14に記載のコンピュータプログラム。
16. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
    複数の保留トランザクションを保存する保留トランザクションリストと、
    前記共用トランザクションログおよび前記保留トランザクションリストにアクセスする保留トランザクションリストプロセッサと、
    を備える、請求項14に記載のコンピュータプログラム。
17. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
    前記共用トランザクションログから削除されるエントリを保存する削除対象リストと、
    トランザクションマネージャが完了トランザクションを完了したときに前記完了トランザクションを前記共用トランザクションログから前記削除対象リストに追加し、前記削除対象リストが定められたサイズに達したときに前記共用トランザクションログからの前記削除対象リスト内の前記エントリを削除する、トランザクションマネージャと、
    を備える、請求項14に記載のコンピュータプログラム。
18. 前記複数のアプリケーションサーバのうちの1つのアプリケーションサーバが、
    前記共用トランザクションログに対するグループ更新を実行するトランザクションマネージャ
    を備える、請求項14に記載のコンピュータプログラム。

Images