JP3445797B2 - 最適化された同期化プロシージャ - Google Patents

Description

【発明の詳細な説明】 技術分野 本発明はデータ処理システムにおけるトランザクショ
ンの同期化に関するものであり、更に詳しく云えば、ト
ランザクションに参加する複数のエージェント及びその
トランザクションをコーディネートするための１つのコ
ーディネータを含むデータ処理システムにおいてそのト
ランザクションの同期化を行うための方法に関するもの
である。それらのエージェントは、それらのうちの少な
くとも１つのエージェントのセットをコーディネートす
る少なくとも１つのミドルマン（middleman）を含む。
その方法は、コミットするために使用可能か又は使用不
能かを表す意思表示（vote）をそれらのエージェントの
各々からコーディネータに送るステップ、及びすべての
意思表示が受信された時、コーディネータによるコミッ
ト又はバックアウトの判断を決定するステップを含む。

背景技術 データ処理システムでは、システム資源に対するアク
セス及び更新は、一般に、個別のトランザクション（又
は、作業単位）の実行によって行われる。トランザクシ
ョンは、変更がすべて成功する或いは全く成功しないと
いうような、システム資源に関する一連のコーディネー
トされたオペレーションである。これらのオペレーショ
ンは、一般にトランザクション処理システムにおける記
憶装置に保持されたデータに対して行われる変更であ
る。システム資源は、データベース、データ・テーブ
ル、ファイル、データ・レコード等を含む。トランザク
ションが全体として成就されるか或いは全く成就されな
いというこの特性は、原子性（atomicity）としても知
られている。

この方法では、資源は相互に不整合にならないように
される。更新オペレーションのセットの１つが失敗する
場合、他のオペレーションも成功しないであろう。そこ
で、作業単位は、必ずしも中間点すべてにおける整合性
を保存することなく、整合状態の資源を他の整合状態に
変換する。

トランザクションの原子的性質は、コミット・プロシ
ージャと一般に呼ばれているトランザクション同期化プ
ロシージャによって維持される。資源変更がトランザク
ション実行の範囲内で同期化される整合性の論理的ポイ
ントは、コミット・ポイント又は同期点と呼ばれる。ア
プリケーションは、同期ポイントを宣言することによっ
て、或いはそのアプリケーションが終了することによっ
て作業単位を終了する。

トランザクションの原子性は、そのトランザクション
の終了時に同期ポイントが宣言されるまで、そのトラン
ザクションの範囲内で行われた資源更新が未確定のまま
（コミットされないで）保持されることによって得られ
る。トランザクションが成功する場合、そのトランザク
ションの結果は恒久的なものにされる（コミットされ
る。）そのトランザクションが失敗する場合、その不成
功のトランザクションの影響はすべて除去（バックアウ
ト）される。即ち、資源更新は、成功裏に終了した時だ
けその更新を行ったアプリケーション以外のアプリケー
ションにとっても恒久的に且つ可視的にされる。各作業
単位の期間の間、すべての更新された資源は、更なる更
新アクセスを防ぐためにロックされなければならない。
それとは対照的に、トランザクションがバックアウト
（ロールバック）される時、資源は、そのトランザクシ
ョンが開始する前に存在した整合状態に回復される。

商業的に入手可能な多くの種々なトランザクション処
理システムが存在する。オンライン・トランザクション
処理システムの一例は、IBM社（インターナショナル・
ビジネス・マシーンズ・コーポレーション）によって開
発されたCICSシステムである（IBM及びCICSは、インタ
ーナショナル・ビジネス・マシーンズ・コーポレーショ
ンの商標である）。

トランザクション・オペレーションが実行される単一
ノードを含む、或いはそのようなオペレーションが如何
なるトランザクション中でも１つのノードでしか実行さ
れないようにするトランザクション・データ処理システ
ムでは、単一フェーズの同期化オペレーションによって
原子性は強化される。この点に関しては、トランザクシ
ョンが終了する時、そのノードは、単一フェーズにおい
て、変更を恒久的にすることをコミットするか或いはバ
ックアウトする。

多数のノードを包含する分散システムでは、１つのト
ランザクションがそのようなノードのうちの複数のもの
に対して変更を行わせることがある。そのようなシステ
ムでは、そのトランザクションに関与したすべてのノー
ドがそれの結果に同意する場合にだけ原子性を保証する
ことができる。簡単な例は、１つの口座から異なる銀行
における他の口座に現金振込を行うための金融アプリケ
ーションであり、クリティカルな資源に対する２つの基
本的なオペレーション（一方の口座における貸方及び他
方の口座における借方）に関連するものである。これら
のオペレーションの両方が成功するか或いは何れも成功
しないことを保証することが重要である。

分散システムは、一般に、原子性を保証するために、
２フェーズ・コミット・プロトコルと呼ばれるトランザ
クション同期化プロシージャを使用する。この点に関し
ては、トランザクションが実行ノードにおいて成功裏に
終了し、しかも、すべてのノード資源マネージャ（又
は、エージェント）がそのトランザクションに関与した
オペレーションをコミットすることをリクエストされる
ものと仮定する。そのプロトコルの第１フェーズ（準備
フェーズ）では、すべての関連のエージェントがコミッ
トする準備をするようにリクエストされる。それに応答
して、それらエージェントは、個々に、それらのオペレ
ーションをコミットすべきか或いはバックアウトすべき
かをローカルの状態に基づいて判断する。これらの判断
は、意思表示がカウントされる場所であるコーディネー
タと呼ばれる同期化ロケーションに伝送される。第２フ
ェーズ（コミット・フェーズ）では、すべてのエージェ
ントがコミットするように意思表示する場合、コミット
を望むリクエストが発生され、それに応答してすべての
エージェントがそれらのオペレーションをコミットす
る。一方、何れのエージェントもそれらのオペレーショ
ンをバックアウトするように意思表示する場合、すべて
のエージェントがそれらのオペレーションをバックアウ
トするように命令される。大量のトランザクションを持
った大型のシステムでは、その２フェーズ・コミット・
プロセスはツリー状にエージェントを構成してもよく、
その場合、エージェントのサブセットの１つが、そのサ
ブセットの意思表示をコーディネートするための及びメ
イン・コーディネータに結合された意思表示を送るため
のミドルマンとして作用する。

分散システムは、システムの障害、即ち、通信障害又
はノード障害から十分に回復可能であるように編成され
る。通信障害及び遠隔のノードにおける障害は、一般
に、１つ又は複数のノードへのメッセージの停止によっ
て明らかになる。その障害によって影響される各ノード
は、種々の機構によってそれを検出することができる。
例えば、その機構は、作業単位が事前設定の最大時間よ
りも長い間アクティブであった時、それを検出するその
ノードにおけるタイマを含む。ノード障害は、一般に、
そのノードの再始動を要求するソフトウエア障害又はそ
のノード上で走るトランザクションの優先使用に関連し
たデッドロックによるものである。

システム障害は、その作業単位に関連したノードの再
同期化を必要とする回復プロシージャによって管理され
る。ノード障害は、一般に、その結果として揮発性記憶
装置における情報の喪失を生じるので、作業単位に関連
した如何なるノードも、２フェーズ・コミット・プロト
コル時にメッセージの伝送と同期して不揮発性記憶装置
に状態変化（チェックポイント）を書き込まなければな
らない。これらのチェックポイント・データ（又は、ロ
グ・メッセージ）は、そのプロトコルが進行する時に安
定した記憶媒体に書き込まれ、ノードの障害の場合に同
じプロトコルが整合状態から再始動されることを可能に
する。これは再同期化として知られている。

米国特許第5,319,773号は、開始アプリケーションが
他のタスクを進行させることを可能にしながら、コミッ
ト・プロシージャを障害後に非同期的に再同期化する方
法を開示している。しかし、それは、分散作業単位に関
与する複数のパートナ・ノードへのコミュニケーション
の中断という問題を処理するものではない。

インターナショナル・ビジネス・マシーンズ・コーポ
レーションによって開発されたIBMシステム・ネットワ
ーク・アーキテクチャ、即ち、IBM SNA LU6.2同期点ア
ーキテクチャは、２つ又はそれ以上の保護された資源相
互間のコミットをコーディネートするものとして知られ
ている。そのLU6.2アーキテクチャは、資源コーディネ
ーション、同期点ロギング、及び回復に責任のある同期
点マネージャ（SPM）をサポートする。このアーキテク
チャにおいて使用される通信プロトコルの説明は、「LU
6.2のためのSNAピア・プロトコル（SNA Peer Protocols
for LU6.2）」（文献番号SC31−6868−１、IBM社）に
見ることができる。

ネットワークにまたがる２フェーズ・コミットのため
の既知のプロトコルによる問題は、作業単位のコーディ
ネータとの接触が失われた場合に対してそれらが十分に
対応しないことである。そのような場合、その結果がど
のようなものであるかを分散作業単位の他方のパートナ
に直ちに知らせることができない。その判断は、コーデ
ィネータとの接触が行われた後でわかるだけである。

接触が失われた場合、接触が再び行われるまで、パー
トナを永久に待ち続けさせることが可能である。それら
のパートナの各々は資源ロックを保つことができ、アプ
リケーション・コード及びユーザを長い時間待たせてお
くことが可能である。そこで、ロック、アプリケーショ
ン、及びエンド・ユーザ・スクリーンを解放するため
に、オペレータ・アクションが必要である。

この問題に対する既知の解決方法は、パートナとのコ
ミュニケーションを中断すること及びすべてのパートナ
相互間の時限再試行ループに入ることである。この従来
技術の方法に伴う幾つかの欠点がある。再試行ループは
非常に非効率的であり、特に、それらを発生する多くの
エージェントが存在するか或いはそれらが頻繁に行われ
る場合に非効率的である。更に、コミュニケーションの
中断によりオペレーション上の問題が生じことがある。

再試行ループのタイミング次第で作業単位の結果の導
出における遅れが生じ、それは資源更新処理の同時性に
おけるかなりの低下を生じさせる（特に、多くの資源が
関与する場合）。ノードの再始動時には、システムを過
負荷にする多くの再同期化タスクが存在することがあ
る。多くのコミュニケートするノードが同時に再始動さ
れる場合、デッドロックが生じることもある。

発明の開示 従来技術の上記欠点は、本発明によるミドルマンを使
用するシステムにおいて克服される。従って、本発明
は、前述のようなデータ処理システムにおけるトランザ
クションの同期化のための方法を提供する。その方法
は、障害のためにミドルマンにおいて判断が得られない
場合、コミットのために使用可能な一組のエージェント
の各々にそのミドルマンから「未知（Not Known）」判
断メッセージを送るステップ（その「未知」判断メッセ
ージは、ミドルマンにおいて判断が得られる場合、前記
使用可能なエージェントの各々の再同期化を停止させ
る）と、前記ミドルマンが再同期化の責任を持つ場合、
前記ミドルマンからその使用可能なエージェントの各々
に再同期化メッセージを送るステップ、又は前記ミドル
マンが再同期化の責任を持たない場合、前記ミドルマン
からその使用可能なエージェントの各々に「既知（Know
n）」判断メッセージを送るステップ（その「既知」判
断メッセージはその使用可能なエージェントの各々の再
同期化を始動する）とを含むことを特徴とする。

従って、パートナは何が問題であるかを詳しく知らさ
れるので、適当なアクションを取ることができる。更
に、そのセッションは解放されず、従って、パフォーマ
ンスを改善し、オペレータ・インターラクションを減少
させる。

この提案された解決方法は如何なる既存のプロトコル
に対する変更も必要なく、しかも、それは既存のシステ
ムに容易に組み込み可能であり、比較的簡単な実施を可
能にする。その解決方法は、上記引用の文献「LU6.2の
ためのSNAピア・プロトコル」においてLUタイプ6.2用の
SNAによって定義された「仮定異常終了、仮定零、及び
最終エージェント最適化（Presumed Abort,Presumed No
thing and Last Agent Optimisation）」プロトコルで
使用される。

本発明の更なる利点は、高いトランザクション速度を
サポートする分散システムの管理をそれが実用的な期間
において単純化することである。

次に、添付図面を参照して本発明の実施例を詳細に説
明することにする。

図面の簡単な説明 第１図は、本発明を実施し得るデータ処理システムの
概略図である。

第２図は、その分野で知られた２フェーズ・コミット
・プロトコルの特定のケースを示す。

第３図は、本発明の特定の実施例におけるメッセージ
・フローの概要図である。

第4a図及び第4b図は、システムの再始動に続く種々の
メッセージ・コミュニケーション・フローを示す。

第５図は、本発明の特定の実施例に従ったプロトコル
のルールを説明する概略的フローチャートである。

第６図は、メッセージの間のレース状態を示す図であ
る。

発明を実施するための最良の形態 図面、特に、第１図を参照すると、本発明を実施する
ために利用し得るデータ処理システムの概略図が示され
る。汎用アーキテクチャ100は、５つのノードより成る
分散データ処理システムを示す。アプリケーション・ノ
ード110には、例えば、IBM社から得られるCICSのような
トランザクション・ベースのアプリケーションプログラ
ムを実行するIBM Enterprise System/9000、即ち、ES
/9000のようなメインフレーム・コンピュータがある（E
nterprise System/9000及びES/9000は、インターナシ
ョナル・ビジネス・マシーンズ・コーポレーションの商
標である）。ノード110は、揮発性メモリ（即ち、RAM）
112、及び２フェーズ・コミット（PC）プロトコルに関
する情報を記憶するために使用される不揮発性メモリ11
4、一般には、ダイレクト・アクセス記憶装置（即ち、D
ASD）を含む。その不揮発性メモリ114に記憶された情報
は恒久的である。即ち、それは、ノード障害の場合に喪
失されるが、そのノードが再始動された後にはアクセス
可能である。対照的に、揮発性メモリ112に記憶された
情報はノード障害の場合に喪失される。アプリケーショ
ン・ノード110は複数のローカル資源をアクセスし、例
えば、データベース管理システムによってデータベース
（即ち、DB）116をアクセスし、及びダイレクト・アク
セス記憶装置114上の複数のファイルをアクセスする。
アプリケーション・ノード110は、データ通信機構によ
って同様の構成のノード120、130、140、及び150とコミ
ュニケートすることを可能にされる。アプリケーション
・ノード110において実行されるトランザクション・ベ
ースのアプリケーション・プログラムは、例えば、6.2
アーキテクチャ拡張機能において実施される対等通信プ
ロトコルによって、システム・ネットワーク・アーキテ
クチャ（SNA）のような標準的なシステム・インターフ
ェースを介して他のノードにおける資源をアクセスする
ことを可能にされる。ノード120はミドルマンとして作
用し、アプリケーション・ノード110がノード130及び14
0における資源をアクセスすることを可能にする。

次に、第２図を参照すると、その分野で知られた２フ
ェーズ・コミット・プロトコルの特定のケースが示され
る。そのプロトコルの２つのフェーズは、システムがそ
れらの作業をバックアウトするために又はコミットする
ためにアクションを取る準備をする時の意思表示フェー
ズ、及び判断がブロードキャストされる時のコミット・
フェーズである。最終的な判断は、コーディネータとし
て知られたそれらのノードの１つのよって行われる。

第２図は、ミドルマン210を介してコーディネータ205
とコミュニケートするエージェント215を示す。作業単
位はノード205−210間及びノード210−215間に２つの会
話を確立することによって管理される。第１ノード及び
第２ノードの間の各会話は、２つのノード相互間のコミ
ュニケーション・セッションの設定を必要とする。同期
点プロトコル中にセッションが失敗する場合、各ノード
はメッセージを再伝送するために又はメッセージの再伝
送を要請するために他のノードと接触しようとするの
で、各ノード相互間の２つのセッションが同時に使用可
能である。そこで、その作業単位の一部としての資源に
対する変更がユーザ・プロセスによって遂行される。ユ
ーザ・データは、ユーザ・データ・メッセージを介して
その作業単位に関連のノード相互間で交換される。その
作業単位及び関連の２フェーズ・コミット同期化時に、
各ノードは状態変更に関する情報をそれの揮発性メモリ
に記憶する。チェックポイントにおいて、この状態変更
情報は、ノードが障害から回復することを可能にするよ
うに不揮発性メモリに対して更に強制される。

ノードは、同期点が期限であることを所定の計画に従
って決定し、そしてそのプロトコルが開始されなければ
ならないことをそれらノードの１つが同期点マネージャ
に信号するまで、データ・メッセージを交換する。コー
ディネータ205は、ミドルマン210に準備メッセージ220
を送ることによって２フェーズ・コミット同期化を始動
する。ミドルマン210はノード205との会話ではエージェ
ントとして作用し、ノード215との会話ではコーディネ
ータとして作用する。従って、ミドルマン210は準備メ
ッセージ225をエージェント215に送る。

ローカルの状態に基づいて、エージェント215は、そ
れのオペレーションをコミットするか或いはバックアウ
トするかを決定する。図示の例では、エージェント215
はコミットすることを決定し、意思表示「イエス」メッ
セージ230をミドルマン210に送る。エージェント215が
その作業単位の結果についてそれのパートナからの連絡
を待っている間、それは「未確定」状態にある。ミドル
マン210（ノード215に対するコーディネータとして作用
する）はコミットすることを決定し、意思表示「イエ
ス」メッセージ235をコーディネータ205に送り、それ自
身は「未確定」になる。

コミュニケーションが何れかのステージで中断される
場合、プロトコルは再同期化フェーズに入る。再同期化
時に接触を再確立する責任は、そのプロトコルにおいて
定義されたようにコミュニケーション・パートナの一方
（又は、時には両方）に依存する。第２図に示された例
では、コーディネータとのコミュニケーションは、判断
240がミドルマン210において受信される前に失われる。
そこで、ミドルマン210は、それがエージェント215から
の再同期化に応答して、コーディネータ205に対するそ
れ自身のコミュニケーションが再確立されるまで、エー
ジェント215とのコミュニケーションを中断し続ける。

次に、第３図を参照すると、本発明の特定の実施例に
おけるメッセージ・フロー・コミュニケーションの概要
図が示される。第３図は、コーディネータ205、ミドル
マン210、及びエージェント215を有するシステムを特徴
とする。コーディネータとの接触が失われたこと或いは
それが再確立されたことをコミュニケートするためのフ
ローが定義される。図示の例では、ノード205−210間又
はノード210−215間の２つの会話が設定され、しかる
後、作業単位の一部としての資源に対する変更が、ノー
ド相互間で交換されるユーザ・データ・メッセージを通
してユーザ・プロセスによって遂行される。状態変更が
各ノードにおいてそれの揮発性メモリに記憶され、更
に、ノードが障害から回復することを可能にするように
不揮発性記憶装置に対してチェックポイントが強制され
る。

コーディネータ205は、ミドルマン210に準備メッセー
ジ220を送ることによって２フェーズ・コミットを始動
する。一方、ミドルマン210は、ノード205との会話に対
するエージェントとして及びノード215との会話に対す
るコーディネータとして作用して準備メッセージ225を
エージェント215に送る。

エージェント215が作業単位をコミットすることを決
定する場合、それは意思表示「イエス」メッセージ230
をミドルマン210に送り、「未確定」になる。一方、ミ
ドルマン210は（ノード215に対するコーディネータとし
て作用して）コミットすることを決定し、意思表示「イ
エス」メッセージ235をコーディネータ205に送り、「未
確定」になる。

意思表示「イエス」メッセージ235がコーディネータ2
05に送られた後且つ判断330がミドルマン210において受
信される前の２フェーズ・コミット同期化中、コミュニ
ケーションは失われる。エージェント215とのコミュニ
ケーションを中断する代わりに、ミドルマン210は「未
知」判断メッセージ（Decision Not Known）310をエー
ジェント215に送り、判断が得られないという事実をコ
ミュニケートする。そこで、ミドルマン210は、コーデ
ィネータ205とのコミュニケーションが回復されるまで
待機する。この「未知」メッセージは、判断が知らされ
るまで、エージェント215に再同期化を抑止させる。一
方、それは、作業単位において修正された如何なる資源
に関するロックも保持し続けなければならない。従っ
て、エージェント215は、なにが問題であるか及び何故
それが待機しているのかを詳しく知らされる。更に、そ
のセッションは解放されず、従って、パフォーマンスは
改善され、オペレータ・インターラクションを減少す
る。

コーディネータ205とミドルマン210との間のコミュニ
ケーションが回復される時、ミドルマン210は再同期化
メッセージ320をコーディネータ205に送り、しかる後、
作業単位に関する判断メッセージ330を受信する。その
判断はミドルマン210において得られるので、ミドルマ
ン210は「既知」判断メッセージ（Decision Known）340
をエージェント215送り、その判断が得られたこと（判
断そのものではないけれども）をコミュニケートする。
そこで、エージェント215は、再同期化シーケンスを始
動して再同期化メッセージ350をミドルマン210に送り、
判断メッセージ360をミドルマン210から受け取る。この
提案された解決方法は如何なる既存のプロトコルに対し
ても変更を必要とせず、しかも、それは既存のシステム
に容易に組み込み可能であり、比較的簡単な実施方法を
可能にすることに注意して欲しい。

その分野で知られたコミュニケーション・プロトコル
では、情報は、そのプロトコルの進行及び行われる判断
をレコードするために不揮発性記憶媒体に固定化され
る。システム障害の場合、この情報はシステムの状態を
回復させるために使用される。本発明の実施例によれ
ば、その解決方法と関連したメッセージ（「未知」判
断）に関する情報は不揮発性媒体上にレコードされない
ことが望ましい。情報を固定化するための既存のルール
がそのような最適化によって複雑にされるので、これは
望ましい特徴である。

第4a図は、システムの再始動に続く第１のメッセージ
・コミュニケーション・フローを示す。それは、その再
始動前に存在した状態を回復するために使用される。図
示の例では、ミドルマン210は、「未知」判断メッセー
ジ310をエージェント215に送った後に障害を生じた。ミ
ドルマン210はその「未知」判断メッセージに関するチ
ェックポイント情報を不揮発性記憶装置に強制しないの
で、ミドルマン210の障害はその結果としてこの情報の
喪失を生じる。ミドルマン210の再始動に続いて、再始
動メッセージ410がエージェント215に送られる。エージ
ェント215が「未知」判断メッセージ310を前に受信して
いたために再同期化を抑止していた場合、それは、再同
期化メッセージ420をミドルマン210に送ることによって
それを試みる。その判断がミドルマン210において依然
として未知である場合、新たな「未知」判断メッセージ
430が送られ、その障害前に存在した関係が再確立され
る。

第4b図は、同じシステムの別の再始動に続く第２のメ
ッセージ・コミュニケーション・フローを示す。図示の
例では、エージェント215は、ミドルマン210から「未
知」判断メッセージ310を受信した後に障害を生じた。
エージェント215はその「未知」判断メッセージに関連
したチェックポイント情報を不揮発性記憶装置に強制し
ないので、そのエージェント215の障害もプロトコルに
関する揮発性情報を喪失させる。この場合、「未知」判
断メッセージ310の受信という知識は喪失される。この
情報は、ミドルマン210との再同期化を試みることによ
って、エージェント215の再始動に続いて回復される。
その場合、再同期化メッセージ440がエージェント215に
よってミドルマン210に送られる。その判断がミドルマ
ン210において依然として未知である場合、新たな「未
知」判断メッセージ450がエージェント215に送られるで
あろう。これは、障害前に存在した状況を再確立する。

次に、一般的なケースを参照すると、２つのコミュニ
ケーション・ノードのうちの１つ又は両方が障害に続い
て再同期化を始動する責任を持つことがある。それらの
うちのどちらに責任があるかは、それら２つのノードの
間の一致したプロトコル、そのシステムが障害を生じる
前に到達した位置、及びそれらのパートナのうちの責任
のある一方を助けることができるコーディネータによっ
て行われた判断に依存する。本発明は、LUタイプ6.2の
ためのSNAによって定義された「仮定異常終了、仮定
零、及び最終エージェント最適化」プロトコルにおいて
動作可能である。しかし、それが２フェーズ・コミット
のための種々のプロトコルにおいて使用可能であること
は、当業者には明らかであろう。

第５図には、本発明の特定の実施例に従ってプロトコ
ルのルールを説明した概略的フローチャートが示され
る。ブロック510を参照すると、そのシステムにおける
すべての関連するエージェントがコミットする準備をす
るようにリクエストされる。それに応答して、エージェ
ントは、それらのオペレーションをコミットすべきか或
いはバックアウトすべきかを、ローカル状態に基づいて
個々に判断する。そこで、それらの判断がコーディネー
タにコミュニケートされる。即ち、それらエージェント
の各々は意思表示を送って、作業単位をコミットするた
めにそれが使用可能であること（意思表示「イエス」）
又は利用不能であること（意思表示「ノー」）を表す。

ブロック520において、エージェントから受信された
意思表示に基づいた判断がコーディネータによって行わ
れる。すべてのエージェントがコミットするという意思
表示をする場合、コミットするためのリクエストが発生
される。一方、何れのエージェントもそれのオペレーシ
ョンをバックアウトするという意思表示をする場合、す
べてのエージェントが、それらのオペレーションをバッ
クアウトするように命令される。

しかる後、ブロック530において、最終判断がコーデ
ィネータによってすべての関連エージェントにブロード
キャストされる。

次に、ブロック540を参照すると、提案された解決方
法のルールは、意思表示「イエス」メッセージに対する
応答が「未知」判断メッセージであることを必要とす
る。これは、その判断がミドルマンにおいて得られる前
にそのコーディネータとのコミュニケーションが失われ
る時に生じる。

「未知」判断メッセージが送られ、その後、その判断
が使用可能になった時、プロセスはブロック550に進
む。

ミドルマンが既存のプロトコルにおける再同期化の責
任を有する場合、制御フローはブロック550に進み、そ
こでは、再同期化メッセージがパートナに送られる。

ミドルマンが再同期化の責任を持たない場合、ブロッ
ク570において、「既知」判断メッセージがパートナに
送られる。

「既知」判断メッセージの受信時に、ブロック580に
示されるように、エージェントは、再同期化メッセージ
を送ることによって再同期化を始動する。

ノードが障害を生じて揮発性情報を失う場合、それは
その事実をそれのパートナにコミュニケートしなければ
ならない。又、それは、既存のプロトコルに関して、未
決の作業単位に対して再同期化を試みなければならな
い。再始動メッセージを受信した時、「未知」判断メッ
セージによって抑止された未決の再同期化が再試行され
る。再同期化メッセージに対する応答は、その判断が未
だ得られない場合、「未知」判断となり得る。本発明は
不揮発性媒体に情報を固定化するための既存のプロトコ
ルにおける変更を必要としないということは注目すべき
ことである。すべての情報が揮発性記憶装置に保持さ
れ、そしてそのシステムが再始動される場合にリフレッ
シュされる。従って、この解決方法は比較的簡単な実施
を可能にする。

第６図を参照すると、メッセージ相互間のレース状態
が示される。ケース（ａ）では、「未知」判断メッセー
ジ610と「既知」判断メッセージ620との間のレース状態
が示される。明らかに、後者は前者の前に送られること
はないが、それらのメッセージは非論理的順序でレシー
バに到達し得る。「未知」判断メッセージ610は送られ
るが、直ちには受信されない。しかる後、「既知」判断
メッセージ620が送られる。第６図に示されたケース
（ａ）では、この「既知」判断メッセージ620は「未
知」判断メッセージ610よりも速く伝播し、その結果、
それは早く送られた「未知」判断メッセージ610よりも
前に受信される。「既知」判断メッセージ620の受信の
後、「未知」判断メッセージ610が受信される。その受
信側は、「未知」判断メッセージ610が順序どおりでな
く現れる場合、そのメッセージを無視できなければなら
ない。ケース（ｂ）では、「未知」判断メッセージ630
と再同期化メッセージ640との間の同様な状態が示され
る。

その分野で知られたプロトコルでは、再同期化の処理
はコミュニケーション・セッションの中断を生じさせる
ことがある。その中断において、受動的なパートナは、
それが責任を有し且つ厳格な再試行ループを防ぐために
その中断の開始前の待機期間が要求される場合、その処
理を再試行しなければならない。この期間はミドルマン
によって制御され、多少は任意の長さのもの、一般的に
は、再試行の頻度と究極的な再同期化の時機との間の妥
協的なものである。この処理のブロッキングが起こり得
るということは、再同期化タスクが並列に実行可能でな
ければならないことを意味する。ノードの再始動時に
は、それを過負荷にし得る多くのそのようなタスクが存
在することがある。数多くのコミュニケートするノード
が同時に再始動される場合、デッドロックが生じ得る。
本発明は、再同期化においてブロッキングが生じ得ない
ことを保証する。一連の実行によって再同期化を順次に
処理することが可能である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ノーミントン、グライン イギリス国ハンプシャー、ウインチェス ター、コレイ・クロス 18 (72)発明者 ツイマー、デニス・ジャック イギリス国ハンプシャー、チャンドラー ズ・フォード、クイーンズ・ロード 17 (72)発明者 ラプトン、ピータ、ジェイムス イギリス国ハンプシャー、チャンドラー ズ・フォード、バッデズレイ・ロード 38 (56)参考文献 特開 平６−259397（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00

Claims (13)

(57)【特許請求の範囲】
1. 【請求項１】トランザクションに参加する複数のエージ
   ェント（120−150）及び前記トランザクションをコーデ
   ィネートするためのコーディネータ（110）を含むデー
   タ処理システム（100）において前記トランザクション
   の同期化を行うための方法にして、前記エージェント
   （120−150）はサブセットのエージェント（130、140）
   をコーディネートする少なくとも１つのミドルマン（12
   0）を含み、 前記方法は、 コミットするために使用可能であるか又は使用不能であ
   るかを表す意思表示を前記サブセットのエージェント
   （130、140）の各々から前記ミドルマン（120）に送る
   ステップ（510）と、 コミットするために使用可能であるか又は使用不能であ
   るかを表す意思表示を前記ミドルマン（120）および前
   記サブセット以外のエージェントから前記コーディネー
   タ（110）に送るステップ（510）と、 前記意思表示がすべて受信されたとき、前記コーディネ
   ータ（110）によりコミット又はバックアウトの決定を
   するステップ（520）と、 前記決定を前記コーディネータ（110）から前記ミドル
   マン（120）および前記サブセット以外のエージェント
   に、そして前記ミドルマン（120）から前記サブセット
   のエージェントに通信するステップと、 前記コーディネータ（110）と前記ミドルマン（120）と
   の間の接触が失われたことに応答して、前記コーディネ
   ータ（110）と前記ミドルマン（120）との間および前記
   サブセットのエージェントと前記ミドルマンとの間で再
   同期化開始メッセージを送信して再同期状態になるよう
   試みるステップと、 前記接触が失われたことにより前記決定が前記ミドルマ
   ンに得られなかったとき、前記サブセットのエージェン
   トから前記ミドルマンへの再同期化開始メッセージの送
   信を禁止するステップと、 前記ミドルマンに前記決定が得られたとき、前記サブセ
   ットのエージェントから前記ミドルマンへ再同期化開始
   メッセージの送信を行わせるステップと、 を含むことを特徴とする方法。
2. 【請求項２】前記禁止するステップは、前記ミドルマン
   から前記サブセットのエージェントの各々に「未知」決
   定メッセージを送ることを含む請求の範囲第１項に記載
   の方法。
3. 【請求項３】前記再同期化開始メッセージの送信を行わ
   せるステップは、前記サブセットのエージェントの各々
   に「既知」決定メッセージを送ることを含み、前記「既
   知」決定メッセージが前記サブセットのエージェントの
   少なくとも１つに再同期化開始メッセージを前記ミドル
   マンに送らせることを特徴とする請求の範囲第２項に記
   載の方法。
4. 【請求項４】「既知」決定メッセージを受け取った後
   は、前記サブセットのエージェントの１つにより受け取
   られる「未知」決定メッセージを無視するステップを含
   む請求の範囲第３項に記載の方法。
5. 【請求項５】前記「未知」決定メッセージに関する情報
   は、前記サブセットのエージェントの各々における揮発
   性メモリにのみ格納されることを特徴とする請求の範囲
   第２項に記載の方法。
6. 【請求項６】前記ミドルマンの障害から再始動した後、
   前記サブセットのエージェントの各々に再始動メッセー
   ジを送るステップと、 前記サブセットのエージェントの各々から前記ミドルマ
   ンに更なる再同期化開始メッセージを送るステップと、 前記ミドルマンで前記決定が得られないとき、前記ミド
   ルマンから前記サブセットのエージェントの各々に更な
   る「未知」決定メッセージを送るステップと、を含む、
   請求の範囲第２項に記載の方法。
7. 【請求項７】トランザクションに参加する複数のエージ
   ェント（120−150）であって、サブセットのエージェン
   ト（130、140）をコーディネートする少なくとも１つの
   ミドルマン（120）を含むものと、 前記トランザクションをコーディネートするコーディネ
   ータと、 コミットするために使用可能であるか又は使用不能であ
   るかを表す意思表示を前記サブセットのエージェント
   （130、140）の各々から前記ミドルマン（120）に送る
   手段と、 コミットするために使用可能であるか又は使用不能であ
   るかを表す意思表示を前記ミドルマン（120）および前
   記サブセット以外のエージェントから前記コーディネー
   タ（110）に送る手段と、 前記意思表示がすべて受信されたとき、前記コーディネ
   ータ（110）によりコミット又はバックアウトの決定を
   する手段と、 前記決定を前記コーディネータ（110）から前記ミドル
   マン（120）および前記サブセット以外のエージェント
   に、そして前記ミドルマン（120）から前記サブセット
   のエージェントに通信する手段と、 前記コーディネータ（110）と前記ミドルマン（120）と
   の間の接触が失われたことに応答して、前記コーディネ
   ータ（110）と前記ミドルマン（120）との間および前記
   サブセットのエージェントと前記ミドルマンとの間で再
   同期化開始メッセージを送信して前記コーディネータ、
   前記ミドルマン及び前記エージェントに再同期状態にな
   るよう試みさせる手段と、 前記接触が失われたことにより前記決定が前記ミドルマ
   ンに得られなかったとき、前記サブセットのエージェン
   トから前記ミドルマンへの再同期化開始メッセージの送
   信を禁止する手段と、 前記ミドルマンに前記決定が得られたとき、前記サブセ
   ットのエージェントから前記ミドルマンへ再同期化開始
   メッセージの送信を行わせる手段と、 を含むことを特徴とする分散データ処理システム。
8. 【請求項８】前記禁止する手段は、前記ミドルマンから
   前記サブセットのエージェントの各々に「未知」決定メ
   ッセージを送り、前記「未知」決定メッセージの受信に
   より前記再同期化開始メッセージを禁止するように動作
   することを特徴とする請求の範囲第７項に記載のシステ
   ム。
9. 【請求項９】前記再同期化開始メッセージの送信を行わ
   せる手段は、前記サブセットのエージェントの各々に
   「既知」決定メッセージを送り、前記「既知」決定メッ
   セージに応答して前記サブセットのエージェントの少な
   くとも１つが再同期化開始メッセージを前記ミドルマン
   に送ることを特徴とする請求の範囲第８項に記載のシス
   テム。
10. 【請求項１０】「既知」決定メッセージを受け取った後
    は、前記サブセットのエージェントの１つにより受け取
    られる「未知」決定メッセージを無視する手段を含む請
    求の範囲第９項に記載のシステム。
11. 【請求項１１】再同期化開始メッセージを受け取った後
    は、前記サブセットのエージェントの１つにより受け取
    られる「未知」決定メッセージを無視する手段を含む請
    求の範囲第８項に記載のシステム。
12. 【請求項１２】前記「未知」決定メッセージに関する情
    報を格納する揮発性メモリを前記サブセットのエージェ
    ントの各々に有することを特徴とする請求の範囲第８項
    に記載のシステム。
13. 【請求項１３】前記ミドルマンの障害から再始動した
    後、前記ミドルマンから前記サブセットのエージェント
    の各々に再始動メッセージを送る手段と、 前記サブセットのエージェントの各々から前記ミドルマ
    ンに更なる再同期化開始メッセージを送る手段と、 前記ミドルマンで前記決定が得られないとき、前記ミド
    ルマンから前記サブセットのエージェントの各々に更な
    る「未知」決定メッセージを送る手段と、を含む、請求
    の範囲第８項に記載のシステム。