(57)【特許請求の範囲】
【請求項１】
マルチテナントアプリケーションサーバ環境におけるトランザクション回復のためのシステムであって、
アプリケーションサーバ環境を含み前記アプリケーションサーバ環境が実行される１つ以上のコンピュータと、
前記アプリケーションサーバ環境内で用いることができる複数のデプロイ可能なリソースと、
ドメイン内において、デプロイ可能なリソースのグループ分けを定義する１つ以上のリソースグループテンプレートと、
１つ以上のパーティションとを含み、各々のパーティションは、前記ドメインの管理および実行時間下位区分を提供し、テナントに関連付けることができ、前記１つ以上のパーティションの各々は、
前記アプリケーションサーバ環境において動作するトランザクションマネージャと、
トランザクションにおいて用いられる複数のリソースマネージャと、
決定リソースマネージャとを含み、前記決定リソースマネージャは、前記１つ以上のパーティションのうちの１つに関連付けられ、前記トランザクションにおいて用いられ、
前記トランザクションマネージャは、
前記複数のリソースマネージャに対する準備アクションの成功についての承認を受取った後にだけ準備メッセージを前記決定リソースマネージャに送信し、かつ、
前記複数のリソースマネージャに対するコミットアクションの成功についての承認を受取った後にだけコミットメッセージを前記決定リソースマネージャに送信することによって、
前記トランザクションを処理するように構成され、前記システムはさらに、
失敗時に、
前記複数のリソースマネージャおよび前記決定リソースマネージャの各々からのインダウト・トランザクションのリストを検索し、
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させる、システム。
【請求項２】
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させることは、
前記複数のリソースマネージャの各々からの検索された前記インダウト・トランザクションのリストを前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストと比較することを含む、請求項１に記載のシステム。
【請求項３】
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させることはさらに、
前記複数のリソースマネージャの各々からの検索された前記インダウト・トランザクションのリストに現われているが、前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストには現われていない１つ以上のインダウト・トランザクションをロールバックすることを含む、請求項２に記載のシステム。
【請求項４】
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させることは、
前記複数のリソースマネージャの各々からの検索された前記インダウト・トランザクションのリストに現われており、前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストに現われている１つ以上のインダウト・トランザクションをコミットすることを含む、請求項２または３に記載のシステム。
【請求項５】
リソースマネージャは、前記１つ以上のパーティションのうちの１つのパーティションによって前記決定リソースマネージャとして指定される、請求項１から４のいずれかに記載のシステム。
【請求項６】
前記トランザクションマネージャは、構成ファイルにおいて前記決定リソースマネージャの指定を持続させる、請求項５に記載のシステム。
【請求項７】
失敗時に、前記システムは、前記複数のリソースマネージャにおける他のすべてのリソースマネージャを回復させた後に、前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストに現われるトランザクションをコミットするように構成される、請求項１から６のいずれかに記載のシステム。
【請求項８】
マルチテナントアプリケーションサーバ環境におけるトランザクション回復のための方法であって、
アプリケーションサーバ環境を含み前記アプリケーションサーバ環境が実行されている１つ以上のコンピュータにおいて、
前記アプリケーションサーバ環境内で用いることができる複数のデプロイ可能なリソースと、
ドメイン内において、デプロイ可能なリソースのグループ分けを定義する１つ以上のリソースグループテンプレートと、
１つ以上のパーティションとを提供するステップを含み、各々のパーティションは、前記ドメインの管理および実行時間下位区分を提供し、テナントに関連付けることができ、前記方法はさらに、
前記アプリケーションサーバ環境内においてトランザクションマネージャを動作させるステップと、
トランザクションにおいて用いられる複数のリソースマネージャを提供するステップと、
前記トランザクションにおいて用いられる決定リソースマネージャを前記１つ以上のパーティションのうちの１つに関連付けるステップとを含み、
前記トランザクションマネージャは、
前記複数のリソースマネージャに対する準備アクションの成功についての承認を受取った後にだけ準備メッセージを前記決定リソースマネージャに送信し、かつ、
前記複数のリソースマネージャに対するコミットアクションの成功についての承認を受取った後にだけコミットメッセージを前記決定リソースマネージャに送信することによって、
前記トランザクションを処理するように構成され、前記方法はさらに、
失敗時に、
前記複数のリソースマネージャおよび前記決定リソースマネージャの各々からのインダウト・トランザクションのリストを検索するステップと、
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させるステップとを含む、方法。
【請求項９】
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させるステップは、
前記複数のリソースマネージャの各々からの検索された前記インダウト・トランザクションのリストを前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストと比較するステップを含む、請求項８に記載の方法。
【請求項１０】
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させるステップはさらに、
前記複数のリソースマネージャの各々からの検索された前記インダウト・トランザクションのリストに現われているが、前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストには現われていない１つ以上のインダウト・トランザクションをロールバックするステップを含む、請求項９に記載の方法。
【請求項１１】
トランザクションログを用いずにすべてのインダウト・トランザクションを回復させるステップはさらに、
前記複数のリソースマネージャの各々からの検索された前記インダウト・トランザクションのリストに現われており、前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストに現われている１つ以上のインダウト・トランザクションをコミットするステップを含む、請求項９または１０に記載の方法。
【請求項１２】
リソースマネージャは、前記１つ以上のパーティションのうちの１つのパーティションによって前記決定リソースマネージャとして指定される、請求項８から１１のいずれかに記載の方法。
【請求項１３】
前記トランザクションマネージャは、構成ファイルにおいて前記決定リソースマネージャの指定を持続させる、請求項１２に記載の方法。
【請求項１４】
失敗時に、前記複数のリソースマネージャにおける他のすべてのリソースマネージャを回復させた後に、前記決定リソースマネージャからの検索された前記インダウト・トランザクションのリストに現われるトランザクションをコミットするステップをさらに含む、請求項８から１３のいずれかに記載の方法。
【請求項１５】
１つ以上のコンピュータシステム上で実行させるためのプログラム命令を含むコンピュータプログラムであって、前記プログラム命令は、実行されると、前記１つ以上のコンピュータシステムに請求項８から１４のいずれかに記載の方法を実行させる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野：
本発明の実施形態は、概して、アプリケーションサーバおよびクラウド環境に関し、特に、マルチテナントアプリケーションサーバ環境におけるトランザクション回復のためのシステムおよび方法に関する。
【背景技術】
【０００２】
背景：
アプリケーションサーバは、概して、ソフトウェアアプリケーションをデプロイして実行することができる管理された環境を提供する。クラウドベースの環境は、クラウドによって提供される分散型リソース内でアプリケーションを実行して、当該分散型リソースを利用することを可能にする。このような環境は、多くのユーザまたはテナントをサポートすることができ、それらのうちのいくつかは、そのユーザまたはテナントに特有の特定条件を有する可能性がある。
【発明の概要】
【課題を解決するための手段】
【０００３】
概要：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるトランザクション回復のためのシステムおよび方法がこの明細書中に記載される。パーティションに関連付けられた少なくとも１つのリソースマネージャは、２相コミットトランザクションを処理する際にトランザクションログ（transaction log：ＴＬＯＧ）を削除することをサポートするために、そのパーティションのための決定リソースマネージャ（限定リソースマネージャ）として指定することができる。トランザクションマネージャは、決定リソースよりも前に、中間層トランザクションシステムにおいて他のすべてのリソースマネージャを準備することができる。さらに、トランザクションマネージャは、トランザクションを回復させるための決定リソースによって提供される、コミットされるべき未処理のトランザクションのリストに依拠することができる。トランザクションマネージャは、リソースマネージャから戻されたインダウト・トランザクションであって、決定リソースマネージャから戻されたインダウト・トランザクションのリストと一致するインダウト・トランザクションをコミットすることができる。それ以外の場合、トランザクションマネージャはインダウト・トランザクションをロールバックすることができる。
【図面の簡単な説明】
【０００４】
【図１】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す図である。
【図２】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。
【図３】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。
【図４】一実施形態に従った、例示的なマルチテナント環境で使用されるドメイン構成を示す図である。
【図５】一実施形態に従った例示的なマルチテナント環境をさらに示す図である。
【図６】本発明の実施形態に従った、トランザクション環境の例を示す図である。
【図７】トランザクションミドルウェアマシン環境における２相コミットをサポートする例を示す図である。
【図８】トランザクションミドルウェアマシン環境においてインダウト・トランザクションを回復させる例を示す図である。
【図９】一実施形態に従った、トランザクションミドルウェアマシン環境においてトランザクションを処理するための２相コミット（two-phase commit：２ＰＣ）コールの厳密な順序付けをサポートする例を示す図である。
【図１０】一実施形態に従った、トランザクションログ（ＴＬＯＧ）を用いずにグローバルトランザクションを回復させる例を示す図である。
【図１１】一実施形態に従った、マルチテナントアプリケーションサーバ環境においてトランザクションログ（ＴＬＯＧ）を用いずにグローバルトランザクションを回復させる例を示す図である。
【図１２】一実施形態に従った、マルチテナントアプリケーションサーバ環境においてトランザクションログ（ＴＬＯＧ）を用いずにトランザクションを回復させる例を示す図である。
【図１３】一実施形態に従った、マルチテナントアプリケーションサーバ環境におけるトランザクション回復を示す具体的なフローチャートである。
【発明を実施するための形態】
【０００５】
詳細な説明：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるトランザクション回復のためのシステムおよび方法がこの明細書中に記載される。パーティションに関連付けられた少なくとも１つのリソースマネージャは、２相コミットトランザクションを処理する際にトランザクションログ（ＴＬＯＧ）を削除することをサポートするために、そのパーティション専用の決定リソースマネージャとして指定することができる。トランザクションマネージャは、決定リソースよりも前に、中間層トランザクションシステムにおける他のすべてのリソースマネージャを準備することができる。さらに、トランザクションマネージャは、トランザクションを回復させるために、決定リソースによって提供される、コミットされるべき未処理のトランザクションのリストに依拠することができる。トランザクションマネージャは、リソースマネージャから戻されるインダウト・トランザクションであって、決定リソースマネージャから戻されるインダウト・トランザクションのリストと一致するインダウト・トランザクションをコミットすることができる。それ以外の場合、トランザクションマネージャはインダウト・トランザクションをロールバックすることができる。
【０００６】
アプリケーションサーバ（たとえば、マルチテナント（Multi-Tenant：ＭＴ））環境
図１は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す。
【０００７】
図１に示されるように、一実施形態に従うと、アプリケーションサーバ（たとえばマルチテナント（ＭＴ））環境１００または他のコンピューティング環境は、ソフトウェアアプリケーションのデプロイメントおよび実行を可能にするものであって、アプリケーションサーバドメインを定義するために実行時に用いられるドメイン１０２の構成を含み、当該ドメイン１０２の構成に従って動作するように構成することができる。
【０００８】
一実施形態に従うと、アプリケーションサーバは、実行時に使用されるよう定義される１つ以上のパーティション１０４を含み得る。各々のパーティションは、グローバルユニークパーティション識別子（identifier：ＩＤ）およびパーティション構成に関連付けることができ、さらに、リソースグループテンプレートの参照１２６および／またはパーティション特有のアプリケーションもしくはリソース１２８とともに、１つ以上のリソースグループ１２４を含み得る。ドメインレベルのリソースグループ、アプリケーションおよび／またはリソース１４０も、任意にはリソースグループテンプレートの参照とともに、ドメインレベルで定義することができる。
【０００９】
各々のリソースグループテンプレート１６０は、１つ以上のアプリケーションＡ１６２、Ｂ１６４、リソースＡ１６６、Ｂ１６８および／または他のデプロイ可能なアプリケーションもしくはリソース１７０を定義することができ、リソースグループによって参照することができる。たとえば、図１に例示されるように、パーティション１０４におけるリソースグループ１２４は、リソースグループテンプレート１６０を参照する（１９０）ことができる。
【００１０】
概して、システムアドミニストレータは、パーティション、ドメインレベルのリソースグループおよびリソースグループテンプレート、ならびにセキュリティ領域を定義することができるとともに、パーティションアドミニストレータは、たとえば、パーティションレベルのリソースグループを作成するか、アプリケーションをパーティションにデプロイするかまたはパーティションについての特定の領域を参照することによって、それら自体のパーティションのアスペクトを定義することができる。
【００１１】
図２は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。
【００１２】
図２に示されるように、一実施形態に従うと、パーティション２０２は、たとえば、リソースグループテンプレート２１０の参照２０６を含むリソースグループ２０５と、仮想ターゲット（たとえば仮想ホスト）情報２０７と、プラグ接続可能なデータベース（pluggable database：ＰＤＢ）情報２０８とを含み得る。リソースグループテンプレート（たとえば２１０）は、たとえば、Ｊａｖａ（登録商標）メッセージサーバ（Java Message Server：ＪＭＳ）サーバ２１３、ストア・アンド・フォワード（store-and-forward：ＳＡＦ）エージェント２１５、メールセッションコンポーネント２１６またはＪａｖａデータベースコネクティビティ（Java Database Connectivity：ＪＤＢＣ）リソース２１７などのリソースとともに、複数のアプリケーションＡ２１１およびＢ２１２を定義することができる。
【００１３】
図２に例示されるリソースグループテンプレートが一例として提供される。他の実施形態に従うと、さまざまなタイプのリソースグループテンプレートおよび要素を提供することができる。
【００１４】
一実施形態に従うと、パーティション（たとえば２０２）内のリソースグループが、特定のリソースグループテンプレート（たとえば２１０）を参照する（２２０）と、パーティション特有の情報２３０（たとえば、パーティション特有のＰＤＢ情報）を示すために、特定のパーティションに関連付けられた情報を、参照されたリソースグループテンプレートと組合わせて用いることができる。次いで、パーティション特有の情報は、パーティションによって使用されるリソース（たとえば、ＰＤＢリソース）を構成するようにアプリケーションサーバによって使用可能である。たとえば、パーティション２０２に関連付けられたパーティション特有のＰＤＢ情報は、そのパーティションによって使用されるべき適切なＰＤＢ２３８を備えたコンテナデータベース（container database：ＣＤＢ）２３６を構成する（２３２）ようにアプリケーションサーバによって使用可能である。
【００１５】
同様に、一実施形態に従うと、特定のパーティションに関連付けられた仮想ターゲット情報を用いて、そのパーティションによって使用されるべきパーティション特有の仮想ターゲット２４０（たとえば、ユニフォーム・リソース・ロケータ（uniform resource locator：ＵＲＬ）（たとえば、http://baylandurgentcare.com）によってアクセス可能にすることができるbaylandurgentcare.com）を定義する（２３９）ことができる。
【００１６】
図３は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。
【００１７】
一実施形態に従うと、config.xml構成ファイルなどのシステム構成を用いて、パーティションを定義する。当該パーティションは、そのパーティションに関連付けられたリソースグループについての構成エレメントおよび／または他のパーティションプロパティを含む。値は、プロパティ名／値の対を用いてパーティション毎に指定することができる。
【００１８】
一実施形態に従うと、複数のパーティションは、管理されたサーバ／クラスタ２４２内で、または、ＣＤＢ２４３にアクセス可能でありかつウェブ層２４４を介してアクセス可能である同様の環境内で、実行することができる。これにより、たとえば、ドメインまたはパーティションを（ＣＤＢの）ＰＤＢのうち１つ以上のＰＤＢに関連付けることが可能となる。
【００１９】
一実施形態に従うと、複数のパーティションの各々、この例においてはパーティションＡ２５０およびパーティションＢ２６０は、そのパーティションに関連付けられた複数のリソースを含むように構成することができる。たとえば、パーティションＡは、アプリケーションＡ１  ２５２と、アプリケーションＡ２  ２５４と、ＪＭＳ  Ａ  ２５６と、さらには、ＰＤＢ  Ａ  ２５９に関連付けられたデータソースＡ２５７とをともに含むリソースグループ２５１を含むように構成することができる。この場合、パーティションは仮想ターゲットＡ２５８を介してアクセス可能である。同様に、パーティションＢ２６０は、アプリケーションＢ１  ２６２と、アプリケーションＢ２  ２６４と、ＪＭＳ  Ｂ  ２６６と、さらには、ＰＤＢ  Ｂ  ２６９に関連付けられたデータソースＢ２６７とをともに含むリソースグループ２６１を含むように構成することができる。この場合、パーティションは仮想ターゲットＢ２６８を介してアクセス可能である。
【００２０】
上述の例のうちいくつかはＣＤＢおよびＰＤＢの使用を例示しているが、他の実施形態に従うと、他のタイプのマルチテナントのデータベースまたは非マルチテナントのデータベースをサポートすることができる。この場合、特定の構成は、たとえば、スキーマを使用するかまたはさまざまなデータベースを使用することによって、各々のパーティションのために提供することができる。
【００２１】
リソース
一実施形態に従うと、リソースは、環境のドメインにデプロイすることができるシステムリソース、アプリケーションまたは他のリソースもしくはオブジェクトである。たとえば、一実施形態に従うと、リソースは、アプリケーション、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、ＷＬＤＦもしくはデータソースであり得るか、または、サーバ、クラスタもしくは他のアプリケーションサーバターゲットにデプロイすることができる他のシステムリソースもしくは他のタイプのオブジェクトであり得る。
【００２２】
パーティション
一実施形態に従うと、パーティションは、パーティション識別子（partition identifier：ＩＤ）および構成に関連付けられ得るドメインのうち実行時間および管理の下位区分またはスライスであるとともに、アプリケーションを含み得て、ならびに／または、リソースグループおよびリソースグループテンプレートを使用することによってドメイン全体に渡るリソースを参照し得る。
【００２３】
概して、パーティションは、それ自体のアプリケーションを含み、リソースグループテンプレートを介してドメイン全体に渡るアプリケーションを参照し、それ自体の構成を有し得る。パーティション可能なエンティティは、リソース、たとえば、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、およびＷＬＤＦリソースや、他のコンポーネント、たとえばＪＮＤＩネームスペース、ネットワークトラフィック、ワークマネージャ、セキュリティポリシーおよび領域などを含み得る。マルチテナント環境のコンテキストにおいては、システムは、テナントに関連付けられたパーティションの管理および実行時間のアスペクトへのアクセスをテナントに提供するように構成することができる。
【００２４】
一実施形態に従うと、パーティション内の各々のリソースグループは、任意には、リソースグループテンプレートを参照することができる。パーティションは、複数のリソースグループを有し得るとともに、それらの各々はリソースグループテンプレートを参照し得る。各々のパーティションは、パーティションのリソースグループが参照するリソースグループテンプレートにおいて指定されていない構成データについてのプロパティを定義することができる。これにより、パーティションが、リソースグループテンプレートで定義されたデプロイ可能なリソースをそのパーティションで使用されるべき特定の値にバインドするものとして機能することが可能となる。場合によっては、パーティションは、リソースグループテンプレートによって指定される構成情報を無効にすることができる。
【００２５】
一実施形態に従うと、パーティション構成は、たとえば、config.xml構成ファイルによって定義されるように、複数の構成エレメントを含み得る。複数の構成エレメントは、たとえば、「パーティション（partition）」（そのパーティションを定義する属性および子エレメントを含む）；「リソース・グループ（resource-group）」（パーティションにデプロイされるアプリケーションおよびリソースを含む）；「リソース・グループ・テンプレート（resource-group-template）」；（そのテンプレートによって定義されるアプリケーションおよびリソースを含む）；「ｊｄｂｃ・システム・リソース・無効化（jdbc-system-resource-override）」（データベース特有のサービス名、ユーザ名およびパスワードを含む）；ならびに、「パーティションプロパティ（partition-properties）」（リソースグループテンプレートにおいてマクロ置換のために使用可能なプロパティキー値を含む）を含む。
【００２６】
始動後、システムは、構成ファイルによって提供される情報を用いて、リソースグループテンプレートから各々のリソースについてのパーティション特有の構成エレメントを生成することができる。
【００２７】
リソースグループ
一実施形態に従うと、リソースグループは、名前付けされ完全に修飾されたデプロイ可能なリソースの集合であって、ドメインまたはパーティションのレベルで定義することができ、かつ、リソースグループテンプレートを参照することができる。リソースグループにおけるリソースは、完全に修飾されているものと見なされる。というのも、アドミニストレータが、それらのリソースを開始させるのに必要とされるかまたはそれらのリソースに接続するのに必要とされるすべての情報、たとえば、データソースに接続するためのクレデンシャル、またはアプリケーションについての目標情報、を提供しているからである。
【００２８】
システムアドミニストレータは、ドメインレベルで、またはパーティションレベルでリソースグループを公開することができる。ドメインレベルでは、リソースグループは、関連するリソースをグループ化するのに好都合な方法を提供する。システムは、グループ化されていないリソースと同じドメインレベルのリソースグループにおいて公開されたリソースを管理することができる。このため、リソースは、システム起動中に開始させたり、システムのシャットダウン中に停止させたりすることができる。アドミニストレータはまた、グループ内のリソースを個々に停止させるか、開始させるかまたは削除することができ、グループ上で動作させることによって暗黙的にグループ内のすべてのリソースに対して機能することができる。たとえば、あるリソースグループを停止させることにより、まだ停止されていないグループにおけるすべてのリソースを停止させ；リソースグループを始動させることにより、まだ始動させていないグループにおけるいずれのリソースも始動させ、リソースグループを削除することにより、グループに含まれるすべてのリソースを削除する。
【００２９】
パーティションレベルでは、システムまたはパーティションアドミニストレータは、任意のセキュリティ制限下で、或るパーティションにおいて０個以上のリソースグループを構成することができる。たとえば、ＳａａＳ使用事例においては、さまざまなパーティションレベルのリソースグループは、ドメインレベルのリソースグループテンプレートを参照することができる。ＰａａＳ使用事例においては、リソースグループテンプレートを参照しないが代わりにそのパーティション内でのみ利用可能にされるべきアプリケーションおよびそれらの関連するリソースを表わすパーティションレベルのリソースグループを作成することができる。
【００３０】
一実施形態に従うと、リソースグループ化を用いることで、アプリケーションと、それらアプリケーションがドメイン内で別個の管理ユニットとして使用するリソースとをともにグループ化することができる。たとえば、以下に記載される医療記録（ＭｅｄＲｅｃ）アプリケーションにおいては、リソースグループ化によりＭｅｄＲｅｃアプリケーションおよびそのリソースが定義される。複数のパーティションは、各々がパーティション特有の構成情報を用いて、同じＭｅｄＲｅｃリソースグループを実行することができ、このため、各々のＭｅｄＲｅｃインスタンスの一部であるアプリケーションが各々のパーティションにとって特有のものにされる。
【００３１】
リソースグループテンプレート
一実施形態に従うと、リソースグループテンプレートは、リソースグループから参照することができドメインレベルで定義されるデプロイ可能なリソースの集合であり、そのリソースを起動するのに必要な情報のうちいくらかは、パーティションレベル構成の仕様をサポートするように、テンプレート自体の一部として記憶されない可能性がある。ドメインは、リソースグループテンプレートをいくつ含んでもよく、それらの各々は、たとえば、１つ以上の関連するＪａｖａアプリケーションと、それらのアプリケーションが依存するリソースとを含み得る。このようなリソースについての情報のうちのいくらかは、すべてのパーティションにわたって同じであってもよく、他の情報はパーティション毎に異なっていてもよい。すべての構成がドメインレベルで指定される必要はなく、代わりに、パーティションレベル構成が、マクロまたはプロパティ名／値の対を使用することによってリソースグループテンプレートで指定することができる。
【００３２】
一実施形態に従うと、特定のリソースグループテンプレートは、１つ以上のリソースグループによって参照可能である。概して、任意の所与のパーティション内では、リソースグループテンプレートは一度に１つのリソースグループによって参照することができる。すなわち、同じパーティション内で複数のリソースグループによって同時に参照することはできない。しかしながら、異なるパーティションにおける別のリソースグループによって同時に参照することができる。リソースグループを含むオブジェクト、たとえばドメインまたはパーティションは、プロパティ名／値の割当てを用いて、任意のトークンの値をリソースグループテンプレートで設定することができる。システムは、参照するリソースグループを用いてリソースグループテンプレートを起動させると、それらのトークンを、リソースグループが含むオブジェクトにおいて設定された値と置換えることができる。場合によっては、システムはまた、静的に構成されたリソースグループテンプレートおよびパーティションを用いて、パーティション／テンプレートの組合せ毎に実行時間の構成を生成することができる。
【００３３】
たとえば、ＳａａＳ使用事例においては、システムは、同じアプリケーションおよびリソースを複数回起動することができるが、そのうちの１回は、それらを用いるであろう各パーティションごとに起動され得る。アドミニストレータがリソースグループテンプレートを定義すると、これらは、どこか他のところで提供されるであろう情報を表わすためにトークンを用いることができる。たとえば、ＣＲＭ関連のデータリソースに接続する際に使用されるユーザ名は、リソースグループテンプレートにおいて＼＄｛ＣＲＭＤａｔａＵｓｅｒｎａｍｅ｝として示すことができる。
【００３４】
テナント
一実施形態に従うと、マルチテナント（ＭＴ）アプリケーションサーバ環境などのマルチテナント環境においては、テナントは、１つ以上のパーティションおよび／もしくは１つ以上のテナント認識型アプリケーションによって表現可能であるエンティティ、または１つ以上のパーティションおよび／もしくは１つ以上のテナント認識型アプリケーションに関連付けることができるエンティティである。
【００３５】
たとえば、テナントは、別個のユーザ組織、たとえばさまざまな外部会社、特定の企業内のさまざまな部門（たとえばＨＲおよび財務部）などを表わすことができ、それら各々は、異なるパーティションに関連付けることができる。テナントのグローバルユニークアイデンティティ（テナントＩＤ）は、特定の時点において特定のユーザを特定のテナントに関連付けるものである。システムは、たとえば、ユーザアイデンティティの記録を参照することによって、ユーザアイデンティティから、特定のユーザがどのテナントに属しているかを導き出すことができる。ユーザアイデンティティにより、ユーザが実行することを認可されているアクションをシステムが実施することが可能となる。ユーザアイデンティティは、ユーザがどのテナントに属し得るかを含むが、これに限定されない。
【００３６】
一実施形態に従うと、システムは、互いに異なるテナントの管理および実行時間を分離することを可能にする。たとえば、テナントは、それらのアプリケーションのいくつかの挙動、およびそれらがアクセスできるリソースを構成することができる。システムは、特定のテナントが別のテナントに属するアーティファクトを確実に管理することができないようにし、かつ、実行時に、特定のテナントの代わりに機能するアプリケーションがそのテナントに関連付けられたリソースのみを参照するが他のテナントに関連付けられたリソースは参照しないことを確実にすることができる。
【００３７】
一実施形態に従うと、テナント非認識型アプリケーションは、アプリケーションが応答している要求をどんなユーザが提示したかにかかわらず、アプリケーションが用いる如何なるリソースにもアクセス可能となるように明示的にテナントに対処する論理を含まないものである。対照的に、テナント認識型アプリケーションは、テナントに明示的に対処する論理を含む。たとえば、ユーザのアイデンティティに基づいて、アプリケーションは、ユーザが属するテナントを導き出すことができ、テナント特有のリソースにアクセスするためにその情報を用いることができる。
【００３８】
一実施形態に従うと、システムは、テナント認識型となるように明示的に書込まれたアプリケーションをユーザがデプロイすることを可能にし、これにより、アプリケーション開発者は、現在のテナントのテナントＩＤを取得することができる。次いで、テナント認識型アプリケーションは、このテナントＩＤを用いて、アプリケーションの単一のインスタンスを用いている複数のテナントを処理することができる。
【００３９】
たとえば、単一の診療室または病院をサポートするＭｅｄＲｅｃアプリケーションは、２つの異なるパーティションまたはテナント（たとえばBayland Urgent CareテナントおよびValley Healthテナント）に対して公開することができ、その各々は、基礎をなすアプリケーションコードを変更することなく、別個のＰＤＢなどの別個のテナント特有のリソースにアクセスすることができる。
【００４０】
例示的なドメイン構成およびマルチテナント環境
一実施形態に従うと、アプリケーションは、ドメインレベルでリソースグループテンプレートにデプロイすることができるか、または、パーティションに範囲指定されているかもしくはドメインに範囲指定されているリソースグループにデプロイすることができる。アプリケーション構成は、アプリケーション毎またはパーティション毎に指定されたデプロイメントプランを用いて無効化することができる。デプロイメントプランはまた、リソースグループの一部として指定することができる。
【００４１】
図４は、一実施形態に従った、例示的なマルチテナント環境で使用されるドメイン構成を示す。
【００４２】
一実施形態に従うと、システムがパーティションを始動させると、当該システムは、提供された構成に従って、それぞれのデータベースインスタンスに対して、各パーティションごとに１つずつ、仮想ターゲット（たとえば仮想ホスト）および接続プールを作成する。
【００４３】
典型的には、各々のリソースグループテンプレートは、１つ以上の関連するアプリケーションと、それらアプリケーションが依存するリソースとを含み得る。各々のパーティションは、それが参照するリソースグループテンプレートにおいて指定されていない構成データを提供することができるが、これは、場合によっては、リソースグループテンプレートによって指定されるいくつかの構成情報を無効にすることを含めて、パーティションに関連付けられた特定値に対するリソースグループテンプレートにおけるデプロイ可能なリソースのバインディングを行なうことによって、実行可能である。これにより、システムは、各々のパーティションが定義したプロパティ値を用いて、パーティション毎にリソースグループテンプレートによってさまざまに表わされるアプリケーションを始動させることができる。
【００４４】
いくつかのインスタンスにおいては、パーティションが含み得るリソースグループは、リソースグループテンプレートを参照しないか、または、それら自体のパーティション範囲指定されたデプロイ可能なリソースを直接定義する。パーティション内で定義されるアプリケーションおよびデータソースは、概して、そのパーティションにとってのみ利用可能である。リソースは、パーティション：<partitionName>/<resource JNDI name>、またはドメイン：<resource JNDI name>を用いて、パーティションの中からアクセスすることができるようにデプロイ可能である。
【００４５】
たとえば、ＭｅｄＲｅｃアプリケーションは、複数のＪａｖａアプリケーション、データソース、ＪＭＳサーバおよびメールセッションを含み得る。複数のテナントのためにＭｅｄＲｅｃアプリケーションを実行させるために、システムアドミニストレータは、テンプレートにおけるそれらのデプロイ可能なリソースを公開している単一のＭｅｄＲｅｃリソースグループテンプレート２８６を定義することができる。
【００４６】
ドメインレベルのデプロイ可能なリソースとは対照的に、リソースグループテンプレートにおいて公開されたデプロイ可能なリソースは、テンプレートにおいて完全には構成されない可能性があるか、または、いくつかの構成情報が不足しているので、そのままでは起動させることができない。
【００４７】
たとえば、ＭｅｄＲｅｃリソースグループテンプレートは、アプリケーションによって用いられるデータソースを公開し得るが、データベースに接続するためのＵＲＬを指定しない可能性がある。さまざまなテナントに関連付けられたパーティション、たとえば、パーティションＢＵＣ−Ａ２９０（Bayland Urgent Care：ＢＵＣ）およびパーティションＶＨ−Ａ２９２（Valley Health：ＶＨ）は、各々がＭｅｄＲｅｃリソースグループテンプレートを参照する（２９６，２９７）ＭｅｄＲｅｃリソースグループ２９３，２９４を含むことによって、１つ以上のリソースグループテンプレートを参照することができる。次いで、当該参照を用いて、Bayland Urgent Careテナントによって使用されるＢＵＣ−Ａパーティションに関連付けられた仮想ホストbaylandurgentcare.com３０４と、Valley Healthテナントによって使用されるＶＨ−Ａパーティションに関連付けられた仮想ホストvalleyhealth.com３０８とを含む各々のテナントのための仮想ターゲット／仮想ホストを作成する（３０２，３０６）ことができる。
【００４８】
図５は、一実施形態に従った例示的なマルチテナント環境をさらに示す。図５に示されるように、２つのパーティションがＭｅｄＲｅｃリソースグループテンプレートを参照している上述の例から引続いて、一実施形態に従うと、サーブレットエンジン３１０は、この例においてはBayland Urgent Careの医師テナント環境３２０およびValley Healthの医師テナント環境３３０といった複数のテナント環境をサポートするために用いることができる。
【００４９】
一実施形態に従うと、各々のパーティション３２１および３３１は、そのテナント環境についての入来トラフィックを受入れるための異なる仮想ターゲットと、異なるＵＲＬ３２２，３３２とを定義することができる。異なるＵＲＬ３２２，３３２は、パーティションと、この例ではBayland Urgent Careデータベースまたはvalley healthデータベースを含むそれぞれのリソース３２４、３３４とに接続するためのものである。同じアプリケーションコードが両方のデータベースに対して実行され得るので、データベースインスタンスは互換性のあるスキーマを用いることができる。システムがパーティションを始動させると、当該システムは、それぞれのデータベースインスタンスに対する接続プールおよび仮想ターゲットを作成することができる。
【００５０】
トランザクション環境およびグローバルトランザクション
図６は、本発明の一実施形態に従ったトランザクション環境の例を示す。図６に示されるように、トランザクション環境６００は、アプリケーションプログラム６０２、１つ以上のトランザクションマネージャ（transaction manager：ＴＭ）６０３、複数のリソースマネージャ（resource manager：ＲＭ）６０４〜６０６、および１つ以上の永続的記憶装置（たとえばデータベース６１０）を含み得る。
【００５１】
本発明の一実施形態に従うと、アプリケーションプログラム６０２は、トランザクションを構成するアクションを指定することができる。図示されるように、アプリケーションプログラム６０２はトランザクションマネージャ６０３と通信してトランザクションを開始させるかコミットするかまたは中止させ、トランザクションマネージャ６０３は、アプリケーションプログラム６０２にトランザクションの開始、終了および破棄を送り返すことができる。さらに、アプリケーションプログラム６０２は、複数のリソースマネージャ（ＲＭ）６０４〜６０６とトランザクション情報をやりとりすることができるトランザクションマネージャ６０３のためのトランザクション境界を定義することができる。加えて、アプリケーションプログラム６０２は、埋込み型構造化クエリ（Structured Query：ＳＱＬ）によって複数のリソースマネージャ６０４〜６０６と通信して作業を行なわせることができる。
【００５２】
複数のリソースマネージャ６０４〜６０６は、永続的記憶装置、たとえばデータベース６１０（またはデータベース）、にアクセスすることができる。本発明の一実施形態に従うと、複数のリソースマネージャ６０４〜６０６は、永続的記憶装置に対するデータベースのトランスペアレントな接続および切断を処理するために、ＸＡ（eXtended Architecture：拡張されたアーキテクチャ）インターフェイスを実現することができる。ＸＡインターフェイスは、トランザクションの調整、コミットメントおよび回復のためのプロトコルを記述する規格に基づき得る。トランザクションに関与するＸＡリソースは、ＸＡリソースマネージャおよびバックエンドの永続的記憶装置を含み得る。
【００５３】
本発明のさまざまな実施形態に従うと、トランザクションシステムは、２つ以上のサーバ上で実行することができるグローバルトランザクションをサポートすることができ、２つ以上のリソースマネージャからデータにアクセスすることができる。
【００５４】
グローバルトランザクションは、４つのプロパティ（すなわち原子性、一貫性、独立性、および耐久性（atomicity, consistency, isolation, and durability：ＡＣＩＤ））によって特徴付けられる特別な一連の動作として処理することができる。グローバルトランザクションは作業の論理単位であり得る。この場合、トランザクションのすべての部分の実行が成功するかまたは無効となる。同様に、リソースを１つの一貫した状態から別の状態まで正確に変換する動作が実行される。加えて、グローバルトランザクション内では、中間結果は、一般的に、他のトランザクションにアクセス可能ではないが、但し、同じトランザクションにおける他のプロセスがデータにアクセスする可能性がある。同様に、完全な一連のグローバルトランザクションの効果は、一般に、失敗のせいで変更されるものではない。
【００５５】
さらに、グローバルトランザクションは、一実施形態に従うと、いくつかのローカルトランザクションを含み得る。各々のローカルトランザクションは単一のリソースマネージャにアクセスし得る。ローカルトランザクションは、単一のデータベースまたはファイルにアクセスすることができ、その別個のデータベースにおいて並列処理制御および更新の原子性を実行する役割を果たすリソースマネージャによって制御することができる。所与のローカルトランザクションは、そのアクセスを完了させるのに成功するかもしれず、または失敗するかもしれない。
【００５６】
一実施形態に従うと、トランザクションマネージャ６０３は、トランザクション環境６００において、グローバルトランザクション識別子（global transaction identifier：ＧＴＲＩＤ）をさまざまなトランザクションに割当てることができる。トランザクションマネージャ６０３は、トランザクションの進渉を監視することができ、トランザクションを確実に完了させたり、障害を回復させたりする役割を果たすことができる。加えて、トランザクションマネージャ６０３は、たとえば２相コミットコールをリソースマネージャ６０４および６０５に送信するなどしてトランザクション情報をやりとりするために、ＸＡインターフェイスを介して複数のリソースマネージャ６０４および６０５と通信することができる。
【００５７】
２相コミット（２ＰＣ）
２相コミット（２ＰＣ）プロトコルは、疎結合グローバルトランザクションなどのトランザクションを実行するために用いることができる。２相コミットプロトコル（２ＰＣ）は、準備相およびコミット相を含み得る。準備相において、調整トランザクションマネージャ（ＴＭ）は、トランザクションをコミットするかまたは中止するための必要なステップを行なうように、関与するリソースマネージャ（ＲＭ）に指示する。コミット相において、トランザクションマネージャ（ＴＭ）は、準備相の結果に基づいて、トランザクションをコミットするべきかまたは中止するべきかどうかを決定する。
【００５８】
図７は、トランザクションミドルウェアマシン環境において２相コミットをサポートする例を示す。図７に示されるように、トランザクション環境７００は、さまざまなトランザクションの実行をサポートするトランザクションマネージャ７０１と、１つ以上のデータソース（たとえばデータベース７０５）を管理する１つ以上のリソースマネージャ７０２〜７０４とを含み得る。
【００５９】
たとえば、トランザクションマネージャ７０１は、トランザクションブランチＡ７１１、トランザクションブランチＢ７１２およびトランザクションブランチＣ７１３を必要とするトランザクションを実行することができる、これらトランザクションブランチは、それぞれ、リソースマネージャ７０２〜７０４に対して実行され得る。いずれかのブランチがトランザクションに失敗すると、トランザクションマネージャ７０１は、トランザクションをコミットすべきかまたはロールバックすべきかどうかをリソースマネージャ７０２〜７０４が決定するのを支援し得る。
【００６０】
図７に示されるように、トランザクションマネージャ７０１は、３つのすべてのブランチ上でリソースマネージャ７０２〜７０４に準備命令を送信する（ステップ１、２および３）ことができる。リソースマネージャ７０２〜７０４が準備ＯＫを示す「承認」票を返した（ステップ４、５および６）後、トランザクションマネージャ７０１は、トランザクションログ（ＴＬＯＧ）をデータベース７０５に書込む（ステップ７）ことができる。
【００６１】
トランザクションログはファイルまたはデータベースのいずれかに書込まれる可能性があり、このため、トランザクションマネージャ７０１は、コミット相中にいずれかのブランチが機能しなくなった場合に、トランザクションを回復させるのに十分な情報を有することができる。
【００６２】
次いで、トランザクションマネージャ７０１は、３つのすべてのブランチをコミットする（ステップ８、９および１０）ようにリソースマネージャ７０２〜７０４に指示することができる。リソースマネージャ７０２〜７０４は、コミット相の完了に成功した（ステップ１１、１２および１３）後、トランザクションマネージャ７０１に通知することができる。
【００６３】
トランザクションログ（ＴＬＯＧ）に基づいたトランザクションの回復
本発明の一実施形態に従うと、トランザクションログ（ＴＬＯＧ）は、トランザクションマネージャによってトランザクションをコミットするための決定を記憶することができる。たとえば、ＴＬＯＧは、リソースチェックポイント記録を記憶することができる。リソースチェックポイント記録は、関与するさまざまなＸＡリソースを追跡することができるようにするために、トランザクションマネージャによって持続させることができる。
【００６４】
準備相の後に、トランザクションマネージャがすべてのトランザクションブランチから成功票を受取ると、トランザクションをＴＬＯＧに書込むことができる。ＴＬＯＧにおけるトランザクション記録は、少なくともトランザクション識別子（transaction identifier：ＸＩＤ）を含み得る。トランザクション識別子はさらに、トランザクションマネージャによって割当てられたＧＴＲＩＤと、リソースマネージャによって割当てられてトランザクションの実行に用いられるローカルＸＩＤとを含む。
【００６５】
さらに、ＴＬＯＧは、コミットされるべく印が付けられているインフライト・トランザクションの状態の記録を保持することができる。ＴＬＯＧはインダウト・トランザクションを回復させるのに有用である。インダウト・トランザクションとは、既に準備されていたトランザクションであるが、たとえばシステムクラッシュの後に中間層トランザクションシステムにおいてまだコミットされていないトランザクションである。インダウト・トランザクションを回復させない場合、システムは、クラッシュ後に不正確で一貫性のない状態になり得る。
【００６６】
たとえば、システムが２相コミットトランザクション中に故障した場合、１つのバックエンド・データストアの更新がコミットされ得るかもしれないが、別のデータストアの更新は、同じトランザクションにおいては、コミットするようにとの指示がまだなされていなかった可能性もある。すなわち、データストアの更新は依然としてペンディング中である。システムのうち故障した部分が再始動されると、ペンディング中の更新を保持しているデータストアは、それらの更新がコミットされるべきであるかまたはロールバックされるべきであるかどうかを認識することができないかもしれない。
【００６７】
図８は、トランザクションミドルウェアマシン環境においてインダウト・トランザクションを回復させる例を示す。図８に示されるように、トランザクションミドルウェアマシン環境８００は、トランザクションマネージャ８０１、複数のリソースマネージャ８０２〜８０４、および永続的記憶装置、すなわちデータベース８０５、を含む。
【００６８】
トランザクションマネージャ８０１は、ＴＬＯＧを読取る／参照する（ステップ１）ことにより、グローバルトランザクションがインダウトであるかどうかを自動的に判断することができる。次いで、トランザクションマネージャ８０１は、関与するリソースマネージャ８０２〜８０４のうち妥当なバックエンド・データストアをポーリングすることができる。関与するリソースマネージャ８０２〜８０４の各々は、ロールバックするべきであるかまたはコミットするべきであるかをトランザクションマネージャ８０１が認識していないトランザクションに該当するインダウト・トランザクションのリストを戻す（ステップ２、４および６）ことができる。
【００６９】
さらに、トランザクションマネージャ８０１は、各々のインダウト・トランザクションをＴＬＯＧと一致させることができ、引き続き、さまざまなリソースマネージャ８０２〜８０４上でインダウト・トランザクションをコミットするかまたはロールバックする（ステップ３、５および７）ことができる。たとえば、インダウト・トランザクションがＴＬＯＧで行なわれると、ＴＬＯＧにおいて指定されているリソースマネージャにインダウト・トランザクションをコミットするために、ＸＡＲｅｓｏｕｒｃｅ．ｃｏｍｍｉｔ（）をコールすることができる。他方では、トランザクションがＴＬＯＧにない場合、すなわち、トランザクションについてのコミットの判断がクラッシュの前になされていなかった場合、トランザクション識別子（ＸＩＤ）に基づいてリソースマネージャ上でこれをロールバックするために、ＸＡＲｅｓｏｕｒｃｅ．ｒｏｌｌｂａｃｋ（）をコールすることができる。
【００７０】
図８に示されるように、トランザクションがリソースマネージャ８０２で準備されていた可能性もあり、そして、リソースマネージャ８０２がトランザクションマネージャ８０１に成功票を送信することができるようになる前に、システムがクラッシュしてしまう。すると、トランザクションマネージャ８０１は、すべてのトランザクションブランチから成功票を受取ることができないかもしれず、このため、ＴＬＯＧにおけるトランザクションをログすることができなくなる。したがって、トランザクションマネージャ８０１は、それぞれのリソースマネージャ８０２〜８０４上ですべてのブランチトランザクションをロールバックすることができる。このため、このような一貫性のある予測可能なトランザクション回復アプローチを用いると、トランザクションマネージャは複雑でヒューリスティックな完了を回避することができ、この場合、いくつかのブランチがコミットされ、いくつかのブランチがロールバックされる。
【００７１】
トランザクションマネージャ回復ログの必要性の軽減
トランザクション環境においては、回復を実行してＡＣＩＤプロパティを確実にするために回復情報の安定した記憶を持続させる必要があるが、これは、概して、２相についての設計要件である。しかしながら、回復情報の安定した記憶（たとえばＴＬＯＧ）を持続させる必要がある場合、これは、リソースマネージャに対する実際のプロトコルネットワークコールとともに、２ＰＣトランザクションのための性能コストの追加をもたらす可能性がある。これは、高度に利用可能な安定したストレージのために必要な共有ファイルシステムまたはデータベースストレージに起因するかなりのアセット容量コストと、さらには、このストレージの管理に起因する管理コストとを伴う可能性もある。これらのコストは、（同期的な）複製および管理が必要となるような、サイト全体に渡って障害を回復させる場合には高騰する一方である。このようなシステムにおいては、主要なサイト付近に常駐するデータベースは、二次的なアクティブサイト上のアプリケーションサーバからアクセスされ、このデータベースは、さらには、二次的なサイト／待機中のサイトに同期的にシンクロされなければならない。この極めて一般的な場合には、１回のトランザクション毎に少なくとも２つのサイトの両方に安定して記憶させるために距離および部門によって意図的に分離されているこれら少なくとも２つのサイト間で通信を行なうことがしばしば必要となる。
【００７２】
たとえば、ＸＡ２相ロギングアルゴリズムを利用する典型的には２ＰＣのトランザクションは以下のステップを必要とし得る。当該アプリケーションは、トランザクションにおいて複数のＸＡリソースを用いることができ、トランザクションのためのコミットを発行する。次いで、トランザクションマネージャは、すべてのＸＡリソースパーティシパント（たとえばリソースマネージャ）上で準備（たとえばＸＡＲｅｓｏｕｒｃｅ．ｐｒｅｐａｒｅ）を発行することができる。次いで、トランザクションマネージャは、トランザクションログを安定したストレージ（たとえばデータベース）内に持続させることができる。この場合、トランザクションログは、少なくともトランザクションのグローバルトランザクションｉｄおよびフォーマットｉｄを含んでいる。リソースマネージャから準備ＯＫの「承認」票を受取った後、トランザクションマネージャは、すべてのＸＡリソースパーティシパント上でコミット（ＸＡＲｅｓｏｕｒｃｅ．ｃｏｍｍｉｔ）を発行することができる。トランザクションマネージャは、次いで（概して、ゆっくりと、バッチで）トランザクション記録を消去／削除することができる。失敗時には、持続させたトランザクション記録を、すべての関与するリソースマネージャ上でなされたＸＡＲｅｓｏｕｒｃｅ．ｒｅｃｏｖｅｒコールから戻されたインダウト・トランザクションＩＤと一致させ、これに応じて、コミットまたはロールバックによる回復が行なわれる。
【００７３】
一実施形態に従うと、トランザクションマネージャが回復ログを記録して持続させる必要性を軽減することは、余分な通信および持続性オーバーヘッドについての必要性を軽減することにより既存のシステムに勝る著しい改善を提供することを可能にする最適化を行うことでもあり得る。
【００７４】
本発明の一実施形態に従うと、２相コミットコールの厳密な順序付けと、回復の決定リソースとして関与する少なくとも１つのリソースの分類とを必要とする技術を用いることにより、トランザクション回復およびＡＣＩＤプロパティを提供しながらもトランザクションログの必要性を軽減することができる。
【００７５】
一実施形態に従うと、トランザクションマネージャは、１回のトランザクションで複数のリソースを利用することができ、そのトランザクションのためのコミットを発行することができる。複数のリソースのうちの或るリソースは、トランザクションの決定（この明細書中においては、決定リソースおよび決定リソースマネージャとも称される）として指定されるように構成することができる。マルチテナントアプリケーションサーバ環境の場合、パーティションは、１つのトランザクション毎に少なくとも１つのパーティション特有の決定リソースを特定することができる。決定リソースが構成／選択されない場合、トランザクションシステムは１つの決定リソースを指名し、その決定リソースを或る構成において持続させることができる。決定リソースがマルチテナントアプリケーションサーバ環境において構成されない場合、パーティション内のインスタンス化されたリソースグループに関連付けられたアプリケーションなどの或るアプリケーションが、パーティション特有の決定リソースを指名することができ、このパーティションの特有の決定リソースを或る構成において持続させることができる。
【００７６】
一実施形態に従うと、決定リソースとして指定されたリソースを含むリソースのグループ（たとえば組合せ）が最初に用いられる場合、または、リソースの新しい組合せが２相トランザクションにおいて最初に用いられる場合、リソースの組合せ（すなわち、リソースマネージャの組合せ）を、トランザクション処理サブシステムによって自動的に取込んで構成状態で持続させることができる。この構成の持続性は、このようなトランザクションのために発行された最初の準備の直前に発生する。この構成変更が失敗した場合、トランザクションをロールバックすることができる。必要でなければ、これにより、回復中にＸＡＲｅｓｏｕｒｃｅ．ｒｅｃｏｖｅｒコールを必要とするリソースのセットを減らすように、さらに最適化を行なうことができる。
【００７７】
一実施形態に従うと、リソースが決定リソースとして指定され、厳密な順序付けが実施されているトランザクション中には、トランザクションマネージャはいずれのトランザクションロギングも行なわない。トランザクションマネージャは、すべてのリソースパーティシパントについて準備（ＸＡＲｅｓｏｕｒｃｅ．ｐｒｅｐａｒｅ）を発行し、「決定」リソースを最後に準備する。決定リソース以外のリソースについての準備コールが失敗した場合、決定は準備されることなく、トランザクションがロールバックされ得る。決定リソースの準備中に失敗した場合、すべての非決定リソースをロールバックすることができ、その後、引き続き、決定リソースをロールバックすることができる。
【００７８】
一実施形態に従うと、トランザクションマネージャは、準備に成功したことを決定リソースが示した場合にだけ、トランザクションにおいてリソースについてのコミットを発行することができる。次いで、トランザクションマネージャはコミット（ＸＡＲｅｓｏｕｒｃｅ．ｃｏｍｍｉｔ）を発行することができる。トランザクションマネージャは、すべてのＸＡリソースパーティシパントについてのＸＡＲｅｓｏｕｒｃｅ．ｃｏｍｍｉｔを発行し、決定リソースを最後にコミットする。準備コールと同様に、決定リソースは、すべての非決定リソースがコミットに成功するまでコミットを行なわないだろう。放棄タイマが終了するまでは、グローバルリトライコミットを発行することができる。
【００７９】
一実施形態に従うと、失敗時には、構成におけるすべての非決定リソースに対してＸＡＲｅｓｏｕｒｃｅ．ｒｅｃｏｖｅｒスキャンを行なうことができ、インダウト・トランザクションＩＤを、決定リソースのＸＡＲｅｓｏｕｒｃｅ．ｒｅｃｏｖｅｒｙから戻されたインダウト・トランザクションＩＤと一致させる。決定リソースのリストに一致（たとえば、既存のトランザクションＩＤ）がある場合、コミットによる回復を発行することができる。代替的には、一致が見いだされなければ、ロールバックを発行することができる。
【００８０】
上述の技術が、以下の項においてさらにより詳細に説明され得る。
２相コミット（２ＰＣ）コールの厳密な順序付け
本発明の一実施形態に従うと、システムは、２相コミットコールの厳密な順序付けに基づいて、トランザクションを処理する際に中間層トランザクションログ（ＴＬＯＧ）を削除することができる。
【００８１】
図９は、一実施形態に従った、トランザクションミドルウェアマシン環境においてトランザクションを処理するための２相コミット（２ＰＣ）コールの厳密な順序付けをサポートする例を示す。図９に示されるように、グローバルトランザクションなどのトランザクション９１０は、トランザクションマネージャ（ＴＭ）９０１、複数のリソースマネージャ（ＲＭ）９０２〜９０４を含む中間層トランザクションシステム９００においてサポートされ得る。リソースマネージャ（ＲＭ）９０２および９０３はグローバルトランザクション９１０に関与し、リソースマネージャ９０４はグローバルトランザクション９１０には関与しない。一実施形態に従うと、トランザクション９１０は複数のトランザクションマネージャには跨っていない。
【００８２】
一実施形態に従うと、リソースマネージャ９０２は、図９に示されるトランザクションのための決定リソースとして指定することができる。この指定は、たとえば、トランザクションマネージャによって、またはパーティションによって実行することができ、この状況においては、決定リソースは、別のパーティションからはアクセスできないパーティション特有の決定リソースとなるだろう。リソースマネージャ（ＲＭ）９０２の決定リソースとしての指定は、トランザクションマシン環境のための構成において持続させることができる。決定リソースが構成内でのトランザクションでは指定されない場合、トランザクションマネージャ９０１は、データソースを決定リソースとして指名し（ステップ１）、その構成において持続させることができる。加えて、決定リソース９０２はメッセージキューなどの、データベース以外のリソースであってもよい。
【００８３】
さらに、リソースが最初に用いられていようとも、または、リソースの新しい組合せが２相グローバルトランザクション９１０の処理時に最初に用いられていようとも、新しいリソースまたはリソースの新しい組合せは、トランザクションマネージャ９０１によって自動的に構成ファイルなどの構成に取込まれて持続させることができる。この構成持続性は、最初の準備要求が２相トランザクションのために発行される前に起こり得る。この構成変更に失敗した場合、トランザクション９１０をロールバックすることができる。
【００８４】
本発明の一実施形態に従うと、トランザクションマネージャ９０１は、決定リソース（たとえば、リソースマネージャ９０２）が最後に準備されることを確実にすることができる。さらに、すべてのリソースマネージャが準備後に承認の票を戻した場合、トランザクションマネージャはまた、２ＰＣトランザクション９１０のために、すべての関与するリソースマネージャのうち決定リソース９０２が最後にコミットされることを確実にすることもできる。
【００８５】
図９に示されるように、トランザクションマネージャ９０１は、最初にリソースマネージャ（ＲＭ）９０３を準備（ステップ２）してから、決定リソースを準備する（ステップ４）ことができる。関与するリソースマネージャ（ＲＭ）９０２および９０３から承認の票を受取った（ステップ３および５）後、トランザクションマネージャ９０１は、リソースマネージャ（ＲＭ）９０３をコミットし（ステップ６）、次に、決定リソースをコミットする（ステップ８）ことができる。トランザクションマネージャ９０１がリソースマネージャ９０２および９０３の各々から成功指示を受取った（ステップ７および９）後に、トランザクションを完了させることができる。
【００８６】
コミットコールおよび準備コールについての厳密な順序付けを強制することにより、トランザクションマネージャ９０１は、準備相の処理が成功した後にＴＬＯＧを書込むことを含むリソース／チェックポイントのロギングをいずれも断念し得る。システムは、トランザクションの性能を向上させることができる一方で、各々のリソースマネージャからのインダウト・トランザクションのリストを検索し、次に、決定リソースマネージャ（たとえば図９における決定ＲＭ９０２）以外の各々のリソースマネージャ（たとえば図９に示される実施形態におけるＲＭ９０３）からの検索されたインダウト・トランザクションのリストを、決定リソースマネージャからの検索されたインダウト・トランザクションのリストと比較することによって、トランザクションログを用いることなく、インダウト・トランザクションをすべて回復させることによって、中間層トランザクションシステム９００がトランザクション９１０を回復させることを可能にし得る。
【００８７】
インダウト・トランザクションを回復させる場合、決定リソースマネージャ以外の各々のリソースマネージャからの検索されたインダウト・トランザクションのリストを、決定リソースマネージャからの検索されたインダウト・トランザクションのリストと比較することと；決定リソースマネージャ以外の各々のリソースマネージャからの検索されたインダウト・トランザクションのリストに現われているが決定リソースマネージャからの検索されたインダウト・トランザクションのリストには現われていないインダウト・トランザクションをロールバックすること；とを必要とし得る。２ＰＣトランザクションの厳密な順序付けを実現することにより、システムは、各々のリソースマネージャのログを最終的な決定リソースマネージャのログと比較することによって、失敗したトランザクションを回復させることができる。
【００８８】
一実施形態に従うと、決定リソースマネージャは、準備されるべき最後のリソースマネージャであるので、仮に決定リソースマネージャが準備されている場合には、先行するリソースマネージャがすべて準備されていなければならない。決定リソースの準備に成功していれば、トランザクションマネージャは、次いで、他のすべてのリソースマネージャの準備が成功しており、このため、回復中にすべてのリソースマネージャに対するトランザクションを安全にコミットすることができると判断することができる。リソースマネージャのうちの数個しか準備されておらず、（列の最後の）決定リソースマネージャが準備されていなければ、トランザクションマネージャは、準備相が完成しておらず、回復中にトランザクションがロールバックされなければならないと、判断し得る。分析は、関与するリソースマネージャおよび決定リソースマネージャ同士のインダウト（準備されているがコミットされていない）トランザクションを比較することにのみ依拠しており、別個のトランザクションログを用いる必要はない。
【００８９】
ＴＬＯＧを使用しないグローバルトランザクションの回復
図１０は、一実施形態に従った、トランザクションログ（ＴＬＯＧ）を用いずにグローバルトランザクションを回復させる例を示す。図１０に示されるように、グローバルトランザクションなどの２ＰＣトランザクション１０１０は、トランザクションマネージャ（ＴＭ）１００１、複数のリソースマネージャ（ＲＭ）１００２〜１００４を含む中間層トランザクションシステム１０００においてサポートすることができる。
【００９０】
失敗した後などにトランザクション１０１０を回復させる必要がある場合、トランザクションマネージャ１００１は、たとえば、決定リソース１００２に対してＸＡ＿ｒｅｃｏｖｅｒ（）コールを行なう（ステップ１）ことによって回復させようと試みることができる。トランザクションマネージャ１００１は、決定リソース１００２からインダウト・トランザクション（準備されているがコミットされていないトランザクション）のリストを受取る（ステップ２）ことができる。さらに、トランザクションマネージャ１００１は、インダウト・トランザクションのリストを用いて、グローバルトランザクションテーブル（global transaction table：ＧＴＴ）１００６を構築／再建する（ステップ３）ことができる。
【００９１】
一実施形態に従うと、２相コミットトランザクションにおいて決定リソース１００２の準備が成功している場合、インダウト・トランザクションのリストは、トランザクションマネージャ１００１が関与するリソースマネージャ１００２および１００３にコミットするように指示した未処理の中間層トランザクションと同一であり得る。
【００９２】
次いで、トランザクションマネージャ１００１は、たとえば、関与するリソースマネージャ１００３（ステップ９）および関与していないリソースマネージャ１００４（ステップ１０）を含むトランザクション中間層システム１０００内の他のすべてのリソースマネージャに対してＸＡ＿ｒｅｃｏｖｅｒ（）コールを行なうことによって、回復させようと試みることができる。
【００９３】
たとえば、トランザクションマネージャ１００１は、関与するリソースマネージャ１００３からインダウト・トランザクションのリストを受取る（ステップ５）ことができる。トランザクションマネージャ１００１は、リスト中のインダウト・トランザクションをＧＴＴ１００６のテーブルと一致させて回復リストを生成する（ステップ６および７）ことができる。次いで、トランザクションマネージャ１００１は、回復リストに基づいて、関与するリソースマネージャ１００３を回復させる（ステップ８）ことができる。たとえば、トランザクションマネージャ１００１は、ＧＴＴ１００６のテーブルと一致するインダウト・トランザクションをコミットすることができ、さらに、ＧＴＴ１００６のテーブルと一致しないインダウト・トランザクションをロールバックすることができる。
【００９４】
上述の手順は、関与していないリソースであるリソースマネージャ１００４に対して実行することができる。図１０に示されるように、リソースマネージャ１００４に対してＸＡ＿ｒｅｃｏｖｅｒ（）コールを行なった後、トランザクションマネージャ１００１は、ＧＴＴ１００６と一致させることのできるインダウト・トランザクションのリストを受取って（ステップ１１）、回復リストを生成する（ステップ１２）ことができる。次いで、トランザクションマネージャ１００１は、リソースマネージャ１００４についてインダウト・トランザクションをコミット／ロールバックする（ステップ１４および１５）ことができる。
【００９５】
他のすべてのリソースマネージャ１００３および１００４を回復させる（ステップ９および１５）と、トランザクションマネージャ１００１は、決定リソースマネージャに対して、準備されたトランザクションのリストにおけるすべてのトランザクションをコミットする（ステップ１６および１７）ことができる。最後に、トランザクションマネージャ１００１は、ＧＴＴ１００６への入力を削除する（ステップ１８）ことができる。
【００９６】
一実施形態に従うと、インダウト・トランザクションのリストからのトランザクションは、たとえ１つ以上のリソースマネージャがトランザクションの一部でなくても、他のすべてのリソースマネージャ１００３および１００４が回復されるまで、決定リソースマネージャ１００２にコミットすることができない。
【００９７】
一実施形態に従うと、トランザクションマネージャ１００１は、トランザクションに関与するリソース１００２および１００３についての知識を有することができる。関与するリソース１００２および１００３についての追加情報を、準備相における決定リソース１００２に渡してそこで持続させることができる。追加情報がある場合、トランザクションマネージャ１００１は、既知のすべてリソースマネージャ１００２〜１００４が回復するのを待つことなく、決定リソースマネージャ１００２から戻されたインダウト・トランザクションのリストにあるトランザクションをコミットすることができる。トランザクションマネージャ１００１は、トランザクションのすべてのパーティシパント（すなわち決定リソースマネージャ１００２およびリソースマネージャ１００３）が回復されるまで、待機するだけでよいかもしれない。加えて、トランザクション中間層システム１０００が完全にシャットダウンされている間またはそれが再始動されている間、不必要な回復および処理が起動中に回避され得るように、構成を消去するかまたは構成に印付けすることができる。
【００９８】
マルチテナント環境における、ＴＬＯＧを用いないトランザクションの回復
図１１は、一実施形態に従った、マルチテナントアプリケーションサーバ環境においてトランザクションログ（ＴＬＯＧ）を用いずにグローバルトランザクションを回復させる例を示す。
【００９９】
一実施形態に従うと、複数のパーティションは、管理されたサーバ／クラスタ２４２内で実行され得るか、または、ＣＤＢ２４３にアクセスすることができるとともにウェブ層２４４を介してアクセス可能である同様の環境内で実行され得る。これにより、たとえば、ドメインまたはパーティションを（ＣＤＢの）ＰＤＢのうち１つ以上に関連付けることが可能となる。
【０１００】
一実施形態に従うと、複数のパーティションの各々、この例においてはパーティションＡ２５０およびパーティションＢ２６０は、それらパーティションに関連付けられた複数のリソースおよびリソースマネージャを含むように構成することができる。たとえば、パーティションＡは、アプリケーション１１２１とリソースマネージャ１１２２とパーティション構成型決定リソースマネージャＡ１１２３とを含むリソースグループ１１２０を含むように構成することができる。この場合、パーティションは仮想ターゲットＡ２５８を介してアクセス可能である。同様に、パーティションＢ２６０は、アプリケーション１１３１とリソースマネージャ１１３２とパーティション構成型決定リソースマネージャＢ１１３３とを含むリソースグループ１１３０を含むように構成することができる。この場合、パーティションは仮想ターゲットＡ２５８を介してアクセス可能である。管理されたサーバは、ＴＭ１１１０′およびＴＭ１１１０″として図に示されているように、各々のパーティションにインスタンス化することができるトランザクションマネージャ１１１０を付加的に含み得る。
【０１０１】
一実施形態に従うと、図１１に示されるシステムは、上述のとおり、厳密な順序を利用して２相コミットトランザクションを実行することができる。たとえば、インスタンス化されたトランザクションマネージャ１１１０′は、パーティションＡ２５０のコンテキストで実行されるアプリケーションに関連付けられたリソースに準備コールを発行することができる。リソースマネージャ（リソースマネージャ１１２３）は、（たとえば実行時に、または構成ファイルを介して）トランザクションのための決定リソースマネージャとしてパーティションによって指定することができた。この指定は、決定リソースマネージャがパーティション特有の決定リソースマネージャであり、このため、別のパーティションからアクセス可能ではないことを示し得る。リソースマネージャ（ＲＭ）１１２３の決定リソースとしての指定は、トランザクションマシン環境のための構成において持続させることができる。
【０１０２】
本発明の一実施形態に従うと、トランザクションマネージャ１１１０′は、決定リソース（たとえば決定リソースマネージャ１１２３）が最後に準備されることを確実にすることができる。さらに、すべてのリソースマネージャが準備の後に承認の票を戻した場合、トランザクションマネージャはまた、２相コミットトランザクションのために、関与するすべてのリソースマネージャのうち決定リソースマネージャ１１２３が最後にコミットされることを確実にすることもできる。
【０１０３】
一実施形態に従うと、決定リソースマネージャがパーティション特有であるので、パーティション内のトランザクションが失敗した場合、（決定リソースマネージャが別のパーティションにおける決定リソースマネージャと同じであったとしても）システムは、依然として、他のパーティションに関連付けられた他のすべてのトランザクションの実行を可能にすることができる。各々の決定リソースマネージャが特定のパーティションに関連付けられているので、システムは、依然として、同じリソースを用いる２つのパーティションを有することができ、システムは、依然として、一方のパーティションの実行を許可しながらも、他方のパーティションの実行を禁止することができる。すなわち、パーティション特有の決定リソースがあるせいで、１つのパーティションにおいてトランザクションを１回失敗しても、トランザクションを実行している別のパーティションに必ずしも影響を与えるわけではないだろう。
【０１０４】
一実施形態に従うと、パーティションに関連付けられた決定リソースマネージャはパーティション特有であり得る。このため、リソースがパーティション特有であり得るという事実により、パーティションレベルでの決定リソースの構成をサポートすることができる。パーティション特有のリソースがリソース名に連結されたそれらのパーティション名を有し得るので、リソース登録が重複しているかまたは無効になっていることに関する問題は発生しない。このことは、同じリソースグループテンプレートを用いるパーティションにも当てはまり得るものであり、リソース名が固有であり得る場合には、これに応じて決定の指定もパーティションにとって固有のままとなる。たとえば、パーティションＡは、パーティションＢと同じリソースグループテンプレートを有する可能性があり、リソースｒｅｓｏｕｒｃｅＡを含む。しかしながら、このような状況では、パーティションＡはｒｅｓｏｕｒｃｅＡを決定リソースとして構成する可能性がある。なぜなら、内部においては、たとえば、ｒｅｓｏｕｒｃｅＡ＿ｐａｒｔｉｔｉｏｎＡおよびｒｅｓｏｕｒｃｅＡ＿ｐａｒｔｉｔｉｏｎＢのように、リソース名が異なっているからである。
【０１０５】
図１２は、一実施形態に従った、マルチテナント環境においてトランザクションログ（ＴＬＯＧ）を用いずにトランザクションを回復させる例を示す。図１２に示されるように、一実施形態に従うと、複数のパーティションは、管理されたサーバ／クラスタ２４２内で実行され得るか、または、ＣＤＢ２４３にアクセスを提供することができるとともにウェブ層２４４を介してアクセス可能となる同様の環境内で実行され得る。これにより、たとえば、ドメインまたはパーティションを（ＣＤＢの）ＰＤＢのうち１つ以上に関連付けることが可能となる。
【０１０６】
一実施形態に従うと、複数のパーティションの各々、この例においてはパーティションＡ２５０およびパーティションＢ２６０は各々、そのパーティションに関連付けられた複数のリソースおよびリソースマネージャを含むように構成することができる。管理されたサーバは、図においてＴＭ１２１０′で示されるように、各々のパーティションにインスタンス化することができるトランザクションマネージャ１２１０を付加的に含むことができる。パーティションＡ２５０は、リソースマネージャ（パーティシパント）１２０３およびパーティションＡのための決定リソースマネージャ１２０４を含み得る。
【０１０７】
一実施形態に従うと、２ＰＣトランザクションは、パーティション（たとえばＴＭ１２１０′）においてインスタンス化されるトランザクションマネージャ（ＴＭ）１２１０と、複数のリソースマネージャ、たとえばリソースマネージャ（ＲＭ）１２０３および１２０４とを含むマルチテナント環境においてサポートすることができる。なお、図１２が簡潔さのためにトランザクション回復に関与する２つのリソースマネージャしか図示していないことに留意されたい。関与するものも関与しないものも含めていくつかのリソースマネージャがシステムに含まれ得ることが認識されるべきである。
【０１０８】
失敗した後などのように、トランザクションを回復させる必要がある場合、トランザクションマネージャは、たとえば、決定リソース１２０４に対してＸＡ＿ｒｅｃｏｖｅｒ（）コールを行なう（ステップ１）ことによって、回復させるよう試みることができる。トランザクションマネージャは、決定リソース１２０４からインダウト・トランザクション（準備されているがコミットされていないトランザクション）のリストを受取る（ステップ２）ことができる。さらに、トランザクションマネージャ１００１は、トランザクションテーブルを構築／再建するためにインダウト・トランザクションのリストを用いることができる。
【０１０９】
一実施形態に従うと、２相コミットトランザクションにおいて決定リソース１２０４の準備に成功すると、インダウト・トランザクションのリストは、トランザクションマネージャが関与するリソースマネージャ１２０３にコミットするように指示した未処理の中間層トランザクションと同一になり得る。
【０１１０】
次いで、トランザクションマネージャは、たとえば、関与するリソースマネージャ１２０３を含む他のすべてのリソースマネージャに対してＸＡ＿ｒｅｃｏｖｅｒ（）コールを行なう（ステップ３）ことによって、回復させるように試みることができる。
【０１１１】
たとえば、トランザクションマネージャは、関与するリソースマネージャ１２０３からインダウト・トランザクションのリストを受取る（ステップ４）ことができる。トランザクションマネージャは、リスト中のインダウト・トランザクションをトランザクションテーブルと一致させて、回復リストを生成することができる。次いで、トランザクションマネージャは、回復リストに基づいて、関与するリソースマネージャ１２０３を回復させる（ステップ５）ことができ、リソースマネージャ１２０３は成功を戻す（ステップ６）ことができる。たとえば、トランザクションマネージャは、トランザクションテーブルと一致するインダウト・トランザクションをコミットすることができ、トランザクションテーブルと一致しないインダウト・トランザクションをロールバックすることができる。
【０１１２】
他のすべてのリソースマネージャ１２０３が回復されると、トランザクションマネージャは、決定リソースマネージャに対して、準備されたトランザクションのリスト中のすべてのトランザクションをコミットすることができ、この決定リソースマネージャが成功を戻す（ステップ８）ことができる。
【０１１３】
一実施形態に従うと、インダウト・トランザクションのリストからのトランザクションは、１つ以上のリソースマネージャがトランザクションの一部でなくても、他のすべてのリソースマネージャが回復されるまで、決定リソースマネージャ１２０４にコミットすることができない。
【０１１４】
図１３は、一実施形態に従った、マルチテナントアプリケーションサーバ環境におけるトランザクション回復を示す具体的なフローチャートである。図１３に示されるように、ステップ１３１０において、当該方法は、アプリケーションサーバ環境を含み当該アプリケーションサーバ環境が実行される１つ以上のコンピュータにおいて、アプリケーションサーバ環境内で用いることができる複数のデプロイ可能なリソースと、ドメイン内においてデプロイ可能なリソースのグループ分けを定義する１つ以上のリソースグループテンプレートと、１つ以上のパーティションとを提供することができる。各々のパーティションは、ドメインの管理および実行時間下位区分を提供し、テナントに関連付けられ得る。
【０１１５】
ステップ１３２０において、当該方法は、上述のとおり、アプリケーションサーバ環境内においてトランザクションマネージャを動作させることができる。
【０１１６】
ステップ１３３０において、当該方法は、決定リソースマネージャを１つ以上のパーティションのうちの１つに関連付けることができる。さらに、決定リソースマネージャはトランザクションにおいて用いることができる。
【０１１７】
ステップ１３４０において、当該方法は複数のリソースマネージャを提供することができる。複数のリソースマネージャはトランザクションにおいても用いられる。
【０１１８】
ステップ１３５０において、トランザクションマネージャは、複数のリソースマネージャに対する準備アクションの成功についての承認を受取った後にだけ準備メッセージを決定リソースマネージャに送信することによって、かつ、複数のリソースマネージャに対するコミットアクションの成功についての承認を受取った後にだけコミットメッセージを決定リソースマネージャに送信することによって、トランザクションを処理することができる。
【０１１９】
失敗時には、ステップ１３６０において、当該方法は、複数のリソースマネージャおよび決定リソースマネージャの各々からのインダウト・トランザクションのリストを検索して、次いで、トランザクションログを用いずにすべてのインダウト・トランザクションを回復させることができる。
【０１２０】
この発明は、この開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取り可能記憶媒体を含む、１つ以上の従来の汎用または特化型デジタルコンピュータ、コンピューティング装置、マシン、またはマイクロプロセッサを使用して都合よく実現され得る。ソフトウェア技術の当業者には明らかであるように、この開示の教示に基づいて、適切なソフトウェアコーディングが、熟練したプログラマによって容易に準備され得る。
【０１２１】
実施形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された非一時的な記録媒体または（１つもしくは複数の）コンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。この記録媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。
【０１２２】
本発明のこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するかまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。変更例および変形例は、開示された特徴の関連する如何なる組合せをも含む。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって他の当業者がさまざまな実施の形態および意図される特定の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は添付の特許請求の範囲およびそれらの同等例によって規定されるものと意図されている。
【図１】
0006564026.tif 000002
【図２】
0006564026.tif 000003
【図３】
0006564026.tif 000004
【図４】
0006564026.tif 000005
【図５】
0006564026.tif 000006
【図６】
0006564026.tif 000007
【図７】
0006564026.tif 000008
【図８】
0006564026.tif 000009
【図９】
0006564026.tif 000010
【図１０】
0006564026.tif 000011
【図１１】
0006564026.tif 000012
【図１２】
0006564026.tif 000013
【図１３】
0006564026.tif 000014