(57)【特許請求の範囲】
【請求項１】
コンピュータシステムにおけるトランザクション処理のための方法であって、
複数のサーバが、トランザクションを処理する要求を、クライアントから受信するステップと、
前記トランザクションのアクティブ段階の間に、前記トランザクションに参加するべきリソースの初期の組を登録するステップであって、前記クライアントによって直接的に又は間接的に登録された前記リソースの初期の組及び該リソースが存在するサーバのチェーンを反映するように前記トランザクションの状態を決定することを含むステップと、
引き続いて、前記複数のサーバにおける第１のサーバが、トランザクションのコミットをコールする要求を、クライアントから受信するステップと、
前記リソースを準備する前に前記トランザクションを前準備するステップであって、
前記チェーンが別のサーバを含むか否かを判断し、前記チェーンが別のサーバを含むと判断した場合、前記別のサーバに前準備要求を送信することと、前記登録されたリソースの組に追加のリソースを動的に加え、ここで、前記追加のリソースが異なるサーバにおけるものであった場合、必要に応じて前記チェーンに追加のサーバを加えることと、前記チェーンにおける前記サーバのすべて及び該サーバ上の前記追加のリソースを反映するように前記トランザクションの状態を変更することを含む前記トランザクションの前準備段階を、前記第１のサーバから順に、前記チェーンにおけるすべてのサーバが前記前準備段階を完了するまで繰り返す副ステップと、
前記チェーンにおける最後のサーバから前記第１のサーバに前準備応答を送信する副ステップとを含むステップと、
前記第１のサーバが、前記登録されたリソースの組における前記リソースを準備し、コミットするステップと、
を含むことを特徴とする方法。
【請求項２】
トランザクション処理のためのシステムであって、
トランザクションにおいて用いることができるリソースを含む複数のサーバを含み、
前記複数のサーバは更に第１のサーバを含み、
前記第１のサーバは、
前記クライアントによって直接的に又は間接的に登録されたリソースの初期の組及び該リソースが存在するサーバのチェーンを反映するように前記トランザクションの状態を決定し、
引き続いて、トランザクションのコミットをコールする要求を、クライアントから受信し、
追加のリソースが要求されているか否かを判断し、前記追加のリソースが異なるサーバにおけるものであった場合、前記チェーンに追加のサーバを加え、前記チェーンにおける前記サーバのすべて及び該サーバ上の前記追加のリソースを反映するために前記トランザクションの状態を更新し、前準備要求を前記チェーンにおける次のサーバに送信することを含む、前記トランザクションの前準備段階を前記リソースを準備する前に実行し、
前記次のサーバは、前記前準備要求を前記第１のサーバから受信し、次いで必要に応じて追加のサーバの追加を含む前記前準備段階を実行し、前準備要求を前記チェーンにおける他のサーバに送信し、前記チェーンにおけるすべてのサーバが前記前準備段階を完了するまで前記他のサーバが前記前準備段階を実行し、
前記第１のサーバが、前記チェーンにおいて最後にコールされた前記サーバから前準備応答を受信し、前記更新されたトランザクションの状態において識別された前記リソースを準備し、次いで該リソースをコミットすることを特徴とするシステム。
【請求項３】
前記第１のサーバは前記複数のサーバから選択されることを特徴とする請求項２に記載のシステム。
【請求項４】
前記複数のサーバの各々はトランザクションを処理する要求をクライアントから受信することができ、特定のトランザクションの要求に対して前記第１のサーバとして選択されるサーバは、前記トランザクションの要求をクライアントから受信するサーバであることを特徴とする請求項３に記載のシステム。
【請求項５】
前記チェーンにおいて最後にコールされたサーバから前記第１のサーバに前記前処理応答が送信される前の前記前処理段階の間の任意の時点で、追加のサーバが前記トランザクションに加えられることができることを特徴とする請求項２に記載のシステム。
【請求項６】
前記第１のサーバは、前記トランザクションについてのトランザクション・コーディネータ・サーバとして識別され、前記トランザクションに参加している他のすべてのサーバは、前記トランザクションについてのトランザクション・サブコーディネータ・サーバとして識別されることを特徴とする請求項２に記載のシステム。
【請求項７】
前記リソースのコールバックは、同期オブジェクトのコールバックであることを特徴とする請求項２に記載のシステム。
【請求項８】
コンピュータシステムにおけるトランザクション処理のための方法であって、
第１のサーバが、トランザクションを処理する要求を、クライアントから受信するステップと、
前記クライアントによって直接的に又は間接的に登録されたリソースの初期の組及び該リソースが存在するサーバのチェーンを反映するように前記トランザクションの状態を決定するステップと、
引き続いて、前記第１のサーバが、トランザクションのコミットをコールする要求を、クライアントから受信するステップと、
追加のリソースが要求されているか否かを判断し、前記追加のリソースが異なるサーバにおけるものであった場合、前記チェーンに追加のサーバを加え、前記チェーンにおける前記サーバのすべて及び該サーバ上の前記追加のリソースを反映するために前記トランザクションの状態を更新し、前準備要求を前記チェーンにおける次のサーバに送信することを含む、前記トランザクションの前準備段階を前記第１のサーバが実行し、
前記次のサーバが、前記前準備要求を前記第１のサーバから受信し、次いで必要に応じて追加のサーバの追加を含む前記前準備段階を実行し、前準備要求を前記チェーンにおける他のサーバに送信するステップと、
前記チェーンにおけるすべてのサーバが前記前準備段階を完了するまで前記他のサーバが前記前準備段階を実行するステップと、
前記第１のサーバが、前記チェーンにおいて最後にコールされた前記サーバから前準備応答を受信するステップと、
前記第１のサーバが、前記更新されたトランザクションの状態において識別された前記リソースを準備し、コミットするステップと、
を含むことを特徴とする方法。
【請求項９】
前記第１のサーバは前記複数のサーバから選択されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記複数のサーバの各々はトランザクションを処理する要求をクライアントから受信することができ、特定のトランザクションの要求に対して前記第１のサーバとして選択されるサーバは、前記トランザクションの要求をクライアントから受信するサーバであることを特徴とする請求項９に記載の方法。
【請求項１１】
前記チェーンにおいて最後にコールされたサーバから前記第１のサーバに前記前処理応答が送信される前の前記前処理段階の間の任意の時点で、追加のサーバが前記トランザクションに加えられることができることを特徴とする請求項８に記載の方法。
【請求項１２】
前記第１のサーバは、前記トランザクションについてのトランザクション・コーディネータ・サーバとして識別され、前記トランザクションに参加している他のすべてのサーバは、前記トランザクションについてのトランザクション・サブコーディネータ・サーバとして識別されることを特徴とする請求項８に記載の方法。
【請求項１３】
前記リソースのコールバックは、同期オブジェクトのコールバックであることを特徴とする請求項８に記載の方法。
【請求項１４】
第１のサーバが、トランザクションを処理する要求を、クライアントから受信するステップと、
前記クライアントによって直接的に又は間接的に登録されたリソースの初期の組及び該リソースが存在するサーバのチェーンを反映するように前記トランザクションの状態を決定するステップと、
引き続いて、前記第１のサーバが、トランザクションのコミットをコールする要求を、クライアントから受信するステップと、
追加のリソースが要求されているか否かを判断し、前記追加のリソースが異なるサーバにおけるものであった場合、前記チェーンに追加のサーバを加え、前記チェーンにおける前記サーバのすべて及び該サーバ上の前記追加のリソースを反映するために前記トランザクションの状態を更新し、前準備要求を前記チェーンにおける次のサーバに送信する副ステップとを含む、前記トランザクションの前準備段階を前記リソースの準備の前に前記第１のサーバが実行するステップと、
前記次のサーバが、前記前準備要求を前記第１のサーバから受信し、次いで必要に応じて追加のサーバの追加を含む前記前準備段階を実行し、前準備要求を前記チェーンにおける他のサーバに送信するステップと、
前記チェーンにおけるすべてのサーバが前記前準備段階を完了するまで前記他のサーバが前記前準備段階を実行するステップと、
前記第１のサーバが、前記チェーンにおいて最後にコールされた前記サーバから前準備応答を受信するステップと、
前記第１のサーバが、前記更新されたトランザクションの状態において識別された前記リソースを準備し、コミットするステップと、
をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記第１のサーバは前記複数のサーバから選択されることを特徴とする請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項１６】
前記複数のサーバの各々はトランザクションを処理する要求をクライアントから受信することができ、特定のトランザクションの要求に対して前記第１のサーバとして選択されるサーバは、前記トランザクションの要求をクライアントから受信するサーバであることを特徴とする請求項１５に記載のコンピュータ読み取り可能な記録媒体。
【請求項１７】
前記チェーンにおいて最後にコールされたサーバから前記第１のサーバに前記前処理応答が送信される前の前記前処理段階の間の任意の時点で、追加のサーバが前記トランザクションに加えられることができることを特徴とする請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項１８】
前記第１のサーバは、前記トランザクションについてのトランザクション・コーディネータ・サーバとして識別され、前記トランザクションに参加している他のすべてのサーバは、前記トランザクションについてのトランザクション・サブコーディネータ・サーバとして識別されることを特徴とする請求項１４に記載のコンピュータ読み取り可能な記録媒体。
【請求項１９】
前記リソースのコールバックは、同期オブジェクトのコールバックであることを特徴とする請求項１４に記載のシステム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
著作権表示
本特許文書の開示の一部は、著作権保護を受けた材料を含む。著作権者は、特許・商標事務所の特許ファイル又は記録に示されるように、特許文書又は特許開示の如何なる人による複製にも異議はないが、そうでない場合は、すべての著作権を保有する。
【０００２】
（技術分野）
本発明は、一般に、アプリケーション及びトランザクションサーバに関し、具体的には、コールバックプロセスをトランザクション又はメッセージの完了と同期させることを可能にするシステムに関する。
優先権主張
本出願は、２００２年７月１５日に出願された米国特許出願番号第＿号の「同期されたコールバック処理特徴をもったトランザクション処理システム及び方法」、２００１年７月１７日に出願された米国特許仮出願番号第６０／３０６，１０５号の「同期されたコールバック処理特徴をもったトランザクション処理システム」、及び２００１年７月３０日に出願された米国特許出願番号第６０／３０８，６９３号の「同期されたコールバック処理特徴をもったトランザクション処理システム」に基づく優先権を主張するものであり、これらの出願は引用によりここに組み入れられる。
相互参照
本出願は、発明者Ｅｄｗａｒｄ  Ｐ．Ｆｅｌｔ、Ｐｒｉｓｃｉｌｌａ  Ｆｕｎｇ、Ａｌｅｘ  Ｓｏｍｏｇｙｉ、及びＳｒｉｒａｍ  Ｓｒｉｎｉｖａｓａｎにより２００２年７月１５日に出願された係属中の米国特許出願番号第＿号の「トランザクション特性特徴をもったトランザクション処理システム」、発明者Ｅｄｗａｒｄ  Ｐ．Ｆｅｌｔ、Ｐｒｉｓｃｉｌｌａ  Ｆｕｎｇ、Ａｌｅｘ  Ｓｏｍｏｇｙｉ、及びＳｒｉｒａｍ  Ｓｒｉｎｉｖａｓａｎにより２００２年７月１５日に出願された米国出願番号第＿号の「委任コミット特徴をもったトランザクション処理システム」に関するものであり、これら出願のすべては本明細書において全体を引用によりここに組み入れられる。
【０００３】
（背景技術）
Ｊａｖａ２プラットフォーム、エンタープライズ・エディション（Ｊ２ＥＥ）仕様は、多層構成エンタープライズ・アプリケーションを開発する現在の基準の１つを定義するものである。Ｊ２ＥＥは、エンタープライズ・アプリケーションの設計、開発、組み立て、及び配置に対してコンポーネントベースの手法を提供し、これは、費用を下げ、より速い設計及び実施を可能にする。Ｊ２ＥＥプラットフォームは、多層構造の分散アプリケーションモデル、コンポーネントを再使用する能力、統一された機密保護モデル、及び融通性のあるトランザクション制御を開発者に与える。これらは、市場に対してかつてないほどに速い革新的なカスタマ・ソリューションを供給できるだけでなく、結果としてもたらされるプラットフォームに異存しないＪ２ＥＥコンポーネントベースのソリューションは、どのベンダの製品及びアプリケーション・プログラム・インターフェース（ＡＰＩ）にも拘束されない。
Ｊ２ＥＥ仕様は、以下の種類のコンポーネント、すなわちアプリケーション・クライアント・コンポーネント、エンタープライズＪａｖａＢｅａｎｓ（ＥＪＢ）、サーブレット及びＪａｖａサーバページ（ＪＳＰ）（ウェブコンポーネントとも呼ばれる）、及びアプレットを定義する。多層構造の分散アプリケーションモデルは、アプリケーション論理が機能によりコンポーネントに分割されて、異なるアプリケーション・コンポーネントが同じであるか又は異なるサーバ上でＪ２ＥＥアプリケーションを構成することができるということを含意する。アプリケーション・コンポーネントが実際にはどこにインストールされるかは、該アプリケーション・コンポーネントが、多層構造Ｊ２ＥＥ環境のどの層に属するかによって決まる。これらの層は図１に示される。図示されるように、ここでは、アプリケーション・サーバの層４は、ＥＪＢコンテナ及び／又はサーブレット、ＪＳＰ、及びｈｔｍｌページのような表示コンテナを開発するように用いられる。これらは、次に、クライアント８及びクライアント・アプリケーションが配置されるクライアント層２と、エンタープライズ又はエンタープライズ・リソース・プラニング（ＥＲＰ）システムのようなレガシー・アプリケーションをホストするために用いられる後端層６との間のインターフェースとして用いられる。
【０００４】
クライアント層。これらは、ブラウザ、Ｊａｖａベースのプログラム、又は企業のファイヤウォールの内側及び外側両方のクライアント層内で作動している他のウェブ使用可能プログラミング環境とすることができる。
アプリケーション・サーバ層。通常、この層は、表示論理及びビジネス論理の組み合わせをホストして、クライアントの要求を支持するようにする。表示論理は、ＨＴＭＬページを表示するＪＳＴページ及びサーブレットを介して支持され、ビジネス論理はリモート・メソッド呼び出し（ＲＭＩ）オブジェクト及びＥＪＢを介して支持される。ＥＪＢは、互いにビーンズが実行される作動時間環境を構成するトランザクション、ライフサイクル及び状態管理、リソースプーリング、機密保護についてのコンテナ環境に依存する。
後端層。これは、一般には、既存のアプリケーション及びデータ記憶装置の組み合わせである。これは、エンタープライズ・リソース・プラニング（ＥＲＰ）、メインフレーム・トランザクション処理、データベースシステムその他のレガシー情報システムのようなシステムを含むことができるため、エンタープライズ情報システム（ＥＩＳ）層とも呼ばれる。
Ｊ２ＥＥアプリケーションのコンポーネントは別々に作動し、多くの場合は異なる装置上で作動するため、クライアント及びアプリケーション・サーバ層のコードが他のコード及びリソースを調べて参照する方法が必要である。クライアント及びアプリケーション・コードは、例えば、Ｊａｖａネーミング・アンド・ディレクトリ・インターフェース（ＪＮＤＩ）１６を用いて、エンタープライズ・ビーンズのようなユーザにより定義されたオブジェクト、及びＪａｖａデータベース・コネクタ（ＪＤＢＣ）データソース・オブジェクトの位置のような環境エントリを調べるようにすることができ、これらは次いで、後端層におけるリソース及びメッセージ連結を調べるのに用いることができる。
【０００５】
機密保護及びトランザクション管理のようなアプリケーション作動は、ウェブ及びエンタープライズ・ビーン・コンポーネント上の配置時間で構成することができる。この配置時間特徴は、アプリケーション論理を、組立体により異なることがある構成の設定から分離するものである。Ｊ２ＥＥ機密保護モデルは、システムリソースが許可ユーザによってのみアクセスできるように、開発者にウェブ又はエンタープライズ・ビーン・コンポーネントを構成させるものである。例えば、ウェブコンポーネントは、ユーザ名及びパスワードの入力を要求するように構成することができる。エンタープライズ・ビーン・コンポーネントは、特定の群の中の人だけがそのメソッドの或る種類を起動できるように構成することができる。或いは、サーブレット・コンポーネントは、幾つかのメソッドは誰からでもアクセス可能であり、幾つかのメソッドは、組織内の特別許可された人だけがアクセス可能であるように構成することができる。同じサーブレット・コンポーネントは、別の環境において、すべてのメソッドが誰からでも利用可能であるようにするか、又は、すべてのメソッドが選択された数人の人にだけ利用可能にするように構成することができる。
カリフォルニア州サンノゼ所在のＢＥＡシステムズ社からのウェブロジック・サーバのような幾つかアプリケーション・サーバは、サーバ上で作動しているコンポーネントの用途についてきめの細かい制御を可能にするアクセス制御リスト（ＡＣＬ）機構を用いる。ＡＣＬを用いて、開発者はＪａｖａメソッドレベルで、ユーザ又はユーザ群により何が実行できるか又は実行できないかを定義することができる。このＡＣＬ機構は、ＥＪＢ仕様で定義される独自のアクセス制御機構を有するＥＪＢ以外のアプリケーション・サーバ上の作動する如何なるものもカバーする。機密保護領域は、管理者が情報を既存の権限又は認証システムからＡＣＬの中にインポートすることを可能にする。
【０００６】
Ｊａｖａサーブレット
サーブレットは、ウェブサーバの機能性を拡張するプログラムである。サーブレットは、クライアントから要求を受け取り、動的に応答を生成し（多分、該要求を満たすためにデータベースを照会して）、次にＨＴＭＬ又はＸＭＬ文書を含む応答をクライアントに送る。サーブレットはＣＧＩと同様であるが、典型的には、該サーブレットはＪａｖａクラス及びストリームを用いるために、書くのが容易である。サーブレットはＪａｖａバイトコード準拠で、実行時間においてはサーブレット・インスタンスはメモリに保持されており、各クライアント要求が別々のスレッドで作動しているために実行がより速い。サーブレットは、動的な様式により、ＨＴＴＰ応答ストリームに対してデータを生成するのを容易にする。クライアント要求は、新しい接続において行われることになるため、フロー制御は本来要求の間に来ない。このセッションを可能にするために、管理は要求間で特定のクライアントの状態を維持する。幾つかアプリケーション・サーバにおいては、サーブレットはＨＴＴＰセッションオブジェクトを利用して、メソッド要求間の状態を保存するようにする。このオブジェクトは、フェールオーバー目的のためにクラスタ環境において複製することができる。
【０００７】
Ｊａｖａサーバページ
ＪＳＰページは、サーブレットを開発するテキストベースの表示中心方法である。ＪＳＰページは、サーブレットのすべての利点を提供し、ＪａｖａＢｅａｎｓクラスと組み合わされると、コンテンツと表示論理とを別々に維持する容易な方法をもたらす。ＪＳＰページ及びサーブレットの両方は、プラットフォームに依存せず、より少ないオーバーヘッドを用いるために、共通ゲートウェイ・インタフェース（ＣＧＩ）よりも望ましい。ＪＳＰページは、ＪａｖａＢｅａｎｓクラスと併せて用いて、同様の外観をもったページで構成されたウェブサイトを作るためのウェブレンプレートを定義するようにすることができる。ＪａｖａＢｅａｎｓクラスは、テンプレートが如何なるＪａｖａコードももたないようにデータレンダリングを行う。このことは、これらがＨＴＭＬエディタにより維持できることを意味する。ＪＳＰページを用いる単純なウェブベースのアプリケーションを用いて、コンテンツをＪａｖａＢｅａｍｓクラスの代わりにカスタムタグ又はスクリプトレットを用いるアプリケーション論理にバインドするようにすることができる。カスタムタグは、ＪＳＰページにインポートされるタグライブラリの中にバンドルされる。スクリプトレットは、ＪＳＰページに直接組み込まれた小さなＪａｖａコードセグメントである。
【０００８】
データベースアクセスサービス（ＪＤＢＣ）
ＪＤＢＣは、リレーショナル・データベースへのブリッジとして作用し、ＯＤＢＣ（オープン・データベース・コネクティビティ）仕様上でモデル化される。これは、ドライバを用いることにより、データベースをプログラムコードから分離するものである。幾つかのＪＤＢＣの実施は、進歩したデータ形式についての支持をもたらし、さらにスクロール可能な結果の組及びバッチの更新についての機能性を支持する。
Ｊａｖａメッセージ・サービス（ＪＭＳ）
ＪＭＳは、Ｊａｖａプログラム間でメッセージのやりとりを支持するように用いられるものである。送り側及び受け取り側が互いを認識している必要がなく、これにより独立して作動できるという方法で、Ｊａｖａは非同期式通信を支持する。ＪＭＳは、２つのメッセージング・モデルを支持する。
２地点間。これは、メッセージ・キューに基づくものである。このモデルにおいては、メッセージの作成者は、メッセージをキューに送る。メッセージのコンシューマは、それ自体をキューに添付して、メッセージを聴取るようにすることができる。メッセージがキューに到達すると、コンシューマはこれをキューから離し、これに応答する。メッセージは、１つのキューにだけ送ることができ、１人のコンシューマによってのみ用いられる。コンシューマは、メッセージをフィルタして、まさに欲しい種類のメッセージを指定するようにすることができる。
パブリッシュ及びサブスクライブ。これは、作成者がメッセージをトピックに対して及びそのトピックについて登録しているすべてのコンシューマに送って、これらのメッセージを取り寄せるようにすることを可能にするものである。この場合においては、多くのコンシューマが同じメッセージを受け取ることができる。
【０００９】
Ｊａｖａインターフェース定義言語（ＩＤＬ）
ＣＯＲＢＡオブジェクトはＩＤＬを用いて、コントラクトを指定するが、これはすなわち、これらがどのように他のオブジェクトと対話するのかを指定するものである。ＪａｖａＩＤＬにより、コントラクトをＪａｖａの世界とＣＯＲＢＡの世界との間に定義することができる。ＳｕｎのＪＤＫ１．２においては、Ｊａｖａアプリケーションが、インターネットＩｎｔｅｒＯＲＢ（ＩＩＯＰ）プロトコルを介して、遠隔ＣＯＲＢＡオブジェクトを起動することを可能にするＯＲＢが含まれている。
エンタープライズＪａｖａＢｅａｎｓ（ＥＪＢ）
ＥＪＢコンポーネントは、ビジネス論理をカプセル化して、開発者が、データベースのアクセス、トランザクションの支持、機密保護、キャッシング、及び並行性のような典型的なタスクについてのプログラミングコードを懸念することが必要ないようにする。ＥＪＢ仕様においては、これらのタスクはＥＪＢコンテナの役割である。エンタープライズ・ビーンは、インターフェースとクラスとからなる。クライアントは、エンタープライズ・ビーンのホーム及び遠隔インターフェースを介してエンタープライズ・ビーン・メソッドにアクセスする。ホーム・インターフェースは、エンタープライズ・ビーンを生成し、除去し、配置するメソッドをもたらし、遠隔インターフェースは、ビジネス・メソッドをもたらす。配置時間において、コンテナはこれらのインターフェースからクラスを生成し、これは次に、エンタープライズ・ビーン上でビジネス・メソッドを生成し、除去し、配置し、及びコールしようとしているクライアントにアクセスをもたらすように用いられる。エンタープライズ・ビーンのクラスは、ビジネス・メソッド、生成メソッド、及びファインダ・メソッドについての実施をもたらし、ビーンがそれ自体の永続性を管理する場合には、それ自体のライフサイクル・メソッドについての実施をもたらすようになる。
エンタープライズ・ビーンズには２つの種類、すなわちエンティティ・ビーンズ及びセッション・ビーンズがある。セッション・ビーンは、クライアントとの一時的な会話を表し、データベースの読み込み及び書き込みを実行することがある。セッション・ビーンは、ＪＤＢＣコールをそれ自体で起動することができるか、又はエンティティ・ビーンを用いてコールをするようにすることもでき、この場合においては、該セッション・ビーンは該エンティティ・ビーンにとってクライアントである。セッション・ビーンのフィールドは、会話状態を含み、これは一時的なものである。サーバ又はクライアントがクラッシュした場合には、セッション・ビーンはなくなる。
【００１０】
エンティティ・ビーンは、データベースにおけるデータ及びそのデータ上で作用するメソッドを表す。エンプロイー情報の表についてのリレーショナル・データベースのコンテクストにおいては、該表の各行について１つのビーンがあることになる。エンティティ・ビーンはトランザクション可能で長命である。データがデータベースに残っている限り、エンティティ・ビーンは存在する。このモデルは、リレーショナル・データベースについて容易に用いることができ、オブジェクト・データベースに制限されるものではない。
セッション・ビーンは、ステートフル又はステートレスであってよい。ステートフルのセッション・ビーンは、クライアントの代わりに、会話状態を含む。会話状態は、セッション・ビーンのインスタンス・フィールド値にセッション・ビーンのフィールドから到達可能なすべてのオブジェクトを足したものである。ステートフルのセッション・ビーンは、データを永続性のあるデータ記憶装置において表さないが、これらはクライアントの代わりにデータにアクセスして更新することができる。ステートレスのセッション・ビーンは、特定のクライアントについて、如何なる状態情報ももたない。これらは、典型的には、如何なる特定の状態も維持しないサーバ側の反応をもたらす。ステートレスのセッション・ビーンズは、より少ないシステムのリソースを必要とする。一般的なサービスを提供するか又は格納されたデータの共用ビューを表すビジネス・オブジェクトは、ステートレスなセッション・ビーンのための良好な候補である。
コンテナ管理された永続性を用いて、リレーショナル・データベースにアクセスするようにするエンタープライズ・ビーンは、コンテナがこれを管理するために、データベースにアクセスするのに、如何なるＪＤＢＣ２．０ＡＰＩも用いることを開発者に要求しない。しかしながら、ビーン管理された永続性が用いられる場合、又はリレーショナル・データベース以外のエンタープライズ情報システムにアクセスする必要がある場合には、これを行う適切なコードが与えられなければならない。
データベースにアクセスするのにビーン管理された永続性を用いるエンタープライズ・ビーンの場合においては、ＪＤＢＣ２．０ＡＰＩをもったビーンのライフサイクル・メソッドを実施して、データのロード及び格納を取り扱い、実行時間と永続データベース記憶装置との間の一貫性を維持するようにしなければならない。Ｗｅｂ層はデータを層間で転送するのにＨＴＴＰ又はＨＴＴＰＳを用いるが、ＥＪＢ層はＲＭＩ−ＩＩＯＰを用いる。ＲＭＩ−ＩＩＯＰは、如何なるクライアント又はエンタープライズ・ビーンにアクセスするウェブ層プログラムにもＥＪＢ層におけるサービスに対して直接アクセスを与えるフルスケールの分散計算プロトコルである。これらのサーバは、エンタープライズ・ビーンを参照するＪＮＤＩ、非同期メッセージを送りかつ受け取るＪａｖａメッセージング・サービス（ＪＭＳ）、及びリレーショナル・データベースのアクセスのためのＪＤＢＣを含む。
【００１１】
トランザクション管理
ＷｅｂＬｏｇｉｃサーバシステムのようなあらゆるアプリケーション・サーバの最も基本的な特徴の１つは、トランザクション管理である。トランザクションは、データベースのトランザクションが正確に完了し、しかもこれらが以下のものを含む高性能トランザクションの「ＡＣＩＳ］特性のすべてを負うことを保証する手段である。
原子性。トランザクションがデータベースに対して行うすべての変更は恒久的なものにされ、そうでない場合はすべての変更はロールバックされる。
一貫性。首尾のよいトランザクションは、データベースを前の有効状態から新しい有効状態に変換する。
独立性。トランザクションがデータベースに対して行うすべての変更は、トランザクションがその作業を完了するまで他の作動からは見えないようにされる。
耐久性。トランザクションがデータベースに対して行うすべての変更は、将来のシステム又は媒体の障害に耐えるものにされる。
Ｊ２ＥＥトランザクションモデルは、アプリケーションの開発者に、配置時間において、単純なトランザクションを含むメソッド間の関係を指定させるようにして、１つのトランザクションにおけるすべてのメソッドが単一のユニットとして扱われるようにする。トランザクションはすべてが完了しなければならない一連の段階であるため、又はそれらのすべてが完了されない場合にはすべてが逆にされるために、このことは望ましい。例えば、開発者は、第１の口座からデビットし、第２の口座にクレジットすることにより、お金を１つの銀行口座から別の銀行口座に移動するエンタープライズ・ビーンの一連のメソッドを有することがある。この例においては、振込み業務全体が１つのユニットとして取り扱われることが望まれるため、デビット後及びクレジット前に障害があった場合には、デビットがロールバックされることになる。
【００１２】
トランザクション属性は、組み立て中にアプリケーション・コンポーネント上で指定されて、開発者が、メソッドを該アプリケーション・コンポーネントにおけるトランザクションの中に群分けすることを可能にするようにする。このようにして、アプリケーション・コンポーネントをＪ２ＥＥアプリケーション内で変更することができ、トランザクション属性は、コードを変更することなく再割り当てされる。Ｊａｖａトランザクション・サービス（ＪＴＳ）及びＪａｖａトランザクションＡＰＩ（ＪＴＡ）は、Ｊ２ＥＥにおける、より具体的にはＥＪＢ及びＪＤＢＣにおけるトランザクション支持の基礎を形成する。ＪＴＳ仕様は、Ｊａｖａをオブジェクト管理グループ（ＯＭＧ）オブジェクト・トランザクション・サービスに対してマップするトランザクション管理についての低レベルのアプリケーション・プログラム・インターフェース（ＡＰＩ）である。ＪＴＡ仕様は、サンマイクロシステムズがトランザクション処理及びデータエースシステム領域における有力な産業パートナーと協力して開発されたものであり、標準のＪａｖａインターフェースをトランザクション・マネージャ、リソース・マネージャ、アプリケーション・サーバ、及びトランザクション可能アプリケーションの間で指定する。具体的には、ＪＴＡは以下の２つの部分からなる高レベルのＡＰＩである。
トランザクション・インターフェース。これは、分散コンポーネントにより行われた作業がグローバルなトランザクションによりバインドされることを可能にし、トランザクションを構成する作動の群をマークするか又は識別する方法である。
ＸＡリソース・インターフェース。これは、分散されたトランザクションの取り扱いを可能にするＸ／オープン又はＸＡインターフェースに基づくインターフェースである。これらは、データベース又はキューの中の又はこれらの間のような１つより多いリソースにおけるトランザクションの調整を含む。
【００１３】
ほとんどの時間において、ＪＴＡとの明示的なトランザクションのプログラミングは、コンテナにより取り扱われるＪＤＢＣ及びＥＪＢのＡＰＩにより行われ、アプリケーションの配置記述子により構成されるため、開発者はこの作業について懸念する必要はない。開発者はその代わりに、トランザクションの実施ではなく、該トランザクションの設計に集中することができる。
ＷｅｂＬｏｇｉｃサーバは、分散されたトランザクション及びエンタープライズ・アプリケーションについての２段階のコミット・プロトコルの両方を支持する。分散されたトランザクションは、調整された方法により多数のリソース・マネージャ（データベースのような）を更新するトランザクションである。対照的に、ローカル・トランザクションは、単一のリソース・マネージャを更新するものである。２段階のコミット・プロトコルは、２つ又はそれ以上のリソース・マネージャにわたり単一のトランザクションを調整する方法である。これは、トランザクション可能な更新が参加しているデータベースすべてにおいてコミットされたか、又はすべてのデータベースから完全にロールバックされたかを確認することによりデータの完全性を保証して、トランザクションの開始前の状態に戻るようにする。換言すると、すべての参加しているデータベースが更新されるか、又はいずれも更新されないかのどちらかである。分散されたトランザクションは、以下の参加者を含む。
トランザクション・オリジネータ。これはトランザクションを開始するものである。トランザクション・オリジネータは、ユーザ・アプリケーション、エンタープライズＪａｖａＢｅａｎ、又はＪＭＳクライアントとすることができる。
トランザクション・マネージャ。これは、アプリケーション・プログラムの代わりにトランザクションを管理するものである。トランザクション・マネージャは、アプリケーション・プログラムからのコマンドを調整して、これらのトランザクションに参加しているすべてのリソース・マネージャと通信することにより、トランザクションを始めて完了するようにする。リソース・マネージャがトランザクション中に故障すると、トランザクション・マネージャは、リソース・マネージャが、待ち状態のトランザクションをコミットするか又はロールバックするかを判断することを助ける。
リカバリ可能リソース。これは、データのための永続的な記憶装置を与えるものである。リソースは、ほとんどの場合、データベースである。
リソース・マネージャ。これは、情報及びプロセスの収集に対するアクセスを与えるものである。
【００１４】
トランザクション認識ＪＤＢＣドライバは、一般的なリソース・マネージャである。リソース・マネージャは、トランザクション能力及び作動の性能を与えるものであり、これは、分散されたトランザクション内でアクセスされて制御されるエンティティである。リソース・マネージャと特定のリソースとの間の通信は、トランザクション・ブランチと呼ばれる。
２段階のコミット・プロトコルの第１の段階は、準備段階と呼ばれる。要求される更新はトランザクションのログファイルに記録され、リソースはリソース・マネージャを介して、変更する準備ができていることを示さなければならない。リソースは、更新をコミットするか又は前の状態のロールバックするかのいずれかを示すことができる。第２段階で何が起こるかは、リソースが何を示すかによって決まる。すべてのリソースがコミットすることを示した場合には、トランザクションに参加しているすべてのリソースが更新される。１つ又はそれ以上のリソースがロールバックすることを示した場合には、トランザクションに参加しているすべてのリソースが、前の状態にロールバックされる。
ビジネス・トランザクションについての支持
トランザクションは、以下に説明される例示的な状況において適切である（しかしこれらの状況は例示的なものに過ぎず、網羅的なものではない。）
第１の例として、クライアント・アプリケーションは、１つ又はそれ以上のデータベースに書き込むことを含むことがある幾つかのオブジェクトの起動をしなければならない。不成功な起動が１つでもあった場合には、いずれかの書き込まれる状態（メモリ内にであるか又はより典型的にはデータベースに、のいずれか）はロールバックされなければならない。例えば、旅行業者のアプリケーションを考慮する。クライアント・アプリケーションは、遠い場所、例えば、フランスのストラスブールからオーストラリアのアリススプリングスまでのような旅行を容易する必要がある。このような旅行は、必然的に多数の個々の飛行機の予約を必要とする。クライアント・アプリケーションは、両方の個々の各々のセグメントを連続した順序で、例えばストラスブールからパリまで、パリからニューヨークまで、ニューヨークからロサンゼルスまで、のように予約することにより作動する。しかしながら、個々に予約できない飛行機があった場合には、クライアント・アプリケーションは、そこまで作られていたすべての飛行機の予約をキャンセルする方法が必要になる。クライアント・アプリケーションは、サーバ・アプリケーションにより管理されたオブジェクトとの会話が必要であり、該クライアント・アプリケーションは、特定のオブジェクトのインスタンス上で多数の起動をする必要がある。会話は、以下の１つ又はそれ以上のものにより特徴づけることができる。
【００１５】
データは、各々の連続する起動中に又はその後に、メモリにキャッシュされるか又はデータベースに書き込まれる。データは会話の最後にデータベースに書き込まれる。クライアント・アプリケーションは、オブジェクトが各々の起動間でメモリ内のコンテクストを維持するようにすることを必要とし、すなわち、各々の連続する起動は、会話にわたりメモリに維持されているデータを用いる。会話の最後において、クライアント・アプリケーションは、会話中に又は会話の最後において生じることがあるすべてのデータベース書き込み作動をキャンセルする能力が必要である。
代替的な例として、インターネットベースのオンライン・ショッピングカートのアプリケーションを考える。クライアント・アプリケーションのユーザは、オンラインのカタログに目を通し、多数の注文の選択をする。ユーザが、買いたい物品のすべてを選択し終わると、彼らはそれをチェックし、購入のためにクレジット・カードの情報を入力するように進む。クレジット・カードのチェックが不成功だった場合には、ショッピング・アプリケーションは、ショッピング・カート内の保留中の注文の選択すべてをキャンセルするか、又は会話中に行われたあらゆる購入についてのトランザクションをロールバックする必要がある。或るオブジェクトについて、単一のクライアント起動の範囲内では、該オブジェクトは、データベースにおけるデータに対して多数の編集を行う。編集の１つが不成功であった場合には、オブジェクトはすべての編集をロールバックする機構が必要である。（この状況においては、個々のデータベース編集は必ずしもＥＪＢ又はＲＭＩ起動でなくてもよい。アプレットのようなクライアントは、ＪＮＤＩを用いてＴｒａｎｓａｃｔｉｏｎオブジェクト及びＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒオブジェクトに対する参照を取得して、トランザクションを始めることができる。）
別の例として、銀行業務のアプリケーションを考える。クライアントは、テラー・オブジェクト上の振込み作動を起動する。振込み作動は、テラーオブジェクトが銀行データベース上で以下の起動、すなわちデビットメソッドを１つの口座で起動すること、及びクレジットメソッドを別の口座で起動すること、を行うようにすることを要求する。銀行データベース上でのクレジット起動が不成功だった場合には、銀行アプリケーションは、前のデビット起動をロールバックするようにする機構が必要になる。
上述のトランザクション管理の従来のメソッドに関する問題は、トランザクションのコールバックが処理される方法において効率性がないということである。各々のコミット・サーバは、クライアントに通信し戻る前に、各々の参加しているサーバに接触しなければならない。さらに、従来の方法は、コミット機能が呼び出された後に、例えば、新しいサーバ又はリソースが、トランザクションのリストに入ることを可能にする機構がないというように、融通性に欠ける。このことは、従来のメソッドの拡張性及び潜在的な有用性の両方を制限し、今日のビジネスで要求されるますます複雑なアプリケーションの開発を阻止することになる。
【００１６】
（発明の開示）
本発明は、トランザクション完了前に、コールバック処理が同期される（又は有効になる）ことを可能にする、アプリケーション・サーバ又はトランザクション・サーバにおいて用いるか又はこれらと併せて用いるための機構を提供する。トランザクションのライフサイクルにおいて、アクティブ、引き渡し、前準備、準備、ロギング、及びコミット状態の間にあるものを含む幾つかの状態の遷移がある。本発明の実施形態においては、同期オブジェクトは、アクティブ段階中に如何なるサーバ上においても登録することができる。コミット（）機能が呼び出された後、各々の同期オブジェクトは、前準備処理段階中に呼び出される。１つの同期オブジェクトは、別のものに登録することができ、又は同期オブジェクトが、トランザクションにおいて前に含まれていなかったサーバを呼び出すようにすることを可能にすることができる。同期オブジェクトはさらに、新しいＸＡオブジェクトをトランザクションにおいて含むことができる。ここで用いられる同期及び同期オブジェクトという用語は、コミットが呼び出された後に、トランザクション・マネージャが、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ．ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎメソッドを起動することを要求する、ＪＴＡにより指定されたプログラミング・インターフェースのことを言う。アプリケーション・コードは、トランザクションのアクティブ段階中にこれらのコールバックについて登録することができる。
円形制御は、サーバ間でループにおいて流れ、すべての同期コールバックが完了すると、コミット・サーバで終了するようになる。新しい同期オブジェクト又はサーバが後から加えられた場合には、これらをループの中に挿入することができる。すべての同期コールバックは、あらゆるリソースが準備される前に完了して、同期コールバックが該リソースにアクセスすることが必要である場合に対処するようにする。この円形制御の流れは、コミット・サーバが参加しているサーバの各々に接触する従来のメソッドと比較して、メッセージの数を減らす。サーバ及び円形制御の流れに沿ってこのサーバリストを通過するリソースを動的に加える能力は、トランザクション処理システム及びアプリケーション・サーバ、及びその上に作られたアプリケーションに、多大な融通性を加える。一実施形態において、本発明は、トランザクションのサブコーディネータの組をトランザクションのコミット前に修正して、特定のトランザクションに参加している同期オブジェクトのコールバック及びリソースの選択における変更を反映するようにすることができる、トランザクションと関連付けることができる複数の同期オブジェクト及びリソースと、特定のトランザクションについて、少なくとも１つの又は複数のトランザクションのサブコーディネータの組を、該特定のトランザクションに参加する同期オブジェクトのコールバック及びリソースの選択と併せて登録するトランザクションのコーディネータとを含む、トランザクションのコールバックをトランザクションの完了と同期させるトランザクション処理のためのシステムを備える。本発明の別の実施形態は、トランザクションのサブコーディネータをトランザクションのコミット前に修正して、特定のトランザクションに参加している同期オブジェクトのコールバック及びリソースの選択における変更を反映するようにすることができる、トランザクションと関連付けることができる複数の同期オブジェクト及びリソースを設けて、特定のトランザクションについて、少なくとも１つの又は複数のトランザクションのサブコーディネータの組を、該特定のトランザクションに参加する同期オブジェクトのコールバック及びリソースの選択と併せてトランザクションのコーディネータにおいて登録するという段階を含む、トランザクションのコールバックをトランザクションの完了と同期させるトランザクション処理のための方法を含む。
【００１７】
（発明を実施するための最良の形態）
一般的に述べると、本発明は、トランザクション完了前に、同期されるべきコールバック処理を可能にするトランザクション又はアプリケーション・サーバにおいて用いられる機構を提供する。この期間中、同期オブジェクトは、トランザクションのアクティブ段階において、いずれのサーバ上にも登録できる。コミット機能が呼び出されると、次に、前準備段階において、各々の同期オブジェクトが呼び出される。このことを行う利点は、コミット期間前に、同期オブジェクトをチェーンに加えることができるということである。１つの同期オブジェクトは、別の同期オブジェクトを登録することができ、又は同期オブジェクトを呼び出して、前にトランザクションに含まれなかったサーバを呼び出すようにすることを可能にすることができる。
円形制御は、サーバ間のループにおいて流れ、同期コールバックが完了すると、コミット・サーバで終了する。新しい同期オブジェクト又はサーバが後から加えられた場合には、これらはループの中に挿入される。すべての同期コールバックは、あらゆるリソースが準備される前に完了して、同期コールバックが該リソースにアクセスする必要がある場合に対処するようにする。円形制御の流れは、コミット・サーバが参加サーバの各々に直接接触する従来の方法と比較すると、メッセージの数を減らす。サーバ及び円形制御の流れに沿ってこのサーバを通過するリソースを動的に加える能力は、トランザクション処理システム、及びアプリケーション・サーバ、及びその上に作られたアプリケーションに対して多大な融通性を加える。
【００１８】
図２は、付加的なサーバ及び同期オブジェクトを、コミット段階及びコールバック段階の前に、どのように同期コールバックループに含むことができるかを示す、本発明の一実施形態の概略図を示す。図２に示されるように、クライアント・アプリケーション１０４を含むクライアント１０２は、多数のサーバ１０６又はこれらのサーバ上のリソースを含むトランザクションを開始する又は始める。典型的には、クライアント・アプリケーション１０４は、どのサーバが又はどのサーバのリソース・オブジェクト又はリソースが、特定のトランザクションに含まれるべきかをサーバに伝える特定のトランザクション・コンテクスト１１２を指定する。ここで用いられる「同期オブジェクト」という用語は、サーバがトランザクションに参加することを可能にするサーバ・オブジェクトのことをいう。同期オブジェクトは、定期的に、Ｊａｖａベースのシステムを含むオブジェクト指向システムで用いられて、過渡状態データを維持するようにする。同期オブジェクトは、トランザクションが完了する前に、同じトランザクションに登録された１つ又はそれ以上のリソース・オブジェクトに及び該同じトランザクションに登録された１つ又はそれ以上のリソース・オブジェクトからデータを移動させる。例えば、図２に示されるように、トランザクション・コンテクスト１１２は、サーバ１  １０８及びサーバＡ１１０が、該サーバＡに位置させられた１つ又はそれ以上のオブジェクト又はリソース１１６を含むトランザクションに参加することを指定することができる。一実施形態においては、いずれのサーバ１０６も処理チェーンを始める初期サーバ１として選択することができる。前準備段階中に、サーバは、コミット期間の前にループの中に加えられる。トランザクションをコミットする前のいずれかの時点において、クライアントプリケーションは、トランザクション・コンテクスト１２２を改変して、例えばサーバ上に位置させられた同期オブジェクト及びリソース１３２のいずれかを含む別のサーバＢ  １２８を加えるようにすることができる。本発明は、このようにして、サーバＢを準備ループの中に含む機構を提供する。サーバはさらに、アクティブ及び前準備段階中にも加えることができる。トランザクション・コンテクストは、典型的には、クライアント・アプリケーションにより直接変更されるように露出されていない。その代わりに、このアプリケーションが他のＪ２ＥＥコンポーネントを呼び出すと、トランザクションにより、Ｊ２ＥＥコンテナが付加的な同期オブジェクトを登録するか又は付加的なＸＡリソースオブジェクトをリストに入れ、例えば、（１）アプリケーションがＥＪＢを呼び出すと、ＥＪＢコンテナが、ＥＪＢの代わりにトランザクション・マネージャにより同期オブジェクトを登録するか、又は（２）アプリケーションがＪＤＢＣを通してデータベースにアクセスすると、ウェブロジックＪＤＢＣ連結プールが、該トランザクションマネージャにより、データベース・インスタンスに関連したＸＡリソースをリストに入れる。
【００１９】
当業者であれば、図２においては第１サーバ１  １０８がトランザクションのコーディネータとして識別されているが、いずれのサーバも所定のトランザクションのためにこの役割を負うことができ、トランザクションのコーディネータとして選択されたサーバは、単純に、クライアントにより最初に接触されたサーバを選択することを含む種々の異なる手段を用いて選択することができることが明らかであろう。トランザクションのコーディネータは、トランザクションと併せて用いる実際のリソースを与えることに参加してもよいし又はしなくてもよい。このことによりもたらされる本発明の特徴の１つは、クライアント・アプリケーションを、如何なる時点においても修正して、トランザクションを変更するようにすることができ、同期オブジェクト又はリソースにおける変更は、即時にもたらされることである。例えば、クライアント・アプリケーションがＥＪＢである場合には、トランザクション・コンテクストは、異なるサーバ上の異なるリソースを含むように、準備又はコミット段階において修正することができ、これらのリソースは動的に処理チェーンの中に入れることができる。このことは、クライアント・アプリケーションを修正するのに大いに融通性を可能にする。
【００２０】
図３は、本発明と併せて用いる典型的なクライアント−サーバシステムの図を示す。一般に、クライアント・アプリケーションと呼ばれる遠隔装置又はアプリケーション２０２は、アプリケーション・サーバ２０４と通信するか、又は、より典型的には、該アプリケーション・サーバでホストされるアプリケーションと通信する。クライアントエンドにおいては、トランザクション・マネージャ２０６がクライアント・アプリケーションにより用いられて、トランザクション２０８をサーバ（又は多数のサーバ）に送りかつ該サーバから受け取るようにする。同様に、サーバエンドにおいては、トランザクション・マネージャ２１０が用いられて、クライアントとのトランザクションを管理するようにする。一実施形態においては、サーバはさらに、トランザクションのコミットプロセスを調整するトランザクション・コーディネータ２１４、トランザクションに参加し、種々の段階のコミット処理をローカルのトランザクション・マネージャに登録された同期オブジェクト及びＸＡリソースオブジェクト上で実行するサブコーディネータ２１６、及びトランザクションをロギングするトランザクション・ロガー２１８を含むことができる。トランザクションが生成されて処理されると、これらは後の監査、参照、又はロールバック目的のためにトランザクション・ログ２２０に記録することができる。本発明は、特性を各々のトランザクションと関連付けることを可能にするトランザクション・マネージャを提供する。クライアント又はサーバ・アプリケーションは、次に、トランザクションが通信されると、これらの特性を分析して２２２、それにしたがって反応することができる。
【００２１】
図４は、本発明の実施形態による種々のトランザクション状態の図を示す。図４は、アクティブ３０２、前準備３０６、準備３０８、ロギング３１０、及びコミッティング３１２状態を含むトランザクションのライフサイクルにおける種々の状態又は段階を示す。いずれのトランザクションのライフサイクルにおいても、アクティブ、引き渡し、前準備、準備、ロギング、及びコミット状態を含むこのような幾つかの状態の遷移がある。アクティブな状態においては、クライアント上で作動しているアプリケーション又はアプリケーション・コードは、トランザクションの実際の実行中に幾つかのサーバに接触するように設計されている。このクライアントは、どのサーバが接触されたかについて、さらにトランザクションに関する他の詳細を覚える役割のものである。本発明の一実施形態においては、接触された最初のサーバは、「コミット・サーバ」又はトランザクション・コーディネータとして指定される。クライアントが「コミット」を要求すると、トランザクションをコミットする実際の役割が、コミット・サーバに委任されるか又は引き渡される。コミット・サーバはコミットを処理する役割のものであるという事実を除いては、このサーバは普通のサーバとすることができ、多くの場合において、いずれのサーバもコミット・サーバの役割を負うことができる。どれが実際にその役割をもつことになるか（及びしたがってコミット・サーバになるか）は、実際の実施によって決まる。
【００２２】
アプリケーション・サーバは、典型的には、種々のアプリケーション形式及びトランザクション形式を支持する。Ｊ２ＥＥ準拠のアプリケーション・サーバは、ＥＪＢ及びＲＭＩアプリケーションの両方を支持するべきである。アプリケーション形式に応じて、種々のトランザクション処理方法を用いることができる。ウェブロジック・サーバ製品は、このようなアプリケーション・サーバ製品の１つであり、その実施は、多くの場合、ここで本発明を図示する目的で説明される。当業者であれば、本発明により提供されるシステム及び方法を、他のトランザクション処理システムと併せて、及び他の種類のアプリケーション・サーバと併せて等しく用いることができることが明らかであろう。
【００２３】
図５は、同期コールバックを用いてトランザクションを処理するようにする本発明の実施形態によるトランザクションシステムを示す。クライアント６０２がトランザクションを通信するか又は処理することを試みると、複数のサーバ６０４、６０６、６０８が接触されて、どれが実際にトランザクションを処理するのかを判断するようにすることができる。実施に応じて、サーバの１つが、コミット・サーバ／トランザクション・コーディネータとして働くように選択され、他のものは、単なる参加サーバとして考慮される。図示目的のためだけに、単一のコミット・サーバ及び２つの参加サーバが図５に示されるが、現実の世界の状態においては、多数のサーバを用いることができること（及び多分利用可能性を与えるように用いられること）が明らかであろう。同様に、この例においては、指定されたコミット・サーバ及び参加サーバが示されているか、他の実施形態においては、複数のサーバ内のサーバの各々がコミット・サーバとして働くことができ、又は単に参加サーバとして働くことができることが明らかであろう。本発明により提供されるシステムは、用いられる数及び種類のサーバの両方に対して融通性がある。選択されると、コミット・サーバは、コミットプロセスを取り扱う役割を負う。トランザクションプロセスは、クライアントと参加サーバ６０６との間のさらに別の通信なしで、クライアント６０２とコミット・サーバ６０４との間の通信だけにより取り扱われる。コミット・サーバ自体は、参加サーバ６０６（又はサーバ６０６、６０８）とのトランザクション処理のすべてを取り扱い、トランザクションを前準備、準備、ロギング、及びコミット段階を通して移動させる。コミット処理が完了すると、コミット・サーバはコミットをクライアントに返す。付加的なサーバ又は参加者を、前準備段階中に、及びコールバックの前のいずれの時点においてもトランザクションプロセスの中に挿入することができる。
【００２４】
同期コールバックの典型的な例
上述のプロセスは、多数のサブコーディネータ（サーバ）及びその上の同期オブジェクトを含むトランザクションの典型的な例を考慮することにより示すことができる。典型的なトランザクションは、５つの区別できる段階を通して進む。
１．アクティブ段階
２．「トランザクションコミットが呼び出される」
３．前準備段階（この段階は、同期コールバックの呼び出し、すなわちＳｙｎｃｈｒｏｎｉｚａｉｏｎ．ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎだけを含み、いずれのリソースも呼び出さない）。
４．準備段階（これはリソースを呼び出すことだけを含み、同期コールバックは呼び出さない）。
５．コミット段階（これもまたリソースを呼び出すことだけを含み、同期コールバックは呼び出さない）。
段階３において、前準備段階、新しい同期オブジェクトをトランザクションに登録することができる。次にトランザクションに参加する新しいリソースをさらに、前準備段階に加えることができる。これらのリソースは、後に、段階４及び段階５において呼び出される。典型的には、リソースは加えられるが、トランザクションから削除されることはない。新しいサブコーディネータ（すなわちサーバ）は、前準備段階中にトランザクションに参加することができる。
【００２５】
例えば、１つのクライアント及び３つのサーバＳ１、Ｓ２、Ｓ３、３つの同期オブジェクト、サーバＳ１上のＳｙｎｃ１、サーバＳ２上のＳｙｎｃ２、サーバＳ３上のＳｙｎｃ３、及び３つのリソース・オブジェクト、Ｓ１上のｒ１、Ｓ２上のｒ２、Ｓ３上のｒ３がある状況を考える。クライアントがトランザクションＴ１を開始するか又は始め、しかもこのトランザクションＴ１がサーバＳ１伝播された場合には、本発明の一実施形態により、該サーバ１がこのトランザクションのためのコミット・サーバ／トランザクションになる。他の実施形態及び実施は、複数の利用可能なサーバからトランザクション・コーディネータを選択する代替的な機構を用いることができる。次に、トランザクションＴ１のアクティブ段階においては、以下の初期状態情報を有する。
現在トランザクションＴ１に参加しているサブコーディネータ（サーバ）：Ｓ２
Ｔ１に登録された同期オブジェクト：Ｓｙｎｃ１（サーバＳ１から）、Ｓｙｎｃ２（サーバＳ２から）
トランザクションＴ１に参加しているリソース：ｒ１（サーバＳ１から）、ｒ２（サーバＳ２から）
【００２６】
クライアントが後に、トランザクションをコミットするために、Ｔ１．ｃｏｍｍｉｔ（）、又は同等の機能を呼び出した場合には、以下の事象のシーケンスが起こる。
１．このコミットは、コーディネータ、サーバＳ１に引き渡される。
２．サーバＳ１は、前準備段階を実行する。サーバＳ１はローカルに登録された同期コールバックを呼び出す：Ｓｙｎｃ１。サーバＳ１は、ｓｔａｒｔＰｒｅｐｒｅｐａｒｅ要求をチェーンにおける第１のサブコーディネータに送る：Ｓ２。
３．サーバ２は、前準備段階を実行する。サーバＳ２は、ローカルに登録された同期コールバックのＳｙｎｃｈｒｏｎｉｚａｔｉｏｎ．ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎを呼び出す：Ｓｙｎｃ２。Ｓｙｎｃ２．ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎ機能は、新しいサーバＳ３上のＥＪＢを呼び出す。ＥＪＢのビジネス・メソッドは、新しいリソースｒ３を起動する。その間に、サーバＳ３上のＥＪＢコンテナはさらに、新しい同期オブジェクトＳｙｎｃ３（サーバＳ３上の）を登録する。
【００２７】
その結果、トランザクションの状態情報がここで以下のように変更される。
ここで現在トランザクションＴ１に参加しているサブコーディネータ（サーバ）：Ｓ２、Ｓ３
ここでＴ１に登録された同期オブジェクト：Ｓｙｎｃ１（サーバＳ１から）、Ｓｙｎｃ２（サーバＳ２から）、Ｓｙｎｃ３（サーバＳ３から）
ここでトランザクションＴ１に参加しているリソース：ｒ１（サーバＳ１から）、ｒ２（サーバＳ２から）、ｒ３（サーバＳ３）
サーバＳ２は、ここで、それ自体の同期コールバックを完了した。これは、前準備要求を、ここではサーバＳ３であるチェーンに沿った次のサブコーディネータに通過させる。サーバＳ２が最初に前準備段階に入ったときには、チェーンにおいて最後のサブコーディネータであったが、ここでは違い、代わりにサーバＳ３が該チェーンにおける最後のサブコーディネータである。
４．サーバＳ３はここで、前準備段階を実行する。サーバＳ３はローカルに登録された同期コールバックを呼び出す：Ｓｙｎｃ３．サーバＳ３は、現在存在するチェーンにおいて、本当に最後のサブコーディネータかどうかを判断し、これにより、前準備応答をトランザクション・コーディネータ、サーバＳ１に送り戻す。
５．サーバ（及びこの場合においては、さらにトランザクション・コーディネータ）Ｓ１は、前準備段階が終わったことを知る。次に、準備に進み、次いでコミット段階に移動することができる。
【００２８】
図６は、本発明の実施形態による同期されたコールバックプロセスの段階を示すフローチャートを示す。段階７０２において、クライアント又はクライアント・アプリケーションは、処理のためのトランザクションを準備する。アクティブ段階（段階７０４）において、トランザクション処理において生じるべき種々の同期オブジェクト、リソース又はサーバが登録される（段階７０６）。トランザクションコミットが呼び出されると（段階７０７）、各々の同期オブジェクト又はリソースが順に呼び出される（段階７０８）。いずれの時点であっても、段階７１０において、同期オブジェクトのリストを修正して、参加サーバのようなリソースをコールバックループに加えるようにすることができる。現在のリストにおけるすべての同期オブジェクトがそれらのコールバックを返すと（段階７１２）、トランザクションがコミットされる（段階７１４）。
【００２９】
ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎ中のビーン起動ビーンの支持
ＥＪＢ又はＪＴＡ仕様書のいずれも、ビーンのｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎ又はｅｊｂＳｔｏｒｅメソッドが、ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎ及び／又はｅｊｂＳｔｏｒｅ方メソッドが既に呼び出された別のビーンを呼び出す場合の取り扱い方法を明らかにしていない。本発明は、このようなシナリオを多数のサーバにわたり支持する。
図７から図１４においては、ウェブロジック・サーバと併せて用いることができる特定の実施により同期されたコールバックプロセスの種々の段階と関連したライフサイクルを示す。当業者であれば、他のライフサイクル及び実施を用いて、本発明の精神及び範囲内にある同期されたコールバックを与えるようにすることができることが明らかであろう。図７は、本発明の実施形態による開始トランザクションのライフサイクルの図を示す。図７に示されるように、このプロセスは、トランザクション・マネージャ８０４で受け取られるトランザクション要求により始められる。トランザクション・マネージャ８０４は、コーディネータ・ロケータ８０５を呼び出して、トランザクション・コーディネータ８０６を選択するようにする。トランザクション・コーディネータ８０６はトランザクション識別子を備え、これを新しいトランザクション８３０と関連させる。この要求は、スレッドのプールの１つに割り当てられて、トランザクション・マネージャ８０４に返される。後続の要求は、プールから異なるスレッドに割り当てられる。
【００３０】
図８は、本発明の実施形態によるトランザクション伝播ライフサイクルの図を示す。図８に示されるように、クライアント・アプリケーション８０２は、サーバへの通信のためにローカル（クライアント）Ｊａｖａ仮想マシン（ＲＪＶＭ）８０７上で起動される遠隔メソッドを作る。クライアント・トランザクション・マネージャ８０４は要求を遮り、サーバＲＪＶＭ８０８を介してこれをサーバ・トランザクション・マネージャ８１０に通過させる。サーバ・トランザクション・マネージャ８１０は、サーバ・アプリケーション８１２によりメソッドを起動する役割のものである。応答がサーバ・アプリケーション８１２から受け取られると、サーバ・トランザクション・マネージャ８１０は、再び、クライアント及びサーバＲＪＶＭを介して、応答をクライアント・トランザクション・マネージャ８０４に通信するように働くものとなる。クライアント・トランザクション・マネージャ８０４は、応答をクライアント・アプリケーション８０２に返す。
図９は、本発明の実施形態によるコミットライフサイクルの図を示す。図９に示されるように、トランザクション・マネージャ８０４は、コミットを受け取る。コミットは、処理のためにトランザクション・コーディネータ８０６に通過される。コミットが完了すると、これはトランザクション・マネージャ８０４に返される。
【００３１】
図１０は、同期オブジェクトをどのようにｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎループに加えることができるかを示す本発明の実施形態による前準備段階のライフサイクルの図を示す。図１０に示されるように、トランザクション・コーディネータ８０６は、第１のサブコーディネータ８１４に対するｓｔａｒｔＰｒｅＰｒｅｐａｒｅにより前準備プロセスを開始する。サブコーディネータは、ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎ段階を通してトランザクションを移動させる役割のものである。ｂｅｆｏｒｅＣｏｍｐｌｅｔｉｏｎ段階が完了する前のいずれの時点においても、同期オブジェクト８１６をループの中に加えることができる。すべての同期オブジェクトが加えられると、第２のサブコーディネータ８１８は、すべての同期オブジェクト８２０と同時に作動する。ＰｒｅＰｒｅｐａｒｅの確認通知が次に、トランザクション・コーディネータ８０６に返される。当業者であれば、図１０に示されるライフサイクルにおいて、及び以下に述べられる他のライフサイクルにおいて、第１及び第２のサブコーディネータは同じエンティティであることが明らかであろう。同様に、第１及び第２の組の同期オブジェクトは、第１及び第２の組のＸＡリソースオブジェクトのように同じであってよい。さらに、ここに与えられる例においては、２つのサブコーディネータ又は２組のリソース・オブジェクトが示されるが、本発明は、トランザクションのコミットプロセスにおいて同時に含まれるべき多数のサブコーディネータ及び多数の組の同期オブジェクト及びリソースを可能にすることが明らかであろう。このようにしてサブコーディネータ及び同期オブジェクトを要求することは、コーディネータとの通信のやりとりの数を最小にすることになる。
【００３２】
図１１は、本発明の実施形態によるＸＡリソースを用いる準備段階ライフサイクルの図を示す。図１１に示されるように、ｓｔａｒｔＰｒｅｐａｒｅをもったトランザクション・コーディネータ８０６は、第１サブコーディネータ８１４を呼び出す。サブコーディネータ（又は複数のサブコーディネータ）は、ＸＡリソースオブジェクト８１７第１の組に対するトランザクションを準備する役割のものである。同時に、トランザクション・コーディネータは、ＸＡリソースオブジェクト８２１の第２の組に対してトランザクションを準備するために、第２サブコーディネータ８１８に対してｓｔａｒｔＰｒｅｐａｒｅコールを送ることができる。各々のＸＡリソースオブジェクトが準備されると、確認通知がトランザクション・コーディネータ８０６に返される。
図１２は、コミット段階のライフサイクルの図を示す。図１２に示されるように、トランザクション・コーディネータ８０６は、最初にトランザクション・ログをフラッシュする。ｓｔａｒｔＣｏｍｍｉｔコールが第１サブコーディネータ８１４に送られる。第１サブコーディネータは、コミットをＸＡリソースオブジェクト８１７の第１の組に対して発行する。同時に、トランザクション・コーディネータはｓｔａｒｔＣｏｍｍｉｔを第２サブコーディネータ８１８に送ることができる。第２サブコーディネータは、コミットをＸＡリソースオブジェクト８２１の第２の組に対して発行する。両方のコミットが完了すると、確認通知がトランザクション・コーディネータ８０６に送られる。
【００３３】
図１３は、本発明の実施形態によるロールバックのライフサイクルの図を示す。図１３に示されるように、システムがロールバックを行うことを望む場合には、トランザクション・コーディネータ８０６はｓｔａｒｔＲｏｌｌｂａｃｋを第１サブコーディネータ８１４に発行する。サブコーディネータは、ロールバックをＸＡリソースオブジェクト８１７の第１の組に行う役割のものである。同時に、システムは、第２サブコーディネータを介してｓｔａｒｔＲｏｌｌｂａｃｋコマンドをＸＡリソースオブジェクト８２１の第２の組に発行することにより、ロールバックを該ＸＡリソースオブジェクト８２１の第２の組に行うことができる。両方のロールバックが完了すると、確認通知がトランザクション・コーディネータ８０６に返される。
図１４は、本発明の実施形態によるリカバリのライフサイクルの図を示す。図１４に示されるように、リカバリプロセスは、トランザクション・コーディネータ８０６からのトランザクション・リカバリ・ログにアクセスするようにという要求により開始される。トランザクション・コーディネータ８０６が、サブコーディネータ８１４に対して、リカバリを行うようにというｓｔａｒｔＲｅｏｃｏｖｅｒｙ要求を発行すると、該サブコーディネータはトランザクション・リカバリ・ログの情報を用いて、ＸＡリソースオブジェクトの組に対してリカバリを行うようにする。サブコーディネータ８１４は、トランザクション識別子を用いて、各々のリカバリを正しく識別するようにし、このトランザクション識別子は、トランザクション・コーディネータ８０６に返される。トランザクション・コーディネータ８０６は、次に、ロールバック要求をサブコーディネータ８１４に発行する。
【００３４】
ＥＪＢアプリケーションにおけるトランザクション
図１５は、ＥＪＢクライアント・アプリケーションとサーバ・アプリケーションとの間のトランザクションが、どのように処理されるかを示す。図１５に示されるように、ＥＪＢクライアント・アプリケーション４０２は、ＥＪＢコンテナを用いて、トランザクション４０４をサーバ・アプリケーション４１０に通過させるようにする。本発明を組み込むアプリケーション・サーバは、ＥＪＢアプリケーションにおいて２種類のトランザクション、すなわちコンテナ管理トランザクション及びビーン管理トランザクションを支持する。
【００３５】
コンテナ管理トランザクションにおいては、サーバＥＪＢコンテナはトランザクション区分を管理する役割のものである。ＥＪＢ配置記述子におけるトランザクション属性は、サーバＥＪＢコンテナが各々のメソッド起動とのトランザクションをどのように取り扱うかを求めるように用いられる。ビーン管理トランザクションにおいては、ＥＪＢ自体がトランザクション区分を管理する。ＥＪＢは、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクト上で、メソッドの開始、コミット、及び必要であればトランザクションをロールバックするという明示的な起動を行う。トランザクション事象のシーケンスは、コンテナ管理トランザクションとビーン管理トランザクションとの間で異なる。コンテナ管理トランザクションをもったＥＪＢアプリケーションにおいては、基本的なトランザクションは以下の方法により作動する。
・ＥＪＢの配置記述子において、ビーンプロバイダ又はアプリケーションアセンブラは、コンテナ管理区分についてのトランザクション形式を指定する。
・ＥＪＢの配置記述子において、ビーンプロバイダ又はアプリケーションアセンブラは、ＥＪＢについてのデフォルトのトランザクション属性を指定し、これは通常、以下の設定、すなわち「支持しない」「要求する」「支持する」「新しいものを要求する」「必須」又は「決してしない］の１つである。
・任意に、ＥＪＢの配置記述子において、ビーンプロバイダ又はアプリケーションアセンブラは、１つ又はそれ以上のメソッドについてトランザクション属性を指定する。
・クライアント・アプリケーション４０２がＥＪＢにおけるメソッドを起動すると、ＥＪＢコンテナはそのメソッドについての配置記述子におけるトランザクション属性の設定をチェックする。どの設定もそのメソッドについて指定されていない場合には、ＥＪＢはそのＥＪＢについてのデフォルトのトランザクション属性の設定を用いる。
・ＥＪＢコンテナ４０６は、適用可能なトランザクション属性の設定に応じて、適切な措置をとる。例えば、トランザクション属性の設定が「要求する」である場合には、ＥＪＢコンテナは既存のトランザクション・コンテクスト内のメソッドを起動するか、又はクライアントがトランザクション・コンテクストなしで呼び出された場合には、ＥＪＢコンテナはメソッドを実行する前に新しいトランザクションを始める。
・別の例においては、トランザクション属性の設定が「必須」である場合には、ＥＪＢコンテナは既存のトランザクション・コンテクスト内のメソッドを起動する。クライアントがトランザクション・コンテクストなしで呼び出された場合には、ＥＪＢコンテナは例外エラーをスローする。
・ビジネス・メソッド４０８の起動中、ロールバックが必要であると判断された場合には、該ビジネス・メソッドは、メソッド起動の終わりに、ＥＪＢコンテナにトランザクションがロールバックされようとしていることを通知するＥＪＢロールバックメソッドを呼び出す。
・メソッド実行の終わりにおいて及び結果がクライアントに送られる前に、ＥＪＢコンテナは、サーバ・アプリケーション（４１０）においてトランザクションをコミットすることにより（この場合は、トランザクションはトランザクション・ログ４１２に書き込まれることになる）、又はこれをロールバックすることのいずれかにより、トランザクションを完了する。
【００３６】
ビーン管理トランザクション区分をもったＥＪＢアプリケーションにおいては、基本的なトランザクションは以下の方法により作動する。
・ＥＪＢの配置記述子においては、ビーンプロバイダ又はアプリケーションアセンブラは、ビーン管理区分についてのトランザクション形式を指定する。
・クライアント・アプリケーション４０２は、ＪＮＤＩを用いて、サーバドメインについてのＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトに対するオブジェクト参照を取得するようにする。
・クライアント・アプリケーション４０２は、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｂｅｇｉｎメソッドを用いてトランザクション４０４を始め、ＥＪＢコンテナを介して要求をＥＪＢに発行する。すべてのＥＪＢ実行における作動は、トランザクションの範囲内にある。
・これらの作動のいずれかに対するコールが例外を挙げた場合には（明示的に又は通信障害の結果としてのいずれか）、この例外をキャッチしてトランザクションをロールバックするようにすることができる（ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｒｏｌｌｂａｃｋ）。
・どんな例外も生じなかった場合には、クライアント・アプリケーションは、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｃｏｍｍｉｔメソッドを用いてサーバ・アプリケーション４１０に対して現在のトランザクションをコミットする。このメソッドは、トランザクションを終わらせ、作動の処理を始める。トランザクションは、該トランザクションのすべての参加者がコミットに合意した場合にのみコミットされる。
・ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｃｏｍｍｉｔメソッドは、ＥＪＢコンテナにトランザクション・マネージャをコールしてトランザクションを完了するようにさせる。
・トランザクション・マネージャは、リソース・マネージャがあらゆるデータベースを更新するように調整する役割のものである。
【００３７】
トランザクションサンプルＥＪＢコード
以下の部分は、ＥＪＢアプリケーションのクラスにおけるサンプルコードの断片のウォークスルーを提供する。コードの断片は、ビーン管理トランザクション区分についてのＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトを用いて示される。このビーンについての配置記述子は、トランザクション区分についてのトランザクション形式を指定する。
トランザクションのパッケージは、最初にインポートされる及び／又は更新されなくてはならない。リスト表示１は、トランザクションのために必要なパッケージをインポートするサンプルコードを示す。
0004550411.tif 000002
リスト表示１
【００３８】
これらのクラスをインポートした後、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトの一例がヌルに初期化される。次の段階はＪＮＤＩを用いてオブジェクト参照を返すようにすることを含む。リスト表示２は、オブジェクト参照を調べるためにＪＮＤＩを用いる一例を示す。
0004550411.tif 000003
リスト表示２
【００３９】
次に、トランザクションを生成するか又は始めなければならない。リスト表示３は、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトを獲得して、トランザクション開始メソッドを呼び出すことによるトランザクションの開始を示す。このメソッド起動後に生じ、かつトランザクションの完了前に生じるデータベース操作は、このトランザクションの範囲内にある。
0004550411.tif 000004
リスト表示３
【００４０】
ＥＪＢ実施の最終段階は、トランザクションを完了することである。リスト表示４は、このトランザクションの範囲内で試みられたデータベース操作のいずれかの間に、例外がスローされたかどうかに応じて、トランザクションを完了するコードを示す。
0004550411.tif 000005
リスト表示４
【００４１】
データベース操作のいずれかの間に、例外がスローされた場合には、アプリケーションはＪａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｒｏｌｌｂａｃｋ（）メソッドを呼び出して、トランザクションをロールバックするようにする。
如何なる例外もスローされなかった場合には、アプリケーションはｊａｖａｘ．Ｔｒａｎｓａｃｔｉｏｎ．ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｃｏｍｍｉｔ（）メソッドを呼び出して、すべてのデータベース操作が首尾よく完了した後に、トランザクションをコミットすることを試みるようにする。このメソッドの呼び出しはトランザクションを終わらせ、作動の処理を開始して、ウェブロジック・サーバＥＪＢコンテナがトランザクション・マネージャを呼び出して、トランザクションを完了するようにさせる。トランザクションは、該トランザクションのすべての参加者がコミットに合意した場合にのみコミットされる。
【００４２】
ウェブロジック・サーバＲＭＩアプリケーションにおけるトランザクション
図１６は、トランザクションがＲＭＩアプリケーションにおいてどように作動するかを示す。ＲＭＩクライアント及びサーバ・アプリケーションにおいては、基本的なトランザクションは以下の方法により作動する。
・アプリケーション５０２はＪＮＤＩを用いて、オブジェクト参照をサーバドメインについてのＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトに返す。
・オブジェクト参照の取得は、アプリケーションとそのオブジェクトとの間の会話状態を始める。会話状態は、トランザクション５０４が完了するまで続く（すなわち、コミットされるか又はロールバックされるかのいずれか）。インスタンス化されると、ＲＭＩオブジェクトはそれらが解放されるまでメモリ内に作動状態で残るが、これは典型的にはサーバのシャットダウン中である。
・クライアント・アプリケーションは、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｂｅｇｉｎメソッドを用いてトランザクションを始め、要求をサーバ・アプリケーションに発行する。
・サーバ・アプリケーション上のすべての作動は、トランザクションの範囲内で実行される。
・これらの作動のいずれかに対するコールが、例外を挙げる場合には（明示的な又は通信障害の結果として）、例外をキャッチして、トランザクションをロールバックするようにすることができる（ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｒｏｌｌｂａｃｋ）。
・どんな例外も生じなかった場合には、クライアント・アプリケーションは、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｃｏｍｍｉｔメソッドを用いて現在のトランザクションをコミットする。このメソッドは、トランザクションを終わらせ、作動の処理を始める。トランザクションは、該トランザクションのすべての参加者がコミットに合意した場合にのみコミットされる。
・ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｃｏｍｍｉｔメソッドは、サーバを呼び出して、トランザクション・マネージャがトランザクションを完了するようにさせる。
・トランザクション・マネージャは、あらゆるデータベース５１２を更新するようにリソース・マネージャを調整する役割のものである。
【００４３】
トランザクションサンプルＲＭＩコード
この部分は、ＲＭＩアプリケーションのクラスにおけるサンプルコードの断片のウォークスルーを提供する。コードの断片は、ＲＭＩトランザクションについてのＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトを用いて示される。
再び、最初の段階として、パッケージは、最初にインポートされる及び／又は必要であれば更新されなくてはならない。リスト表示５は、必要なパッケージをインポートするサンプルコードを示す。
0004550411.tif 000006
リスト表示５
【００４４】
これらのクラスをインポートした後、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトの一例がヌルに初期化される。
ＪＮＤＩを用いて、オブジェクト参照をＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトに返すようにする。リスト表示６は、適切なウェブロジック・サーバドメインについてのＵｓｅｒＴｒａｎｓａｃｔｉｏｎオブジェクトに対するオブジェクト参照を返すＪＮＤＩツリーの検索を示す。
オブジェクト参照の取得は、アプリケーションとそのオブジェクトとの間の会話状態を始める。会話状態は、トランザクションが完了するまで続く（すなわち、コミットされるか又はロールバックされるかのいずれか）。インスタンス化されると、ＲＭＩオブジェクトはそれらが解放されるまでメモリ内に作動状態で残る。
0004550411.tif 000007
リスト表示６
【００４５】
次に、トランザクションを生成されるか又は始められる。リスト表示７は、ｊａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｂｅｇｉｎ（）メソッドを呼び出すことによるトランザクションの開始を示す。このメソッド起動後に生じ、かつトランザクションの完了前に生じるデータベース操作は、このトランザクションの範囲内にある。
0004550411.tif 000008
リスト表示７
ＥＪＢ実施におけるように、トランザクションプロセスの最終段階は、トランザクションを完了することである。リスト表示８は、このトランザクションの範囲内で試みられたデータベース操作のいずれかの間に、例外がスローされたかどうかに応じて、トランザクションの完了を示す。
0004550411.tif 000009
リスト表示８
【００４６】
データベース操作のいずれかの間に、例外がスローされた場合には、アプリケーションはＪａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｒｏｌｌｂａｃｋ（）メソッドを呼び出す。
如何なる例外もスローされなかった場合には、アプリケーションはｊａｖａｘ．Ｔｒａｎｓａｃｔｉｏｎ．ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ．ｃｏｍｍｉｔ（）メソッドを呼び出して、すべてのデータベース操作が首尾よく完了した後に、トランザクションをコミットすることを試みるようにする。このメソッドの呼び出しはトランザクションを終わらせ、作動の処理を開始して、ウェブロジック・サーバがトランザクション・マネージャを呼び出して、トランザクションを完了するようにさせる。トランザクションは、該トランザクションのすべての参加者がコミットに合意した場合にのみコミットされる。
本発明の上記の説明は、図示及び説明目的のために提供された。これは、網羅的であるか又は本発明を開示された精密な形態に制限することを意図するものではない。明らかに、多くの修正及び変形が当業者には明らかであろう。実施形態は、本発明の原理及びその実用的な用途を最もよく説明するために選択されて述べられたものであり、したがって、当業者が種々の実施形態について及び考慮される特定の用途に適当な種々の修正をもって本発明を理解するようにするものである。本発明の範囲は特許請求の範囲及びその均等技術により定義されることが意図される。
【図面の簡単な説明】
【００４７】
【図１】Ｊ２ＥＥアーキテクチャの図を示す。
【図２】本発明による同期されたコールバック特徴の図を示す。
【図３】本発明と併せて用いる典型的なクライアント−サーバシステムの図を示す。
【図４】本発明の実施形態による種々のトランザクション状態の図を示す。
【図５】本発明の実施系地アによるトランザクションの同期されたコールバックシステムの第１の図を示す。
【図６】本発明の実施形態によるトランザクションの同期されたコールバックプロセスのフローチャートを示す。
【図７】本発明の実施形態によるトランザクションライフサイクルの図を示す。
【図８】本発明の実施形態による伝播ライフサイクルの図を示す。
【図９】本発明の実施形態によるコミットライフサイクルの図を示す。
【図１０】本発明の実施形態による前準備段階ライフサイクルの図を示す。
【図１１】本発明の実施形態による準備段階ライフサイクルの図を示す。
【図１２】本発明の実施形態によるコミット段階ライフサイクルの図を示す。
【図１３】本発明の実施形態によるロールバックライフサイクルの図を示す。
【図１４】本発明の実施形態によるリカバリライフサイクルの図を示す。
【図１５】本発明の実施形態によるＥＪＢアプリケーションにおいてトランザクションがどのように作動するかを示す。
【図１６】本発明の実施形態によるＲＭＩアプリケーションにおいてトランザクションがどのように作動するかを示す。
【図１】
0004550411.tif 000010
【図２】
0004550411.tif 000011
【図３】
0004550411.tif 000012
【図４】
0004550411.tif 000013
【図５】
0004550411.tif 000014
【図６】
0004550411.tif 000015
【図７】
0004550411.tif 000016
【図８】
0004550411.tif 000017
【図９】
0004550411.tif 000018
【図１０】
0004550411.tif 000019
【図１１】
0004550411.tif 000020
【図１２】
0004550411.tif 000021
【図１３】
0004550411.tif 000022
【図１４】
0004550411.tif 000023
【図１５】
0004550411.tif 000024
【図１６】
0004550411.tif 000025