JP2006227816A - 分散システム、コンピュータおよび分散システムの状態遷移制御方法 - Google Patents

Abstract

【課題】コーディネータによる通常の制御は３相コミット方式の制御と同等とし、３相コミット方式の終了手続きに替わって非同期ネットワークモデルでも正しく動作する終了手続きを実行する分散システムを提供する。
【解決手段】複数のリソース４ａ〜ｃによって分散トランザクションが実行される分散システムにおいて、リソース４ａ〜ｃは、コーディネータからの指示に基づき、自身の更新処理の状態を遷移させる。また、リソース４ａ〜ｃは、終了手続き部５を備え、この終了手続き５によって、複数のリソース４ａ〜ｃそれぞれの更新処理の状態を収集し、コーディネータ３からの指示によらずに、この収集した更新処理の状態から自身の更新処理のコミットまたはアボートを決定して終了手続きを行う。
【選択図】 図１

Description

この発明は、例えばインターネット上の複数のサイトによって実行される分散トランザクションが実行される分散システムの状態遷移制御技術に関する。

昨今のインターネットの発達は、インターネットを介した企業と顧客の取り引き、あるいは企業と企業の間の取り引きを可能にし始めている。このような取り引きは一般的にトランザクションという概念でとらえる事ができる。トランザクションが複数のリソースに跨っている場合、それは、分散トランザクションと呼ばれる。

一般的に、トランザクションは、いわゆるＡＣＩＤ特性を保持して制御される必要がある。ここでＡＣＩＤは、Atomicity（原子性）、Consistency（一貫性）、Isolation（隔離性）、Duration（持続性）の４つの特性の頭文字を並べたものである。分散トランザクションにおいても、ＡＣＩＤ特性を持つことが必要であり、２相コミット（2 phase commit）と呼ばれる方法で制御されることが広く行われている。例えば、インターネットを介した取り引きを可能にするWebServiceにおいては、WS-Transaction仕様で２相コミット方式が採用されている。

ところで、この２相コミット方式は、分散トランザクションのＡＣＩＤ特性を保証するものではあるが、トランザクションに関係するリソースに障害が発生した場合に、トランザクションがブロックしてしまう可能性があるという問題がある。ここで、「トランザクションがブロックする」とは、そのトランザクションに関係するすべてのリソースの更新処理がコミットもアボートもできない状態を保持し続けることを指す。あるトランザクションがブロックすると、そのトランザクションは関係するリソースのロックを保持しつづけるため、別のトランザクションがそのロックを取得できずに待たされ、次々とデッドロックを引き起こす可能性があることが問題となる。

この障害が発生したときにトランザクションをブロックするという２相コミット方式の性質は、本来的な問題点なのであるが、旧来、同一システム内において２相コミット方式を使用している場合には、それは大きな問題ではなかった。なぜなら、障害が発生した場合は、その障害を取り除き、復旧することがシステムの第一の課題であり、一方、障害が復旧すればトランザクションのブロックは解除できるからである。このように、一元的に運用管理される単一のシステム内に２相コミットが止まっている限り、トランザクションのブロックは、そのシステムの障害とひっくるめて考える事ができるため、それ自体が大きく問題視される事はなかった。

しかしながら、トランザクションが、複数の会社をまたがっている場合には、これは大きな問題となり得る。例えばあるトランザクションにＡ社、Ｂ社およびＣ社の３社が関わっており、そのうちのＢ社、Ｃ社のサイトではまったく障害が発生していないにもかかわらず、Ａ社のサイトの障害から引きずられる形でトランザクションがブロックし、デッドロックの連鎖の結果として、Ａ社との取り引きと関係のない業務までもがストップする可能性がある。このような事態において、Ｂ社、Ｃ社は、Ａ社のサイトが復旧するまで、ただ呆然と待つ事になるとしたら、それはとても許容できないだろう。このように、それぞれ独立に運用管理されているシステムに跨って２相コミットが行われる場合、特定のサイトの障害によりトランザクションのブロックが発生し、その他の正常なサイトの業務までもが継続できなくなる可能性があるという問題がある。そして、この２相コミット方式のブロックする問題点を改良したものとして、３相コミット方式がすでに知られている。

２相コミットから３相コミットへの変更点は、リソースの状態遷移について、２相コミットにおけるprepared状態を２つに分け（本明細書ではこれをＷ状態、Ｐ状態とする）、コーディネータからリソースへのコミットの指示をＷ状態→Ｐ状態→コミットと２段階で行うようにした点である。

３相コミットでは、途中でコーディネータやリソースが障害となったとしても、正常なリソースの更新処理の状態を収集する事により、コミットまたはアボートを決定できることが特徴である。この手順を終了手続き(Termination Protocol)と称する。

３相コミットの終了手続きでは、コーディネータが障害となった場合には新しいコーディネータを立ち上げ、正常なリソースの更新処理の状態を収集し、それらの状態がすべて未確定状態であれば、トランザクションはアボートする。それらの状態がすべて確定状態であれば、トランザクションはコミットする。それ以外の場合は、Ｗ状態とＰ状態が混在する場合となるが、コーディネータは正常なリソースに関して、再度、コミットの指示をＷ状態→Ｐ状態→コミットと２段階で行う。なお、ここでいう未確定状態とは、更新中またはアボートまたはＷ状態のいずれかの状態である事を指し、また、確定状態とは、Ｐ状態またはコミットのいずれかの状態である事を指す。

また、障害が発生したリソースが復旧した時には、終了手続きで既に決定したコミットまたはアボートに従って、そのリソースの更新処理をコミットまたはアボートする。復旧したリソースが障害発生の前にすでにコミットまたはアボートしていたとすれば、それが終了手続きの決定と矛盾していないことは、３相コミットのアルゴリズムによって保証されていることに留意する。

以上のように、３相コミット方式は、終了手続きによりトランザクションをブロックさせないことができる方式であるが、この終了手続きが正しく動作するためには、
（１）リソースの障害が判定できなくてはならない
（２）一度障害だと判定されたリソースは、そのあと終了手続きには参加できない
（３）新しいコーディネータを立ち上げあげる時、それは唯一でなければならない
という条件を満たす必要がある。

ところが、特にインターネットのような不確実性の高いネットワークを介して通信を行う一般的なサーバの場合には、上記条件（１）〜（３）のいずれも満たされない。具体的には、それぞれ、（１）はネットワーク障害によるアクセス不可がサーバの障害と区別できないことに起因し、（２）はサーバの高負荷のためのスローダウンがサーバの障害と区別できないことに起因し、（３）はネットワークパーティショニングが起きた場合にそれぞれのパーティションで独立して終了手続きを実行してしまうことに起因して、それぞれの条件が満たされないことになる。従って、この３相コミット方式は、インターネット環境ではそのまま適用できないという問題点がある。

より一般的に言えば、インターネットのような不確実性の高いネットワーク環境は、非同期ネットワークモデル(asynchronous network model)に分類されるが、３相コミット方式の終了手続きは非同期ネットワークモデルにおいては正しく動作しないという問題点がある。

この発明は、このような事情を考慮してなされたものであり、コーディネータによる通常の制御は３相コミット方式の制御と同等とし、３相コミット方式の終了手続きに替わって非同期ネットワークモデルでも正しく動作する終了手続きを実行する分散システム、コンピュータおよび分散システムの状態遷移制御方法を提供することを目的とする。

前述した目的を達成するために、この発明は、複数のリソースによって分散トランザクションが実行される分散システムにおいて、前記複数のリソースそれぞれが、前記分散トランザクションに関わる更新処理の状態遷移を３相コミット方式で調整するコーディネータからの指示に基づき、自身の更新処理の状態を遷移させる第１の状態遷移制御手段と、前記複数のリソースそれぞれの更新処理の状態を収集し、前記コーディネータからの指示によらずに、前記収集した更新処理の状態から自身の更新処理のコミットまたはアボートを決定して終了手続きを行う第２の状態遷移制御手段とを具備することを特徴とする。

また、この発明は、ネットワークを介して接続される他のコンピュータと共に分散トランザクションを実行するコンピュータにおいて、前記分散トランザクションに関わる更新処理の状態遷移を３相コミット方式で調整するコーディネータからの指示に基づき、自身の更新処理の状態を遷移させる第１の状態遷移制御手段と、前記他のコンピュータそれぞれの更新処理の状態を収集し、前記コーディネータからの指示によらずに、自身の更新処理の状態と前記収集した更新処理の状態とから自身の更新処理のコミットまたはアボートを決定して終了手続きを行う第２の状態遷移制御手段とを具備することを特徴とする。

また、この発明は、複数のリソースによって分散トランザクションが実行される分散システムの状態遷移制御方法であって、前記複数のリソースそれぞれが、前記分散トランザクションに関わる更新処理の状態遷移を３相コミット方式で調整するコーディネータからの指示に基づき、自身の更新処理の状態を遷移させ、前記複数のリソースそれぞれの更新処理の状態を収集し、前記コーディネータからの指示によらずに、前記収集した更新処理の状態から自身の更新処理のコミットまたはアボートを決定して終了手続きを行うことを特徴とする。

この発明によれば、コーディネータによる通常の制御は３相コミット方式の制御と同等とし、３相コミット方式の終了手続きに替わって非同期ネットワークモデルでも正しく動作する終了手続きを実行する分散システム、コンピュータおよび分散システムの状態遷移制御方法を提供できる。

以下、図面を参照してこの発明の実施形態について説明する。図１は、本発明の一実施形態に係る分散システムによる分散トランザクションを示す図である。ここでは、Ａ社、Ｂ社、Ｃ社の３社がオンラインで取り引きを行う場合を想定し、そのために、図示のように、インターネット１を介してＡ社サーバ（サイト）２ａ、Ｂ社サーバ２ｂ、Ｃ社サーバ２ｃが相互に通信可能に接続されているものとする。また、この分散トランザクションに関わる更新処理の状態遷移を調整するコーディネータ３はＡ社サーバ２ａにあり、このトランザクションによって３社のリソース４ａ〜ｃがそれぞれ更新されるものとする。そして、このようなトランザクションを実行する本実施形態の分散システムは、非同期ネットワークモデルでも正しく動作する終了手続きを実現するために、リソース４ａ〜ｃそれぞれが、コーディネータ３からの指示によって状態を遷移させる通常の機能のほか、コーディネータ３からの指示によらずに当事者間同士の通信のみによって適切な終了手続きを行う終了手続き部５を有する点を特徴としており、以下、この点について詳述する。

まず、この終了手続き部５の動作原理の理解を助けるために、第１に、図２〜図５を参照しながら、２相コミットの典型的な手順を説明する。図２に示すように、２相コミットでは、各リソース４ａ〜ｃがコーディネータ３と通信しながら、その指示に従って状態を遷移させていく。そして、各リソース４ａ〜ｃの状態は、図３に示すように、更新中（ａ１）となった後、prepared（ａ２）を経てコミット（ａ３）またはアボート（ａ４）となるか、あるいは更新中から直接にアボート（ａ４）となるといったように遷移する。prepared状態とは、処理が完了する直前で保留された状態であって、その処理をコミットすることもアボートすることも任意に可能な状態を指す。この２相コミットでトランザクションがコミットまたはアボートする場合の流れを以下に示す。

（１）トランザクションがコミットする場合の流れ
ａ．Ａ社、Ｂ社、Ｃ社の各リソース４ａ〜ｃでの更新処理が行われてprepared状態となり、それぞれがコーディネータに通知する。

ｂ．コーディネータ３は３社の更新処理がprepared状態になったのを知り、トランザクションのコミットを決定し、更新処理をコミットする指示を各リソース４ａ〜ｃに送信する。そして、その指示を受けて３社の各リソース４ａ〜ｃの更新処理がコミットする。

（２）トランザクションがアボートする場合の流れ（例）
ａ．Ｂ社、Ｃ社の各リソース４ｂ，ｃでの更新処理が行われてprepared状態となり、それぞれがコーディネータに通知する。一方で、Ａ社のリソース４ａでの更新処理は失敗してアボートし、コーディネータにそれを通知する。

ｂ．コーディネータ３はＡ社の更新処理がアボートしたのを知り、トランザクションのアボートを決定し、Ｂ社、Ｃ社の各リソース４ｂ，ｃの更新処理をアボートする指示を送信する。その指示を受けてＢ社、Ｃ社の各リソース４ｂ，ｃの更新処理がアボートする。

以上のような流れによる、この２相コミットでの状態遷移を調整するためのコーディネータ３の動作手順を図４に示す。

まず、コーディネータ３は、すべてのリソースから更新処理の状態が通知されるのを待機する（ステップＡ１）。そして、コーディネータ３は、すべてprepared状態であった場合（ステップＡ２のＹＥＳ）、トランザクションのコミットを決定し、更新処理のコミットの指示をすべてのリソースに送信する（ステップＡ３）。一方、prepared状態でないものが存在した場合には（ステップＡ２のＮＯ）、コーディネータ３は、トランザクションのアボートを決定し、prepared状態となっている更新処理のアボートの指示を必要なリソースに送信する（ステップＡ４）。

図５は、２相コミットでのコーディネータ３と各リソース４ａ〜ｃとのやり取りを示すタイミングチャートであり、各リソース４ａ〜ｃに対してコーディネータ３から更新処理の開始が指示され（図５の（１））、各リソース４ａ〜ｃによる更新処理が各々実行された後（図５の（２））、その結果（prepared状態かどうか）が各リソース４ａ〜ｃからコーディネータ３に返却される（図５の（３））。

この結果の返却を受けて、コーディネータ３は、トランザクションのコミットまたはアボートを決定し、各リソース４ａ〜ｃに指示する（図５の（４））。そして、各リソース４ａ〜ｃは、この指示通りにコミットまたはアボートを行い（図５の（５））、その完了をコーディネータ３に報告する（図５の（６））。

ここまでは、障害が発生しない場合の流れである。次に、障害が発生してトランザクションがブロックする場合の流れを示す。

（３）トランザクションがブロックする場合の流れ（例）
ａ．Ａ社、Ｂ社、Ｃ社の各リソース４ａ〜ｃでの更新処理が行われてprepared状態となり、それぞれがコーディネータに通知する。

ｂ．ここで、Ａ社のサーバ２ａに障害が発生し、Ａ社のリソースおよびコーディネータが動作しなくなった。その結果、Ｂ社、Ｃ社の各リソース４ｂ，ｃの更新処理はprepared状態のままブロックする。

この後、Ｂ社、Ｃ社の各リソース４ｂ，ｃの更新処理を勝手にコミットもアボートもできないという点に留意する。なぜなら、Ｂ社、Ｃ社の更新処理の状態からだけでは、そのトランザクションがコミットする場合とアボートする場合の区別ができず、Ａ社の更新処理がコミットした可能性もアボートした可能性も両方あり得るからである。トランザクションのアトミシティを保つためには、Ａ社のサーバ２ａが障害から復旧してＡ社のリソース４ａの更新処理の出来を判別した後に、それに応じてＢ社、Ｃ社のリソースの更新処理をコミットまたはアボートしなければならないのである。

続いて、終了手続き部５の動作原理の理解を助けるために、第２に、図６〜図８を参照しながら、２相コミット方式のブロックする問題点を改良した３相コミットについて簡単に説明する。

この３相コミットでは、図６に示すように、２相コミットにおけるprepared状態がＷ状態（ｂ２）とＰ状態（ｂ３）に分けられ、コーディネータ３から各リソース４ａ〜ｃへのコミットの指示がＷ状態→Ｐ状態→コミットと２段階で行われる。この３相コミットでの状態遷移を調整するためのコーディネータ３の動作手順を図７に示す。

まず、コーディネータ３は、すべてのリソースから更新処理の状態が通知されるのを待機する（ステップＢ１）。コーディネータ３は、すべてＷ状態であった場合（ステップＢ２のＹＥＳ）、更新処理をＰ状態に遷移させる指示をすべてのリソースに送信し（ステップＢ３）、すべてのリソースの更新処理がＰ状態になるのを待機する（ステップＢ４）。そして、すべてＰ状態となったら、コーディネータ３は、トランザクションのコミットを決定し、更新処理のコミットの指示をすべてのリソースに送信する（ステップＢ５）。

一方、Ｗ状態でないものが存在した場合には（ステップＢ２のＮＯ）、コーディネータ３は、トランザクションのアボートを決定し、Ｗ状態となっている更新処理のアボートの指示を必要なリソースに送信する（ステップＢ６）。

図８は、３相コミットでのコーディネータ３と各リソース４ａ〜ｃとのやり取りを示すタイミングチャートであり、各リソース４ａ〜ｃに対してコーディネータ３から更新処理の開始が指示され（図８の（１））、各リソース４ａ〜ｃによる更新処理が各々実行された後（図８の（２））、その結果（Ｗ状態かどうか）が各リソース４ａ〜ｃからコーディネータ３に返却される（図８の（３））。ここでは、Ｗ状態が返却されたものとし、この結果の返却を受けて、コーディネータ３は、Ｐ状態に遷移させる指示を各リソース４ａ〜ｃに送信する（図８の（４））。この指示を受けて、各リソース４ａ〜ｃは、更新処理をＰ状態に遷移させ（図８の（５））、その遷移完了をコーディネータ３に報告する（図８の（６））。そして、このＰ状態への遷移完了を報告されると、コーディネータ３は、トランザクションのコミットを各リソース４ａ〜ｃに指示し（図８の（７））、一方、各リソース４ａ〜ｃは、この指示通りにコミットを行い（図８の（８））、その完了をコーディネータ３に報告する（図８の（９））。

３相コミットは、途中でコーディネータ３や各リソース４ａ〜ｃが障害となったとしても、正常なリソースの更新処理の状態を収集する事により、コミットまたはアボートを決定できる（終了手続き）ことを特徴としている。

しかしながら、前述したように、インターネットのような不確実性の高いネットワーク環境は、非同期ネットワークモデルに分類されるが、この３相コミット方式の終了手続きは非同期ネットワークモデルにおいては正しく動作しないという問題がある。次に、この問題を解決する本発明のコミット方式について説明する。

本発明のコミット方式は、コーディネータによる通常の制御は３相コミット方式の制御と同等とし、３相コミット方式の終了手続きに替わって、非同期ネットワークモデルでも正しく動作する終了手続きを新たに提供することにより、インターネットを介した取り引きにおいても利用可能にしたものである。つまり、各リソース４ａ〜ｃが備える終了手続き部５は、この新たに提供する本発明の終了手続きを実行する。

終了手続き部５が実行する終了手続きは、図９に示すように、コーディネータ３を利用せず、トランザクションに関係するリソース４ａ〜ｃの間で直接通信する方式である。それぞれのリソースにおける終了手続きのフローチャートが対称で、フローの中でランダムな選択を行う個所があるという特徴をもつ。理論的には、非同期ネットワークモデルにおける合意アルゴリズムの一つであるBen-orの合意アルゴリズムと同等である(参考文献：Ben-Or, Another Advantage of Free Choice: Completely Asynchronous Agreement Protocols, Proceedings of the Socond Annual ACM Symposium on Principles of Distributed Computing, pp27-30, 1983)。

それぞれのリソースにおける終了手続きのフローは、
（１）あるリソースの更新処理の状態がコミットまたはアボートまたは更新中であることがわかった場合には、終了処理は自明であるから即座にコミットまたはアボートを決定する。

（２）それ以外の場合には、Ｗ状態またはＰ状態をそれぞれのリソースの更新処理の状態の初期値と考え、Ben-orの合意アルゴリズムを実行し、Ｗ状態での合意はアボート、Ｐ状態での合意はコミットとする。

というものである。

Ben-orの合意アルゴリズムは、初期値がすべてＷ状態であったときにはすべてのリソースの更新処理ががアボートに統一され、初期値がすべてＰ状態であったときはすべてのリソースの更新処理がコミットに統一され、それ以外の場合では、すべてのリソースの更新処理がコミットまたはアボートのいずれかに統一されることを保証する。これによって、トランザクションのAtomicityが保証される。

この終了手続きでは、障害となるリソースの数がリソースの全体数の半数未満である場合に、トランザクションのコミットまたはアボートを決定できる。なお、終了手続きが完了する前に、障害が発生したリソースの数が全体の半数以上となった場合には、終了手続きはブロックし、したがってトランザクションがブロックする。ただし、障害となったリソースが復旧した場合には、そのリソースは任意に再び終了手続きに参加できる。そのため、障害の復旧により正常なリソースの数が全体の半数以上となれば、本発明の終了手続きはトランザクションのコミットまたはアボートを決定できる。

また、この終了手続きは、任意の時点で開始する事ができる。したがって、本発明の合理的な展開としてさまざまな終了手続きの開始方法が可能である。たとえば、まったく障害の発生していない状況で終了手続きを開始したとしても、それは正しく動作する。ただし、終了手続きを開始することによって、本来コミットできるはずのトランザクションがアボートしてしまう可能性もあるため、終了手続きを使わずにコーディネータによる制御でトランザクションが完了できることが期待できる場合には、終了手続きを開始しないほうが全体としての効率がよいという傾向もある。

例えば、任意に設定可能なタイムアウト値を使って、コーディネータがいずれかのリソースのタイムアウトを検出するか、あるいは、いずれかのリソースがコーディネータのタイムアウトを検出した場合に、この終了手続きを開始するような方式とすれば、タイムアウト値の設定によって全体の効率のバランスを調節できるようになる。あるいは、外部の障害検出機構があれば、それによってこの終了手続きを開始するような方式でもよい。

なお、本実施形態におけるコーディネータ３の動作手順は、図７に示す３相コミット方式のそれとまったく同一である。そして、終了手続き部５が実行する終了手続きには、コーディネータ３は参加せず、それぞれのリソース間で通信する事により行われる。それぞれのリソースにおける終了手続きのフローは、番号付けされたステップを順次処理するようになっており、各ステップの基本動作は、全体の過半数以上のリソースの更新処理の状態を他のリソースと通信することにより収集し、次のステップでの自身の更新処理の状態を決定する。それぞれのリソースにおける更新処理の状態は、３相コミット方式のそれに加えて、図１０に示すように、ステップ番号で添え字付けされたＷ状態、Ｐ状態およびＺ状態（ステップ番号が偶数だけ）からなる。ステップ番号１のＷ１状態とＰ１状態は、それぞれＷ状態とＰ状態のことを指すものとする
次に、図１１〜図１３のフローチャートを参照して、この終了手続き部５の具体的な動作手順を説明する。なお、説明中のＳはステップに付される順序番号、Ｎはトランザクションに関係するリソースの数、ＱはＮの過半数となる最小の数、ＦはＮ−Ｑである。

図１１は、基本フローであり、自身の更新処理の状態がコミットまたはアボートであれば（ステップＣ１のＹＥＳ）、終了手続きは完了である。一方、自身の更新処理の状態が更新中であれば（ステップＣ１のＮＯ，ステップＣ２のＹＥＳ）、更新処理をアボートし（ステップＣ３）、終了手続きは完了である。そして、自身の更新処理の状態がＷ状態またはＰ状態であれば（ステップＣ２のＮＯ）、図１２〜図１３にその詳細な流れが示される判定処理に進む。

判定処理では、まず、ステップ番号を１にセットし（ステップＤ１）、他のリソースと通信して、それぞれのリソースの更新処理の状態を収集する（ステップＤ２）。もし、その中にコミットがあれば（ステップＤ３のＹＥＳ）、自身の更新処理をコミットし（ステップＤ４）、終了手続きは完了である。また、もし、その中にアボートまたは更新中があれば（ステップＤ５のＹＥＳ）、自身の更新処理をアボートし（ステップＤ６）、終了手続きは完了である。

もし、その中に、自身のステップ番号より大きなステップ番号をもつ状態があれば（ステップＤ７のＹＥＳ）、自身の更新処理の状態をその状態と同じにし（ステップＤ８）、ステップＤ２からの処理を繰り返す。また、もし、その中に、自身のステップ番号より小さなステップ番号をもつ状態があれば（ステップＤ９のＹＥＳ）、それは無視して破棄する（ステップＤ１０）。

そして、自身と同じステップ番号の状態を、全体の過半数のリソースについて収集（この中には自身の状態を含んでもよい）できた場合（ステップＤ１１のＹＥＳ）、以下の判定基準にしたがって、次のステップでの自身の更新処理の状態を決定し、次のステップに進む。

ステップ番号が奇数の場合（ステップＤ１２のＹＥＳ）、収集したリソースの更新状態はＷs かＰs で、Ｑ個以上あることになる。そこで、もし、Ｗs がＱ個以上あれば（ステップＤ１３のＹＥＳ）、次のステップでの自身の更新処理の状態をＷs+1 とし（ステップＤ１４）、また、Ｐs がＱ個以上あれば（ステップＤ１５のＹＥＳ）、次のステップでの自身の更新処理の状態をＰs+1 とする（ステップＤ１６）。また、それ以外では、次のステップでの自身の更新処理の状態をＺs+1 とする（ステップＤ１７）。以上の状態遷移を終えたら、ステップ番号をインクリメントして（ステップＤ２７）、ステップＤ２からの処理を繰り返す。

一方、ステップ番号が偶数の場合には（ステップＤ１２のＮＯ）、収集したリソースの更新状態はＷs かＰs かＺs で、Ｑ個以上あることになる。さらに、Ｗs とＰs が同時に現れる事はない。これは、一つ前のステップ番号で、全体の中でＷs-1 とＰs-1 が同時に過半数を超える事がないからである。

もし、Ｗs がＦ＋１個以上あれば（ステップＤ１８のＹＥＳ）、自身の更新処理をアボートする（ステップＤ１９）。また、Ｆ＋１個はないが（ステップＤ１８のＮＯ）、Ｗs が１個以上あれば（ステップＤ２０のＹＥＳ）、次のステップでの自身の更新処理の状態をＷs+1 とする（ステップＤ２１）。

もし、Ｐs がＦ＋１個以上あれば（ステップＤ２２のＹＥＳ）、自身の更新処理をコミットする（ステップＤ２３）。また、Ｆ＋１個はないが（ステップＤ２２のＮＯ）、Ｐs が１個以上あれば（ステップＤ２４のＹＥＳ）、次のステップでの自身の更新処理の状態をＰs+1 とする（ステップＤ２５）。そして、上記のいずれにも該当しない場合（ステップＤ２４のＮＯ）、次のステップでの自身の更新処理の状態をＰs+1 かＷs+1 のいずれかにランダムに決定する（ステップＤ２６）。

以上の手順で、コーディネータ３を利用せず、全リソースが他のリソースと矛盾を起こすことなく終了手続きを行うことが可能となる。

ところで、前述した手順によれば、全体の過半数までのリソースの障害については、トランザクションのブロックが発生しない。しかし、過半数以上の障害に対しては、やはりトランザクションのブロックが発生する。この点を実質的に緩和するため、クオラムサイトを導入する例を説明する。

図１４に示すように、クオラムサイト６は、インターネット１上に配置されたサーバであって、更新処理の中身としてはなにもせず更新処理の状態遷移だけを行うリソース（状態遷移専用リソース７）を提供する。更新処理は中身がないので、実質的に更新中の状態をもたず、したがって初期状態は実質的にＷ状態である。このリソースをトランザクションに含めて本発明のコミット方式を用いることにより、上記実質的緩和を実現する。

すなわち、あるトランザクションに関係する本来のリソースの数をＮとすると、クオラムサイト６にあるリソース７をＮ−１個選び、これをこの分散トランザクションに参加させる。すると、全体のリソースの数は２Ｎ−１となり、Ｎ−１個までのリソースの障害に対してトランザクションのブロックが発生しない。したがって、クオラムサイトに障害が発生しない場合には、本来のリソースがすべて障害とならない限りトランザクションのブロックは発生せず、かならずコミットまたはアボートが決定できる。

クオラムサイトにあるＮ−１個のリソースは、１つのクオラムサイトから選んでもよいし、例えば地理的に離れた複数のサーバから選んで総和をＮ−１個としてもよい。全体として、十分な信頼性が選られるようにクオラムサイトのリソースを選択すれば、上記実質的緩和が実現する。

また、クオラムサイトを利用する場合、本発明のコミット方式を少し改変して、図１５に示すように、クオラムサイトのリソースと、コーディネータおよび本来のリソースの間での通信が、障害が発生しない通常処理において、まったく発生しないようにできる。これにより、障害がまったく発生しない場合には、クオラムサイトのリソースとはまったく通信せずにトランザクションをコミットまたはアボートできるという利点がある。クオラムサイトは本来のリソースに障害があったときに初めて実質的に使うという性質のものとなるため、１つのクオラムサイトで、数多くのトランザクションおよびリソースをまかなう事が可能である。

以下、このクオラムサイトを利用する場合の原理を詳細に説明する。なお、ここでは通信量の削減に関わる部分について説明する。

コーディネータの手順の改変として、クオラムサイト６のリソース７の更新処理は自動的にＷ状態まで遷移したとみなして、クオラムサイトのリソースとまったく通信せずに、Ｐ状態への遷移を指示するところまで進める。本来のＮ個のリソースにＰ状態への遷移を通知したところで、クオラムサイト６のリソース７にはＰ状態への遷移を指示せず、終了手続きを始める。図１６は、この場合のクオラムサイト６の状態遷移図であり、また、図１７は、この場合のコーディネータ３の動作フローである。

本発明の終了手続きの改変として、最初のステップ番号１とステップ番号２では、クオラムサイト６のリソース７との間で通信障害があたかも発生したとみなして、クオラムサイトのリソースとまったく通信せずにBen-orのアルゴリズムを進める。すると、Ben-orのアルゴリズムの性質から、本来のリソースに障害がまったく発生していない場合には、ステップ番号２が終わったところですべての本来のリソースの更新処理がコミットする。

このように、改変後の本発明のコミット手順では、障害が発生しない場合でも終了手続きを実行する事になるが、障害が発生しない場合には、ステップ番号２で必ずコミットするため、本来コミットできるはずのトランザクションがアボートしてしまうということはない。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の一実施形態に係る分散システムによる分散トランザクションを示す図 ２相コミット方式でのコーディネータ−リソース間の通信の様子を示す図 ２相コミット方式でのリソースの状態遷移を示す図 ２相コミット方式でのコーディネータの動作手順を示すフローチャート ２相コミット方式でのコーディネータと各リソースとのやり取りを示すタイミングチャート ３相コミット方式でのリソースの状態遷移を示す図 ３相コミット方式でのコーディネータの動作手順を示すフローチャート ３相コミット方式でのコーディネータと各リソースとのやり取りを示すタイミングチャート 同実施形態の分散システムの終了手続き時におけるコーディネータ−リソース間の通信の様子を示す図 同実施形態の分散システムにおけるリソースの状態遷移を示す図 同実施形態の分散システムの終了手続き時における基本フロー 同実施形態の分散システムの終了手続き時における詳細フロー（１／２） 同実施形態の分散システムの終了手続き時における詳細フロー（２／２） 同実施形態のクオラムサイトを導入した場合の分散システムを示す図 同実施形態のクオラムサイトを導入した場合の分散システムのコーディネータ−リソース間の通信の様子を示す図 同実施形態のクオラムサイトを導入した場合の分散システムにおけるリソースの状態遷移を示す図 同実施形態のクオラムサイトを導入した場合におけるコーディネータの動作手順を示すフローチャート

符号の説明

１…インターネット、２ａ〜ｃ…サーバ、３…コーディネータ、４ａ〜ｃ…リソース、５…終了手続き部、６…クオラムサイト、７…状態遷移専用リソース。

Claims (9)

1. 複数のリソースによって分散トランザクションが実行される分散システムにおいて、
   前記複数のリソースそれぞれが、
   前記分散トランザクションに関わる更新処理の状態遷移を３相コミット方式で調整するコーディネータからの指示に基づき、自身の更新処理の状態を遷移させる第１の状態遷移制御手段と、
   前記複数のリソースそれぞれの更新処理の状態を収集し、前記コーディネータからの指示によらずに、前記収集した更新処理の状態から自身の更新処理のコミットまたはアボートを決定して終了手続きを行う第２の状態遷移制御手段と
   を具備することを特徴とする分散システム。
2. 前記第２の状態遷移制御手段は、前記収集した更新処理の状態を各々の初期値として合意アルゴリズムを実行し、前記複数のリソースのうちの過半数以上での合意が得られた場合に、その合意結果に基づき、自身の更新処理のコミットまたはアボートを決定することを特徴とする請求項１記載の分散システム。
3. 前記第２の状態遷移制御手段は、前記収集した更新処理の状態の中にコミットが存在した場合、自身の更新処理のコミットを決定し、前記収集した更新処理の状態の中にアボートまたは更新中が存在した場合、自身の更新処理のアボートを決定することを特徴とする請求項１または２記載の分散システム。
4. 前記複数のリソースの総数は、２Ｎ−１個であり、この２Ｎ−１個のうちのＮ−１個のリソースは、前記分散トランザクションの実行に実質的には関係せず、中身のない自身の更新処理の状態遷移のみを行うものであることを特徴とする請求項１、２または３記載の分散システム。
5. 前記２Ｎ−１個のうちのＮ個のリソースは、前記分散トランザクションの実行に実質的に関係し、このＮ個のリソースの前記第２の状態遷移制御手段は、所定の事象が発生しない限りにおいては、前記Ｎ−１個のリソースからの更新処理の状態の収集を行わずに、前記Ｎ個のリソースより収集された更新処理の状態から自身の更新処理のコミットまたはアボートを決定することを特徴とする請求項４記載の分散システム。
6. 前記Ｎ−１個のリソースすべてが同一のコンピュータ上に存在することを特徴とする請求項４または５記載の分散システム。
7. ネットワークを介して接続される他のコンピュータと共に分散トランザクションを実行するコンピュータにおいて、
   前記分散トランザクションに関わる更新処理の状態遷移を３相コミット方式で調整するコーディネータからの指示に基づき、自身の更新処理の状態を遷移させる第１の状態遷移制御手段と、
   前記他のコンピュータそれぞれの更新処理の状態を収集し、前記コーディネータからの指示によらずに、自身の更新処理の状態と前記収集した更新処理の状態とから自身の更新処理のコミットまたはアボートを決定して終了手続きを行う第２の状態遷移制御手段と
   を具備することを特徴とするコンピュータ。
8. ネットワークを介して接続される他のコンピュータと共に分散トランザクションの実行に供されるコンピュータにおいて、
   前記分散トランザクションの実行に実質的には関係せず、中身のない自身の更新処理の状態遷移のみを実行する状態遷移制御手段を具備することを特徴とするコンピュータ。
9. 複数のリソースによって分散トランザクションが実行される分散システムの状態遷移制御方法であって、
   前記複数のリソースそれぞれが、
   前記分散トランザクションに関わる更新処理の状態遷移を３相コミット方式で調整するコーディネータからの指示に基づき、自身の更新処理の状態を遷移させ、
   前記複数のリソースそれぞれの更新処理の状態を収集し、前記コーディネータからの指示によらずに、前記収集した更新処理の状態から自身の更新処理のコミットまたはアボートを決定して終了手続きを行う
   ことを特徴とする状態遷移制御方法。

Images