JP3790589B2 - 分散データベーストランザクションのコミットメント方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、一般的には分散データベーストランザクションのためのコミットメントプロトコルに関し、より詳しく述べれば、コーディネータが関係者と定期的にメッセージを交換するようなコミットメントプロトコルに関する。
【０００２】
【従来の技術】
どのようなデータベースシステムでも、その基本的な設計の目標は「一貫性」であり、これはデータベース内に格納されている情報を若干の制約に従わせることを意味する。例えば、預金勘定から小切手勘定へ金銭を振替える場合、２つの勘定の合計を同一に保たなければならない。もし預金勘定に借方には記入したが小切手勘定の貸方に記入しなければ顧客は不満を抱くであろう。一方、もし小切手勘定の貸方には記入したが預金勘定の借方に記入しなければ銀行が不満であろう。
操作処理( operation ) とは、例えばデータベース内の情報の単片の改訂、削除、または挿入のような変更のことである。トランザクション( transaction ) とは、データベースアプリケーション内で単一の論理動作を遂行する操作処理の集まりのことである。例えば、勘定振替を行うことはトランザクションである。預金勘定の借方に記入することは勘定振替トランザクションにおける１つの操作処理であり、小切手勘定の貸方に記入することは別の操作処理である。一貫性を保存するためには、あるトランザクションの全ての操作処理が遂行されなければならないか、または何も遂行しないことである。この要求を、「アトミシティ」( atomicity ) と呼ぶ。
【０００３】
通常の状態の下では、トランザクションの全ての操作処理を遂行するだけで、課せられた制約はデータベースシステムによって遵守される。しかしながら、ソフトウェアのバグ、ハードウェアのクラッシュ、及び停電は、データベースシステムに障害を発生させる。障害が発生すると、例えばランダムアクセスメモリ（ＲＡＭ）のような揮発性メモリ内の情報が失われ、一貫性が損なわれる可能性がある。例えば、銀行データベースシステムにおいて、預金勘定の借方には記入したが、小切手勘定の貸方に記入する前にクラッシュが発生するかも知れない。従って、データベースシステムの設計上の別の目標は、障害から復旧した時に揮発性メモリ内に格納した情報を復元する能力である。
たとえ障害が発生したとしても一貫性を保証するようにするために、データベースシステムがトランザクションの全ての操作処理を実行するのか、または全く実行しないのかを保証することはクリティカルである。ある場合にはトランザクションが一貫性を損なわせたことが原因でそのトランザクションを完了させることができず、またある場合には障害が原因でトランザクションを完了させることができない。ある場合には、ユーザが変心して、トランザクションを完了させないことを決定するかも知れない。もしトランザクションを成功裏に完了させることができずに若干の操作処理しか実行されなければ、そのトランザクションは「打切り」にしなければならない。打切られたトランザクションの後に、データベースはそのトランザクションを前の状態に「ロールバック」即ち復元される。
【０００４】
一方、もし障害が起こっても、トランザクションの全ての操作処理を成功裏に実行することができれば、そのトランザクションは「コミット」される。もし障害が発生して若干の操作処理だけが実行されれば、コンピュータが復旧した時、コミットされたトランザクションは「ロールフォワード」即ち完了され、打切られたトランザクションは「ロールバック」即ち元に戻される。
換言すれば、もしコンピュータが障害の後に復旧すれば、コミットされたトランザクションはデータベース内に格納されていることが保証され、コミットされなかったトランザクションはデータベース内に格納されていることは保証されない。
全ての操作処理要求を保証する、または保証しない一つの方法は、データベースシステムに「コミットメントプロトコル」を課すことである。要約すれば、コミットメントプロトコルは、例えばハードディスクのような非揮発性記憶装置内にトランザクションログを維持することを要求する。トランザクションログは、そのトランザクションをロールバック、または完了させるのに十分な情報を含むログ記録のリストである。ログ記録は、各トランザクションの始まりに関するデータ、そのトランザクションによって変更された記録の古い値と新しい値、及びそのトランザクションがコミットされたのか、または打切られたのかの情報を含む。
【０００５】
データベースの変化が非揮発性記憶装置に書き込まれた後に、打切りが発生するかも知れない。このような場合、打切られたものとしてマークされたトランザクションは、変更された記録を古い値にセットすることによって元に戻される。例えば、銀行データベースシステムが、改訂された小切手勘定の残高( balance ) をハードディスクに書き込んだが、借方が預金勘定の残高を０以下に減らすことになるかも知れない。データベースシステムは、トランザクションログに打切りを書き込み、小切手勘定の残高を古い値に戻す。
コミットメントの後ではあるが、変化が非揮発性記憶装置へ書き込まれる前に障害が発生するかもしれない。このような場合、トランザクションログ内にコミット済みとしてマークされているトランザクションは、古い記録を新しい値にセットすることによってやり直される。例えば、銀行データベースシステムは、ＲＡＭ内の小切手及び預金勘定の残高を成功裏に改訂して検査し、トランザクションログのコミットメントをディスク上に書き込むが、ＲＡＭ内の変化をディスクへ格納する前に停電になることがあるかも知れない。データベースシステムが復旧した時に、データベースシステムはトランザクションログを探索して勘定振替トランザクションがコミットされていることを決定し、借方・貸方操作処理をやり直す。
【０００６】
分散データベースとは、記録がコンピュータネットワーク内の異なる幾つかのコンピュータまたはノードに格納されているような、または記録を格納しているコンピュータまたはノード以外のコンピュータまたはノードから記録を改訂する要求が発せられるようなデータベースのことである。例えば、小切手勘定記録を第１のコンピュータが格納し、預金勘定記録を第２のコンピュータが格納し、そして銀行の金銭出納係が使用する第３のコンピュータから預金勘定から小切手勘定への資金の振替要求を発することができる。例えば、ローカルに格納されている情報を変更するために、ある操作処理を実行することによってそのトランザクションに関与する全てのコンピュータを「関係者」( participant ) と呼ぶ。トランザクションを発した関係者をそのトランザクションの「オーナー」( owner ) と呼ぶ。
【０００７】
「コンピュータネットワーク」は、高速ノード間に接続を有している複数の処理ノードからなる（並列コンピュータのような）単一のコンピュータであることができる。「コンピュータネットワーク」は相互接続されたコンピュータのクラスタであることもできる。本明細書においては、これら各種コンピュータシステムをコンピュータネットワークであるとし、これらのシステム上のデータベースを分散データベースシステムと呼ぶことにする。
分散データベースプログラムとインタラクトする銀行の出納係のような人を「ユーザ」と呼ぶ。ユーザは、データベースプログラムにおいては、各トランザクション毎の１またはそれ以上の「セッション」によって表される。セッションとは、データベース記録の改訂のようなトランザクションの実際の仕事を行うために作成されるプログラムエンティティのことである。通常は、トランザクションの各関係者には、トランザクション当たり１セッションが存在する。オーナー上で走るセッションが「トランザクションオーナー」である。他のセッションを「トランザクションヘルパー」( helper )と呼ぶことができる。
【０００８】
障害の影響は、分散データベースシステムと単一コンピュータシステムとでは若干異なる。単一コンピュータシステムにおいては、システムが動作してトランザクションが正常に処理されているか、またはシステムが障害を起こしてトランザクションを処理できないかの何れかである。分散システムにおいては、若干のコンピュータは動作しているが、他のコンピュータは動作していないような部分的障害が存在し得る。また、コンピュータは動作しているが、コンピュータ間の通信リンクが故障しているような部分的障害も存在し得る。
分散データベースシステムの一つの主要な利点は、性能が改善されることである。別の主要な利点は拡張可能性（スケーラビリティ）、即ち性能を劣化させることなくデータベースシステムを成長させ得る能力である。別の利点は、信頼性が改善されることである。普通は部分的障害しか発生しないから、データベースシステムの性能が低下することはない。しかしながら、部分的障害が発生する可能性があるということは、一貫性の保証を一層困難にする。例えば、預金勘定記録を有するコンピュータが正常に機能していて借方から控除しているが、小切手勘定記録を有するコンピュータが故障して貸方に加算しないかも知れない。
【０００９】
一貫性を保存するために、この例における２つのコンピュータは互いに通信し合って振替トランザクションをコミットすべきか、または打切るべきかを決定しなければならない。そのトランザクションに関与する全てのコンピュータが同一の行動（コミットまたは打切り）を行うことを保証するコンピュータ間の通信の構造及び方法を、「コミットメントプロトコル」と呼ぶ。
分散データベーストランザクションのための現在の標準コミットメントプロトコルを「２相コミット（２ＰＣ）プロトコル」と呼んでいる。２相コミットプロトコルは、概ね次のように動作する。
第１に、「コミット可」相において、トランザクションオーナーはコミットのための準備メッセージを各関係者へ送り、コミットか、打切りかを投票で応答するように各関係者に依頼する。各関係者は、そのトランザクションのコミット、または打切りの何れを望むかを決定する。
【００１０】
もし関係者がそのトランザクションをコミットすることを望めば、その関係者は、そのトランザクションがコミットメント可であることを非揮発性記憶装置内のそのローカルトランザクションログへ記録する。ローカルトランザクションログは、そのトランザクションによってなされたローカル変化の古い値及び新しい値をデータベースへ既に記録していよう。そこで関係者は“ｙｅｓ”投票をオーナーへ送り返す。
もし関係者が打切りを決定すれば、その関係者は、トランザクションの打切りを非揮発性記憶装置へ記録して“ｎｏ”投票をオーナーへ送り返す。関係者が打切りを決定する理由は数多くある。そのデータベースに課せられたある一貫性を操作処理が損なうかも知れない。例えば、もし預金勘定の借方がその預金勘定の残高を０以下に減ずるようなことがあれば、その関係者はその振替トランザクションを打切るであろう。
【００１１】
第２に、「決定」相においてオーナーは、関係者からの全ての投票を集める。もし全ての関係者の投票が“ｙｅｓ”であれば、オーナーはそのトランザクションのコミットを非揮発性記憶装置内のトランザクションログ内に記録する。この点でそのトランザクションはコミットされる。次いでオーナーは各関係者へメッセージを送ってそのトランザクションをコミットさせる。
もし何れかの関係者が“ｎｏ”を投票すれば、オーナーはそのトランザクションの打切りを非揮発性記憶装置へ記録し、各関係者へメッセージを送ってそのトランザクションを打切らせる。コミット可であることを非揮発性記憶装置内へ記録した各関係者は、行動を起こすために、オーナーからのコミットメッセージ、または打切りメッセージを待つ。
【００１２】
不幸にも、２相コミットはメッセージ重視プロトコルである。詳しく説明すれば、個々のトランザクション毎に１組のメッセージを交換し、コミットメッセージに対して特別に準備するので大量のネットワークトラフィックを作り出す。２相コミットでは、コミットメントネットワークを通して送られるメッセージの数は、トランザクションの数及び各トランザクションの関係者の数に比例する。多数の小さいトランザクションを有するシステムの場合には、２相コミットがネットワークに大きい負担をかけ得る。
【００１３】
【発明の目的】
以上に鑑みて、本発明の目的は、ネットワークの使用を最小にする分散データベースコミットメントプロトコルを提供することである。
本発明の別の目的は、殆どの動作条件の下で２相コミットよりも優れている分散データベースコミットメントプロトコルを提供することである。
本発明の他の目的及び長所は以下の説明から理解されよう。本発明の目的及び長所は、特に特許請求の範囲に指摘されている手法及び組合わせによって実現できる。
【００１４】
【発明の概要】
本発明は、分散データベースシステム内に分散したトランザクションをコミットする方法を目指している。データベースシステムは、インタバルコーディネータ、複数のコサーバ( coserver )、及び少なくとも１つのトランザクションログを含む。インタバルコーディネータは一連のインタバルメッセージを各コサーバへ送り、各コサーバはそれに応答してその関連トランザクションログを非揮発性記憶装置へフラッシュする。トランザクションログをフラッシュした後に、各コサーバは閉止メッセージをインタバルコーディネータへ伝送する。コサーバは、最も新しく受信したインタバルメッセージを識別する状態を維持する。各分散トランザクションは、オーナー及びヘルパーを関連コサーバと共に含む。あるトランザクションに関して、オーナーは、関連コサーバに実行させる分散したトランザクションの操作処理を識別する要求メッセージをヘルパーへ伝送する。操作処理を実行したコサーバは、最も新しく受信したインタバルメッセージを識別するタグと共に、完了メッセージをオーナーへ伝送する。この完了メッセージを受信した後、オーナーはそのトランザクションについての適格性メッセージをインタバルコーディネータへ伝送する。次いでインタバルコーディネータは、そのトランザクションについてのコミット状態を安定な記憶装置へ書き込む。コミット状態を安定な記憶装置へ書き込んだ後に、インタバルコーディネータは、そのトランザクションについてのコミットメッセージをオーナー及びヘルパーへ送る。
【００１５】
以下に添付図面を参照して本発明の好ましい実施例を説明する。
【００１６】
【実施例】
図１に示すように、分散データベースはコンピュータネットワーク１０上で動作する。コンピュータネットワーク１０は、ネットワークライン１４によって接続されたワークステーションのような複数のコンピュータ１２ａ−１２ｇを含んでいる。勿論、ネットワーク１０は図示の７つのコンピュータよりも少ない、または多いコンピュータを有することができる。ネットワーク１０は、サーバ１６及びプリンタ１８のような他のデバイスをも含んでいる。増殖的に相互接続されるように図示されているが、コンピュータネットワーク１０は環状、星形、樹木、または他のどのような相互接続トポロジを使用することもできる。コンピュータネットワーク１０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、クラスタ相互接続、または相互接続スイッチを通して通信する複数の処理ノードを有する単一のコンピュータであることができる。高性能デバイスシステムの場合には、ネットワーク１０はマルチノード並列処理コンピュータ、またはクラスタであることが好ましい。しかしながら、明瞭化のために、以下のデータベースシステム５はＬＡＮネットワークとして説明する。
【００１７】
コンピュータネットワーク１０の故障は不可避である。若干の故障は、ノード（コンピュータ１２ａ−１２ｇ）間の通信リンクが関連している。例えば、ネットワークライン１４が切断されることがあり得るし、またはネットワークライン１４上のメッセージの量がネットワークの容量を超えることもあり得る。他の故障は、コンピュータ１２ａ−１２ｇが関連するものである。例えば停電は、１またはそれ以上のコンピュータを停止させたり、または特定コンピュータの構成要素を誤動作させかねない。
図２に示すように、分散データベースシステム５は、分散データベースプログラム１００を備えている。データベースプログラム１００は、通信リンク１０４によって接続されているコサーバ１０２ａ−１０２ｇを含んでいる。各コサーバ１０２ａ−１０２ｇは、単一のノード上で共働するデータベースプログラムの集まりである。各コサーバは、通信リンク１０４を介して、格納、保管、データ操作、及び通信能力を提供することができる。典型的には任意の１つのコンピュータノード上では１つのコサーバしか走らないが、複数のコサーバを単一のコンピュータノード上で走らせることも可能である。更に、ネットワーク内の若干のコンピュータはコサーバをサポートしないことができる。
【００１８】
データベースネットワーク１００も故障を起こすことがあり得る。例えば、ソフトウェアにバグがあると、コサーバ１０２ｄのような特定のコサーバをクラッシュさせ得る。勿論、コサーバ１０２ａをサポートしているコンピュータ１２ａが部分的に、または完全に故障すると、データベースプログラム１００に障害がもたらされる。
図３に示すように、コンピュータネットワーク１０は、ＬＡＮのようなネットワークライン１４に接続されている１組のコンピュータとして表すことが可能である。ネットワークライン１４は制限された帯域幅容量を有している。即ち、ネットワークライン１４は、一時に制限された量の情報しか輸送することができない。例えば、もしネットワークがイーサネットであれば、典型的に 10 メガビット／秒を処理することができる。
【００１９】
コンピュータ１２ａのような各コンピュータは、少なくとも１つの中央処理ユニット（ＣＰＵ）２０ａ、メモリ２２ａ、及び記憶装置２４ａを含んでいる。メモリ２２ａは、ランダムアクセスメモリ（ＲＡＭ）のような揮発性記憶装置であり、停電の場合にはその内容は失われる。記憶装置２４ａは、１またはそれ以上のハードディスクのような非揮発性記憶装置である。クラスタ構成では、コンピュータは非揮発性記憶装置へのアクセスを共用することができる。ＣＰＵ ２０ａ、メモリ２２ａ、及び記憶装置２４ａは、バス２６ａによって相互接続されている。典型的には、ネットワークライン１４もバス２６ａを通してコンピュータ１２ａに接続されている。
図４に示すように、データベース３０は関連情報の集まりである。典型的にはデータベースは、情報を、類似情報の列（「フィールド」と呼ぶ）と、関連情報の行（「記録」と呼ぶ）とを有するテーブル内に格納する。例えば銀行は、小切手勘定及び預金勘定を監視するためにデータベース３０を使用できる。小切手勘定テーブル３２は、顧客名３４、小切手勘定番号３６、及び現在の小切手勘定残高３８を格納するフィールドを有することができる。預金勘定テーブル４２も同様に、顧客名４４、預金勘定番号４６、及び現在の預金勘定残高４８を格納するフィールドを有することができる。例えば、データ記録５０は、顧客 G. Brown が小切手勘定番号 745-906内に＄2500.00 の残高を有していることを示す。特定フィールド内の特定データ記録を「エントリ」と呼ぶ。例えばエントリ５５は、M. Karvel の小切手勘定が＄600.00であることを示している。
【００２０】
図５に示すように、分散データベースシステム５は、コサーバ１０２ａ及び１０２ｂ上のデータベース３０からの情報を格納する。コサーバ１０２ａ及び１０２ｂに関連しているのは、それぞれコンピュータ１２ａ及び１２ｂのメモリブロック２２ａ及び２２ｂ、及び非揮発性記憶装置２４ａ及び２４ｂである。小切手勘定テーブル３２をハードディスク２４ａ上に格納し、預金勘定テーブル４２をハードディスク２４ｂ上に格納することができる。コサーバ１０２ａは小切手勘定テーブル３２内の情報の操作処理を実行することができ、コサーバ１０２ｂは預金勘定テーブル４２内の情報の操作処理を実行することができる。
各コサーバはトランザクションログへのアクセスを有している。各コサーバ毎に１つのトランザクションログを設けることが好ましい。例えば、コサーバ１０２ａのトランザクションログ６４ａの一部はメモリ２２ａのバッファ６０ａ内に、また一部はハードディスク２４ａのディスクスペース６２ａ上に格納される。バッファ内のトランザクションのリストが非揮発性ディスクへ書き込まれると、そのトランザクションログは「ディスクへフラッシュ」されたと称される。
【００２１】
コサーバのトランザクションログを、同一の記憶装置上の１またはそれ以上のトランザクションログとして一緒に多重化することが可能である。コサーバ１０２ａ−１０２ｇがどのように記憶装置またはログを共用するかには拘わりなく、書き込み及びフラッシングに関連するセマンティクス及び動作は同一に維持される。従って、特定の各コサーバにおけるトランザクションのロギング及びコミットの処理は影響を受けない。
２以上のコサーバを単一のコンピュータまたはノードにおいて動作させることができるので、データベースシステム５の関係者の定義を明白にしておかなければならない。本明細書では、そのトランザクションに関与している全てのコサーバが「関係者」であり、トランザクションを発した関係者がそのトランザクションの「オーナー」である。そのトランザクションの関係者ではあるが、オーナーではないコサーバが「ヘルパー」である。例えば、以下に説明する勘定振替トランザクションでは、コサーバ１０２ａ−１０２ｂはそのトランザクションのヘルパーであり、コサーバ１０２ｃがそのトランザクションのオーナーである。
【００２２】
図５及び６に関して説明したように、データベースシステム５は、M. Karvel の預金勘定から小切手勘定へ＄1000を振替えるような、データベース３０上の分散したトランザクションを実行することができる。例えば、もし銀行の出納係がコサーバ１０２ｃにおいてトランザクションに関する要求を入力すれば、コサーバ１０２ｃが勘定振替トランザクションのオーナーになる。コサーバ１０２ｃは、コサーバ１０２ａの小切手勘定テーブル３２を制御し、１０２ｂが及び預金勘定テーブル４２を制御していることを判断する。コサーバ１０２ｃは、小切手勘定＄100 を貸方に記入する操作処理を伴うメッセージを、コサーバ１０２ａへ送り、また預金勘定＄100 を借方に記入する操作処理を伴うメッセージを、コサーバ１０２ｂへ送る。メッセージは、そのトランザクションを識別するトランザクションコードと、オーナーを識別するオーナーコードとを含んでいる。
【００２３】
メッセージがコサーバ１０２ａに到着すると、コサーバ１０２ａはログ記録７０ａを書き込んで勘定振替トランザクションの開始を表す。もしこの顧客の小切手勘定のデータ記録５２（図４参照）がメモリ２２ａ内に未だ存在していなければ、データ記録５２がディスク２４ａからメモリ２２ａ内に読み込まれる。次いで、貸方操作処理がデータ記録５２の残高フィールド３８上で遂行され、残高エントリ５５が＄100 だけ増加される。別のログ記録７２ａがトランザクションバッファ６０ａに追加され、エントリ５５の古い値（＄600 ）と新しい値（＄700 ）とが記録される。結局は、以下に詳細を説明する本発明のコミットプロトコルに従って、勘定振替トランザクションがコミットされたのか、または打切られたのかに関するログ記録７４ａがトランザクションバッファ６０ａ内に記録される。２相コミットプロトコルとは異なり、本発明では勘定振替トランザクションが準備されたか、またはコミットに適格であるかのログ記録はバッファ６０ａ内に記録されない。
【００２４】
借方操作処理についてコサーバ１０２ｂが遂行するプロセスは、預金勘定記録５３（図４参照）がメモリ２４ｂ内へ読み込まれることを除いて、極めて類似しており、借方操作処理が残高エントリ５６上で遂行される。ログ記録７２ｂは残高エントリ５６の古い値（＄1300）及び新しい値（＄1200）を記録する。ログ記録７０ｂは振替トランザクションの始まりを表し、ログ記録７４ｂはその振替トランザクションがコミットされたのか、または打切られたのかを表している。
ディスク２４ａ上のテーブル３２は、残高エントリ５５の古い値及び新しい値を有するログ記録７２ａがディスクへフラッシュされた後の任意の時点に、残高エントリ５５の新しい値を用いて更新することができる。同様に、ディスク２４ｂ上のテーブル４２は、ログ記録７２ｂがディスクへフラッシュされた後の任意の時点に、残高エントリ５６の新しい値を用いて更新することができる。
【００２５】
以下に説明するように、本発明のデータベースシステムは、トランザクションのオーナーと、非オーナーである関係者との間に直接的なメッセージの交換を必要とせずに分散したトランザクションをコミットし、またあるトランザクションをコミットする前にそのトランザクションに関連する全てのログバッファがディスクへフラッシュされていることを保証する。これは、「インタバルコーディネータ」（ＩＣ）と、２またはそれ以上の「インタバル関係者」（ＩＰ）との間で定期的にメッセージを交換することによって達成される。インタバルコーディネータは、トランザクションがコミットされるか、または打切られる時点を決定するプログラムである。インタバル関係者は、トランザクションの更新に関するログ記録がディスクへフラッシュされることを保証するプログラムである。これらのインタバルコーディネータ及びインタバル関係者は、コサーバによって呼出し可能なプログラムの部分、サブルーチン、または分離したプログラムであることができる。
【００２６】
あるトランザクションに単一のコサーバだけが関与している場合には、インタバルコーディネータとのインタラクションを必要としない「１相コミット」プロトコルが使用される。本発明は分散トランザクション（以後、単に「トランザクション」という）に適用されるので、また１相コミットプロトコルは当分野においては公知であるので、これ以上の説明は省略する。
データベースシステム５は、「コミットインタバル」（もしくは単に「インタバル」）を使用して、トランザクションをコミットすることができるか否かを決定する。コミットインタバルは、インタバルコーディネータとインタバル関係者との間のメッセージの交換を編成するのに使用される時間の単位である。インタバル関係者がそのトランザクションログをディスクへフラッシュしたことを表すメッセージを、全てのインタバル関係者がインタバルコーディネータへ送ると、インタバルは「閉じる」。もし全てのインタバル関係者がこのようなメッセージを送らなければ、インタバルは「開いている」という。
【００２７】
インタバルコーディネータがトランザクションをコミットする場合、インタバルを閉じる必要はない。詳しく述べれば、全てのトランザクション関係者に関連するコサーバが現インタバル及び先行インタバルの全てのログ記録を非揮発性記憶装置へフラッシュしたことを表すメッセージをインタバルコーディネータへ送ると、インタバルコーディネータはトランザクションをコミットできる。トランザクションはデータの数片のみに対する操作処理を行うことができるので、トランザクション内の関係者は全てのインタバル関係者の小さい部分集合だけを構成することができる。
前述したように、データベースプログラム１００は、通信リンク１０４によって接続されている複数のコサーバ１０２ａ−１０２ｇを有している。図７に示すように、データベースシステム５は、１つのコサーバ、例えばコサーバ１０２ｄ上で走る単一のインタバルコーディネータ（ＩＣ）１１０を含んでいる。ＩＣ１１０は、分散したトランザクションの何れかがコミットされる、または打切られる時点を決定するのに使用される。詳しく説明すると、データベースシステム５においては、ＩＣ １１０が、コミットされたものとしてあるトランザクションをマークする記録をディスクへフラッシュすると、そのトランザクションはコミットされる。
【００２８】
データベースシステム５は、コサーバ１０２ａ−１０２ｇ上でそれぞれ走るＩＰ １１５ａ−１１５ｇをも含んでいる。１つのＩＰは各コサーバ上で走る。各ＩＰ １１５ａ−１１５ｇは、詳細を後述するように、若干のメッセージを交換することによってＩＣ １１０と通信する。
図８に示すように、分散データベース３０は、異なるコサーバ１０２ａ及び１０２ｂ上で走るＩＰ １１５ａ及び１１５ｂに関連する情報を有することができる。例えば、小切手勘定テーブル３２はＩＰ １１５ａに関連するディスク２４ａ上に格納することができ、預金勘定テーブル４２はＩＰ １１５ｂに関連するディスク２４ｂ上に格納することができる。例として、ＩＣ １１Ｏは別のコサーバ１０２ｄ上で走るように示されているが、ＩＣ １１Ｏはどのコサーバ１０２ａ−１０２ｇ上でも走ることができる。
【００２９】
以下に説明する、そして図９に示すようにデータベースシステム５は、ＩＣ
１１０とＩＰ １１５ａ−１１５ｇとの間で定期的にメッセージを交換する。図示のデータベースシステム５は７つのコサーバ１０２ａ−１０２ｇを含んでいるが、コサーバの数は特定のアプリケーションに必要な異なる数であることができる。各インタバルの始まりに、ＩＣ １１０は「インタバルメッセージ」１２０を、全てのＩＰ １１５ａ−１１５ｇへ伝送する。インタバルメッセージ１２０は、新しいインタバルが開始されたことをＩＰ １１５ａ−１１５ｇに通報する。好ましい実施例では、ＩＣ １１０は約 100ｍｓおきにインタバルメッセージを伝送する。インタバルの時間の長さは構成毎に変化するが、メッセージを送受し、あるページをトランザクションログへフラッシュするのに要する時間よりも長くすべきである。
【００３０】
各ＩＰは、「閉止メッセージ」１２５でＩＣ １１０に返答する。閉止メッセージ１２５はインタバルメッセージ１２０に応答して作成され、特定のコサーバに関するインタバル閉止記録（即ち、現ローカルインタバルに関するログ記録）を受信する前に作成された全てのログ記録を含むトランザクションログが、ディスクへフラッシュされたことを表している。更に、どのＩＰも閉止メッセージ１２５を送る度に、そのＩＰがインタバルを完了したことを表すログ記録をコサーバのトランザクションログ内に入力することができる。しかしながら、トランザクションログが空のログ記録で満たされてしまわないように、ＩＰは、もしトランザクションがそのインタバル中にそのコサーバ上でコミットされれば、インタバル閉ログ記録だけを書き込む。インタバルメッセージ１２０及び閉止メッセージ１２５の内容のより詳細な説明は、図１２及び１３を参照して後述する。
【００３１】
新しいコミットインタバルは、ＩＣ １１０内の「マスタインタバルキー」１５０が増数（インクリメント）される度に開始される。マスタインタバルキー１５０は、ＩＣ １１０及びＩＰ １１５ａ−１１５ｇの活動を調整する時計のようなものである。しかしながら、マスタインタバルキー１５０は、実時計に関連付けたり、または実時計に同期させる必要はない。むしろ、マスタインタバルキー１５０は、現コミットインタバルを識別するカウンタである。ＩＣ １１０はマスタインタバルキー１５０を読み、現コミットインタバル番号を決定する（人が時計を見て現在の時刻を理解するのに似ている）。
マスタインタバルキー１５０は、４バイトの（または、それより大きい）符号なし整数変数であることが好ましい。コミットインタバルは、マスタインタバルキー１５０が増数される時に「終了する」。マスタインタバルキー１５０の増数は、次のマスタインタバルの始まりでもある。
【００３２】
コミットインタバルの「終わり」は、必ずしもコミットインタバルの「閉止」と同一のものである必要はない。好ましい実施例では、ＩＣ １１０はインタバルメッセージ１２０を送出した後、ある時（期）間待機する。各マスタインタバルにおいては、この待機期間は、連続するインタバルメッセージ間の時間の合計長がほぼ 100ｍｓであるようにセットされている。待機期間の正確な長さは、先行マスタインタバル中に閉止メッセージを処理するのに消費した時間長に依存する。待機期間の設定は設備毎に変化するが、２つのメッセージ交換及びログのディスクへのフラッシュを可能にするよう十分に長くすべきである。
待機期間中に到着するどの閉止メッセージ１２５も待ち行列内に配置される。待機期間の終わりに、ＩＣ １１０は待ち行列内のメッセージを処理し始める。処理中に、さらなるインタバルメッセージが到着し、待ち行列内に配置されるかも知れない。しかし結局はＩＣ １１０は、閉止メッセージの待ち行列を空にする。もし全てのＩＰ １１５ａ−１１５ｇが閉止メッセージを送ってしまえば、そのインタバルは閉じる。もし、ＩＰ １１５ａのようなＩＰが（例えば、もしコサーバ１０２ａが故障して）閉止メッセージを送ることを妨げられれば、インタバルは開き続ける。もしインタバルが開き続ければ、ＩＣ １１０は、閉止記録を送らなかったＩＰの記録をメモリ内に保持するので、そのインタバルは後刻閉じることができる。しかしながら、一旦待ち行列が空になると、インタバルが開き続けているか、または閉じているかには拘わりなくマスタインタバルキー１５０が増数され、新しいインタバルが開始される。
【００３３】
ＩＰ １１５ａ−１１５ｇは「ローカルインタバルキー」１５５ａ−１５５ｇと呼ぶタイマ変数を保持している。ローカルインタバルキーは、ＩＰのためのローカル時計に似た動作をする。ローカルインタバルキー１５５ａ−１５５ｇは最新のマスタインタバルを格納し、ＩＣ １１０からのインタバルメッセージ１２０によって更新される。ＩＣ １１０からの各インタバルメッセージ１２０は、ＩＣ １１０のマスタインタバルキー１５０の現在の値に等しい「マスタインタバルタグ」を含む。ＩＰ １１５ａ−１１５ｇはインタバルメッセージを読み、マスタインタバルタグを抽出し、そしてそれらのローカルインタバルキー１５５ａ−１５５ｇをマスタインタバルタグに等しくセットする。
ＩＰがＩＣ １１０からのインタバルメッセージ１２０（値Ｎのマスタインタバルタグを含む）に応答する時、そのＩＰに関連するコサーバは、先行マスタインタバルＮ−１の間にそのコサーバが作成した全てのトランザクションログ記録をディスクへフラッシュしている。例えば、もしＩＣ １１０が、マスタインタバル＃５の開始を知らせるインタバルメッセージ１２０−１ｃを送れば、ＩＰ１１５ａが閉止メッセージ１２５−１ａで応答する時、コサーバ１０２ａはマスタインタバル＃４の間に作成した全てのログ記録をディスクへフラッシュしている（図１０参照）。
【００３４】
要約すれば、ＩＣ １１０内にはマスタカウンタ（マスタインタバルキー１５０）が存在していてマスタインタバルを画定し、各ＩＰ内にはローカルカウンタ（ローカルインタバルキー１５５ａ−１５５ｇ）が存在していてローカルインタバルを画定している。ローカルインタバルキーは、ＩＰがＩＣ １１０からインタバルメッセージを受信すると更新される。従って、ＩＣ １１０上の各マスタインタバルは、概ねあるインタバルメッセージ１２０の伝送から次のインタバルメッセージの伝送まで走る。同様に、各ローカルインタバルは、概ねあるインタバルメッセージの受信から次のインタバルメッセージの受信まで走る（図１０参照）。
ＩＣ １１０とＩＰ１１５ａ−１１５ｇとの間のインタバルメッセージ及び閉止メッセージの定期的な交換に加えて、分散した各トランザクション毎に、トランザクションオーナーとトランザクションヘルパーとの間にメッセージが交換される。詳しく説明すると、トランザクションオーナーは、そのトランザクションの１またはそれ以上の操作処理を遂行することを依頼する「要求メッセージ」をトランザクションヘルパーに送る。例えば、勘定振替トランザクションの場合、要求メッセージ１４０ａがヘルパー１３５ａへ、また要求メッセージ１４０ｂが１３５ｂへ送られる。コサーバ１０２ａ及び１０２ｂがヘルパー１３５ａ及び１３５ｂとして図示され、またコサーバ１０２ｃがオーナーとして図示されているが、オーナー及びヘルパーは異なるトランザクションに関しては異なるコサーバであろう。
【００３５】
特定のトランザクションヘルパーがその操作処理を実行してしまうと、そのトランザクションヘルパーは、操作処理が完了したことを表す「完了メッセージ」でトランザクションオーナーに返答する。完了メッセージは、トランザクションヘルパーのローカルインタバルキーの値にセットされている「トランザクションインタバルタグ」を含んでいる。トランザクションインタバルタグは、後述するようにトランザクションオーナーがコミットすべきトランザクションを指定（ノミネート）することができる。
以後、要求メッセージ及び完了メッセージの交換に関しては、オーナー及びトランザクションヘルパーを、オーナー及びヘルパーと呼ぶことがある。
オーナー１３０は、ヘルパーから完了メッセージを受信する度に、受信した新しいトランザクションインタバルタグを、格納されている古いトランザクションインタバルタグと比較し、大きい方の（最も新しいものに等価の）インタバルタグを保持する。ヘルパーは、オーナーと同一のノード上で動作できることに注目されたい。たとえトランザクションのオーナーと同一のコサーバ上でトランザクションの更新が行われたとしても、トランザクションタグは使用する。
【００３６】
全てのヘルパーが完了メッセージをオーナー１３０へ送ってしまうと、オーナーはユーザへ完了応答を供給することができる。トランザクションオーナーは、現トランザクションのための付加的なタスクを完了させることを要求することができ、またはユーザは、そのトランザクションをコミットまたは打切ることを要求することができる。もしトランザクションオーナーがトランザクションのコミットを要求すれば、トランザクションオーナー１３０は据置き制約( deferred constraint ) の検査を開始することができる。据置き制約とは、あるトランザクションの完了時に検査を必要とする規則のことである。例えば、もし小切手勘定に最低残高が要求されていれば、これはトランザクションの後に確かめることができる。据置き制約に関しては、コミットプロトコルの説明の後に説明することにする。
【００３７】
次に、オーナー１３０は、格納されているトランザクションインタバルタグとローカルインタバルキー１５５ｃとを比較する。もしローカルインタバルキー１５５ｃが、格納されているトランザクションインタバルタグに等しいか、または大きければ、オーナー１３０はそのトランザクションをコミットについて適格であるとしてマークし、ＩＣ １１０にそのトランザクションをコミットする要求を次の閉止メッセージ１２５内に含ませる。
もしローカルインタバルキー１５５ｃが、格納されているトランザクションインタバルタグよりも小さければ、そのトランザクションに関するログ記録（現インタバルの終わりにディスクへフラッシュされない）が存在しているかも知れない。この場合オーナー１３０は待機し、ＩＣ １１０にそのトランザクションをコミットさせる要求を閉止メッセージ１２５内に含ませるか否かを決定するために次のインタバル中に再度検査することができる。
【００３８】
オーナー１３０が待機する場合には、単一の閉止メッセージ１２５内に送られる全てのトランザクションが、単一のインタバルに関係付けられるように、適切なインタバルが必要である。代替例では、オーナー１３０は、ＩＣが所与のトランザクションをコミットすることを要求する前に、適切なインタバルを待機しない。この場合、トランザクションタグが閉止メッセージに対してグローバルであるような好ましいアルゴリズムの実施例とは異なり、ＩＣへの閉止メッセージ内の各トランザクションに対してインタバルタグ２５２（図１３参照）の指定を行わなければならない。
時には、ユーザ要求を処理している間に問題が発生し、トランザクションを打切らなければならないことがある。若干の状況においては、ヘルパーは独立的にトランザクションを打切ることができるが、他の場合にはヘルパーはトランザクションを打切ることができない。もしヘルパーが（オーナーに打切り状態を戻すことによって）オーナーの操作処理を現在実行中であれば、ヘルパーは独立的にトランザクションを打切ることができる。また、ＩＣ １１０への次の閉止メッセージ内の打切りリストにそのトランザクションを追加することによって、もしＩＰの現在のインタバルタグとローカルインタバルタグとが同一であれば、ヘルパーは独立的にトランザクションを打切ることができる。
【００３９】
他のどのような状況でも、ヘルパーは、ＩＣへ別のメッセージを送るか、または閉止メッセージに打切り要求を追加するかの何れかによって、ＩＣにトランザクションを打切ることを要求しなければならない。何れの場合も、ＩＣがそのトランザクションの処理のコミットを既に開始しているかも知れないので、ＩＣが打切り要求を受けるような必要性は存在しない。
本発明の好ましい実施例においては、トランザクションオーナーだけがトランザクションを打切ることができる。トランザクションヘルパーは一方的にトランザクションを打切るような自律性を放棄する。この実施例は、単一の管理コンテクスト内の単一のサーバとして機能するローカルに分散したデータシステムにとって適切である。
【００４０】
図１０は、勘定振替トランザクションにおけるオーナー、ヘルパー、及びＩＣ間のメッセージの交換の時間線例を示している。水平の線はコサーバ１０２ａ、１０２ｃ、及び１０２ｄを表している。斜めの線は、コサーバ間で交換されるメッセージを表している。銀行の出納係のようなユーザは、ＩＰ １１５ｃに関連するコサーバ１０２ｃのようなコサーバから勘定振替トランザクションを入力することができる。トランザクションはコサーバ１０２ｃから発しているので、コサーバ１０２ｃは上述したようにそのトランザクションのオーナーとして動作する。オーナー１３０は、小切手勘定テーブル３２がＩＰ １１５ａに関連するコサーバ１０２ａ内に格納されており、預金勘定テーブルがＩＰ １１５ｂに関連するコサーバ１０２ｂ内に格納されてと判断する（図８及び９参照）。
【００４１】
インタバルメッセージ１２０が、コサーバ１０２ｄからコサーバ１０２ａ及び１０２ｃ上のＩＰへ定期的に送り出される。各ＩＰは、閉止メッセージ１２５でインタバルメッセージ１２０に返答する。例えば、図１０に示すように、コサーバ１０２ｄはインタバルメッセージ１２０−１ｃをコサーバ１０２ｃへ送り、コサーバ１０２ｃは閉止メッセージ１２５−１ｃで応答する。
勘定振替トランザクションの例では、メッセージはコサーバ１０２ａ、１０２ｂ、１０２ｃ、及び１０２ｄの間で伝送される。両コサーバ１０２ａ及び１０２ｂはヘルパーであるので、コサーバ１０２ａ及び１０２ｂへの、及びこれらからのメッセージは同じである。従って、簡略化のためにコサーバ１０２ｂへの、及びそれからのメッセージは図１０には示してない。またこの例は、マスタインタバル＃４で開始されているが、これらの原理は早めの、または遅めのインタバルにも適用することができる。
【００４２】
マスタインタバル＃４の閉止を要求するＩＣ １１０からのインタバルメッセージ１２０−１ａに応答してＩＰ １１５ａは、コサーバ１０２ａ上の時点Ｘから開始してそのローカルインタバルキー１５５ａをローカルインタバル＃５に将にセットしたところである。ＩＰ １１５ａは、閉止メッセージ１２５−１ａでＩＣ １１０に応答しようとしている。図１０及び１１の（Ａ）に示すように、時点ＸにＩＰ １１５ａはトランザクションログ６４ａをフラッシュし、それによってローカルインタバル＃４の閉止のログ記録１６０をディスク２４ａへ書き込む。
引き続き図９、１０、及び１１の（Ａ）を参照する。小切手勘定テーブル３２の貸方操作処理を実行するために、オーナー１３０は、ローカルインタバル＃５の間に要求メッセージ１４０ａをコサーバ１０２ａへ伝送する。ＩＰ １１５ａがそのローカルインタバルキーを丁度セットしているから、オーナー１３０らの要求メッセージ１４０ａはローカルインタバル＃５の間にコサーバ１０２ａに到着する。
【００４３】
時点Ａに貸方操作処理の実行を完了したコサーバ１０２ａは、ログ記録１６１をトランザクションログ６４ａ内に入力する。ログ記録１６１は、トランザクション識別（ＩＤ）コード及びエントリ５５の古い値及び新しい値のような操作処理を元に戻すか、またはやり直すのに十分な情報を含んでいる。ログ記録１６１はメモリ２２ａ内に留まってはいるが、未だディスク２４ａへフラッシュされてはいない。
コサーバ１０２ａは、ログ記録１６１をトランザクションログ６４ａ内に入力した後に、完了メッセージ１４５ａをコサーバ１０２ｃ上のオーナー１３０へ送る。完了メッセージは、コサーバ１０２ａ上のローカルインタバルキー１５５ａの現在の値（即ち、ローカルインタバル＃５）に等しくセットされたトランザクションタグを含む。
【００４４】
図１０には示してないが、前述したように、他のヘルパー及びオーナーは要求メッセージ及び完了メッセージを交換して預金勘定テーブル４２上で借方操作処理を実行する。しかしながら、もし借方操作処理によって勘定が０以下になれば借方操作処理は失敗し、ヘルパーはそのトランザクションが誤りをもたらすことを表すメッセージをオーナー１３０へ送る。もし借方操作処理に成功すればヘルパーはオーナーへ完了メッセージを送り、コサーバ１０２ｂはログ記録を、トランザクションＩＤ、借方操作処理を完了したローカルインタバル、及びエントリ５６（図４参照）の古い値及び新しい値と共に、ログ６４ｂ（図８参照）内に入力する。
図９に戻って、オーナー１３０は各完了メッセージ１４５ａ及び１４５ｂを調べ、誤りが戻されてきたか否かを決定する。もしヘルパー１３５ａ及び１３５ｂから誤りを受信していれば、オーナー１３０はそのトランザクションを打切られるものとしてマークする。完了メッセージ１４５ｂの前に完了メッセージ１４５ａがオーナー１３０に到着したものとすれば、オーナー１３０は完了メッセージ１４５ａからのトランザクションインタバルタグをメモリ２２ａ内に格納する。次の完了メッセージ１４５ｂがオーナー１３０に到着すると、オーナー１３０は完了メッセージ１４５ｂからの新しいトランザクションインタバルタグと、完了メッセージ１４５ａからのトランザクションインタバルタグとを比較する。もし受信した新しいタグが、格納されている古いタグよりも大きければ、格納されているタグは新たに受信したタグに置換される。この例では、コサーバ１０２ａ及び１０２ｂの両者が、ローカルインタバル＃５の間に完了メッセージを送っている。従って、オーナー１３０は格納されるトランザクションインタバルタグとして完了メッセージ１４５ａからのローカルインタバル＃５を格納する。完了メッセージ１４５ｂが到着しても、格納されたトランザクションインタバルタグには変化はもたらされない。
【００４５】
次にオーナー１３０は、格納されているトランザクションインタバルタグと、ローカルインタバルキー１５５ｃとを比較する。もしローカルインタバルキー１５５ｃが、格納されているトランザクションインタバルタグに等しいか、または大きければ、オーナー１３０はそのトランザクションをコミット可としてマークする。この例では、格納されているトランザクションインタバルタグ、及びオーナー１３０のローカルインタバルは共にインタバル＃５にセットされている。ローカルインタバルが、格納されているトランザクションインタバルタグに等しいので、このトランザクションはコミット可としてマークされる。
ある状況では、格納されているトランザクションインタバルタグが、ローカルインタバルよりも大きいことがあり得る。あるインタバルの始まりにＩＣ １１０がインタバルメッセージを、操作処理の実行に繁忙なヘルパーへ送ることを考えよう。オーナー１３０がＩＣからオーナーへのインタバルメッセージの処理を完了する前に、ヘルパーが操作処理を完了してその完了メッセージ１４５ａをオーナー１３０へ送るかも知れない。この場合、オーナーは未だそのローカルインタバルキーを増数させていないから、トランザクションインタバルタグはローカルインタバルキーよりも大きくなる。もしこのようなことが発生すれば、オーナー１３０はその次のローカルインタバルの終わりにコミット要求を提出する。
【００４６】
ＩＰ １５５ｃが閉止メッセージ１２５−２ｃを作成する時、ＩＰ １５５ｃは勘定振替トランザクションがコミット可であることに注目し、そのトランザクションをコミットに適格であるとして注目するコミット要求を、閉止メッセージ１２５−２ｃに追加する。
図１０及び１１の（Ｂ）を参照する。ＩＰ １１５ａが閉止メッセージ１２５−２ａを送る前の時点Ｂに、ＩＰ １１５ａはトランザクションログ６４ａをフラッシュしてログ記録１６１をディスク上に配置する。次いでＩＰ １１５ａは、ローカルインタバル＃５の閉止を表すログ記録１６２をバッファ２２ａに追加する。
ＩＣ １１０は閉止メッセージ１２５−２ｃを受信すると、その勘定振替トランザクションがコミットに適格であることを決定する。マスタインタバル＃６の終わりに、ＩＣ １１０は、そのインタバルに閉止メッセージを送ったＩＰのリストと、そのトランザクションに関与した関係者のリストとを比較する。図１０に示すように、コサーバ１０２ａに関連するＩＰ １１５ａ及びコサーバ１０２ｃに関連するＩＰ １１５ｃは共に、それぞれインタバルメッセージ１２０−２ａ及び１２０−２ｃに応答して閉止メッセージ１２５−２ａ及び１２５−２ｃを送っている。コサーバ１０２ｂ上のＩＰ １１５ｂも、閉止メッセージをＩＣ１１０へ送っているものとすれば、勘定振替トランザクションは、揮発性メモリ２２ｄ内のトランザクション状態リスト１７０（図８）内にコミット済みとしてマークされよう。
【００４７】
図２１を参照する。メモリ２２ｄ内のトランザクション状態リスト１７０は、トランザクション記録４１０のリストである。各トランザクション記録４１０は少なくとも、オーナーＩＤコード４１１、トランザクションＩＤコード４１２、トランザクションインタバルタグ４１３、トランザクション状態４１４、及びトランザクション関係者リスト４１５を含む。例えば、上例の勘定振替トランザクションでは、オーナーＩＤコードは＃ 102ｃ、トランザクションＩＤコードは＃ 312、インタバルタグはインタバル＃５、状態はコミット、そしてトランザクションの関係者リストはコサーバ１０２ａ−１０２ｃである。
図１０に示すように、マスタインタバル＃６の終わりにＩＣ １１０はインタバルメッセージ１２０−３ａと１２０−３ｃとをアセンブルする。インタバルメッセージ１２０−３ａと１２０−３ｃとをアセンブルすると、ＩＣ １１０はトランザクション状態リスト１７０（図８参照）をディスク２４ｄへフラッシュする。この時点で、トランザクションはコミットされる。後刻故障が発生しても（非揮発性記憶装置が実際に破壊された場合を除く）、打切られたトランザクションを元に戻し、コミットされたトランザクションをやり直すことによって一貫性データベース３０を得ることができる。ＩＰ １１５ａ−１１５ｃは、データベースエントリの古い値及び新しい値の記録が成功裏にディスクへフラッシュされた後に閉止メッセージ内に送っているから、ＩＣ １１０がそのトランザクションをコミット済みとしてマークする時、データベース３０を再構成するのに必要な情報は、既に非揮発性記憶装置内に保管されている。
【００４８】
ＩＣ １１０がマスタインタバル＃７の始まりにトランザクション状態リストをディスク２４ｄへフラッシュすると、インタバルメッセージが各ＩＰ １１５ａ−１１５ｇへ伝送される。インタバルメッセージ１２０−３ａ及び１２０−３ｃは、コミットされたトランザクション、及び打切られたトランザクションのリストを含んでいよう。勘定振替トランザクション（トランザクション＃ 312）はコミットリスト内にあろう。
図１０及び１１の（Ｂ）に示すように、ＩＰ １１５ａはインタバルメッセージ１２０−３ａを受信した後に、トランザクションＩＤコード＃ 312がコミットされたことを知らせるログ記録１６３をトランザクションログ６４ａ内に入力する。
【００４９】
図１０及び１１の（Ｃ）を参照する。ＩＰ １１５ａがその閉止メッセージをＩＣ １１０へ送る前の時点Ｃに、ＩＰ １１５ａはログ６４ａをディスク２４ａへフラッシュし、次いでローカルインタバル＃６の閉止を表すログ記録１６４をバッファ２２ａに追加する。しかしながら、もし最後のローカルインタバル中にトランザクションログ記録が書き込まれていれば、ＩＰはそのログをフラッシュすることを要求するだけである。これは、分散データベースシステム５の分散したトランザクションコミットプロトコルを意図しているのである。
据置き制約検査はコミットと同じような手法で遂行することができる。ユーザが据置き制約検査を受けたトランザクションのコミットを要求する場合、トランザクションオーナーは、ＩＣ １１０がそのトランザクションのコミットを処理する前に、これらの据置き制約の評価を開始することを要求しよう。閉止メッセージ１２５内のこの据置き制約検査要求を受けたＩＣ １１０は、幾つかの行動を起こす。第１に、そのトランザクションを、別の制約検査を必要とするトランザクションのリストに追加する。このリストは、関係者が制約検査を完了したことを追跡するのに使用される。第２に、ＩＣはリスト１７０内のトランザクションの状態を「据置き」に変化させる。第３に、全ての関係者が、そのトランザクションのインタバルタグ値によって表されるインタバルの閉止メッセージを送ってしまうと、ＩＣは次のインタバルメッセージ１２０内にそのトランザクションについての検査要求を含ませる。
【００５０】
各関係者は、インタバルメッセージ１２０で検査要求を受けると、指定されたトランザクションの据置き制約を評価する。制約検査を完了するためには、複数のローカルインタバルが必要であるが、各関係者は完了するとその成果を閉止メッセージ内へ挿入する。もしＩＣ １１０がある関係者から制約を侵したことを受信すると、そのトランザクションは打切られたとしてマークされる。もしどの関係者も制約を侵していなければ、全ての関係者が返答すると、そのトランザクションはコミットされるものとしてマークされ、そのトランザクションプロトコルは上述したように続行される。
メッセージ交換
図１２及び１３は、ＩＣ １１０とＩＰ １１５ａ−１１５ｇとの間で伝送可能な考え得るメッセージの構造を示している。
【００５１】
図１２に示すように、ＩＣ １１０から１またはそれ以上のＩＰ １１５ａ−１１５ｇへのどのメッセージも、１バイトのメッセージの型２００で始まる。通常のメッセージの型は「トランザクション」であり、ＩＰに閉止メッセージで応答させる通常の要求を表している。ＩＣがＩＰへ送ることができる他の考え得るメッセージの型は以下のものを含む。
「返答可」：もしＩＰが、ＩＣ １１０へ「使用可」メッセージを送れば、ＩＣ １１０は現マスタインタバルタグ２０２を含む「返答可」メッセージで応答する。
「ＩＣ使用可」：もしＩＣ １１０が故障して使用不能であったのであれば、ＩＣ １１０は復旧した時に全てのＩＰ １１５へ「ＩＣ使用可」メッセージを同報（または放送）する。これは、ＩＣ １１０が再び使用可能であり、及び各ＩＰの状態を確認する必要があることをＩＰに通告する。例えばもしバックアップＩＣが制御を行っていればＩＣ １１０の位置が変化しているかも知れない。従って「ＩＣ使用可」メッセージは、ＩＣ １１０を走らせている現コサーバの識別をも含む。
【００５２】
「更新」：もしＩＰが、ＩＣ １１０へ「更新要求」メッセージを送れば、ＩＣ １１０は指定されたＩＰに「更新」メッセージで応答する。このメッセージは、マスタインタバルタグと、そのコサーバが関係者であった全てのトランザクションの状態の状態リストとを含む。
「復旧返答」：もし特定のＩＰが故障し、後に復旧すれば、それはＩＣ １１０へ「復旧」メッセージを送る。それに応答してＩＣ １１０はＩＰへ「復旧返答」を送る。このメッセージは、マスタインタバルタグと、そのコサーバが関係者であった全てのトランザクションの状態の状態リストとを含む。
「延期」：このメッセージは、あるＩＰからの最後の閉止メッセージ以降、閉じたインタバルが多過ぎるために、ＩＣ １１０がそのＩＰへの「トランザクション」メッセージを延期していることをそのＩＰに通告する。
【００５３】
図１２に示すインタバルメッセージ１２０においては、４バイトのマスタインタバルタグ２０２が状態２００に続いている。マスタインタバルタグ２０２は、マスタインタバルキー１５０から入手した最新の閉止インタバルである。タグ２０２の後には、単一の１バイトのフィールドを占める４つのフラグ２０４−２０７が続いている。これらのフラグは、インタバルメッセージ１２０が、何れかのトランザクションを、コミットするか否か（フラグ２０４）、打切るか否か（フラグ２０５）、または制約検査を遂行するか否か（フラグ２０６）を表している。フラグ２０７は、何れかのコサーバが故障したことをＩＣ １１０が知らされたか否かを表す。
フラグ２０４−２０７の次に続くのは、順番に、コミットリスト２１０、打切りリスト２１２、制約検査リスト２１４、及び故障（ダウン）したコサーバリスト２１６である。コミットリスト２１０、打切りリスト２１２、及び制約検査リスト２１４は全て同一の編成を有している。各リストは、リスト内のトランザクションオーナーの２バイトのカウント２２０で始まる。次いで、各オーナー毎に、２バイトのオーナーＩＤ ２２２、２バイトのそのオーナーのトランザクションの数のカウント２２４、及びそのオーナーのトランザクションＩＤリスト２２６が続く。トランザクションＩＤリスト２２６は、トランザクション当たり４バイトを使用する。
【００５４】
インタバルメッセージ１２０は、他のグローバルデータベースシステム関連情報をも含む。例えば、日のグローバル時間の値を、いろいろなコサーバ上の時計を粗く同期させるために分配することができる。勿論、メッセージの上述したフィールドサイズは単なる例示に過ぎず、本発明に必須ではない。フィールドサイズは、所与のコンピュータネットワークのトランザクション処理能力を反映している。
図１３に示すように、ＩＰからＩＣへのどのメッセージも１バイトのメッセージの型２５０で始まる。通常のメッセージの型は「トランザクション」であり、これはＩＣへの通常の閉止応答を指示している。しかしながら、他の考え得るメッセージの型は、以下のものを含む。
【００５５】
「復旧」：ＩＰは「復旧」メッセージをＩＣ １１０へ送って現トランザクション情報を入手する。
「使用可」：もしあるＩＰが静止していたが今は使用可能であれば、そのＩＰは「使用可」メッセージをＩＣ １１０へ送る。これは、そのＩＰがトランザクション処理に使用できることをＩＣ １１０に通告する。
「更新要求」：あるＩＰは、「延期」メッセージをＩＣ １１０から受信した後に「更新要求」メッセージをＩＣ １１０へ送る。
「遊休」：特定のＩＰ １１５ａは、「遊休」メッセージを送ることによって遊休に入ることをＩＣ １１０に通告する。あるＩＰは、かなりの数のローカルインタバルが推移しても、そのＩＰに関連するコサーバに目立った活動的なトランザクション、即ちトランザクションアクティビティが存在しない場合に遊休になる。
【００５６】
「ＩＣ更新」：ＩＣ １１０からの「ＩＣ使用可」メッセージに応答して、あるＩＰは、そのＩＰからＩＣへの先行トランザクションメッセージで伝送した情報を含む「ＩＣ更新」メッセージを送る。この情報は、ＩＣ １１０が故障していために到着しなかったかも知れない。
「復旧完了」：故障に続いて、開いているどのトランザクションも、ＩＰによって解消され、インタバル閉記録がディスクにフラッシュされた後に、ＩＰはＩＣ １１０へ「復旧完了」メッセージを送る。次いでＩＣ １１０は、特定のＩＰが閉じたことを示すように全ての格納されたインタバル閉記録を変更し、関与したトランザクションからそのＩＰを除去するようにトランザクション状態リストを変更する。
【００５７】
図１３に示す閉止メッセージでは、型２５０の後に４バイトのローカルインタバルタグ２５２が続いている。ローカルインタバルタグ２５２は、ローカルインタバルキーから得たインタバルである。タグ２５２の次は２バイトのインタバル関係者ＩＤ ２５４である。インタバル関係者ＩＤ ２５４の次は、４つのフラグ２５６−２５９であり、１バイトを占めている。これらのフラグは、インタバルメッセージが、コミットに適格な何等かのトランザクションを含むか否か（フラグ２５６）、打切ることを要求されているか否か（フラグ２５７）、またはどれが制約検査を要求しているか（フラグ２５８）を表している。フラグ２５９は制約検査に対する返答を表している。
フラグ２５６−２５９の後に、順番に、適格コミットリスト２６０、打切りリスト２６２、制約検査リスト２６４、及び制約返答リスト２６６が続く。コミットリスト２６０、打切りリスト２６２、及び制約検査リスト２６４は、全て同じ編成を有している。各リストは、２バイトのリスト内のトランザクションの数のカウント２７０から始まる。次いで各トランザクション毎に、４バイトのトランザクションＩＤ ２７２、２バイトのトランザクションの関係者の数のカウント２７４、及びそのトランザクションの関係者リスト２７６が続く。コサーバの数が 40 より少ないシステムの場合には、関係者リスト２７６は、各ビットが１つのコサーバを表しているようなビットマップであろう。コサーバの数が 40 より多いシステムの場合には、関係者リスト２７６は、ビットマップまたは関係者当たり２バイトの関係者ＩＤのリストの何れかであり、何れにしてもバイトの数は少なくて済む。関係者リスト２７６の第１のビット２７７は、どのフォーマットが使用されているかを表している。
【００５８】
ＩＰインタバル閉止メッセージ１２５は、トランザクション関係者による据置き制約の評価の結果を有する返答リスト２６６をも含んでいる。返答リスト２６６は若干異なる構造を有している。返答リスト２６６は、２バイトのリスト内のトランザクションの数のカウント２８０から始まる。次いで各トランザクション毎に、２バイトのトランザクションオーナーＩＤ ２８２、４バイトのトランザクションＩＤ ２８４、及び制約検査が成功したか、または失敗したかを表す１バイトのフラグ２８６が続く。
閉止メッセージ１２５はインタバルタグ２５２を含むので、ＩＣ １１０は閉止メッセージが伝送されたローカルインタバルを知る。インタバルタグ２５２は、閉止メッセージ１２５のリスト２６０、２６２、２６４、及び２６６内に識別されている各トランザクションにグローバルに適用される。
【００５９】
リスト２６０内の打切られたトランザクションのＩＤ、及びリスト２６２内のコミットに適格であるトランザクションのＩＤは、ＩＣ １１０によって最新のトランザクションとして、メモリ２２ｄ（図８参照）に維持されているトランザクション状態リスト１７０に追加される。ＩＣ １１０は、次のインタバルメッセージ１２０を作成する時にトランザクション状態リスト１７０を参照する。
インタバルコーディネータ及びインタバル関係者
図１４に示すように、各マスタインタバル中に、ＩＣ １１０は以下の諸段階を実行する。
１．タイマの終わりを待機 （段階３０１）
２．待ち行列内のメッセージを処理 （段階３０２）
３．待ち行列が空か否かを決定 （段階３０３）
４．トランザクション状態リストを処理 （段階３０４）
５．トランザクション状態リストをディスクへフラッシュ （段階３０５）
６．インタバルメッセージを伝送 （段階３０６）
７．マスタインタバルキーを増数 （段階３０７）
ＩＣ １１０は、メモリ２２ｄ内のタイマ１８５（図２１参照）が時間切れになるのを待って段階３０１における新しいマスタインタバルを始動する。タイマ１８５が時間切れになるのを待機することによって、ＩＰは先行マスタインタバル中に送られたインタバルメッセージ１２０に応答し、閉止メッセージ１２５でＩＣ １１０に返答することが可能になる。ＩＣ １１０に到着した各閉止メッセージは、メモリ２２ｄ内の待ち行列１８０（図８及び１９参照）内に配置される。タイマ１８５は、先行インタバルの始まりから 100ｍｓのような最短時間が経過するのを保証するようにセットされる。タイマ１８５が時間切れになるか、またはタイマ１８５が既に時間切れであれば、現時点に 100ｍｓのような最短時間を付加することによってリセットされる。
【００６０】
ＩＣ １１０は、ＩＰからのメッセージを増加的に処理することもできる。この場合、ＩＣ １１０は、新しい閉止メッセージが到着するのを待つか、または現マスタインタバルのためのタイマ１８５が時間切れになるのを待機するだけである。
タイマ１８５が時間切れになった後、段階３０２においてＩＣ １１０は、待ち行列１８０（図８参照）内の何れかの閉止メッセージを処理し始める。ＩＣ１１０が処理している間に、ＩＰ １１５ａ−１１５ｇからさらなる閉止メッセージが到着することが考えられる。これらの閉止メッセージ１２５は、待ち行列の後尾に配置され、順番に処理される。
ＩＣ １１０は、段階３０３によって決定されるように、待ち行列１８０が空になるまで閉止メッセージを処理し続ける。各ＩＰは、１つの閉止メッセージだけを送り、ＩＣ １１０からの新しいインタバルメッセージを待機するであろうから（図１９の段階３５１参照）、待ち行列１８０には有限数の閉止メッセージだけが累積する。例えば、もしＩＰ（コサーバ）１１５ａが故障であるか、または他のある源からの大量の負荷を処理中であることによって、ＩＰ １１５ａのようなＩＰが時間通りに閉止メッセージをＩＣ １１０へ送ることができないこともあり得る。このような場合には、ＩＣ １１０はそのインタバルを閉じることはできず（但し上述したように、そのインタバルを終わらせる）、ＩＣ １１０はそのインタバル中に応答しないコサーバのビットマップを格納する。
【００６１】
処理段階３０２の詳細に関しては図１５及び１６を参照して後述するが、要約すれば、この処理段階中に閉止メッセージ１２５が調べられ、コミットリスト２６０、打切りリスト２６２、検査リスト２６４、及び返答リスト２６６内のトランザクションがトランザクション状態リスト１７０内へ配置される。更に、インタバルメッセージ１２０のために打切りリスト２１２がアセンブルされる。
待ち行列１８０内の全ての閉止メッセージが処理されてしまうと、作成されたばかりのトランザクション状態リスト１７０が処理される。処理段階３０４の詳細に関しては図１７及び１８を参照して後述するが、要約すれば、この段階中にＩＣは、そのトランザクションをコミットするか否かを評価する。更に、段階３０４において、インタバルメッセージ１２０のためにコミットリスト２１０及び検査リスト２１４がアセンブルされる。
【００６２】
段階３０５において、ＩＣ １１０はクリティカルトランザクション情報をディスク２４ｄ（図８参照）へフラッシュする。この情報は、マスタインタバルキー１５０、トランザクション状態リスト１７０、どの関係者が閉止メッセージを送ったか否を示すインタバル開アレイ４２５（図２１、後述）、及びローカルインタバルタグの最後のタグアレイ４３５（図２１）を含む。アレイ４３５は、各コサーバ１０２ａ−１０２ｇ毎のエントリ４３６を含む。各エントリ４３６は、適切なコサーバから受信した最新のローカルインタバルタグ２５２を含む。
もし、分散データベースシステム５がバックアップＩＣを含んでいれば、処理段階３０４とフラッシュ段階３０５との間に、クリティカルトランザクション情報のコピーがＩＣ １１０から活動バックアップＩＣへ送られる。バックアップＩＣの使用に関しては図２３を参照して後述する。
【００６３】
トランザクション情報がディスク２４ｄへフラッシュされてしまうと、段階３０６においてインタバルメッセージ１２０がＩＰ １１５ａ−１１５ｇへ伝送される。好ましい実施例では、同じインタバルメッセージが各ＩＰへ送られる。しかしながら、ＩＣに付加的な処理負荷を追加することによって、各ＩＰ毎に独自に最適化された異なるインタバルメッセージを送ることができる。
メッセージを複数のサイトへ送るには多くの方法が存在する。インタバルメッセージは直列に、即ち一時に１つのＩＰへ送ることができる。好ましくは、もしハードウェアによってサポートされるならば、単一のインタバルメッセージ１２０を同報する、即ち全てのＩＰ １１５ａ−１１５ｇへ同時に送ることができる。また、同報はソフトウェアによってシミュレートすることができる。代替として、特にもし多数のＩＰが存在すれば、樹木伝送を使用することができる。本発明はインタバルメッセージ１２０を全てのＩＰ １１５ａ−１１５ｇへ伝送するどのような方法にも適用される。
【００６４】
段階３０６において送られるインタバルメッセージは、マスタインタバルから得たマスタインタバルタグ２０２を含み、これはＩＰ １１５ａ−１１５ｇがそれらのローカルインタバルキー１５５ａ−１５５ｇをリセットするのに使用される。これは、ローカルインタバルキーのグローバルな一貫性を保証する。好ましくない実施例では、各ＩＰは各インタバルメッセージ１２０に応答してそれ自体のローカルインタバルキーを増数することができる。
最後に、段階３０７において、ＩＣ １１０はマスタインタバルキー１５０を増数させて新しいマスタインタバルの始動を表し、段階３０１へループバックして段階３０６で送られたインタバルメッセージに応答する閉止メッセージの到着を待機する。
【００６５】
要約すれば、ＩＣ １１０は分散トランザクションのコミット及び打切り、及びデータベースシステム５内の据置き制約検査の中央調整に応答する。ＩＣ １１０はコミットインタバルを始動させ、トランザクションがコミットまたは打切られる時点を決定して記録し、マスタインタバルキーを維持し、分散した据置き制約検査を管理し、分散した全てのトランザクションのコミットまたは打切り状態を維持し、そして、全ての関係者の状態をデータベースシステム５内に維持する。
図１５に示すように、段階３０２においてＩＣは、待ち行列１８０内のこの閉止メッセージ１２５を処理する。段階３１０においてＩＣ １１０は、最新のインタバルメッセージ１２０にどのコサーバが応答したかを追跡し始める。
【００６６】
各マスタインタバルの始まりに（例えば、段階３０１において）、ＩＣ １１０はインタバル開アレイ４２５内にインタバル記録４２０を作成する（図２１参照）。インタバル記録４２０は、現マスタインタバルキー１５０にセットされるインタバルタグ４２１を含む。インタバル記録４２０は、データベースシステム５内のコサーバの数に等しいビット数を有するインタバルビットマップ４２２をも含む（図２１参照）。例えば、データベースシステム５が７つのコサーバを含むものとすれば、インタバルビットマップ４２２も７ビットを有する。インタバルビットマップ４２２が作成される時、各活動コサーバ毎のビットは「オン」にセットされ、中断（もしくは延期）されたコサーバのためのビットは「オフ」にセットされる。段階３１０において、ＩＣ １１０は閉止メッセージ１２５からのインタバル関係者ＩＤ ２５２に注目し、インタバルビットマップ４２２内のそのコサーバのためのビットをオフにする。各マスタインタバルの終わりに、もし全てのコサーバが閉止メッセージを送っていればそのインタバルは閉じられ、ＩＣ １１０はインタバル記録４２０を消去できる。そうでなければ、マスタインタバルは開き続け、ＩＣ １１０はインタバル開アレイ４２５内にインタバル記録４２０を格納する。
【００６７】
次に、段階３１１においてＩＣ １１０は、閉止メッセージ１２５内のトランザクションの処理を終了したか否かを決定する。もしリスト２６０、２６２、２６４、及び２６６が空であれば、この終了は直ちに発生する。そうでなければ、ＩＣ １１０は各トランザクションを調べて処理した後に限って終了させる。
閉止メッセージ１２５内に処理すべきトランザクションが未だ存在しているものとすれば、段階３１２においてＩＣは、そのトランザクションが検査返答リスト２６６からのものか否かを決定する。もしこれが検査返答リストトランザクションであれば、段階３１３においてＩＣは、図１６を参照して後述する検査返答サブルーチンを遂行する。
もしトランザクションが検査返答でなければ、段階３１４においてＩＣは、トランザクション記録４１０をトランザクション状態リスト１７０に追加する。図１３及び２１を参照する。オーナーＩＤ ４１１がオーナーＩＤ ２５４から入手され、トランザクションＩＤ ４１２がトランザクションＩＤ ２７２から入手され、トランザクションインタバルタグ４１３がローカルインタバルタグ２５２から入手され、そして、関係者リスト４１５がリスト２７６から入手される。関係者のリストは、各コサーバ毎に１ビットのビットマップの形状である。関係者であるコサーバは、ビットマップ４１５内に「オン」にスイッチしているビットを有している。トランザクションの状態４１４は、フラグ２５６−２５８によって始めにコミット要求、打切り、または検査要求として決定されるが、以下に説明するようにＩＣ １１０によって変えることができる。
【００６８】
図１５に戻る。段階３１５においてＩＣは、そのトランザクションがコミットリスト２６０からのものか否かを決定する。もしそうであれば、ＩＣ １１０は段階３２０において次のトランザクションを続行し、何等の行動も起こさない。もしそうでなければ、段階３１６においてＩＣは、そのトランザクションが閉止メッセージ１２５の打切りリスト２６２からのものか否かを決定する。もしこれが打切りトランザクションであれば、段階３１７において、打切りリスト２６２内のトランザクションが次のインタバルメッセージ１２０のための打切りリスト２１２へ追加される（オーナーだけが打切りを行うことができるような好ましい実施例を想定している）。本発明の代替例では、トランザクション関係者はＩＣへの打切り要求を一方的に行うことができる。このような場合ＩＣは、マスタインタバルの終わりを待ち、コミットに適格のトランザクションのリストに対する打切りの候補であるトランザクションのリストを検査しなければならない。ＩＣは、そのトランザクションに対するコミット処理が既に開始されていない場合に限って、要求に応じて打切り処理を開始する。もしＩＣがトランザクションを打ち切ることを決定すれば、そのトランザクションは打切りリスト２１２に追加される。打切りリスト（もしあれば）が更新されてしまうと、ＩＣ １１０は段階３２０へ移動する。
【００６９】
もしトランザクションが打切りリスト２６２からのものでなければ、段階３１８においてＩＣ １１０は、そのトランザクションが制約検査リスト２６４に関する要求からのものか否かを決定する。もし諾であれば、段階３１９においてＩＣは、返答記録４４０を検査返答アレイ４４５へ追加する。検査返答アレイ４４５はＩＣ １１０によって維持されており、トランザクションへの全ての関係者が据置き制約検査を完了したか否かを決定する。ＩＣ １１０がテーブル４４０内のトランザクション（例えば、＃312 ）を指定する返答リスト２６６を含む閉止メッセージ１２５を受信する度に、ＩＣ １１０はその関係者に関連するビットを返答したとしてマークする。トランザクションへの全ての関係者が返答し、制約障害が報告されていなければ、そのトランザクションはコミットするこができる。各返答記録４４０は、トランザクションＩＤ ４４１と、関係者のビットマップリスト４４２とを含む。ビットマップ４４２が作成される時、関係者のビットはオンにセットされ、非関係者のビットはオフにセットされる。例えば、図２１に示すように、もし勘定振替トランザクションに関して据置き検査が要求されれば、コサーバ１０２ａ−１０２ｃはそれらのビットが未だオンにセットされ、コサーバ１０２ｄ−１０２ｇのビットがオフにセットされていることが予測されているが、未だそのようにはなっていない。後述するように、ある関係者が制約検査返答を送る度に、その関係者のビットはオフにセットされる。ビットマップ４４２内の全てのビットがオフになると、制約障害はないものと見做されてトランザクションはコミットすることができる。返答記録４４０が返答検査アレイ４４５へ追加された後、ＩＣ １１０は段階３２０において閉止メッセージの処理を続行する。
【００７０】
トランザクションがどのリストからのものかには関係なく、段階３２０ではＩＣは、次のトランザクションメッセージへ移動する。そうでなければＩＣ １１０は、その閉止メッセージで終了し、段階３０３へ進んで待ち行列１８０内の次のメッセージへ移動する。
図１６及び２１を参照する。もしトランザクションが検査返答リスト２６６内にリストされていたならば、段階３２１においてＩＣは、故障が発生したか否かを決定する。もし返答リスト２６６内のトランザクションのためのフラグ２８６が故障を示していれば、段階３２２においてトランザクション状態リスト１７０内の状態４１４が「打切り」に変えられ、段階３２３においてそのトランザクションが打切りリスト２１２に追加される。次いでＩＣは閉止メッセージ１２５の処理を続行する。
【００７１】
もし閉止メッセージ１２５を送った関係者における制約検査を通れば、段階３２４において、閉止メッセージ１２５を送ったコサーバに対応するビットマップ４４２内のビットが前述したようにオフにされる。次いで段階３２５においてＩＣは、全ての関係者が制約検査を完了したか否かを決定する。もし返答ビットマップ４４２内の全てのビットがオフであれば、返答ビットマップ４４２は０に等しく、そのトランザクションはコミットされるように進むことができる。段階３２６においてそのトランザクションの状態４１４が「コミット」に変えられ、段階３２７においてそのトランザクションがコミットリスト２１０に追加される。もしビットマップ４２２が何等かのオンビットを含んでいれば、ＩＣは閉止メッセージの処理を続行する。
【００７２】
図１７及び１８に示すように、段階３０４においてＩＣは、トランザクション状態リスト１７０を処理してトランザクションをコミットし、コミットリスト２１０及び検査リスト２１４を作成する。各トランザクション毎に、段階３３０においてＩＣ １１０は、インタバルアレイ４２５の底（最も古い記録）から開始する。次いで段階３３１においてＩＣ １１０は、トランザクションタグ４１３とインタバル開タグ４２１とを比較する。もしトランザクションタグ４１３がインタバル開タグ４２１よりも大きければ、そのトランザクションはリスト１７０内で変更されないままにされる。
もしトランザクションタグ４１３が、インタバル開タグ４２１に等しいか、または小さければ、段階３３２においてＩＣは、そのトランザクションの全ての関係者がそのインタバルの閉止メッセージを送ったか否かを決定する。これはビットマップの比較によって遂行される。トランザクションエントリ４１０のための関係者リスト４１５は、関係者ビットマップの形状で格納されている（そのトランザクションに関与している各コサーバはオンにセットされたビットで表され、関与していないコサーバはオフにセットされたビットで表されている）。関係者ビットマップ４１５は、インタバルビットマップと「論理積」される。即ち、関係者ビットマップとインタバルビットマップとのブールのＡＮＤ演算が遂行される。
【００７３】
例えば、図２１に示すように、勘定振替トランザクションにおいては、関係者ビットマップ４１５はコサーバ１０２ａ、１０２ｂ、及び１０２ｃのための３つのオンビットを有し、コサーバ１０２ｄ−１０２ｇのための４つのオフビットを有していよう。インタバルビットマップ４２２がマスタインタバル＃６のために作成される時、それは７つのオンビット（各コサーバ１０２ａ−１０２ｇ毎に１つ）を有していよう。ＩＣ １１０が閉止メッセージ１２５を受信すると、インタバルビットマップ４２２内の対応するビットがオフにセットされる。例えば、ＩＣ １１０がインタバル＃６のための閉止メッセージ１２５−２ａを受信すると、コサーバ１０２ａのためのビットがオフにセットされる。コサーバ１０２ａ−１０２ｃが閉止メッセージを伝送するものとすれば、図２１に示すように、インタバル＃６のためのビットマップ４２２内のこれらのコサーバのためのビットはオフにセットされる。このような場合、ＡＮＤ演算の結果７つのビットがオフ、即ち０になる。もし１またはそれ以上のコサーバ１０２ａ−１０２ｃが応答しなければ、オンビット、即ち非０ビットを含むことになる。
【００７４】
図１７に示すように、段階３３５において、もしＡＮＤ演算の結果が０であれば、そのトランザクションの全ての関係者は指定されたインタバル４２１を閉じており、トランザクションは状態を変えることができる。この場合、ＩＣ １１０はトランザクションの処理を続行する。
段階３４０（図１８）においてＩＣは、トランザクション状態がそのトランザクションをコミットする、または打切ることを表しているか否かを決定する。もしトランザクション状態４１４が「コミット」または「打切り」であれば、段階３４１において、そのトランザクションはリスト１７０から除去される。トランザクションに関与しているＩＰは、それらのローカルトランザクションログ６４ａ−６４ｃへコミットまたは打切りログ記録を有することが保証され、またこれらのログ記録がディスクへフラッシュされているので、これらのトランザクションはリスト１７０から除去できるのである。全てのローカルトランザクションログがこれらのコミットまたは打切り記録で更新されてしまうと、ＩＣ １１０は最早トランザクションの状態を思い出す必要はない。全てのトランザクション関係者のコサーバは、ＩＣからのさらなる援助がなくてもこれらのトランザクションの最終状態に関する曖昧さを局部的に解消できることを保証されているので、ＩＣ １１０はこれらのコミットされたトランザクションに関して「忘れる」ことができる。
【００７５】
もしトランザクション状態４１４が「コミット」または「打切り」でなければ、段階３４２においてＩＣは、据置き制約検査が要求されているか否かを決定する。もしトランザクション状態４１４が「検査要求」であれば、段階３４３において状態が「据置き」に変えられ、段階３４４においてそのトランザクションが検査リスト２１４に追加される。代替実施例においては、この点において、段階３０２（図１５）の一部としてではなく、返答記録４４０を検査返答アレイ４４５に追加することができる。
もしトランザクション状態４１４が「検査要求」であれば、段階３４５においてＩＣは、ＩＰがトランザクションのコミットを要求したか否かを決定する。もしトランザクション状態４１４が「コミット要求」であれば、段階３４６においてリスト１７０内の状態がコミットに変えられる。次いで段階３４７において、トランザクション状態リスト１７０内のトランザクションタグ４１３が改訂される。即ち、トランザクションタグ４１３は、それが現マスタインタバルキー１５０プラス（＋）ある遅延値、即ち１に等しくなるように改訂される。４１０内のコミットされたトランザクションのためのインタバルタグ４１３のこのセッティングは、ＩＣ １１０がトランザクションを「忘れる」ことができる（情報が、関係者内の非揮発性記憶装置内に格納されているから）時点を指示する。段階３４８において、トランザクションはコミットリスト２１０に追加される。
【００７６】
ＩＰは閉止メッセージを送る前にそのディスクをフラッシュするから、任意のインタバルＮに関連するデータベースシステム５内の全てのログ記録は、ＩＣ１１０がインタバルＮを閉じる時までにディスクへフラッシュされている。従って、インタバルＮに、またはそれより早くトリガされるコミット要求状態を有するトランザクションは、インタバルＮが閉じられると、即ち全てのＩＰが閉止メッセージを送ると、ＩＣ １１０によってコミットすることができる。
段階３３８において、もしトランザクション状態が「コミット要求」でなければ、何等の行動も起こされない。他の全てのトランザクション状態は無視され、この時点、即ち段階３４９において、ＩＣは明示された動作を要求しない。
最後に、段階３３６においてＩＣは、トランザクション状態リスト１７０内のさらなるトランザクションの存否を決定する。もしＩＣ １１０が最後のトランザクションを処理すれば、段階３０５へ進められる。もしさらなるトランザクションが存在すれば、段階３３７においてＩＣは、次のトランザクション記録４１０を処理し、段階３３０へループバックする。
【００７７】
もしトランザクションタグ４１３がインタバルタグ４２１より大きいか、またはＡＮＤの結果が非０であれば、段階３３３においてＩＣ １１０は、インタバル開アレイ４２５内の最後の（最も古い）記録４２０を解析したか否かを決定する。もし否であれば、段階３３４においてＩＣは、次のインタバル開へ移動し、段階３３１へ戻ってプロセスを繰り返す。
図１９に示すように、各ローカルインタバル中に、各ＩＰは以下の諸段階を実行する。
１．トランザクションログバッファのフラッシュを開始 （段階３５１）
２．インタバルメッセージを解析 （段階３５２）
３．閉止メッセージを作成 （段階３５３）
４．インタバル閉ログ記録を書き込み （段階３５４）
５．ログバッファのディスクへのフラッシュを待機 （段階３５５）
６．閉止メッセージを送る （段階３５６）
７．トランザクションセッションを目覚めさせる （段階３５７）
８．ＩＣからのインタバルメッセージを待機 （段階３５８）
９．ローカルインタバルキーを更新 （段階３５９）
オーナーが新しい分散したトランザクションを開始させる度に、またはヘルパーが要求メッセージを受信する度に、トランザクションは、記録４７０としてローカルトランザクション状態テーブル４８０内へ入力される。トランザクション状態テーブルは、ハッシュテーブルとしてフォーマットすることができる。図２２に示すように、ハッシュテーブル４８０内の各記録４７０は、グローバルトランザクションＩＤ ４７１、ローカルトランザクションＩＤ ４７２、トランザクションが最後に状態を変えたローカルインタバルを示すタグ４７３、トランザクションの状態を「コミット要求」、「コミット済」、「打切り済」、「検査要求」、または「据置き」として識別するフィールド４７４、及びセッションＩＤ４７５を含み、トランザクションが状態を変える時を通告する。セッションＩＤ ４７５は、ＩＣからのインタバル閉止メッセージ１２０の結果としてのトランザクションの状態の変化をＩＰから知らされるべき正しいトランザクション関係者を内部的に識別するために使用される。ハッシュテーブル４８０は、そのコサーバが関係者であるような活動トランザクションのリストとして役立つ。
【００７８】
ＩＰ １１５ａのようなＩＰは、図１９の段階３５８においてＩＣからのインタバル閉止メッセージを受信することによってローカルインタバルを開始する。段階３５９においてＩＰは、ＩＣからの閉止メッセージ内に含まれるマスタインタバルの値を、そのローカルインタバルキーに割当てる。次に、段階３５１においてＩＰは、バッファ６０ａ内のトランザクションログ６４ａの内容を非同期的にディスク２４ａへフラッシュし始める。トランザクションログフラッシュは、ディスク書き込みの遅れと、ＩＰがインタバル閉止メッセージを処理する時点とが重なるように直ちに要求される。
ディスク２４ａへのフラッシュを開始した後に、段階３５２においてＩＰ １１５ａは、それが受信したインタバルメッセージ１２０を解析する。処理段階３５２の詳細に関しては図２０を参照して後述するが、要約すれば、この処理段階中にインタバルメッセージ１２０が調べられ、そのコサーバが関与しているコミットリスト２１０、打切りリスト２１２、検査リスト２１４、及び故障リスト２１６内の何等かのトランザクションが処理される。段階３５２の間に、ＩＰのトランザクション状態テーブルが更新され、ＩＣから今受信したばかりのインタバル閉止メッセージの結果として状態を変えるであろうトランザクションを表す。また、段階３５２においては、一時的に変化した状態スタック４６５が作成される。これは段階３５７において、状態を変えたトランザクションに関連する特定関係者に通告するのに使用される。これらのトランザクションのコミッッテイング及び打切りに加えてＩＰ １１５ａ−１１５ｇは、直接またはトランザクション関係者を介して、マークされたトランザクションのためのローカルロックを解除する。
【００７９】
段階３５３においてＩＰは、コミット要求リスト２６０、打切りリスト２６２、検査要求リスト２６４、及び検査返答リスト２６６と、必要な見出し情報（メッセージの型２５０、ローカルタグ２５２、ＩＰ識別２５４、及びフラグ２５６−２５９）とを組合わせることによって閉止めメッセージ１２５を作成する。
コミットリスト２６０、打切りリスト２６２、及び検査要求リスト２６４は、トランザクションオーナーの代わりにそのＩＰによって作成される。検査返答リスト２６６は、トランザクション関係者に代わって作成される。トランザクションオーナーまたは関係者が、そのＩＣのための特定トランザクション関係者に関する命令または情報を入手する度に、トランザクションオーナーはＩＰ内のルーチンを呼出してそのトランザクションを適切なリストへ追加する。
【００８０】
トランザクションオーナーが、各関係者セッションから完了メッセージ１４５を受信すると、トランザクションは、暗示的に、またはユーザからの明示的な要求に基づいて、コミット評価を開始できる点にある。もしそのトランザクションが据置き制約評価を要求しなければ、トランザクションオーナーはＩＰ １１５ｃ内のルーチンを呼出してそのトランザクションをコミット要求リスト２６０に追加する。
図１０を参照する。例えば、オーナー１３０がコサーバ１０２ａから完了メッセージ１４５ａを受信し、そのトランザクションをコミットする要求を受信すると、ＩＰ １１５ｃは据置き制約が存在しないことに注目し、トランザクションの状態をコミット要求に変え、その勘定振替トランザクションを閉止メッセージ１２５−２ｃ内のコミット要求リスト２６０へ追加する。
【００８１】
同様に、もしユーザがトランザクションを打切ることを決定するか、またはもし制約検査に失敗すれば、トランザクションオーナーはＩＰ １１５ｃ内のルーチンを呼出してそのトランザクションを打切りリスト２６２へ追加する。
もしコミットは要求されているが据置き制約が存在すれば、トランザクションオーナーはルーチンを呼出してそのトランザクションを検査要求リスト２６４へ追加する。次いで制約検査要求が、コミットまたは打切りのための要求の同じようにＩＣ １１０へ送られる。次いでＩＣ １１０はそのトランザクション内の全ての関係者へ検査メッセージを送り、制約検査を遂行して結果を報告するように関係者に命令する。もしどのコサーバも制約を侵していなければ、ＩＣ １１０はオーナー１３０が要求を明示しなくとも、そのトランザクションをコミットする。
【００８２】
トランザクションオーナーを含むトランザクション関係者は、ＩＣ １１０からの検査要求に応答して制約検査を完了する。その検査が成功であっても、または不成功であっても、トランザクション関係者はルーチンを呼出してそのトランザクションを検査返答リスト２６６へ追加する。
図１９へ戻って、閉止メッセージ１２５を作成した後、段階３５４においてＩＰは、ＩＰがＩＣに応答してそのインタバルを閉じたことを表す「インタバル閉」ログ記録をトランザクションログ内に入力する。インタバル閉ログ記録は、インタバル番号と、そのインタバルにおいてコミットされたトランザクションのリスト４５５とを含む。書き込み段階３５４が作成段階３５３の後に発生するように示してあるが、書き込み段階３５４は目覚め段階３５７の前のどの時点に発生しても差し支えない。代替実施例では、書き込み段階３５４及び待機段階３５５は、作成段階３５３の前に配置されている。
【００８３】
段階３５５においてＩＰは、最後のローカルインタバルに関するログ記録を含むバッファ６０ｃがディスク２４ｃへフラッシュされるのを待つ。フラッシュは段階３５１に開始されたのであるが、段階３５５の前に完了していないかも知れない。続行する前にバッファ６０ｃのフラッシュを待つことによって、ＩＰ １１５ｃが閉止メッセージを送る時点が確保され、そのローカルインタバルに関する全てのログ記録は非揮発性記憶装置内に格納され、障害が起こっても失われなくなる。次いで、段階３５６においてＩＰは、閉止メッセージ１２５をＩＣ １１０へ送る。
段階３５６において閉止メッセージ１２５をＩＣ １１０へ送った後、段階３５７においてＩＰは、トランザクションの状態が変化しているトランザクション関係者に通告する。ＩＰは、変化した状態スタック４６５内の各記録を調べて適切なトランザクション関係者へ通報するので、その関係者は、例えばトランザクションがコミットされたことをユーザに知らせるような適切な行動を起こすことができる。分離したデータ構造として示してあるが、変化した状態スタック４６５は単に、状態が変化したトランザクションを接続するトランザクション状態テーブル４８０内の１組のリンクであってよい。各リンクは、記録４７０内のポインタ（別の記録４７０を指し示す）であることができる。このような場合ＩＰは、リンクを辿ってハッシュテーブル４８０を通って移動することによってトランザクション関係者に通告する。
【００８４】
通告されたトランザクション関係者は、もしそのトランザクションが打切られていれば、その操作処理を元に戻し、トランザクションログ６４ｃ内に打切りログ記録を入力する。もしトランザクションがコミットされていれば、トランザクション関係者はトランザクションログ６４ｃ内にコミットログ記録を入力する。もし新しい状態が「検査要求」であれば、トランザクション関係者は制約検査を開始することができる。
上述したように、トランザクションが制約検査に成功すれば、そのトランザクションは検査返答リスト２６６内の次の閉止メッセージ１２５内へ含まれる。もしトランザクションが制約検査に成功しなければ、そのトランザクションは検査返答リスト２６６内の次の閉止メッセージ１２５内へ障害として含まれる。
【００８５】
待機段階３５８においてＩＰは、ＩＣ １１０からの次のインタバルメッセージを、時間を決めずに待機する。データベースシステム５はバックアップＩＣ（図２３を参照して後述する）を使用してＩＣ １１０内の障害を検出し、応答する。
段階３５８における待機状態がＩＰの初期状態であることは理解されよう。インタバルメッセージを受信した後に限って、ＩＰは、待機状態から脱してインタバル処理を開始する。
ＩＰ １１５ａのようなＩＰがＩＣ １１０からインタバルメッセージを受信した後、段階３５９においてＩＰは、インタバルメッセージ１２０内に指定されているマスタインタバルタグ２０２を用いてローカルインタバルキー１５５ａをリセットする。次いでＩＰは、段階３５１へループバックしてトランザクションログのフラッシュを要求することによって、新しいローカルインタバルを開始する。
【００８６】
要約すれば各ＩＰは、ＩＣ １１０からのインタバルメッセージ１２０に応答して閉止メッセージ１２５を送り、インタバル閉ログ記録を書き込み、ローカルインタバルキーを維持し、そしてトランザクションの状態が変化するとトランザクション関係者に通告する。トランザクション関係者は制約検査に応答し、コミット及び打切りログ記録をトランザクションログ６４ａ−６４ｃへ書き込む。
図２０に示すように、段階３５２においてＩＰは、インタバルメッセージ１２０を解析する。段階３７１においてＩＰ １１５ｃのようなＩＰは、トランザクション状態テーブル４８０内のトランザクションを調べ、コサーバ１０２ｃがインタバル閉止メッセージ１２０内の次のトランザクション内の関係者であるか否かを決定する。もしコサーバ１０２ｃがそのトランザクションに関与していなければ、ＩＰ １１５ｃはインタバルメッセージ１２０内の次のトランザクションへ移動する。
【００８７】
もしコサーバ１０２ｃがそのトランザクションに関与していれば、段階３７２においてＩＰ １１５はハッシュテーブル４８０内の状態４７４を変える。詳しく説明すれば、トランザクションがコミットリスト２１０、打切りリスト２１２、または検査要求リスト２１４内にあるか否かに依存して、状態４７４はそれぞれ「コミット」、「打切り」、または「検査要求」に変化する。
状態４７４を変化させた後、段階３７３においてコミットされた、及び打切られたトランザクションはトランザクション状態テーブルから除去され、変化した状態スタック４６５に追加される。据置き制約検査に関与したトランザクション関係者は、制約検査が開始されたことを通告される。
コサーバ１０２ｃがトランザクションに関係したものとすれば、段階３７４においてＩＰは、トランザクション状態が「コミット」に変化したか否かを決定する。もしそのように変化していれば、段階３７５においてそのトランザクションは、コミット記録４５０としてコミットリスト４５５（図２２参照）に追加される。コミットリスト４５５は、インタバル閉記録の一部としてトランザクションログ及びディスク２４ｃへコピーされる。
【００８８】
段階３７６においてＩＰは、トランザクションが完了したか否かを決定する。ＩＣメッセージのリスト内に「コミット」または「打切り」として分類されているトランザクションは完了と見做され、「据置き検査」として分類されているものは未だに活動のトランザクションであると見做される。もしトランザクションが完了ならば、段階３７７においてトランザクション記録４７０をハッシュテーブル４８０から除去することができる。
もしさらなるトランザクションが存在しないことが段階３７８によって決定されれば、ＩＰはその解析を完了したのであり、段階３５３へ移動する。
繁忙なシステムでは、コサーバ１０２ｄ上で走るＩＰ １１５ｄは、閉止メッセージ１２０にタイムリに応答できないかも知れない。例えばコサーバ１０２ｄが、その処理能力一杯の極めて複雑な１組の操作処理を実行しているかも知れない。もしＩＰ １１５ｄがインタバルのしきい値数（例えば、 50 乃至 100インタバル）をミスすれば、ＩＣ １１０は、ＩＰ １１５ｄを延期にし、インタバルメッセージをＩＰ １１５ｄへ送るのを中断する。もしＩＰ １１５ｄが「延期」メッセージを送れば、それは不活動としてマークされる。ＩＰ １１５ｄが応答できるようになるとＩＰは「更新要求」メッセージをＩＣ １１０へ送ることができ、ＩＣは「更新」メッセージで応答する。これによりＩＰ １１５ｄは、それがミスした全てのインタバル閉止メッセージを処理することなく現インタバルを取り戻すことができる。
【００８９】
ＩＰ １１５ｄを延期し、後刻それを更新できるようにすると、コサーバが所与の時間内に全てのインタバルメッセージを処理できるようになった時に発生する２つの費用が緩和される。第１の費用は、そのようになっていなければ、全ての介在インタバルメッセージを現在にするためにＩＰ １１５ｄが処理する必要があることである。第２の費用は、ＩＰが応答しなかった全てのインタバルに関する記録をＩＣ １１０が維持しなければならないことである。
ＩＰ １１５ａ−１１５ｇが不活動である場合、ネットワーク資源を保存するためにＩＣ １１０は遊休状態に入ることができる。ＩＰ １１５ａのようなＩＰは、分散したトランザクションがコサーバ１０２ａ上で実行され始めた時から、ＩＰ １１５ａが「遊休」メッセージを送るか、ＩＣ １１０によって延期されるか、または故障してラインから外されるまで活動であると見做される。ＩＰは、もしそれが指定された時間（例えば、100 インタバル）にわたってトランザクション関係者でなければ「遊休」に入ることができ、「遊休」メッセージをＩＣに送る。正常な動作状態の下では、待機段階３０１呼出しが自動的にタイマを失効させる。ＩＣ １１０は、もし活動ＩＰが存在しなければ遊休状態に入ることができる。遊休状態では、ＩＣ １１０はインタバル処理を中止し、代わりにＩＰからのメッセージを、時間を定めずに待機する。ＩＣ １１０は、ＩＣ １１０の健全性を監視するためにそのバックアップＩＣ（図２３を参照して後述する）へメッセージを送るのに十分な頻度で目覚める。
【００９０】
復旧
２つの障害シナリオ、即ちＩＣ １１０を走らせているコサーバの故障、またはデータベースシステムの完全な故障が、ＩＣ １１０に直接影響を与える。両方の故障に対して保護するために、クリティカル情報は、各マスタインタバルが閉じる時にＩＣ １１０によってディスク２４ｄへ書き込まれる（説明の目的から、ＩＣ １１０がコサーバ１０２ｄ上で走っているものとする）。
データベースシステム５においては、トランザクション状態リスト１７０がＩＣ １１０によって非揮発性記憶装置へコピーされると、トランザクションはコミットされる。しかしながら、ＩＣ １１０はコミット記録を恒久的に保持する必要はない。後述するように、ＩＣ １１０は、（このようなトランザクション状態を伝統的にロッギングして恒久的に格納するのではなく）先行マスタインタバルに関するトランザクション状態の「スナップショット」だけを保持することが好ましい。トランザクションがコミットまたは打切られたことをＩＣ １１０がＩＰ １１５ａ−１１５ｇに通報すると、関係者はその情報をそれらのトランザクションログ内に格納する。ＩＣ １１０が各関係者から閉止メッセージを受信すると、ＩＣ １１０はコミットまたは打切り記録が、所与のトランザクションに関係する全てのコサーバのディスク２４ａ−２４ｇ上のそれぞれのログへフラッシュされたことを知る。従って、各コサーバはＩＣをさらに参照することなく所与のトランザクションの最終状態を持続的に解消することができる。この点において、ＩＣは最早トランザクションの最終状態をディスク２４ｄ上のシステムのトランザクション状態の「スナップショット」内に維持する必要はなくなる。従って、データベースシステム５においては、ＩＣ １１０は、各関係者があるトランザクションの状態のログ記録をフラッシュするまで、そのトランザクションの状態の記録を維持する責を負い、一方個々のＩＰはコサーバ及び打切り記録をそれらのローカルトランザクションログ内に恒久的にログする責を負う。
【００９１】
ＩＣ １１０は、ディスク上にシステムの現トランザクション状態の完全且つ正確なコピーが常に存在することを保証するために、二重バッファリング方式を使用する。例えば、もしＩＣ １１０がマスタインタバル＃５に関するログ記録をディスク上の１つの位置へフラッシュすれば、ＩＣ １１０はマスタインタバル＃６を閉じる時そのログ記録をディスク上の異なる位置へ書き込む。ログ記録がフラッシュされてしまえば、マスタインタバル＃５に関するデータは古いものとしてマークされるので、そのディスクスペースはマスタインタバル＃７のために使用することができる。もしマスタインタバル＃７中にディスクへの書き込みに失敗するか、またはもしマスタインタバル＃７のログ記録を書き込んでいる間にデータベースシステム５がクラッシュすれば、マスタインタバル＃６のログ記録は未だにＩＣ １１０の次の適切な操作処理のために完全、正確、且つ十分である。
【００９２】
システム内の全てのコサーバは、現ＩＣ、活動バックアップＩＣ、またはリザーブバックアップＩＣの何れかを含むことができる。図２３に示すように、もしデータベースネットワーク１００が２またはそれ以上のコサーバを有していれば、データベースシステム５は活動バックアップＩＣ ５２０を含んでいよう。活動バックアップＩＣ ５２０がコサーバ１０２ｅ上で走るように示してあるが、活動バックアップＩＣは、ＩＣ １１０が走っているコサーバ１０２ｃを除くどのコサーバ上でも走ることができる。もし、ネットワーク１００が３またはそれ以上のコサーバを有していれば、データベースシステム５は活動バックアップＩＣ ５２０、及び１またはそれ以上のリザーブバックアップＩＣ ５２５ａ、５２５ｂを含むであろう。リザーブバックアップＩＣ ５２５ａ、ｂ、ｄ、ｆ、及びｇは、未だＩＣ １１０及び活動バックアップＩＣ ５２０が走っていない例えばそれぞれコサーバ１０２ａ及び１０２ｇのようなどのコサーバ上でも走ることができる。もし活動バックアップＩＣ ５２０が何時か故障すれば、リザーブＩＣが活動化される。これにより、ＩＣ １１０が使用不能になった場合に素早いレスポンスが得られる。
【００９３】
各マスタインタバルの終わりに、トランザクション情報リスト１７０内のトランザクション状態情報が、「バックアップメッセージ」５３０の形状で、ＩＣ１１０から活動バックアップＩＣ ５２０へ送られる。活動バックアップＩＣ５２０はこの情報をローカル揮発性バッファ２２ｅへコピーし、「承認（またはアクノリッジ）メッセージ」５３５をＩＣ １１０へ送る。承認メッセージ５３５は、活動バックアップＩＣ ５２０がトランザクション状態情報を受信したことをＩＣ １１０へ通告する。しかしながら活動バックアップＩＣ ５２０は、そのトランザクション情報をコサーバ１０２ｅのディスク２２ｅへ書き込まない。ＩＣ １１０は、それが活動バックアップＩＣ ５２０から承認メッセージ５３５を受信するまで、且つＩＣ １１０がトランザクション状態情報をディスク２２ｄへ書き込むまで、ＩＰ １１５ａ−１１５ｇへ閉止メッセージ１２０を送らない。もしＩＣ １１０が承認メッセージ５３５を待たなければ、活動バックアップＩＣ ５２０内の情報が、ＩＰの情報と矛盾するかも知れず、復旧には無用になるであろう。
【００９４】
ＩＣ １１０及び活動バックアップＩＣ ５５０の両方が故障の場合には、ディスク２２ｄ上のマスタインタバル情報５７７は、再始動したＩＣ １１０、再始動したバックアップＩＣ ５５０による、またはリザーブバックアップＩＣ５２５ａ−５２５ｇの１つの活動化によるシステムのトランザクション状態の回復及び再初期化に使用される。
もしＩＣ １１０が指定された時間（例えば、３秒）内に承認メッセージ５３５を受信しなければ、ＩＣ １１０は、活動バックアップＩＣ ５２０が故障して、リザーブバックアップＩＣ ５２５の１つが昇格しているものと考えることができる。同様にもし活動バックアップＩＣ ５２０が指定された時間内に次のバックアップＩＣメッセージ５３０を受信しなければ、活動バックアップＩＣ５２０は、ＩＣ １１０が故障しているものと見做し、その任務を引き継ごうと試みる。
【００９５】
データベースシステム５は、ＩＣ位置の変化及びバックアップＩＣの昇格を処理する構成管理者５４０（例えば、コサーバ１０２ｇ上で走る）を含む。ＩＣ１１０の位置を変えるという構成管理者５４０への要求は、活動バックアップＩＣ ５２０からしか到来しない。もしコサーバ１０２ｅが活動バックアップＩＣとして管理者に認識されれば要求は承認され、コサーバ１０２ｅ上のバックアップＩＣがＩＣ １１０になる。次いで、リザーブバックアップＩＣが活動バックアップＩＣとして昇格する。もし要求者が要求時に活動バックアップＩＣでなければ（例えば、もしそれがコーディネータにより早めに降格されていれば）、その要求は拒否され、コサーバ１０２ａはリザーブバックアップＩＣとして登録される。
【００９６】
本発明の好ましい実施例では、リザーブバックアップＩＣだけが、活動バックアップＩＣになる中間段階を経て、ＩＣ １１０に直接昇格することができる。リザーブバックアップＩＣは、メッセージ５３０を通してグローバルトランザクション状態を受信することによって、または先にログされた故障ＩＣ １１０のグローバルトランザクション状態５７７を受信することによって、活動バックアップＩＣになることができる。代替実施例では、リザーブバックアップＩＣは、システムの現グローバルトランザクション状態を集めるためにＩＰと「ＩＣ使用可」及び「ＩＣ更新」メッセージを交換することによってＩＣ １１０になることもできる。
活動バックアップＩＣ ５２０がＩＣ １１０になると、それはメモリ２２ｅ内の情報を使用してその構造を最新のトランザクション状態で初期化し、情報をディスクへ書き込み、「ＩＣ使用可」メッセージを全てのＩＰ １１５ａ−１１５ｇへ送ってＩＣ １１０の位置が変わったことを通告する。ＩＰからの「ＩＣ更新」応答が、新しいＩＣ １１０のグローバルトランザクション状態を確認するために使用される。これで、トランザクション処理を続行することが可能になる。
【００９７】
リザーブされたバックアップＩＣを、ＩＣ １１０または活動バックアップＩＣに指名変えできるのは構成管理者５４０だけである。先に説明したリザーブバックアップＩＣの活動バックアップＩＣへの昇格、及び活動バックアップＩＣのＩＣ １１０への昇格の両方に関しては、構成管理者が唯一の決定者になっている。この構成管理者とのインタラクションは、２つの独立したインタバルコーディネータからインタバルメッセージを受信することを防ぐために必要である。このような事態は、もしＩＣ １１０が、活動バックアップＩＣ ５２０は死んでいると信じて新しい活動バックアップＩＣを要求し、ＩＣ １１０は故障であると活動バックアップＩＣ ５２０が考えて自分自身をインタバルコーディネータに昇格させると発生し得る。
【００９８】
ある時点にコサーバ１０２ａのようなコサーバが故障すると、そのコサーバはＩＣ １１０によって登録抹消される。コサーバ１０２ａが復旧すると、それはディスク２４ａ上のトランザクションログ６４ａ内に格納されている全ての操作処理を再生することによってロールフォワードする。
もしＩＰ １０２ａがトランザクションログ６４ａに基づいてそのロールフォワードを完了した後に開いたトランザクションが残っていれば、ＩＣ １１０はどのようにしてそれらを解消するかを決定する。ＩＰ １１５ａはＩＣ １１０へ「復旧」メッセージを送り、ＩＣ １１０はメモリ６０ｄ内のトランザクション状態リスト１７０にアクセスしてＩＰ１１５ａが関係者であったトランザクションを見出すことによって応答する。次いでＩＣ １１０はコミットしたトランザクションをリストしている「復旧返答」メッセージをＩＰ １１５ａへ送る。「復旧返答」メッセージによって伝送された情報に対して行動が起こされた後も開いたままのトランザクションは打切られる。コサーバ１０２ａが復旧を完了した後、ＩＰ １１５ａはそのトランザクションログ６４ａをディスク２４ａへフラッシュし、「復旧完了」メッセージをＩＣ １１０へ送る。ＩＣ １１０はコサーバ１０２ａに関するトランザクション情報を、トランザクション状態リスト１７０からクリヤする。全てのトランザクションが解消され、最初の分散したトランザクションが実行され始めると、ＩＰ １１５ａは「使用可」メッセージをＩＣ １１０へ送り、ＩＣ １１０はコサーバ１０２ａを再登録する。
【００９９】
上述した構成では、データベースシステム５は以下に説明する故障シナリオから復旧することができる。
図９を参照する。もしＩＣ １１０によるトランザクションが完了する前にオーナー１３０が故障すれば、ＩＣ １１０は次のインタバルメッセージ内にコサーバ１０２ｃの未解消トランザクションの打切りを含ませ、そのトランザクションは全ての関係者コサーバ上で打切られる。復旧中に、コサーバ１０２ｃはそのトランザクションを打切る。
もしトランザクションがＩＣ １１０によってコミットされた後に故障すればトランザクションの他の関係者は、そのトランザクションが正常にコミットされたことを通報される。しかしながら、ＩＣ １１０はコサーバ１０２ｃが復旧するまで、コサーバ１０２ｃに関する記録をトランザクション状態リスト１７０内に格納している。結局は、復旧プロセス中に、コサーバ１０２ｃはＩＣ １１０へメッセージを送って何等かの未解消トランザクションの最終状態を要求する。ＩＣ １１０は、リスト１７０内の情報に基づいて、オーナー１３０が開始したトランザクションがコミットされたことをＩＰへ通報する。そこでコサーバ１０２ｃはコミットログ記録をトランザクションログ６４ｃ内へ書き込む。
【０１００】
もし、インタバル閉ログ記録がディスク２４ｃへフラッシュされた後にオーナー１３０が故障すれば、復旧中に、コサーバ１０２ｃはトランザクションログ６４ｃ内の情報を使用するだけでトランザクションのローカルコミット処理を完了する。コサーバ１０２ｃとＩＣとのインタラクションは必要としない。
もし、完了メッセージ１４０ａがオーナー１３０へ送られる前にヘルパー１３５ａが故障すれば、コサーバ１０２ｃはコサーバ１０２ａが故障したことを通知し、そのトランザクションは打切られる。コサーバ１０２ｅがトランザクションの打切りをＩＣ １１０へ通知すると、ＩＣ １１０は前述したように、１０２ａを除くトランザクションの全ての関係者にトランザクションの打切りを通知する。復旧中に、コサーバ１０２ａはそのトランザクションを打切る。
【０１０１】
もし、完了メッセージ１４０ａがオーナー１３０へ送られた後ではあるが、ＩＣ １１０がそのログ記録をディスクへフラッシュすることによってそのトランザクションをコミットする前にヘルパー１３５ａが故障すれば、それでもそのトランザクションは他のコサーバ１０２ｂ−１０２ｇ上で進行することができる。もしオーナー１３０が、コサーバ１０２ａの故障を通知する前にコミットを要求されなければ、オーナー１３０はそのトランザクションを打切る。これは、通常のトランザクション打切りとして処理される。もしオーナー１３０が既にコミットを要求されていれば、ＩＣ １１０は、コサーバ１０２ａが故障したことを通知された時にそのトランザクションを打切りとしてマークする。両方の場合に、コサーバ１０２ａは、復旧処理の一部としてそのトランザクションを打切る。
【０１０２】
もし、ＩＣ １１０がそのトランザクションをコミットした後ではあるが、トランザクションログ６４ａ内のコミットログ記録がディスクへフラッシュされる前にヘルパ１３５ａが故障すれば、トランザクション内の他の関係者はそのトランザクションが通常通りコミットされたことを通報される。しかしながら、もしＩＣ １１０は、コサーバ１０２ａが復旧するまでリスト１７０内にそのトランザクションを格納する。結局は、復旧プロセス中に、コサーバ１０２ａはＩＣ１１０へメッセージを送ってその未解消トランザクションの最終状態を要求する。ＩＣ １１０はリスト１７０へアクセスし、そのトランザクションがコミットされたことをコサーバ１０２ａに通報する。そこで、コサーバ１０２ａはコミットログ記録をトランザクションログ６４ａ内に書き込む。
【０１０３】
もし、コミットログ記録がディスク２２ａへフラッシュされた後にヘルパ１３５ａが故障すれば、コサーバ１０２ａは、自分自身のトランザクションログ６４ａを使用してそのトランザクションがコミットされたか否かを決定する。ＩＣとインタラクトする必要はない。
もしＩＣ １１０が故障し、活動バックアップＩＣがコーディネータまたはコサーバのホスティングの役割を果たすまで、分散したトランザクションをコミットまたは打切ることができなければ、コーディネータがラインに戻される。何れの場合も、保管されていたグローバルトランザクション状態が復元され、「ＩＣ使用可」メッセージがＩＣに登録された全ての関係者へ送られる。
もしオーナー１３０及びヘルパー１３５ａが故障すれば、その状況は一方または他方が故障した場合と同じように処理される。
【０１０４】
もし全システムが故障（全てのコサーバ１０２ａ−１０２ｇが故障）すれば、データベースシステム５が復旧した時に、リスト１７０内に保管されていたトランザクション状態５７７がディスク２２ｄから復元され、ＩＣ １１０は、クラッシュ時に活動または遊休として登録されていた全てのコサーバへ「ＩＣ使用可」メッセージを送る。次いでＩＣ １１０は返答を待つ。各コサーバは復旧情報に関する要求を送り、その復旧のロールフォワード段階を完了した後も開き続けているトランザクションを解消する。
活動バックアップＩＣが使用不能であり、ＩＣ １１０を走らせているコサーバが故障すれば、以下の２つの動作の一方が行われる。もしデータベースシステム５がコサーバ再始動をサポートしていれば、分散した全てのトランザクションの終止は、ＩＣが再始動できるまで遅らされる。もしコサーバの再始動が不可能であれば、データベースシステム５は、ＩＣ １１０またはバックアップＩＣが再始動するまでトランザクションを処理することはできない。
【０１０５】
若干のトランザクションは、複数のデータベースシステムにわたっている。このようなトランザクションの場合には、本発明のデータベースシステムは外部データベースシステムとインタラクトしなければならない。外部データベースシステムは、標準２相コミットプロトコルのような異なるコミットメントプロトコルを使用しているかも知れない。外部データベースシステムとインタラクトするデータベースシステム１００を必要とするトランザクションを、外部トランザクションと呼ぶ。外部トランザクションの場合には、本発明のコミットメントプロトコルは、２相コミットにおける関係者のセマンティック要求を満足できなければならない。
データベースシステム１００は、２つの例外を除いて、外部トランザクションを通常の内部トランザクションとして処理することができる。第１は、データベースシステム１００は、外部データベースシステムが使用しているグローバル外部トランザクション識別子と、データベースシステム１００のＩＰ及びＩＣが使用している内部識別子との間で写像（またはマッピング）を行うことである。
【０１０６】
第２は、もし外部トランザクションが「コミット要求」状態に入っていれば、外部トランザクション内の各内部関係者が閉止メッセージを送った後に、ＩＣが外部トランザクションを「休止」状態に置く。外部トランザクションが「休止」状態に入った後に、データベースシステム１００は、外部トランザクションを準備するための外部要求に応答して成功状態を取り戻すことができる。続いて、外部要求に応答して、ＩＣは外部トランザクションの状態を「打切り」または「コミット」に変えることができる。
復習すれば、本発明はコンピュータネットワーク上の分散データベースシステム内に分散したトランザクションをコミットする方法である。分散データベースシステムは、コサーバと呼ぶ複数のデータベースサーバからなる。コンピュータネットワーク内のコンピュータまたはノード上には１より多くのコサーバが存在し得る。インタバルコーディネータ（ＩＣ）はコサーバの１つに存在し、インタバル関係者（ＩＰ）は各コサーバに存在する。ＩＣは「インタバルメッセージ」と呼ぶメッセージを各ＩＰへ定期的に送出する。インタバルメッセージは、連続する各インタバル毎にＩＣによって増加させられるインタバル識別子を含み、新しいインタバルが開始されたことをＩＰに通告する。各ＩＰは、そのローカルインタバルを指定するインタバルカウンタを維持している。インタバルメッセージに応答して、ＩＰはそのインタバルカウンタをインタバル識別子からの値にセットし、そのコサーバに関連するトランザクションログを非揮発性記憶装置へフラッシュする。ログをフラッシュした後、ＩＰは「閉止メッセージ」と呼ぶメッセージをＩＣへ送り返す。
【０１０７】
分散トランザクションに関与している各コサーバはそのトランザクション内の関係者である。トランザクションを発した関係者を「オーナー」と呼び、他の関係者を「ヘルパー」と呼ぶ。ヘルパーはデータベース更新を完了すると、そのインタバルカウンタの値でタグを付けられた応答メッセージをオーナーへ送る。
オーナーは何れかの関係者によるトランザクションの更新に関連する最新のタグを格納する。ユーザ（即ち、トランザクションオーナー）がトランザクションをコミットすることを要求する場合、オーナーはトランザクションのコミット要求を、格納したタグ及びトランザクションに関係しているコミットのリストと共にＩＣへ伝送する。この要求は、次の閉止メッセージ中に送ることができる。
ＩＣは、全てのＩＰがあるインタバルのための閉止メッセージを送るまで、そのインタバルに関する記録を格納する。ＩＣは、そのトランザクション内の関係者の全てがあるインタバル（そのトランザクションに関して格納したタグに等しいか、またはより新しいインタバル）のための閉止メッセージを送ったと決定すると、そのトランザクションをコミットすることができる。トランザクションをコミットできるとＩＣが決定すると、ＩＣはそのトランザクションに関するコミット記録をＩＣのログへ書き込む。コミットされたトランザクションのリストは、次のインタバルメッセージ内に含まれる。ＩＣのログは、インタバルメッセージが送られる前に非揮発性記憶装置へフラッシュされるから、トランザクションをコミットするためのＩＣの復旧可能性が保証される。
【０１０８】
コミットするトランザクションのリストを含むインタバルメッセージの受信に応答して、各コサーバは、それが関係者であった各トランザクション毎のトランザクションログ内にコサーバログ記録を入力する。トランザクション内の全ての関係者がそのインタバルのための閉止メッセージ（トランザクションのコミット通知を含む）を送ってしまうと、ＩＣはそのトランザクションを忘れることができる。
このコミットプロトコルは、特にマルチノード並列処理コンピュータにおいて、交換されるメッセージの数を大幅に減少させ、それによって分散データベースシステムの性能を改善する。
以上に本発明の好ましい実施例に関して説明した。しかしながら、本発明はこの実施例に限定されるものではない。本発明の範囲は特許請求の範囲によってのみ限定されるものである。
【図面の簡単な説明】
【図１】コンピュータネットワークの概要図である。
【図２】コサーバネットワークの概要図である。
【図３】あるネットワークに接続されている２台のコンピュータのブロック線図である。
【図４】コンピュータデータベースの例である。
【図５】分散データベースのブロック線図である。
【図６】分散データベースが使用する２つのトランザクションログの例である。
【図７】本発明によりインタバルコーディネータ及び複数のインタバル関係者が走っているコサーバネットワークの概要図である。
【図８】本発明による分散データベースシステムの概要図である。
【図９】本発明によりインタバル関係者とインタバルコーディネータとの間のメッセージの交換を示すブロック線図である。
【図１０】オーナー、ヘルパー、及びインタバルコーディネータの間のメッセージの交換を示す時間線である。
【図１１】（Ａ）、（Ｂ）、及び（Ｃ）は、図１０の時点Ａ、Ｂ、及びＣに本発明の分散データベースによって維持されるコサーバログの例である。
【図１２】インタバルメッセージの概要図である。
【図１３】閉止メッセージの概要図である。
【図１４】インタバルコーディネータのプロセスの流れ図である。
【図１５】待ち行列内のメッセージを処理する方法の流れ図の一部である。
【図１６】図１５の流れ図の続きである。
【図１７】トランザクション状態リストを処理する方法の流れ図の一部である。
【図１８】図１７の流れ図の続きである。
【図１９】インタバル関係者のプロセスの流れ図である。
【図２０】インタバルメッセージを解析する方法の流れ図である。
【図２１】インタバルコーディネータが使用するデータ構造のブロック図である。
【図２２】インタバル関係者が使用するデータ構造のブロック図である。
【図２３】バックアップ内部コーディネータを使用する分散データシステムのブロック線図である。
【符号の説明】
５ 分散データベースシステム
１０ コンピュータネットワーク
１２ コンピュータ
１４ ネットワークライン
１６ サーバ
１８ プリンタ
２０ ＣＰＵ
２２ メモリ
２４ 記憶装置
２６ バス
３０ データベース
３２ 小切手勘定テーブル
４２ 預金勘定テーブル
６０ トランザクションバッファ
６４ トランザクションログ
７０−７４ ログ記録
１００ 分散データベースプログラム
１０２ コサーバ
１１０ インタバルコーディネータ
１１５ インタバル関係者
１２０ インタバルメッセージ
１２５ 閉止メッセージ
１３０ オーナー
１３５ ヘルパー
１４０ 要求メッセージ
１５０ マスタインタバルキー
１５５ ローカルインタバルキー
１６０ ログ記録
１７０ トランザクション状態リスト
１８０ 待ち行列
１８５ タイマ
４２５ インタバルアレイ
４３５ 最後のタグアレイ
４４５ 検査返答アレイ
４５５ コミットリスト
４６５ 変化した状態スタック
４７０ トランザクション状態テーブル
５２０ 活動バックアップＩＣ
５２５ リザーブＩＣ
５４０ 構成管理者

Claims (8)

1. 分散データベースシステムにおいて、オーナーとヘルパーとを含む分散したトランザクションをコミットする方法であって、
   インタバルコーディネータを走らせる段階と、
   複数のコサーバ、第１のコサーバに関連付けられている上記オーナー、及び第２のコサーバに関連付けられている上記ヘルパーを走らせる段階と、
   上記コサーバを、少なくとも１つのトランザクションログに関連付ける段階と、
   一連のインタバルメッセージを、上記インタバルコーディネータから上記各コサーバへ送る段階と、
   上記インタバルメッセージの１つの受信に応答して、上記トランザクションログを、非揮発性記憶装置へフラッシュする段階と、
   最も新しく受信したインタバルメッセージを識別する状態を、上記各コサーバ内に維持する段階と、
   上記トランザクションログをフラッシュした後に、閉止メッセージを、上記各コサーバから上記インタバルコーディネータへ伝送する段階と、
   上記第２のコサーバに実行させる上記分散したトランザクション内の操作処理を識別する要求メッセージを、上記オーナーから上記ヘルパーへ伝送する段階と、
   上記処理操作を実行した後に、上記第２のコサーバの上記最も新しく受信したインタバルメッセージを識別するタグを含む完了メッセージを、上記ヘルパーから上記オーナーへ伝送する段階と、
   上記完了メッセージを受信した後に、上記トランザクションについての適格性メッセージを、上記オーナーから上記インタバルコーディネータへ伝送する段階と、
   上記オーナーから上記適格性メッセージを受信し、且つ上記ヘルパーから閉止メッセージを受信した後に、上記トランザクションに関するコミット状態を、安定した記憶装置へ書き込む段階と、
   上記コミット状態を書き込んだ後に、上記トランザクションのコミットメッセージを、上記インタバルコーディネータから上記オーナー及び上記ヘルパーへ送る段階と、
   を備えていることを特徴とする方法。
2. 上記コミットメッセージは、上記インタバルメッセージを伴っている請求項１に記載の方法。
3. 上記適格性メッセージは、上記閉止メッセージを伴っている請求項１に記載の方法。
4. もし上記オーナーの状態が、上記タグと同一のインタバルメッセージを識別していれば、または上記オーナーの状態が、上記タグより早めのインタバルメッセージを識別していれば、上記適格性メッセージが送られるようにした請求項１に記載の方法。
5. 上記トランザクションは複数のヘルパーを含み、上記オーナーは複数の要求メッセージを上記複数のヘルパーへ伝送し、上記各ヘルパーは完了メッセージを上記オーナーへ伝送し、上記インタバルコーディネータは上記各ヘルパーから閉止メッセージを受信した後にコミットメッセージを上記オーナー及び上記各ヘルパーへ送る請求項１に記載の方法。
6. 上記コミットメッセージは、コミット命令である請求項１に記載の方法。
7. 上記コミットメッセージは、打切り命令である請求項１に記載の方法。
8. 上記各コサーバは、トランザクションログを有している請求項１に記載の方法。

Images