JP3846852B2 - 分散コンピューティング環境の処理グループを管理する方法、システム、およびプログラム製品 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、全般的には分散システムに関し、具体的には、分散同期トランザクション・システムの管理に関する。
【０００２】
【従来の技術】
関連出願の相互参照
この特許出願には、本願と同一の譲受人に譲渡される、本願と同一の日付に出願された米国特許出願番号第０９／５８３６７７号明細書の主題に関する主題が含まれる。上記米国特許出願は、参照によってその全体を本明細書に組み込まれる。
【０００３】
分散システムは、高スループットの作業もしくはシステムの連続的またはほぼ連続的な可用性が要求される情況を含むさまざまな情況で使用される、高可用性のスケーラブルなシステムである。
【０００４】
分散システムの一種が、分散同期トランザクション・システムであり、これは、分散クライアントの代わりに分散同期トランザクションを実行するシステムである。分散同期トランザクションとは、クライアント・アプリケーションによって要求された時に実質的に即座に開始され、実質的にトランザクションの完了の直後にトランザクションの成功についてクライアント・アプリケーションに通知されるトランザクションである。
【０００５】
現在、分散同期トランザクションを管理する機能があるが、これらの機能は、複雑になる傾向がある。したがって、分散システムでの同期トランザクションの管理を容易にする機能の必要がまだ存在する。
【０００６】
【発明が解決しようとする課題】
本発明の目的は、複製された分散トランザクションの管理および使用を容易にすることである。
【０００７】
【課題を解決するための手段】
分散コンピューティング環境の処理グループを管理する方法の提供を介して、従来技術の短所が克服され、追加の長所がもたらされる。この方法には、たとえば、処理グループの見込みのあるメンバの状態の少なくとも一部を、処理グループのグループ状態の少なくとも一部と比較するステップと、比較によって差が示される場合に、見込みのあるメンバの状態の少なくとも一部を更新するステップと、見込みのあるメンバを処理グループに参加（join）させるステップとが含まれる。
【０００８】
上で要約した方法に対応するシステムおよびコンピュータ・プログラム製品も、本明細書で説明し、請求する。
【０００９】
追加の特徴および長所は、本発明の技法を介して実現される。本発明の他の実施形態および態様を、本明細書で詳細に説明するが、これらは、請求される発明の一部とみなされる。
【００１０】
【発明の実施の形態】
本発明の諸態様に従って、分散同期トランザクションを実行し、管理する。分散同期トランザクションは、分散コンピューティング環境の分散クライアント・アプリケーションによって使用される。
【００１１】
本発明の諸態様が組み込まれ、使用される分散コンピューティング環境の一例を、図１に示し、本明細書で説明する。分散コンピューティング環境１００には、たとえば、複数のＬＡＮゲート１０４を介して互いに結合される複数のフレーム１０２が含まれる。フレーム１０２およびＬＡＮゲート１０４を、下で詳細に説明する。
【００１２】
一例では、分散コンピューティング環境１００に、８つのフレームが含まれ、各フレームに、複数の処理ノード１０６が含まれる。一例では、各フレームに、１６個の処理ノードが含まれる（各処理ノードが１つまたは複数のプロセッサを有する）。各処理ノードは、たとえば、ＵＮＩＸベースのオペレーティング・システムであるＡＩＸを実行するＲＩＳＣ／６０００コンピュータである。１フレーム内の各処理ノードは、たとえば内部ＬＡＮ接続を介して、フレームの他の処理ノードに結合される。さらに、各フレームは、ＬＡＮゲート１０４を介して他のフレームに結合される。
【００１３】
例として、各ＬＡＮゲート１０４に、ＲＩＳＣ／６０００コンピュータ、ＬＡＮへのコンピュータ・ネットワーク接続、またはネットワーク・ルータのいずれかが含まれる。しかし、これらは例にすぎない。他の種類のＬＡＮゲートがあることと、他の機構を使用してフレームを互いに結合することもできることが、当業者には明白であろう。
【００１４】
図１の分散コンピューティング環境は、１つの例にすぎない。８つよりも多数または少数のフレームもしくはフレームあたり１６個より多数または少数のノードを有することが可能である。さらに、処理ノードが、ＡＩＸを実行するＲＩＳＣ／６０００コンピュータである必要はない。処理ノードの一部またはすべてに、異なる種類のコンピュータまたは異なるオペレーティング・システムを含めることができる。さらに、環境のノードまたはオペレーティング・システムの１つまたは複数が環境の他のノードまたはオペレーティング・システムと別個である異機種環境に、本発明を含め、使用することができる。そのような異機種環境のノードは、本明細書で説明するように、それらが共同作業し、互いにリソースを共用するという点で、相互運用する。
【００１５】
分散コンピューティング環境のノードに関するさらなる詳細を、図２に関して説明する。１つの例では、分散クライアント・アプリケーション２００が、複数のノード２０２上で稼動する。具体的に言うと、クライアント・アプリケーションのインスタンスが、複数のノードのそれぞれで実質的に同時に稼動し、この複数のノードには、この特定の例では３つのノードが含まれる（当業者は、クライアント・アプリケーションが、１つだけのノードを含む、環境の任意の数のノードで稼動できることを諒解するであろう）。
【００１６】
一実施形態では、クライアント・アプリケーション・インスタンスが、分散同期トランザクション・システム（ＤＳＴＳ）に結合され、これによって、アプリケーション・インスタンスが、本発明の態様に従って、トランザクションの同期複製に参加できるようになる。分散同期トランザクション・システムを使用することによって、クライアント・アプリケーション・インスタンスが、そのアプリケーションの他のインスタンスの直接の知識を有しない場合であっても、クライアント・インスタンスが、トランザクションの同期複製に参加することができる。分散同期トランザクション・システムには、１つまたは複数のノードで稼動する１つまたは複数のＤＳＴＳインスタンス（たとえば、コンピュータ・プログラム）２０４が含まれる。一例では、ＤＳＴＳインスタンスが、分散トランザクションへの参加に関心を持つクライアント・アプリケーション・インスタンスを有するノードのそれぞれで実行される。各ＤＳＴＳインスタンスは、１つまたは複数のクライアント・アプリケーションの１つまたは複数のインスタンスに結合される。
【００１７】
ＤＳＴＳインスタンスが、ノードのメモリにロードされ、実行される時に、そのＤＳＴＳインスタンスは、対応する１つまたは複数のクライアント・アプリケーション・プロセスにサービスするサーバ・プロセスとして認められる。クライアント・アプリケーションの代わりに分散同期トランザクションを実行するのは、ＤＳＴＳシステムである。トランザクションは、クライアントによって要求される時に、ＤＳＴＳサーバによって実質的に即座に開始される。さらに、クライアントは、トランザクションの完了時に、トランザクションの結果（たとえば、成功、失敗）について実質的に即座に通知される。
【００１８】
分散同期トランザクションの実行に参加する１つまたは複数のクライアント・アプリケーション・インスタンスの集合を、クライアント・アプリケーション・インスタンスの複製されたグループと呼称する。このグループは、分散システムの他の形態のグループとは異なる。というのは、複製されたグループのメンバが、お互いの直接の知識を有しないからである。そうではなくて、このグループは、クライアント・アプリケーション・インスタンスが、１つまたは複数の他のクライアント・アプリケーション・インスタンスに複製される更新動作の流れを方向転換する時に、暗黙のうちに形成される。
【００１９】
具体的に言うと、クライアント・アプリケーションは、動作の流れを方向転換し、これによって、その永続的（保管される）状態または実行時（保管されない）状態が変更される。これらの更新動作は、書込動作として分類される。クライアント・アプリケーションの状態を変更しない他のトランザクションを、照会または読取トランザクションと呼ぶことができる。本発明の一態様によれば、クライアント・アプリケーションは、分散同期トランザクションとして書込動作を実行し、これによって、クライアント・アプリケーションの各コピーに、一貫性のある状態または同一の状態が与えられる。そのような機能によって、アプリケーションのどのコピーでも、他の複製のいずれかに照会をリダイレクトする必要なしに、その状態に対する照会（読取動作）に応答することが可能になる。言い換えると、クライアント・アプリケーションは、ＤＳＴＳサーバを使用せずにローカルに読取動作をサービスすることができ（図３を参照されたい）、書込動作は、クライアント・アプリケーションの他のインスタンスに複製され、したがって、下でさらに説明するように、ＤＳＴＳが使用される（図４を参照されたい）。このアーキテクチャは、読取集中であり、低い割合の書込動作を示すシステムに最適であるが、これに制限はされない。
【００２０】
更新動作の流れは、クライアント・アプリケーションによって、たとえばクライアント・アプリケーションによって使用されるＤＳＴＳプロトコルを介して、方向転換される。本発明の一態様によるこのプロトコルの特徴の１つに、１つまたは複数の処理グループへのメンバシップが含まれる。処理グループ５００（図５）には、１つまたは複数のメンバ５０２が含まれる。各メンバは、この例ではＤＳＴＳサーバである。したがって、複製されたグループのクライアント・アプリケーション・インスタンスごとに、対応するＤＳＴＳサーバが所与の処理グループ（グループとも称する）にある。たとえば、複製されたグループに、クライアント・アプリケーション・インスタンスＡおよびＢが含まれる場合には、処理グループにＤＳＴＳサーバＡおよびＢが含まれ、これらが、それぞれアプリケーション・インスタンスＡおよびＢに結合される。これによって、処理グループが、複製されたグループのクライアント・アプリケーションに関するトランザクションを複製できるようになり、複製をこれらのクライアント・アプリケーションにとって透過的にすることができる。
【００２１】
処理グループの各メンバは、グループの状態データの一貫性のあるビューを保証される。このデータの一貫性が保たれるのは、このデータが、明確に定義されたグループ・プロトコルのみによって更新されるからである。プロトコルの例には、グループの活動化およびグループへの参加を含むグループに対する許可と、グループからの排除が含まれ、このそれぞれを、下で詳細に説明する。さらに、処理グループの管理に関する詳細が、参照によってその全体を本明細書に組み込まれる米国特許第５７４８９５８号明細書に記載されている。
【００２２】
グループに対する許可に関連する論理の一実施形態を、図６ないし９に関して説明する。具体的に言うと、図６は、グループの活動化に用いられる構成要素の例を示す図であり、図７ないし９は、論理の実施形態を示す図である。最初のグループ活動化の場合には、処理グループにメンバが存在しない。グループは、前に定義されたものと仮定されるが、グループのコピー（すなわちＤＳＴＳ）のどれもが、現在は実行されていない。ＤＳＴＳコピーは、クライアント・アプリケーションによって接続される時に実行を開始する。
【００２３】
一例では、ステップ６００（図６、図７）で、クライアント・アプリケーション６０２が、初期化メッセージを介してＤＳＴＳサーバ６０４に接続する。初期化メッセージは、ＤＳＴＳシステムに接続するために、クライアント・アプリケーション６０２からＤＳＴＳサーバ６０４に送られる。具体的に言うと、一例では、クライアント・アプリケーション・インスタンスが、そのクライアント・アプリケーション・インスタンスと同一のノードにあるＤＳＴＳサーバに接続する。初期化メッセージの一例を、図１０に関して説明する。
【００２４】
初期化メッセージ７００には、たとえば、要求される動作の種類（たとえば初期化）を示す動作コード７０２と、要求を発行したクライアント・アプリケーションの名前７０４が含まれる。ＤＳＴＳシステムは、アプリケーション名を使用して、同一の名前を有するアプリケーションの他のインスタンス（すなわち、複製されたグループのメンバ）にトランザクションを伝搬させる。
【００２５】
図６および図７に戻ると、このメッセージに応答して、ステップ６０６（図７）で、ＤＳＴＳサーバが、グループ（クライアント・アプリケーションの名前７０４（図１０）によって指定される）への参加を提案する。グループへの参加を提案する際に、ＤＳＴＳサーバは、永続的ストレージ６０８（図６）からグループ状態を読み取る。グループ状態６１０には、たとえば、グループ・シーケンス番号および活動化状況が含まれる。問合せ６１２（図７）で、グループ状態がアクティブの場合には、ステップ６１４で、下で説明するように、参加するコピーが、参加プロトコルを実行する。そうでない場合には、状態が非アクティブであり、ステップ６１６で、コピーが、下で定義される参加プロトコルを実行せずに直接にグループに参加することができる。
【００２６】
ＤＳＴＳサーバがグループに参加する時に、ステップ６１８で、コピーが、グループのシーケンス番号をそれ自体のシーケンス番号と比較する。グループのシーケンス番号が、それ自体のシーケンス番号より小さい場合には、ステップ６２０で、コピーが、グループのシーケンス番号を更新する。その後、またはグループのシーケンス番号がコピーのシーケンス番号以上である場合に、問合せ６２２で、メンバの定数（この例では）に達したかどうかに関する判定を行う。
【００２７】
定数に達していない場合には、処理は、別のメンバについて、少なくとも定数に達するまで、ステップ６００で継続される。定数のメンバがグループに参加する時に、処理グループのメンバであるコピーが、定数に達したことの知識を有する。この時点で、ステップ６２４で、グループのシーケンス番号に、メンバの最も高いインカーネーション（incarnation）をセットする。この点に達した時にグループのシーケンス番号と一致するシーケンス番号を有するメンバが、ステップ６２６で、グループ活動化メッセージを送ることによって活動化プロトコルを開始する。グループ活動化メッセージによって、複数フェーズ・プロトコルが開始される。
【００２８】
活動化の第１フェーズでは、ステップ６２８（図８）で、グループのメンバが、グループ活動化メッセージを受け取り、このグループ活動化メッセージには、そのメッセージを送ったメンバのノード・アドレスが含まれる。その後、ステップ６３０で、現在のグループのシーケンス番号より小さいシーケンス番号を有する現在のグループ・メンバが、活動化メッセージの送信側に、グループのシーケンス番号に関連するグループ状態のコピーを要求する。これらのメンバは、ステップ６３２で、新しいグループ状態を使用してそれ自体を再初期化し、その後、ステップ６３４で、グループ活動化の第２フェーズに継続することを提案する。この時点で初期化に失敗したメンバは、プロトコルの打切りに投票する。
【００２９】
グループのシーケンス番号と一致するシーケンス番号を有するメンバも、第２フェーズに進むことを提案する。すべての現在のメンバが第２フェーズに進むことを提案する（どれもが打切りを提案しない）場合に、第２フェーズが開始される。
【００３０】
グループ活動化の第１フェーズが完了する際に、ステップ６３６（図９）で、処理グループの現在のメンバが、メンバの過半数が維持されたことを検証する。さらに、各メンバは、現在、同一の一貫性のあるシーケンス番号および分散状態のコピーを有する。
【００３１】
ステップ６３８で、メンバが、たとえば１を足すことによって、グループ・シーケンス番号を変更する。その後、ステップ６４０で、メンバが、新しいシーケンス番号をグループ状態に保管し、プロトコルの終了を提案する。この段階で障害を発生したメンバは、プロトコルの打切りを提案する。
【００３２】
プロトコル完了では、問合せ６４２で、現在のメンバのどれもが打ち切らない場合に、グループが、グループの現在のメンバが同一の一貫性のあるグループ状態およびシーケンス番号を有することと、新しいシーケンス番号がグループの数の過半数によって保管されていることの保証を得る。その後、ステップ６４４で、グループ状態をアクティブに変更する。
【００３３】
メンバがアクティブ・グループに参加するたびに、そのメンバが、複数フェーズ・グループ許可プロトコルを開始するが、その一実施形態を、図１１ないし１３に関して説明する。具体的に言うと、図１１は、参加処理の構成要素を示す図であり、図１２および図１３は、その論理の一実施形態を示す図である。プロトコルの第１フェーズでは、ステップ９００（図１２）で、参加するメンバ（図１１の８００）が、参加提案メッセージを、永続的ストレージから取り出したシーケンス番号、または、シーケンス番号を取り出すことができなかった場合には負の無限大と共に送る。例として、シーケンス番号ならびに他のグループ状態は、状態が保管されたディスクが壊れているか他の理由で使用可能でない時、または、これが実際に所与のプロセッサの下でそのメンバ・コピーが初めて実行される時である時に使用可能でない可能性がある。
【００３４】
参加提案メッセージの受取に応答して、ステップ９０２で、グループの他のメンバ（図１１の８０２）が、分散データに対する更新を行うことを止める。一実施形態では、更新を止めるために、グループの各メンバが、それに対応するクライアント・アプリケーション・インスタンスに静止メッセージを送る。静止メッセージの一例を、図１４に関して説明する。
【００３５】
静止メッセージ１０００には、たとえば、これが静止動作であることを指定する動作コード１００２が含まれる。静止メッセージによって、アプリケーションの大域的状態が安定するように、クライアント・アプリケーションが、更新要求（たとえば下で説明する複製要求メッセージ）を送るのを止めるように要求される。
【００３６】
その後、ステップ９０４で、アプリケーションの各コピーが、そのアプリケーションの現在の状態のスナップショットを作り、この状態を永続的ストレージに保管するように要求される。この要求は、アーカイブ・メッセージをアプリケーションのコピーに送ることによって実行される。アーカイブ・メッセージの一例を、図１５に関して説明する。一例では、アーカイブ・メッセージ１１００に、これがアーカイブ要求であることを示す動作コード１１０２が含まれる。
【００３７】
メンバのすべてが、参加するメンバを含めて、参加提案のコピーを受け取る。問合せ９０６で、参加するメンバが、提案のシーケンス番号を、現在のグループ・メンバシップまたは他のメンバがグループの一部でない場合には負の無限大と比較する。参加するメンバのシーケンス番号が、グループのシーケンス番号より小さい場合には、問合せ９０８で、グループがアクティブであるかどうかに関する判定を行う。一例では、この判定は、グループ状態（図１１の８０４）の活動化状況を検査することによって行われる。
【００３８】
グループがまだアクティブである場合には、ステップ９１０で、参加するメンバが、より大きいシーケンス番号を有するメンバの１つに連絡し、そのメンバのノードから分散システムの永続的状態を取り出し、適当な記憶域に移動する。具体的に言うと、一例では、ＤＳＴＳシステムが、アーカイブ解除（dearchive）メッセージを使用して、ストレージからスナップショットを取り出し、アプリケーションの古くなったコピーに最新の更新されたスナップショットをロードするように要求する。
【００３９】
アーカイブ解除メッセージの一例を、図１６に関して説明する。アーカイブ解除メッセージ１２００には、これがアーカイブ解除メッセージであることを示す動作コード１２０２と、データが取り出される場所を示すアーカイブ位置フィールド１２０４が含まれる。
【００４０】
アーカイブ解除メッセージの発行のほかに、ＤＳＴＳサーバは、ハンドル列挙要求メッセージ（enumerate handles message）も発行し、このメッセージは、たとえば、実質的にクライアント・アプリケーションが永続的状態のスナップショットをロードした直後に実行される。ハンドル列挙要求メッセージ１３００（図１７）には、たとえば、これがハンドル列挙要求メッセージであることを示す動作コード１３０２が含まれる。このメッセージを受け取った後に、クライアント・アプリケーションは、ハンドル列挙応答メッセージ（handle enumeration message）をＤＳＴＳシステムに返し、ＤＳＴＳシステムは、アプリケーションが作成したリソースの名前をリソース・ハンドルにマッピングする。
【００４１】
ハンドル列挙応答メッセージの一例を、図１８に示す。これには、たとえば、これがハンドル列挙応答メッセージであることを示す動作コード１４０２と、リソース名およびハンドルの１つまたは複数の対を含むリソース・ハンドル・マップ１４０４が含まれる。これらのハンドルは、たとえば、下で説明するように、クライアント・アプリケーションの状態の変更についてサード・パーティ・アプリケーションに通知し、同一のリソースに対する同時更新要求を直列化するのに使用される一意の名前である。
【００４２】
スナップショットをロードすることによってそれ自体を成功裡に再初期化した後に、新しいコピーは、ＤＳＴＳシステムへの参加を許可され、再開メッセージがすべてのコピーに送られ、ＤＳＴＳシステムが通常動作を再開することができるようになる。さらに、ステップ９１２で、新しいコピーが、参加の第２フェーズの開始を提案する。
【００４３】
問合せ９８０に戻って、グループが非アクティブになる場合には、参加するメンバが、ステップ９１６でそのシーケンス番号が古いことに注目し、ステップ９１８で、次のアクションを行うために活動化メッセージを待つ。参加するメンバは、参加の第２フェーズに加わらない。
【００４４】
問合せ９０６に戻って、参加するメンバのシーケンス番号がグループのシーケンス番号と等しい場合には、グループが非アクティブである。この事実は、グループ活動化プロトコルによって（たとえばこの例では定数ポリシ）および定数実施の特性によって与えられる。したがって、ステップ９１８で、参加するメンバが、活動化メッセージが効力を生じるのを待ち、参加の第２フェーズはない。同様に、問合せ９０６で、参加するメンバのシーケンス番号の方が大きい場合には、やはりそのグループが非アクティブであることになり、したがって、ステップ９１８で、参加するメンバが活動化メッセージを待つ。
【００４５】
参加するメンバが、第２フェーズに進むことを提案した場合、そのメンバは、新しいシーケンス番号および分散状態を有する。したがって、メンバ（参加するメンバを含む）が、ステップ９２２（図１３）で、たとえば１を足すことによって、グループのシーケンス番号を変更する。メンバは、その後、ステップ９２４で、新しいシーケンス番号およびグループ状態を保管し、さらに、ステップ９２６で、プロトコルを終了することを提案する。この段階で障害を発生したメンバは、プロトコルの打切りを提案する。打ち切るメンバがない場合には、このグループは、グループの現在のメンバが同一の一貫性のあるグループ状態およびシーケンス番号を有することと、新しいシーケンス番号がグループのメンバの過半数について保管されたことを保証される。
【００４６】
上記のほかに、メンバを、グループから排除することができる。具体的に言うと、ノードが障害を発生するたびに、またはノード上で実行されるＤＳＴＳコピーが障害を発生するたびに、ステップ１５００（図１９）で、グループの残存メンバに、メンバが障害を発生したことが通知される。問合せ１５０２で、グループが非アクティブである場合には、ステップ１５０４に進み、処置を講じない。さらに、問合せ１５０６で、グループがアクティブであるが、メンバの過半数を有しない場合には、処置を講じない。
【００４７】
しかし、グループがアクティブであり、問合せ１５０６で過半数が保たれている場合には、ステップ１５０７で、各メンバが分散状態に対するそれ以上の更新を停止する。さらに、ステップ１５０８で、各メンバが、たとえば１を足すことによって、グループ・シーケンス番号を変更し、ステップ１５１０で、新しいシーケンス番号およびグループ状態を保管する。その後、ステップ１５１２で、メンバがプロトコルの終了を提案する。この段階で障害を発生したメンバは、プロトコルの打切りを提案する。
【００４８】
打ち切るメンバがない場合には、グループは、グループの現在のメンバが同一の一貫性のあるグループ状態およびシーケンス番号を有することと、新しいシーケンス番号がグループのメンバの過半数によって保管されたことを保証される。
【００４９】
ＤＳＴＳシステムは、ＤＳＴＳサーバの定数（過半数）が使用可能である時または失われた時に、たとえば定数通知メッセージを使用することによって、クライアント・アプリケーション・インスタンスに通知する。一例では、定数通知メッセージ１６００（図２０）に、動作コード１６０２と、グループが定数を有するかどうかを示す定数情報１６０４が含まれる。
【００５０】
本明細書で説明するように、処理グループのメンバは、分散同期トランザクションを複製するのに使用され、この分散同期トランザクションは、グループのメンバに結合されたクライアント・アプリケーション・インスタンスによって開始される。クライアント・インスタンスとグループのサーバ・メンバの間の通信を容易にするために、さまざまなメッセージが使用される。一例では、これらのメッセージに（上で説明したメッセージのほかに）、複製要求メッセージ、複製コールバック・メッセージ、複製コールバック結果メッセージ、複製完了メッセージ、およびシャットダウン・メッセージが含まれ、これらのそれぞれを下で説明する。
【００５１】
複製要求メッセージの一例を、図２１に関して説明する。複製要求メッセージ１７００は、分散トランザクションを開始するメッセージである。一例では、これに、これが複製要求メッセージであることを示す動作コード１７０２、リソースが作成される場合には作成される新しいリソース名のリスト１７０４、クライアント・アプリケーションの０個以上の排他リソースを指定する排他アクセス・セット１７０６、クライアント・アプリケーションの０個以上の共用リソースを指定する共用アクセス・セット１７０８、複製中に守らなければならない規則（たとえば、ある作業について進行するのに必要なグループの定数）を与える複製ポリシ１７１０、複製され実行されるトランザクションを指定する要求１７１２（たとえば作成または更新の要求）、および要求のサイズを示す要求サイズ１７１４が含まれる。
【００５２】
複製要求メッセージは、単一のクライアント・アプリケーション・インスタンス（イニシエータとも称する）によって、ＤＳＴＳシステムのサーバ・プロセスに送られる。メッセージの受取の際（またはその後）に、サーバ・プロセスは、このメッセージを、分散コンピューティング環境の１つまたは複数の他のサーバ・プロセスに配布する。具体的に言うと、一例では、メッセージは、処理グループの他の現在のサーバ・プロセスのすべてに送られる。
【００５３】
これに応答して、サーバ・プロセスのそれぞれが、クライアント・アプリケーションの対応するインスタンス（ピア）に複製コールバック・メッセージを送る。複製コールバック・メッセエージの一例を、図２２に関して説明する。複製コールバック・メッセージ１８００には、たとえば、これが複製コールバック・メッセージであることを示す動作コード１８０２、新しいリソースが作成される場合に、新しいリソース名の配列１８０４、クライアント・アプリケーションの０個以上の排他リソースを指定する排他アクセス・セット１８０６、クライアント・アプリケーションの０個以上の共用リソースを指定する共用アクセス・セット１８０８、複製され実行されるトランザクションを指定する要求１８１０、および要求のサイズを示す要求サイズ１８１２が含まれる。
【００５４】
上記のほかに、複製コールバック結果メッセージが、要求されたトランザクションが処理された後に、クライアント・アプリケーションからＤＳＴＳサーバに送られる。複製コールバック結果メッセージの一例を、図２３に関して説明する。複製コールバック結果メッセージ１９００には、これが複製コールバック結果メッセージであることを示す動作コード１９０２、新しいリソースがある場合に、そのハンドル（たとえば一意の識別子）と共に新しいリソース名の配列１９０４、変更されたリソースのハンドルを含む変更済みリソース・セット１９０６、および削除されたリソースのハンドルを含む削除済みリソース・セット１９０８が含まれる。
【００５５】
サーバ・プロセスは、複製コールバック結果を受け取った後に、複製完了メッセージ２０００（図２４）を転送することによって、トランザクションが完了したことを検証する。一例では、複製完了メッセージ２０００に、これが複製完了メッセージであることを示す動作コード２００２およびトランザクションが成功裡に実行されたかどうかを指定する動作状況２００４が含まれる。
【００５６】
システムがシャット・ダウンされる場合には、ＤＳＴＳシステムは、システムがシャット・ダウンされようとしていることをクライアント・アプリケーションのコピーに通知するシャットダウン・メッセージを使用する。一例では、シャットダウン・メッセージ２１００（図２５）に、シャットダウンが実行されることを示す動作コード２１０２が含まれる。このメッセージは、クライアント・アプリケーションのコピーが安全シャットダウン・プロシージャを実行できるようにし、保留中のすべてのトランザクションを終了させるという目的を有する。クライアント・アプリケーションは、シャットダウン・プロセスを終了する時に、ＤＳＴＳシステムに、シャットダウン肯定応答を用いて応答する。
【００５７】
上で説明した複製メッセージの使用を、図２６および図２７に関して下でさらに説明する。図２６を参照すると、複製要求メッセージ２２００が、単一のクライアント・アプリケーション・インスタンス２２０２によって、ＤＳＴＳシステムのサーバ・プロセス２２０４に送られる。サーバは、複製要求メッセージを処理グループの他のサーバ２２０８ａおよび２２０８ｂに配布する２２０６。サーバのそれぞれは、この例では、複製コールバック・メッセージ２２１０を、それに対応するクライアント・アプリケーションのインスタンスに送る。たとえば、サーバ・プロセス２２０４は、複製コールバック・メッセージ２２１０を、ノード１に配置されたクライアント・アプリケーション・インスタンスに送る。同様に、サーバ２２０８ａは、複製コールバック・メッセージをノード２に配置されたクライアント・アプリケーション・インスタンスに送り、以下同様である。
【００５８】
その後、クライアント・アプリケーション・インスタンス２２０２（図２７）の各コピーが、要求されたトランザクションを処理し、コールバックをコミットし、複製コールバック結果メッセージ２２１２をそれに対応するサーバに送る。その後、コールバック結果メッセージのコピーが、非イニシエータ・クライアントのサーバ（たとえばサーバ２２０８ａ、サーバ２２０８ｂ）から要求イニシエータのサーバ（たとえば２２０８）に転送される。
【００５９】
その後、要求イニシエータのＤＳＴＳサーバ（たとえばサーバ２２０８）が、トランザクションがアプリケーションのコピーの過半数によって完了されたことを検証する。過半数は、２によるサーバの数の整数除算、小数部分の破棄、および結果への１の加算として定義される。たとえば、３つのクライアント・インスタンスの過半数は、３／２＋１すなわち２である。クライアント・アプリケーションの過半数が、トランザクションの実行に成功する場合、トランザクションがコミットされ、複製完了メッセージが、サーバ２２０８からそれに対応するアプリケーション・インスタンスに転送される。そうでない場合には、トランザクションが打ち切られる。アプリケーションのコピーの過半数によるトランザクションの完了によって、動作の永続性が保証される。トランザクションを実行することができないアプリケーションのコピーは、上で説明したように、ＤＳＴＳグループから追い出される。
【００６０】
本発明の一態様によれば、複製された分散トランザクションは、２フェーズ・コミット・プロトコルを使用してコミットされる。さらに、トランザクションは、サーバの１つのコピーによってコミットされる時に、処理グループの他のコピーによってもコミットされる。
【００６１】
同期式の複製されたトランザクションのそれぞれに、１組のトークン（ハンドル）が関連し、これらに対して、排他アクセスまたは共用アクセスのいずれかが、トランザクションの処理中に要求される。トランザクションは、開始の前にアクセス・トークンに関するロックを得ることを必要としないが、同一の排他アクセス・トークンにアクセスするトランザクションは、直列化される。すなわち、処理グループのメンバは、別のトランザクションのコミットを許可される前に、１つのトランザクション（同一のトランザクション）をコミットする。
【００６２】
本発明の一態様によれば、同一のリソースを使用するトランザクションを並列に初期化できるようにする直列化技法が提供される。トランザクションのイニシエータが、排他使用および共用使用についてトランザクションが必要とするトークン（たとえばハンドル）をリストする。代替案として、中央トークン許可機構（サーバ）を使用することができる。イニシエータは、トランザクションを開始する前に、中央トークン許可機構からトークンを得る。しかし、大多数の場合に、トークンは衝突せず、したがって、トークン許可サーバ手法に対する大幅な性能の改善がある。しかし、トークンが実際に衝突する場合には、処理サーバ・グループの各メンバのデータの一貫性を保つために、本発明の直列化技法が実行される。
【００６３】
たとえば、「Ａ」というラベルを付けられたトークンへの排他アクセスを必要とする２つのトランザクションが同時に開始されると仮定する。さらに、サーバ１が、トランザクションＴ１を開始し、サーバ２が、トランザクションＴ２を開始すると仮定する。Ｔ１は、Ａ＝１をセットし、Ｔ２は、Ａ＝２をセットすると仮定する。さらに、処理グループ内に、これらのトランザクションを処理する３つのメンバがあると仮定する。これらのトランザクションは同時に開始されるので、その順序は重要でないが、すべてのメンバによって同一の順序で実行される。
【００６４】
同期式に複製されたトランザクションは、２フェーズ・コミット・プロトコルを使用して実行される。したがって、データが、コミット準備（ＰＴＣ）フェーズと称する第１フェーズで伝送され、トランザクションが、コミット（ＣＭＴ）フェーズと称する第２フェーズでコミットされる。２フェーズ・コミットは、並列に進行することができ（すなわち、トランザクションＴ１およびＴ２を並列に開始することができる）、トランザクションの複製をより効率的にすることができる。しかし、２フェーズ・コミット・プロトコルのある点で、トランザクションを直列化しなければならない。そうでない場合には、下で説明するように問題が生じる。
【００６５】
２フェーズ・コミットが、直列化なしで並列に進行することを許可される場合には、下に示すように一貫性のない結果につながる可能性がある。
サーバ１ サーバ２ サーバ３
ＰＴＣ（Ｔ１） ＰＴＣ（Ｔ２） ＰＴＣ（Ｔ２）
ＰＴＣ（Ｔ２） ＰＴＣ（Ｔ１） ＰＴＣ（Ｔ１）
／／^**サーバが、コミット・フェーズに進む前に、ＰＴＣが受け取られたことの肯定応答を待つ
ＣＭＴ（Ｔ１） ＣＭＴ（Ｔ１） ＣＭＴ（Ｔ２）
ＣＭＴ（Ｔ２） ＣＭＴ（Ｔ２） ＣＭＴ（Ｔ１）
【００６６】
ここでの問題は、サーバ１およびサーバ２が、Ｔ１およびＴ２を実行し、これらのサーバでＡ＝１がセットされることである。しかし、サーバ３は、Ｔ２およびＴ１を実行し、最終結果としてＡ＝２をセットする。「Ａ」の値は、処理グループ内で一貫性がなく、これは、同期式に複製されるトランザクション・システムでは許容可能ではない。
【００６７】
この問題を克服するために、２フェーズ・コミット処理の第１フェーズ（ＰＴＣフェーズ）は、並列に進行することを許可され、その後、コミット・フェーズが、本発明の一態様に従って、ＰＴＣで送られたトークン情報に基づいて直列化される。ＰＴＣプロトコルは、各トランザクションの排他／共用アクセスにどのトークンが必要であるかに関する情報を提供するように拡張される。割当（Ａ＝１）が排他アクセスを必要とするので、トークン「Ａ」が、Ｔ１およびＴ２の両方のＰＴＣで排他アクセスに関してリストされる。
【００６８】
２フェーズ・コミット・プロトコルに関するさらなる詳細を、図２８および図２９に関して説明する。具体的に言うと、２フェーズ・コミット・プロトコルの第１フェーズすなわちコミット準備フェーズの一例を、図２８に関して説明し、第２フェーズすなわちコミット・フェーズの一例を、図２９に関して説明する。
【００６９】
図２８を参照すると、まず、ＰＴＣを実行しなければならないことを示す複製要求メッセージ２３００が、クライアント・アプリケーション・インスタンス２３０２からサーバ２３０４に送られる。ＰＴＣ要求の受取に応答して、サーバ２３０４が、ＰＴＣメッセージ２３０６を、グループの他のサーバ（たとえばサーバ２３０８ａ、２３０８ｂ）に送る。一例では、ＰＴＣメッセージに、複製要求メッセージと同一のフィールドならびに要求の識別子が含まれる。サーバ２３０４は、ＰＴＣを開始しようとしているので、これをプロトコル・イニシエータと呼称する。
【００７０】
その後、各非イニシエータ・サーバが、ＰＴＣ肯定応答（ＰＴＣ＿ＡＣＫ）メッセージ２３１０を用いてＰＴＣ要求に応答する。具体的に言うと、サーバ２３０８ａが、肯定応答を送り、この肯定応答には、動作コードならびに要求識別子が含まれる。同様に、サーバ２３０８ｂが、肯定応答を送るが、これは、すべての衝突を直列化した後に限られる。すなわち、この例では、サーバ２３０８ｂが、グループのコーディネータとして選択される。したがって、サーバ２３０８ｂは、受け取るＰＴＣ要求のすべてを監視し、衝突する要求を直列化してＰＴＣ＿ＡＣＫメッセージ２３１０を送る。サーバ２３０８ｂが、複数のＰＴＣが同一の排他アクセス・リソースに関して発行されること（または共用されるリソースと衝突する排他的要求）に気付いた場合に、グループ・コーディネータが、それらのうちの１つをまずコミットすることを選択し、更新が完了したことの確認を待ち、その後、第２の要求をコミットし、以下同様である。
【００７１】
プロトコル・イニシエータ（たとえばサーバ２３０４）が、他のサーバからＰＴＣ＿ＡＣＫメッセージを受け取る。このプロトコル・イニシエータは、所与のメッセージに関するＰＴＣ＿ＡＣＫメッセージのすべてを受け取った後に、コミット・メッセージを送る、すなわち、２フェーズ・コミット・プロトコルの第２フェーズを開始する。
【００７２】
２フェーズ・コミット・プロトコルの第２フェーズの一例を、図２９に関して説明する。まず、プロトコル・イニシエータ２４００が、グループのメンバのすべてからＰＴＣ＿ＡＣＫメッセージを受け取り、処理グループの他のサーバのそれぞれにコミット・メッセージ２４０２を送る。グループの各サーバは、それに対応するアプリケーションに複製コールバック・メッセージ２４０４を送って、アプリケーションに動作をコミットするように要求する。動作をコミットした後に、複製コールバック結果メッセージ２４０６が、クライアント・アプリケーションからＤＳＴＳサーバに送られる。
【００７３】
その後、コミット肯定応答メッセージ２４０８が、各ＤＳＴＳサーバからプロトコル・イニシエータ（たとえばプロトコル・イニシエータ２４００）に送られる。プロトコル・イニシエータは、グループのすべてのメンバからコミット肯定応答メッセージを受け取り、メンバの少なくとも過半数が要求を完了した場合に、複製完了メッセージ２４１０を開始クライアントに送る。
【００７４】
本発明の一態様によれば、この暗黙の直列化が、明示的なリソースのロック・メッセージを含めて余分なメッセージなしに可能にされる。その代わりに、処理グループのメンバが、ＰＴＣメッセージに関するトランザクションを開始する。処理グループのメンバが、他のメンバがＰＴＣメッセージを受け取ったことの肯定応答を待つが、この肯定応答をＰＴＣ＿ＡＣＫメッセージと称する。開始メンバは、ＰＴＣ＿ＡＣＫのすべてを受け取った時に、コミット・メッセージを発行することができる。したがって、並列トランザクションは、グループ・コーディネータがＰＴＣフェーズで衝突を検出した場合に、グループ・コーディネータにその肯定応答を保持させることによって直列化される。
【００７５】
したがって、前の例で示した衝突の問題は、次のように解決される（サーバ３がコーディネータであると仮定する）。

【００７６】
分散トランザクションの２フェーズ・コミット処理（または他の処理）中に、障害が発生する可能性がある。そのような障害が発生した場合に、本発明の一態様に従って、そこから回復するための手順が適所にある。一例では、ＤＳＴＳシステムの透過的回復が実行され、保留中のトランザクションは、回復処理中に全く失われない。一例として、保留中のトランザクションは、ＤＳＴＳグループの複数のメンバに障害が発生した場合であっても、トランザクションの再ポストを必要とせずに完了される。
【００７７】
本発明の一態様によれば、ＤＳＴＳグループのメンバが障害を経験する場合に保留中のトランザクションの完了を可能にする機構が提供される。ＤＳＴＳシステムは、システムの１つまたは複数のメンバ・コピーの障害から回復することができるので、このシステムを、高可用性であるという。この問題に対する解決策は、トランザクションが同期式に完了することがＤＳＴＳシステムによって保証される場合であっても、２フェーズ・プロトコルのメッセージの到着が同期式でないという事実によって複雑になる。すなわち、すべてのメンバが、ＰＴＣメッセージおよびＣＭＴメッセージを同時には受け取らず、その結果、ある時点で、各メンバが、１つのプロトコルに関するメッセージの異なる組を受け取っている可能性があり、メッセージが異なる順序で受け取られた可能性がある。
【００７８】
たとえば、図３０の、通常動作中に取られたＤＳＴＳのスナップショットのＴ＝４を検討されたい。その点で、各サーバは、下記のメッセージの組を受け取っている。
サーバ１ サーバ２ サーバ３
ＰＴＣ（Ａ） ＰＴＣ（Ｂ） ＰＴＣ（Ｃ）
ＰＴＣ（Ｂ） ＰＴＣ（Ａ） ＰＴＣ（Ａ）
ＣＭＴ（Ａ） ＰＴＣ（Ｃ）
【００７９】
ここで、サーバ２がＴ＝４で障害を発生したと仮定する。
【００８０】
障害の場合に、残存しいるメンバの１つが、グループ・コーディネータとして選ばれる。この例では、サーバ１がグループ・コーディネータとして選ばれると仮定する。グループ・コーディネータは、本明細書で説明するように回復に参加する。
【００８１】
回復機構に関連する論理の一実施形態を、図３１に関して説明する。当初、ステップ２６００で、各残存メンバが、最後の同期化点以降の、ＰＴＣが観察されたトランザクション識別子のリストをグループ・コーディネータに送る。この例では、サーバ３がＰＴＣ（Ｃ）およびＰＴＣ（Ａ）を送る。その後、ステップ２６０２で、グループ・コーディネータが、他の残存メンバによって送られたＰＴＣ識別子をそれ自体のＰＴＣのリストと比較する。この例では、サーバ３からのリストを、｛ＰＴＣ（Ｂ）、ＰＴＣ（Ａ）｝と比較する。
【００８２】
次に、ステップ２６０４で、グループ・コーディネータが、他のメンバによって報告されたがコーディネータによって受け取られていないメッセージに関する実際のＰＴＣメッセージを要求する。たとえば、グループ・コーディネータであるサーバ１は、サーバ３にＰＴＣ（Ｃ）メッセージを要求する。この時点で、グループ・コーディネータは、最後の同期化点以降のすべての保留中のトランザクションの知識を有する。この時に、グループ・コーディネータは、すべての保留中のプロトコルに関するプロトコル・イニシエータの役割を引き受ける。グループの他のメンバは、障害が発生した時にシステムが回復モードに入るので、プロトコル・イニシエータの役割が変更されたことを知っている。
【００８３】
ステップ２６０６で、グループ・コーディネータが、そのＰＴＣリストとステップ２６００で受け取った他のＰＴＣリストの和集合に含まれるすべてのＰＴＣメッセージについて、他の残存メンバにＰＴＣメッセージを送る。たとえば、グループ・コーディネータは、｛ＰＴＣ（Ａ）、ＰＴＣ（Ｂ）、ＰＴＣ（Ｃ）｝を送出する。ステップ２６０８で、残存グループ・メンバが、保留中のＰＴＣを受け取り、まだ受け取っていないＰＴＣを保管する。たとえば、サーバ３が、ＰＴＣ（Ｂ）を保管する。
【００８４】
その後、ステップ２６１０で、残存メンバが、受け取ったＰＴＣのそれぞれについてＰＴＣ＿ＡＣＫメッセージを送る。ＰＴＣ＿ＡＣＫが、各ＰＴＣについてグループ・メンバに関して受け取られる際に、ステップ２６１２で、グループ・コーディネータが、コミット（ＣＭＴ）メッセージを送る。ステップ２６１４で、残存メンバが、コミット・メッセージを受け取る際に、ＣＭＴ＿ＡＣＫメッセージを送る。保留中のトランザクションに関してＣＭＴ＿ＡＣＫＳが受け取られる時に、ＤＳＴＳシステムは、もう１つの同期点（すなわち、保留中のトランザクションなし）に達する。
【００８５】
有利なことに、２フェーズ・コミット処理の詳細が、クライアント・アプリケーションから隠蔽される。具体的に言うと、クライアント・アプリケーションは、コミット処理にかかわるアプリケーションの他のコピーがあることを知らない。
【００８６】
さらに、有利なことに、上で説明した回復技法は、複数の障害を扱うことができる。すなわち、この技法は、グループ・メンバが障害発生を継続する場合であっても、回復がすでに進行中の場合であっても、たとえばグループ・メンバの定数が維持される限り、成功裡にトランザクションを完了することができる。障害に気付いた時に、この技法が先頭から再始動される。しかし、トランザクションのイニシエータが、ＰＴＣメッセージを送出する前に障害を発生する場合、またはＰＴＣメッセージの宛先の過半数のすべてが、メッセージを受け取った後に障害を発生する場合には、トランザクションが失われる可能性がある。この回復技法は、ロールバック動作をサポートしないアプリケーションであっても、すべてのタイプのアプリケーションに適用可能である。さらに、この回復技法は、非共用分散システム用の有用な通信プロトコルである。
【００８７】
上記のほかに、障害を発生したメンバに、観察される最後の同期点を検出させることと、ＤＳＴＳシステムの最新の同期点に達するために必要なトランザクションのデルタを現在のグループから取得することによって、障害を発生したメンバがグループに再参加することができる。
【００８８】
一実施形態では、グループ・メンバシップおよびグループ状態が、ＤＳＴＳシステムの回復に使用される。
【００８９】
上で説明したのは、複製された分散同期トランザクションの管理のさまざまな態様である。有利なことに、複製の詳細が、クライアント・アプリケーションから隠蔽される（たとえば、２フェーズ・コミットの投票がなく、グループ・プロトコルへの参加がない）。本発明の１つまたは複数の態様は、同種システムならびに異機種システムに適用可能である。一例として、異機種環境のシステムのインターオペラビリティを促進する機能が提供される。
【００９０】
本発明を、たとえばコンピュータ使用可能媒体を有する製造品（たとえば、１つまたは複数のコンピュータ・プログラム製品）に含めることができる。媒体は、その中に、たとえば本発明の機能を提供し促進するコンピュータ可読プログラム・コード手段を実施される。製造品は、コンピュータ・システムの一部として含めるか、別に販売することができる。
【００９１】
さらに、計算機によって読取可能であり、本発明の機能を実行するために計算機によって実行可能な命令の少なくとも１つのプログラムを具体的に実施する少なくとも１つのプログラム記憶装置を提供することができる。
【００９２】
本明細書に示された流れ図は、例にすぎない。本発明の趣旨から逸脱しない、これらの図または本明細書に記載のステップ（または動作）に対する多数の変形形態がありえる。たとえば、ステップを、異なる順序で実行することができ、ステップの追加、削除、または変更を行うことができる。これらの変形形態のすべてが、請求される発明の一部とみなされる。
【００９３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００９４】
（１）分散コンピューティング環境の処理グループを管理する方法であって、
処理グループの見込みのあるメンバの状態の少なくとも一部を、前記処理グループのグループ状態の少なくとも一部と比較するステップと、
前記比較が差を示す場合に、前記見込みのあるメンバの前記状態の前記少なくとも一部を更新するステップと、
前記見込みのあるメンバを前記処理グループに参加させるステップと
を含む方法。
（２）前記グループ状態に対するアクティビティを静止させるステップと、
前記比較での使用のために、アクティビティを静止させた後に、前記グループ状態を取り出すステップと
をさらに含む、上記（１）に記載の方法。
（３）分散コンピューティング環境の処理グループを管理するシステムであって、
処理グループの見込みのあるメンバの状態の少なくとも一部を、前記処理グループのグループ状態の少なくとも一部と比較する手段と、
前記比較が差を示す場合に、前記見込みのあるメンバの前記状態の前記少なくとも一部を更新する手段と、
前記見込みのあるメンバを前記処理グループに参加させる手段と
を含むシステム。
（４）前記グループ状態に対するアクティビティを静止させる手段と、
前記比較での使用のために、アクティビティを静止させた後に、前記グループ状態を取り出す手段と
をさらに含む、上記（３）に記載のシステム。
（５）計算機によって可読であり、分散コンピューティング環境の処理グループを管理する方法を実行するために前記計算機によって実行可能な命令の少なくとも１つのプログラムを具体的に実施する、少なくとも１つのプログラム記憶装置であって、前記方法が、
処理グループの見込みのあるメンバの状態の少なくとも一部を、前記処理グループのグループ状態の少なくとも一部と比較するステップと、
前記比較が差を示す場合に、前記見込みのあるメンバの前記状態の前記少なくとも一部を更新するステップと、
前記見込みのあるメンバを前記処理グループに参加させるステップと
を含む、少なくとも１つのプログラム記憶装置。
（６）前記グループ状態に対するアクティビティを静止させるステップと、
前記比較での使用のために、アクティビティを静止させた後に、前記グループ状態を取り出すステップと
をさらに含む、上記（５）に記載の少なくとも１つのプログラム記憶装置。
【図面の簡単な説明】
【図１】本発明の諸態様が組み込まれ、使用される、コンピューティング環境の一例を示す図である。
【図２】本発明の一態様による、図１の複数のノードのさまざまな構成要素の一例を示す図である。
【図３】本発明の一態様による、クライアント・アプリケーション・インスタンスがＤＳＴＳサーバを使用せずにサード・パーティ・アプリケーションの要求に応答するコンピューティング環境の一実施形態を示す図である。
【図４】本発明の一態様による、クライアント・アプリケーション・インスタンスがＤＳＴＳサーバを使用してサード・パーティ・アプリケーションに応答するコンピューティング環境の一実施形態を示す図である。
【図５】本発明の一態様に従って使用される処理グループの一例を示す図である。
【図６】本発明の一態様による、グループ活動化プロトコルに関連する構成要素の一例を示す図である。
【図７】本発明の一態様による、グループ活動化の実行に関連する論理の一実施形態を示す図である。
【図８】本発明の一態様による、グループ活動化の実行に関連する論理の一実施形態を示す図である。
【図９】本発明の一態様による、グループ活動化の実行に関連する論理の一実施形態を示す図である。
【図１０】本発明の一態様による、初期化メッセージに関連するフィールドの一例を示す図である。
【図１１】本発明の一態様による、グループ参加プロトコルに関連する構成要素の一実施形態を示す図である。
【図１２】本発明の一態様による、処理グループへの参加に関連する論理の一実施形態を示す図である。
【図１３】本発明の一態様による、処理グループへの参加に関連する論理の一実施形態を示す図である。
【図１４】本発明の一態様による、静止メッセージに関連するフィールドの一例を示す図である。
【図１５】本発明の一態様による、アーカイブ・メッセージに関連するフィールドの一実施形態を示す図である。
【図１６】本発明の一実施形態による、アーカイブ解除メッセージに関連するフィールドの一実施形態を示す図である。
【図１７】本発明の一実施形態による、ハンドル列挙要求メッセージに関連するフィールドの一例を示す図である。
【図１８】本発明の一実施形態による、ハンドル列挙応答メッセージに関連するフィールドの一例を示す図である。
【図１９】本発明の一実施形態による、処理グループからのメンバの排除に関連する論理の一実施形態を示す図である。
【図２０】本発明の一実施形態による、定数通知メッセージに関連するフィールドの一例を示す図である。
【図２１】本発明の一実施形態による、複製要求メッセージに関連するフィールドの一例を示す図である。
【図２２】本発明の一実施形態による、複製コールバック・メッセージに関連するフィールドの一例を示す図である。
【図２３】本発明の一実施形態による、複製コールバック結果メッセージに関連するフィールドの一例を示す図である。
【図２４】本発明の一実施形態による、複製完了メッセージに関連するフィールドの一例を示す図である。
【図２５】本発明の一実施形態による、シャットダウン・メッセージに関連するフィールドの一例を示す図である。
【図２６】本発明の一態様による、同期トランザクションの処理に関連するメッセージの流れの一実施形態を示す図である。
【図２７】本発明の一態様による、同期トランザクションの処理に関連するメッセージの流れの一実施形態を示す図である。
【図２８】本発明の一態様による、コミット準備動作に関連するメッセージの流れの一実施形態を示す図である。
【図２９】本発明の一態様による、コミット動作に関連するメッセージの流れの一実施形態を示す図である。
【図３０】本発明の一態様による、特定の時点での分散システムのスナップショットの一例を示す図である。
【図３１】本発明の一態様に従って使用される、回復手順に関連する論理の一実施形態を示す図である。
【符号の説明】
１００ 分散コンピューティング環境
１０２ フレーム
１０４ ＬＡＮゲート
１０６ 処理ノード
２００ 分散クライアント・アプリケーション
２０２ ノード
２０４ ＤＳＴＳインスタンス

Claims (6)

1. １以上のコンピュータからなるノードにより構成される分散コンピューティング環境の前記１以上のノードからなる処理グループの管理を行う方法であって、
   前記処理グループに属さないノードが、前記処理グループのそれぞれのメンバが持つ同一の前記処理グループの状態を取得し、前記ノードの状態に含まれたシーケンス番号と、前記処理グループの状態に含まれたシーケンス番号とを比較するステップと、
   前記比較するステップで比較した結果に基づいて、前記処理グループの前記シーケンス番号を前記ノードが更新するステップと、
   前記ノードが前記更新されたシーケンス番号を前記処理グループの状態に保管することによって、前記処理グループに前記ノードが参加するステップとを含む方法。
2. 前記ノードが前記処理グループに参加する際に発する参加メッセージを前記処理グループに送った後に前記処理グループを構成するメンバが処理を静止するステップと、
   前記処理を静止させた後に、前記比較での使用のために前記処理グループの前記メンバの内の一のノードから、前記ノードが前記処理グループの状態を取り出すステップとをさらに含む、請求項１に記載の方法。
3. １以上のコンピュータからなるノードにより構成される分散コンピューティング環境の前記１以上のノードからなる処理グループの管理を行うシステムであって、
   前記処理グループに属さないノードが、前記処理グループのそれぞれのメンバが持つ同一の前記処理グループの状態を取得し、前記ノードの状態に含まれたシーケンス番号と、前記処理グループの状態に含まれたシーケンス番号とを比較する手段と、
   前記比較する手段で比較した結果に基づいて、前記処理グループの前記シーケンス番号を前記ノードが更新する手段と、
   前記ノードが前記更新されたシーケンス番号を前記処理グループの状態に保管することによって、前記処理グループに前記ノードが参加する手段とを含むシステム。
4. 前記ノードが前記処理グループに参加する際に発する参加メッセージを前記処理グループに送った後に、前記処理グループを構成するメンバが処理を静止する手段と、
   前記処理を静止させた後に、前記比較での使用のために前記処理グループの前記メンバの内の一のノードから、前記ノードが前記処理グループの状態を取り出す手段とをさらに含む、請求項３に記載のシステム。
5. 計算機によって可読であり、１以上のコンピュータからなるノードにより構成される分散コンピューティング環境の前記１以上のノードからなる処理グループの管理を行う方法を実行するために前記計算機によって実行可能な命令の少なくとも１つのプログラムを具体的に実施する、少なくとも１つのプログラム記憶装置であって、
   前記プログラムが、
   前記処理グループに属さないノードが、前記処理グループのそれぞれのメンバが持つ同一の前記処理グループの状態を取得し、前記ノードの状態に含まれたシーケンス番号と、前記処理グループの状態に含まれたシーケンス番号とを比較するステップと、
   前記比較するステップで比較した結果に基づいて、前記処理グループの前記シーケンス番号を前記ノードが更新するステップと、
   前記ノードが前記更新されたシーケンス番号を前記処理グループの状態に保管することによって、前記処理グループに前記ノードが参加するステップとを含む、少なくとも１つのプログラム記憶装置。
6. 前記プログラムが、
   前記ノードが前記処理グループに参加する際に発する参加メッセージを前記処理グループに送った後に前記処理グループを構成するメンバが処理を静止するステップと、
   前記処理を静止させた後に、前記比較での使用のために前記処理グループの前記メンバの内の一のノードから、前記ノードが前記処理グループの状態を取り出すステップとをさらに含む、請求項５記載の少なくとも１つのプログラム記憶装置。

Images