JP3790589B2 - 分散データベーストランザクションのコミットメント方法 - Google Patents
分散データベーストランザクションのコミットメント方法 Download PDFInfo
- Publication number
- JP3790589B2 JP3790589B2 JP29185696A JP29185696A JP3790589B2 JP 3790589 B2 JP3790589 B2 JP 3790589B2 JP 29185696 A JP29185696 A JP 29185696A JP 29185696 A JP29185696 A JP 29185696A JP 3790589 B2 JP3790589 B2 JP 3790589B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- interval
- message
- coserver
- owner
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 70
- 230000004044 response Effects 0.000 claims abstract description 42
- 238000011010 flushing procedure Methods 0.000 claims abstract description 10
- 238000012545 processing Methods 0.000 claims description 42
- 230000008569 process Effects 0.000 description 51
- 238000012546 transfer Methods 0.000 description 24
- 238000011084 recovery Methods 0.000 description 22
- 239000000872 buffer Substances 0.000 description 15
- 238000010586 diagram Methods 0.000 description 14
- 230000008859 change Effects 0.000 description 10
- 206010000210 abortion Diseases 0.000 description 8
- 230000009471 action Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 230000008901 benefit Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 5
- 238000007689 inspection Methods 0.000 description 4
- 238000012360 testing method Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000011156 evaluation Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 231100000176 abortion Toxicity 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99937—Sorting
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99939—Privileged access
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明は、一般的には分散データベーストランザクションのためのコミットメントプロトコルに関し、より詳しく述べれば、コーディネータが関係者と定期的にメッセージを交換するようなコミットメントプロトコルに関する。
【0002】
【従来の技術】
どのようなデータベースシステムでも、その基本的な設計の目標は「一貫性」であり、これはデータベース内に格納されている情報を若干の制約に従わせることを意味する。例えば、預金勘定から小切手勘定へ金銭を振替える場合、2つの勘定の合計を同一に保たなければならない。もし預金勘定に借方には記入したが小切手勘定の貸方に記入しなければ顧客は不満を抱くであろう。一方、もし小切手勘定の貸方には記入したが預金勘定の借方に記入しなければ銀行が不満であろう。
操作処理( operation ) とは、例えばデータベース内の情報の単片の改訂、削除、または挿入のような変更のことである。トランザクション( transaction ) とは、データベースアプリケーション内で単一の論理動作を遂行する操作処理の集まりのことである。例えば、勘定振替を行うことはトランザクションである。預金勘定の借方に記入することは勘定振替トランザクションにおける1つの操作処理であり、小切手勘定の貸方に記入することは別の操作処理である。一貫性を保存するためには、あるトランザクションの全ての操作処理が遂行されなければならないか、または何も遂行しないことである。この要求を、「アトミシティ」( atomicity ) と呼ぶ。
【0003】
通常の状態の下では、トランザクションの全ての操作処理を遂行するだけで、課せられた制約はデータベースシステムによって遵守される。しかしながら、ソフトウェアのバグ、ハードウェアのクラッシュ、及び停電は、データベースシステムに障害を発生させる。障害が発生すると、例えばランダムアクセスメモリ(RAM)のような揮発性メモリ内の情報が失われ、一貫性が損なわれる可能性がある。例えば、銀行データベースシステムにおいて、預金勘定の借方には記入したが、小切手勘定の貸方に記入する前にクラッシュが発生するかも知れない。従って、データベースシステムの設計上の別の目標は、障害から復旧した時に揮発性メモリ内に格納した情報を復元する能力である。
たとえ障害が発生したとしても一貫性を保証するようにするために、データベースシステムがトランザクションの全ての操作処理を実行するのか、または全く実行しないのかを保証することはクリティカルである。ある場合にはトランザクションが一貫性を損なわせたことが原因でそのトランザクションを完了させることができず、またある場合には障害が原因でトランザクションを完了させることができない。ある場合には、ユーザが変心して、トランザクションを完了させないことを決定するかも知れない。もしトランザクションを成功裏に完了させることができずに若干の操作処理しか実行されなければ、そのトランザクションは「打切り」にしなければならない。打切られたトランザクションの後に、データベースはそのトランザクションを前の状態に「ロールバック」即ち復元される。
【0004】
一方、もし障害が起こっても、トランザクションの全ての操作処理を成功裏に実行することができれば、そのトランザクションは「コミット」される。もし障害が発生して若干の操作処理だけが実行されれば、コンピュータが復旧した時、コミットされたトランザクションは「ロールフォワード」即ち完了され、打切られたトランザクションは「ロールバック」即ち元に戻される。
換言すれば、もしコンピュータが障害の後に復旧すれば、コミットされたトランザクションはデータベース内に格納されていることが保証され、コミットされなかったトランザクションはデータベース内に格納されていることは保証されない。
全ての操作処理要求を保証する、または保証しない一つの方法は、データベースシステムに「コミットメントプロトコル」を課すことである。要約すれば、コミットメントプロトコルは、例えばハードディスクのような非揮発性記憶装置内にトランザクションログを維持することを要求する。トランザクションログは、そのトランザクションをロールバック、または完了させるのに十分な情報を含むログ記録のリストである。ログ記録は、各トランザクションの始まりに関するデータ、そのトランザクションによって変更された記録の古い値と新しい値、及びそのトランザクションがコミットされたのか、または打切られたのかの情報を含む。
【0005】
データベースの変化が非揮発性記憶装置に書き込まれた後に、打切りが発生するかも知れない。このような場合、打切られたものとしてマークされたトランザクションは、変更された記録を古い値にセットすることによって元に戻される。例えば、銀行データベースシステムが、改訂された小切手勘定の残高( balance ) をハードディスクに書き込んだが、借方が預金勘定の残高を0以下に減らすことになるかも知れない。データベースシステムは、トランザクションログに打切りを書き込み、小切手勘定の残高を古い値に戻す。
コミットメントの後ではあるが、変化が非揮発性記憶装置へ書き込まれる前に障害が発生するかもしれない。このような場合、トランザクションログ内にコミット済みとしてマークされているトランザクションは、古い記録を新しい値にセットすることによってやり直される。例えば、銀行データベースシステムは、RAM内の小切手及び預金勘定の残高を成功裏に改訂して検査し、トランザクションログのコミットメントをディスク上に書き込むが、RAM内の変化をディスクへ格納する前に停電になることがあるかも知れない。データベースシステムが復旧した時に、データベースシステムはトランザクションログを探索して勘定振替トランザクションがコミットされていることを決定し、借方・貸方操作処理をやり直す。
【0006】
分散データベースとは、記録がコンピュータネットワーク内の異なる幾つかのコンピュータまたはノードに格納されているような、または記録を格納しているコンピュータまたはノード以外のコンピュータまたはノードから記録を改訂する要求が発せられるようなデータベースのことである。例えば、小切手勘定記録を第1のコンピュータが格納し、預金勘定記録を第2のコンピュータが格納し、そして銀行の金銭出納係が使用する第3のコンピュータから預金勘定から小切手勘定への資金の振替要求を発することができる。例えば、ローカルに格納されている情報を変更するために、ある操作処理を実行することによってそのトランザクションに関与する全てのコンピュータを「関係者」( participant ) と呼ぶ。トランザクションを発した関係者をそのトランザクションの「オーナー」( owner ) と呼ぶ。
【0007】
「コンピュータネットワーク」は、高速ノード間に接続を有している複数の処理ノードからなる(並列コンピュータのような)単一のコンピュータであることができる。「コンピュータネットワーク」は相互接続されたコンピュータのクラスタであることもできる。本明細書においては、これら各種コンピュータシステムをコンピュータネットワークであるとし、これらのシステム上のデータベースを分散データベースシステムと呼ぶことにする。
分散データベースプログラムとインタラクトする銀行の出納係のような人を「ユーザ」と呼ぶ。ユーザは、データベースプログラムにおいては、各トランザクション毎の1またはそれ以上の「セッション」によって表される。セッションとは、データベース記録の改訂のようなトランザクションの実際の仕事を行うために作成されるプログラムエンティティのことである。通常は、トランザクションの各関係者には、トランザクション当たり1セッションが存在する。オーナー上で走るセッションが「トランザクションオーナー」である。他のセッションを「トランザクションヘルパー」( helper )と呼ぶことができる。
【0008】
障害の影響は、分散データベースシステムと単一コンピュータシステムとでは若干異なる。単一コンピュータシステムにおいては、システムが動作してトランザクションが正常に処理されているか、またはシステムが障害を起こしてトランザクションを処理できないかの何れかである。分散システムにおいては、若干のコンピュータは動作しているが、他のコンピュータは動作していないような部分的障害が存在し得る。また、コンピュータは動作しているが、コンピュータ間の通信リンクが故障しているような部分的障害も存在し得る。
分散データベースシステムの一つの主要な利点は、性能が改善されることである。別の主要な利点は拡張可能性(スケーラビリティ)、即ち性能を劣化させることなくデータベースシステムを成長させ得る能力である。別の利点は、信頼性が改善されることである。普通は部分的障害しか発生しないから、データベースシステムの性能が低下することはない。しかしながら、部分的障害が発生する可能性があるということは、一貫性の保証を一層困難にする。例えば、預金勘定記録を有するコンピュータが正常に機能していて借方から控除しているが、小切手勘定記録を有するコンピュータが故障して貸方に加算しないかも知れない。
【0009】
一貫性を保存するために、この例における2つのコンピュータは互いに通信し合って振替トランザクションをコミットすべきか、または打切るべきかを決定しなければならない。そのトランザクションに関与する全てのコンピュータが同一の行動(コミットまたは打切り)を行うことを保証するコンピュータ間の通信の構造及び方法を、「コミットメントプロトコル」と呼ぶ。
分散データベーストランザクションのための現在の標準コミットメントプロトコルを「2相コミット(2PC)プロトコル」と呼んでいる。2相コミットプロトコルは、概ね次のように動作する。
第1に、「コミット可」相において、トランザクションオーナーはコミットのための準備メッセージを各関係者へ送り、コミットか、打切りかを投票で応答するように各関係者に依頼する。各関係者は、そのトランザクションのコミット、または打切りの何れを望むかを決定する。
【0010】
もし関係者がそのトランザクションをコミットすることを望めば、その関係者は、そのトランザクションがコミットメント可であることを非揮発性記憶装置内のそのローカルトランザクションログへ記録する。ローカルトランザクションログは、そのトランザクションによってなされたローカル変化の古い値及び新しい値をデータベースへ既に記録していよう。そこで関係者は“yes”投票をオーナーへ送り返す。
もし関係者が打切りを決定すれば、その関係者は、トランザクションの打切りを非揮発性記憶装置へ記録して“no”投票をオーナーへ送り返す。関係者が打切りを決定する理由は数多くある。そのデータベースに課せられたある一貫性を操作処理が損なうかも知れない。例えば、もし預金勘定の借方がその預金勘定の残高を0以下に減ずるようなことがあれば、その関係者はその振替トランザクションを打切るであろう。
【0011】
第2に、「決定」相においてオーナーは、関係者からの全ての投票を集める。もし全ての関係者の投票が“yes”であれば、オーナーはそのトランザクションのコミットを非揮発性記憶装置内のトランザクションログ内に記録する。この点でそのトランザクションはコミットされる。次いでオーナーは各関係者へメッセージを送ってそのトランザクションをコミットさせる。
もし何れかの関係者が“no”を投票すれば、オーナーはそのトランザクションの打切りを非揮発性記憶装置へ記録し、各関係者へメッセージを送ってそのトランザクションを打切らせる。コミット可であることを非揮発性記憶装置内へ記録した各関係者は、行動を起こすために、オーナーからのコミットメッセージ、または打切りメッセージを待つ。
【0012】
不幸にも、2相コミットはメッセージ重視プロトコルである。詳しく説明すれば、個々のトランザクション毎に1組のメッセージを交換し、コミットメッセージに対して特別に準備するので大量のネットワークトラフィックを作り出す。2相コミットでは、コミットメントネットワークを通して送られるメッセージの数は、トランザクションの数及び各トランザクションの関係者の数に比例する。多数の小さいトランザクションを有するシステムの場合には、2相コミットがネットワークに大きい負担をかけ得る。
【0013】
【発明の目的】
以上に鑑みて、本発明の目的は、ネットワークの使用を最小にする分散データベースコミットメントプロトコルを提供することである。
本発明の別の目的は、殆どの動作条件の下で2相コミットよりも優れている分散データベースコミットメントプロトコルを提供することである。
本発明の他の目的及び長所は以下の説明から理解されよう。本発明の目的及び長所は、特に特許請求の範囲に指摘されている手法及び組合わせによって実現できる。
【0014】
【発明の概要】
本発明は、分散データベースシステム内に分散したトランザクションをコミットする方法を目指している。データベースシステムは、インタバルコーディネータ、複数のコサーバ( coserver )、及び少なくとも1つのトランザクションログを含む。インタバルコーディネータは一連のインタバルメッセージを各コサーバへ送り、各コサーバはそれに応答してその関連トランザクションログを非揮発性記憶装置へフラッシュする。トランザクションログをフラッシュした後に、各コサーバは閉止メッセージをインタバルコーディネータへ伝送する。コサーバは、最も新しく受信したインタバルメッセージを識別する状態を維持する。各分散トランザクションは、オーナー及びヘルパーを関連コサーバと共に含む。あるトランザクションに関して、オーナーは、関連コサーバに実行させる分散したトランザクションの操作処理を識別する要求メッセージをヘルパーへ伝送する。操作処理を実行したコサーバは、最も新しく受信したインタバルメッセージを識別するタグと共に、完了メッセージをオーナーへ伝送する。この完了メッセージを受信した後、オーナーはそのトランザクションについての適格性メッセージをインタバルコーディネータへ伝送する。次いでインタバルコーディネータは、そのトランザクションについてのコミット状態を安定な記憶装置へ書き込む。コミット状態を安定な記憶装置へ書き込んだ後に、インタバルコーディネータは、そのトランザクションについてのコミットメッセージをオーナー及びヘルパーへ送る。
【0015】
以下に添付図面を参照して本発明の好ましい実施例を説明する。
【0016】
【実施例】
図1に示すように、分散データベースはコンピュータネットワーク10上で動作する。コンピュータネットワーク10は、ネットワークライン14によって接続されたワークステーションのような複数のコンピュータ12a−12gを含んでいる。勿論、ネットワーク10は図示の7つのコンピュータよりも少ない、または多いコンピュータを有することができる。ネットワーク10は、サーバ16及びプリンタ18のような他のデバイスをも含んでいる。増殖的に相互接続されるように図示されているが、コンピュータネットワーク10は環状、星形、樹木、または他のどのような相互接続トポロジを使用することもできる。コンピュータネットワーク10は、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、クラスタ相互接続、または相互接続スイッチを通して通信する複数の処理ノードを有する単一のコンピュータであることができる。高性能デバイスシステムの場合には、ネットワーク10はマルチノード並列処理コンピュータ、またはクラスタであることが好ましい。しかしながら、明瞭化のために、以下のデータベースシステム5はLANネットワークとして説明する。
【0017】
コンピュータネットワーク10の故障は不可避である。若干の故障は、ノード(コンピュータ12a−12g)間の通信リンクが関連している。例えば、ネットワークライン14が切断されることがあり得るし、またはネットワークライン14上のメッセージの量がネットワークの容量を超えることもあり得る。他の故障は、コンピュータ12a−12gが関連するものである。例えば停電は、1またはそれ以上のコンピュータを停止させたり、または特定コンピュータの構成要素を誤動作させかねない。
図2に示すように、分散データベースシステム5は、分散データベースプログラム100を備えている。データベースプログラム100は、通信リンク104によって接続されているコサーバ102a−102gを含んでいる。各コサーバ102a−102gは、単一のノード上で共働するデータベースプログラムの集まりである。各コサーバは、通信リンク104を介して、格納、保管、データ操作、及び通信能力を提供することができる。典型的には任意の1つのコンピュータノード上では1つのコサーバしか走らないが、複数のコサーバを単一のコンピュータノード上で走らせることも可能である。更に、ネットワーク内の若干のコンピュータはコサーバをサポートしないことができる。
【0018】
データベースネットワーク100も故障を起こすことがあり得る。例えば、ソフトウェアにバグがあると、コサーバ102dのような特定のコサーバをクラッシュさせ得る。勿論、コサーバ102aをサポートしているコンピュータ12aが部分的に、または完全に故障すると、データベースプログラム100に障害がもたらされる。
図3に示すように、コンピュータネットワーク10は、LANのようなネットワークライン14に接続されている1組のコンピュータとして表すことが可能である。ネットワークライン14は制限された帯域幅容量を有している。即ち、ネットワークライン14は、一時に制限された量の情報しか輸送することができない。例えば、もしネットワークがイーサネットであれば、典型的に 10 メガビット/秒を処理することができる。
【0019】
コンピュータ12aのような各コンピュータは、少なくとも1つの中央処理ユニット(CPU)20a、メモリ22a、及び記憶装置24aを含んでいる。メモリ22aは、ランダムアクセスメモリ(RAM)のような揮発性記憶装置であり、停電の場合にはその内容は失われる。記憶装置24aは、1またはそれ以上のハードディスクのような非揮発性記憶装置である。クラスタ構成では、コンピュータは非揮発性記憶装置へのアクセスを共用することができる。CPU 20a、メモリ22a、及び記憶装置24aは、バス26aによって相互接続されている。典型的には、ネットワークライン14もバス26aを通してコンピュータ12aに接続されている。
図4に示すように、データベース30は関連情報の集まりである。典型的にはデータベースは、情報を、類似情報の列(「フィールド」と呼ぶ)と、関連情報の行(「記録」と呼ぶ)とを有するテーブル内に格納する。例えば銀行は、小切手勘定及び預金勘定を監視するためにデータベース30を使用できる。小切手勘定テーブル32は、顧客名34、小切手勘定番号36、及び現在の小切手勘定残高38を格納するフィールドを有することができる。預金勘定テーブル42も同様に、顧客名44、預金勘定番号46、及び現在の預金勘定残高48を格納するフィールドを有することができる。例えば、データ記録50は、顧客 G. Brown が小切手勘定番号 745-906内に$2500.00 の残高を有していることを示す。特定フィールド内の特定データ記録を「エントリ」と呼ぶ。例えばエントリ55は、M. Karvel の小切手勘定が$600.00であることを示している。
【0020】
図5に示すように、分散データベースシステム5は、コサーバ102a及び102b上のデータベース30からの情報を格納する。コサーバ102a及び102bに関連しているのは、それぞれコンピュータ12a及び12bのメモリブロック22a及び22b、及び非揮発性記憶装置24a及び24bである。小切手勘定テーブル32をハードディスク24a上に格納し、預金勘定テーブル42をハードディスク24b上に格納することができる。コサーバ102aは小切手勘定テーブル32内の情報の操作処理を実行することができ、コサーバ102bは預金勘定テーブル42内の情報の操作処理を実行することができる。
各コサーバはトランザクションログへのアクセスを有している。各コサーバ毎に1つのトランザクションログを設けることが好ましい。例えば、コサーバ102aのトランザクションログ64aの一部はメモリ22aのバッファ60a内に、また一部はハードディスク24aのディスクスペース62a上に格納される。バッファ内のトランザクションのリストが非揮発性ディスクへ書き込まれると、そのトランザクションログは「ディスクへフラッシュ」されたと称される。
【0021】
コサーバのトランザクションログを、同一の記憶装置上の1またはそれ以上のトランザクションログとして一緒に多重化することが可能である。コサーバ102a−102gがどのように記憶装置またはログを共用するかには拘わりなく、書き込み及びフラッシングに関連するセマンティクス及び動作は同一に維持される。従って、特定の各コサーバにおけるトランザクションのロギング及びコミットの処理は影響を受けない。
2以上のコサーバを単一のコンピュータまたはノードにおいて動作させることができるので、データベースシステム5の関係者の定義を明白にしておかなければならない。本明細書では、そのトランザクションに関与している全てのコサーバが「関係者」であり、トランザクションを発した関係者がそのトランザクションの「オーナー」である。そのトランザクションの関係者ではあるが、オーナーではないコサーバが「ヘルパー」である。例えば、以下に説明する勘定振替トランザクションでは、コサーバ102a−102bはそのトランザクションのヘルパーであり、コサーバ102cがそのトランザクションのオーナーである。
【0022】
図5及び6に関して説明したように、データベースシステム5は、M. Karvel の預金勘定から小切手勘定へ$1000を振替えるような、データベース30上の分散したトランザクションを実行することができる。例えば、もし銀行の出納係がコサーバ102cにおいてトランザクションに関する要求を入力すれば、コサーバ102cが勘定振替トランザクションのオーナーになる。コサーバ102cは、コサーバ102aの小切手勘定テーブル32を制御し、102bが及び預金勘定テーブル42を制御していることを判断する。コサーバ102cは、小切手勘定$100 を貸方に記入する操作処理を伴うメッセージを、コサーバ102aへ送り、また預金勘定$100 を借方に記入する操作処理を伴うメッセージを、コサーバ102bへ送る。メッセージは、そのトランザクションを識別するトランザクションコードと、オーナーを識別するオーナーコードとを含んでいる。
【0023】
メッセージがコサーバ102aに到着すると、コサーバ102aはログ記録70aを書き込んで勘定振替トランザクションの開始を表す。もしこの顧客の小切手勘定のデータ記録52(図4参照)がメモリ22a内に未だ存在していなければ、データ記録52がディスク24aからメモリ22a内に読み込まれる。次いで、貸方操作処理がデータ記録52の残高フィールド38上で遂行され、残高エントリ55が$100 だけ増加される。別のログ記録72aがトランザクションバッファ60aに追加され、エントリ55の古い値($600 )と新しい値($700 )とが記録される。結局は、以下に詳細を説明する本発明のコミットプロトコルに従って、勘定振替トランザクションがコミットされたのか、または打切られたのかに関するログ記録74aがトランザクションバッファ60a内に記録される。2相コミットプロトコルとは異なり、本発明では勘定振替トランザクションが準備されたか、またはコミットに適格であるかのログ記録はバッファ60a内に記録されない。
【0024】
借方操作処理についてコサーバ102bが遂行するプロセスは、預金勘定記録53(図4参照)がメモリ24b内へ読み込まれることを除いて、極めて類似しており、借方操作処理が残高エントリ56上で遂行される。ログ記録72bは残高エントリ56の古い値($1300)及び新しい値($1200)を記録する。ログ記録70bは振替トランザクションの始まりを表し、ログ記録74bはその振替トランザクションがコミットされたのか、または打切られたのかを表している。
ディスク24a上のテーブル32は、残高エントリ55の古い値及び新しい値を有するログ記録72aがディスクへフラッシュされた後の任意の時点に、残高エントリ55の新しい値を用いて更新することができる。同様に、ディスク24b上のテーブル42は、ログ記録72bがディスクへフラッシュされた後の任意の時点に、残高エントリ56の新しい値を用いて更新することができる。
【0025】
以下に説明するように、本発明のデータベースシステムは、トランザクションのオーナーと、非オーナーである関係者との間に直接的なメッセージの交換を必要とせずに分散したトランザクションをコミットし、またあるトランザクションをコミットする前にそのトランザクションに関連する全てのログバッファがディスクへフラッシュされていることを保証する。これは、「インタバルコーディネータ」(IC)と、2またはそれ以上の「インタバル関係者」(IP)との間で定期的にメッセージを交換することによって達成される。インタバルコーディネータは、トランザクションがコミットされるか、または打切られる時点を決定するプログラムである。インタバル関係者は、トランザクションの更新に関するログ記録がディスクへフラッシュされることを保証するプログラムである。これらのインタバルコーディネータ及びインタバル関係者は、コサーバによって呼出し可能なプログラムの部分、サブルーチン、または分離したプログラムであることができる。
【0026】
あるトランザクションに単一のコサーバだけが関与している場合には、インタバルコーディネータとのインタラクションを必要としない「1相コミット」プロトコルが使用される。本発明は分散トランザクション(以後、単に「トランザクション」という)に適用されるので、また1相コミットプロトコルは当分野においては公知であるので、これ以上の説明は省略する。
データベースシステム5は、「コミットインタバル」(もしくは単に「インタバル」)を使用して、トランザクションをコミットすることができるか否かを決定する。コミットインタバルは、インタバルコーディネータとインタバル関係者との間のメッセージの交換を編成するのに使用される時間の単位である。インタバル関係者がそのトランザクションログをディスクへフラッシュしたことを表すメッセージを、全てのインタバル関係者がインタバルコーディネータへ送ると、インタバルは「閉じる」。もし全てのインタバル関係者がこのようなメッセージを送らなければ、インタバルは「開いている」という。
【0027】
インタバルコーディネータがトランザクションをコミットする場合、インタバルを閉じる必要はない。詳しく述べれば、全てのトランザクション関係者に関連するコサーバが現インタバル及び先行インタバルの全てのログ記録を非揮発性記憶装置へフラッシュしたことを表すメッセージをインタバルコーディネータへ送ると、インタバルコーディネータはトランザクションをコミットできる。トランザクションはデータの数片のみに対する操作処理を行うことができるので、トランザクション内の関係者は全てのインタバル関係者の小さい部分集合だけを構成することができる。
前述したように、データベースプログラム100は、通信リンク104によって接続されている複数のコサーバ102a−102gを有している。図7に示すように、データベースシステム5は、1つのコサーバ、例えばコサーバ102d上で走る単一のインタバルコーディネータ(IC)110を含んでいる。IC110は、分散したトランザクションの何れかがコミットされる、または打切られる時点を決定するのに使用される。詳しく説明すると、データベースシステム5においては、IC 110が、コミットされたものとしてあるトランザクションをマークする記録をディスクへフラッシュすると、そのトランザクションはコミットされる。
【0028】
データベースシステム5は、コサーバ102a−102g上でそれぞれ走るIP 115a−115gをも含んでいる。1つのIPは各コサーバ上で走る。各IP 115a−115gは、詳細を後述するように、若干のメッセージを交換することによってIC 110と通信する。
図8に示すように、分散データベース30は、異なるコサーバ102a及び102b上で走るIP 115a及び115bに関連する情報を有することができる。例えば、小切手勘定テーブル32はIP 115aに関連するディスク24a上に格納することができ、預金勘定テーブル42はIP 115bに関連するディスク24b上に格納することができる。例として、IC 11Oは別のコサーバ102d上で走るように示されているが、IC 11Oはどのコサーバ102a−102g上でも走ることができる。
【0029】
以下に説明する、そして図9に示すようにデータベースシステム5は、IC
110とIP 115a−115gとの間で定期的にメッセージを交換する。図示のデータベースシステム5は7つのコサーバ102a−102gを含んでいるが、コサーバの数は特定のアプリケーションに必要な異なる数であることができる。各インタバルの始まりに、IC 110は「インタバルメッセージ」120を、全てのIP 115a−115gへ伝送する。インタバルメッセージ120は、新しいインタバルが開始されたことをIP 115a−115gに通報する。好ましい実施例では、IC 110は約 100msおきにインタバルメッセージを伝送する。インタバルの時間の長さは構成毎に変化するが、メッセージを送受し、あるページをトランザクションログへフラッシュするのに要する時間よりも長くすべきである。
【0030】
各IPは、「閉止メッセージ」125でIC 110に返答する。閉止メッセージ125はインタバルメッセージ120に応答して作成され、特定のコサーバに関するインタバル閉止記録(即ち、現ローカルインタバルに関するログ記録)を受信する前に作成された全てのログ記録を含むトランザクションログが、ディスクへフラッシュされたことを表している。更に、どのIPも閉止メッセージ125を送る度に、そのIPがインタバルを完了したことを表すログ記録をコサーバのトランザクションログ内に入力することができる。しかしながら、トランザクションログが空のログ記録で満たされてしまわないように、IPは、もしトランザクションがそのインタバル中にそのコサーバ上でコミットされれば、インタバル閉ログ記録だけを書き込む。インタバルメッセージ120及び閉止メッセージ125の内容のより詳細な説明は、図12及び13を参照して後述する。
【0031】
新しいコミットインタバルは、IC 110内の「マスタインタバルキー」150が増数(インクリメント)される度に開始される。マスタインタバルキー150は、IC 110及びIP 115a−115gの活動を調整する時計のようなものである。しかしながら、マスタインタバルキー150は、実時計に関連付けたり、または実時計に同期させる必要はない。むしろ、マスタインタバルキー150は、現コミットインタバルを識別するカウンタである。IC 110はマスタインタバルキー150を読み、現コミットインタバル番号を決定する(人が時計を見て現在の時刻を理解するのに似ている)。
マスタインタバルキー150は、4バイトの(または、それより大きい)符号なし整数変数であることが好ましい。コミットインタバルは、マスタインタバルキー150が増数される時に「終了する」。マスタインタバルキー150の増数は、次のマスタインタバルの始まりでもある。
【0032】
コミットインタバルの「終わり」は、必ずしもコミットインタバルの「閉止」と同一のものである必要はない。好ましい実施例では、IC 110はインタバルメッセージ120を送出した後、ある時(期)間待機する。各マスタインタバルにおいては、この待機期間は、連続するインタバルメッセージ間の時間の合計長がほぼ 100msであるようにセットされている。待機期間の正確な長さは、先行マスタインタバル中に閉止メッセージを処理するのに消費した時間長に依存する。待機期間の設定は設備毎に変化するが、2つのメッセージ交換及びログのディスクへのフラッシュを可能にするよう十分に長くすべきである。
待機期間中に到着するどの閉止メッセージ125も待ち行列内に配置される。待機期間の終わりに、IC 110は待ち行列内のメッセージを処理し始める。処理中に、さらなるインタバルメッセージが到着し、待ち行列内に配置されるかも知れない。しかし結局はIC 110は、閉止メッセージの待ち行列を空にする。もし全てのIP 115a−115gが閉止メッセージを送ってしまえば、そのインタバルは閉じる。もし、IP 115aのようなIPが(例えば、もしコサーバ102aが故障して)閉止メッセージを送ることを妨げられれば、インタバルは開き続ける。もしインタバルが開き続ければ、IC 110は、閉止記録を送らなかったIPの記録をメモリ内に保持するので、そのインタバルは後刻閉じることができる。しかしながら、一旦待ち行列が空になると、インタバルが開き続けているか、または閉じているかには拘わりなくマスタインタバルキー150が増数され、新しいインタバルが開始される。
【0033】
IP 115a−115gは「ローカルインタバルキー」155a−155gと呼ぶタイマ変数を保持している。ローカルインタバルキーは、IPのためのローカル時計に似た動作をする。ローカルインタバルキー155a−155gは最新のマスタインタバルを格納し、IC 110からのインタバルメッセージ120によって更新される。IC 110からの各インタバルメッセージ120は、IC 110のマスタインタバルキー150の現在の値に等しい「マスタインタバルタグ」を含む。IP 115a−115gはインタバルメッセージを読み、マスタインタバルタグを抽出し、そしてそれらのローカルインタバルキー155a−155gをマスタインタバルタグに等しくセットする。
IPがIC 110からのインタバルメッセージ120(値Nのマスタインタバルタグを含む)に応答する時、そのIPに関連するコサーバは、先行マスタインタバルN−1の間にそのコサーバが作成した全てのトランザクションログ記録をディスクへフラッシュしている。例えば、もしIC 110が、マスタインタバル#5の開始を知らせるインタバルメッセージ120−1cを送れば、IP115aが閉止メッセージ125−1aで応答する時、コサーバ102aはマスタインタバル#4の間に作成した全てのログ記録をディスクへフラッシュしている(図10参照)。
【0034】
要約すれば、IC 110内にはマスタカウンタ(マスタインタバルキー150)が存在していてマスタインタバルを画定し、各IP内にはローカルカウンタ(ローカルインタバルキー155a−155g)が存在していてローカルインタバルを画定している。ローカルインタバルキーは、IPがIC 110からインタバルメッセージを受信すると更新される。従って、IC 110上の各マスタインタバルは、概ねあるインタバルメッセージ120の伝送から次のインタバルメッセージの伝送まで走る。同様に、各ローカルインタバルは、概ねあるインタバルメッセージの受信から次のインタバルメッセージの受信まで走る(図10参照)。
IC 110とIP115a−115gとの間のインタバルメッセージ及び閉止メッセージの定期的な交換に加えて、分散した各トランザクション毎に、トランザクションオーナーとトランザクションヘルパーとの間にメッセージが交換される。詳しく説明すると、トランザクションオーナーは、そのトランザクションの1またはそれ以上の操作処理を遂行することを依頼する「要求メッセージ」をトランザクションヘルパーに送る。例えば、勘定振替トランザクションの場合、要求メッセージ140aがヘルパー135aへ、また要求メッセージ140bが135bへ送られる。コサーバ102a及び102bがヘルパー135a及び135bとして図示され、またコサーバ102cがオーナーとして図示されているが、オーナー及びヘルパーは異なるトランザクションに関しては異なるコサーバであろう。
【0035】
特定のトランザクションヘルパーがその操作処理を実行してしまうと、そのトランザクションヘルパーは、操作処理が完了したことを表す「完了メッセージ」でトランザクションオーナーに返答する。完了メッセージは、トランザクションヘルパーのローカルインタバルキーの値にセットされている「トランザクションインタバルタグ」を含んでいる。トランザクションインタバルタグは、後述するようにトランザクションオーナーがコミットすべきトランザクションを指定(ノミネート)することができる。
以後、要求メッセージ及び完了メッセージの交換に関しては、オーナー及びトランザクションヘルパーを、オーナー及びヘルパーと呼ぶことがある。
オーナー130は、ヘルパーから完了メッセージを受信する度に、受信した新しいトランザクションインタバルタグを、格納されている古いトランザクションインタバルタグと比較し、大きい方の(最も新しいものに等価の)インタバルタグを保持する。ヘルパーは、オーナーと同一のノード上で動作できることに注目されたい。たとえトランザクションのオーナーと同一のコサーバ上でトランザクションの更新が行われたとしても、トランザクションタグは使用する。
【0036】
全てのヘルパーが完了メッセージをオーナー130へ送ってしまうと、オーナーはユーザへ完了応答を供給することができる。トランザクションオーナーは、現トランザクションのための付加的なタスクを完了させることを要求することができ、またはユーザは、そのトランザクションをコミットまたは打切ることを要求することができる。もしトランザクションオーナーがトランザクションのコミットを要求すれば、トランザクションオーナー130は据置き制約( deferred constraint ) の検査を開始することができる。据置き制約とは、あるトランザクションの完了時に検査を必要とする規則のことである。例えば、もし小切手勘定に最低残高が要求されていれば、これはトランザクションの後に確かめることができる。据置き制約に関しては、コミットプロトコルの説明の後に説明することにする。
【0037】
次に、オーナー130は、格納されているトランザクションインタバルタグとローカルインタバルキー155cとを比較する。もしローカルインタバルキー155cが、格納されているトランザクションインタバルタグに等しいか、または大きければ、オーナー130はそのトランザクションをコミットについて適格であるとしてマークし、IC 110にそのトランザクションをコミットする要求を次の閉止メッセージ125内に含ませる。
もしローカルインタバルキー155cが、格納されているトランザクションインタバルタグよりも小さければ、そのトランザクションに関するログ記録(現インタバルの終わりにディスクへフラッシュされない)が存在しているかも知れない。この場合オーナー130は待機し、IC 110にそのトランザクションをコミットさせる要求を閉止メッセージ125内に含ませるか否かを決定するために次のインタバル中に再度検査することができる。
【0038】
オーナー130が待機する場合には、単一の閉止メッセージ125内に送られる全てのトランザクションが、単一のインタバルに関係付けられるように、適切なインタバルが必要である。代替例では、オーナー130は、ICが所与のトランザクションをコミットすることを要求する前に、適切なインタバルを待機しない。この場合、トランザクションタグが閉止メッセージに対してグローバルであるような好ましいアルゴリズムの実施例とは異なり、ICへの閉止メッセージ内の各トランザクションに対してインタバルタグ252(図13参照)の指定を行わなければならない。
時には、ユーザ要求を処理している間に問題が発生し、トランザクションを打切らなければならないことがある。若干の状況においては、ヘルパーは独立的にトランザクションを打切ることができるが、他の場合にはヘルパーはトランザクションを打切ることができない。もしヘルパーが(オーナーに打切り状態を戻すことによって)オーナーの操作処理を現在実行中であれば、ヘルパーは独立的にトランザクションを打切ることができる。また、IC 110への次の閉止メッセージ内の打切りリストにそのトランザクションを追加することによって、もしIPの現在のインタバルタグとローカルインタバルタグとが同一であれば、ヘルパーは独立的にトランザクションを打切ることができる。
【0039】
他のどのような状況でも、ヘルパーは、ICへ別のメッセージを送るか、または閉止メッセージに打切り要求を追加するかの何れかによって、ICにトランザクションを打切ることを要求しなければならない。何れの場合も、ICがそのトランザクションの処理のコミットを既に開始しているかも知れないので、ICが打切り要求を受けるような必要性は存在しない。
本発明の好ましい実施例においては、トランザクションオーナーだけがトランザクションを打切ることができる。トランザクションヘルパーは一方的にトランザクションを打切るような自律性を放棄する。この実施例は、単一の管理コンテクスト内の単一のサーバとして機能するローカルに分散したデータシステムにとって適切である。
【0040】
図10は、勘定振替トランザクションにおけるオーナー、ヘルパー、及びIC間のメッセージの交換の時間線例を示している。水平の線はコサーバ102a、102c、及び102dを表している。斜めの線は、コサーバ間で交換されるメッセージを表している。銀行の出納係のようなユーザは、IP 115cに関連するコサーバ102cのようなコサーバから勘定振替トランザクションを入力することができる。トランザクションはコサーバ102cから発しているので、コサーバ102cは上述したようにそのトランザクションのオーナーとして動作する。オーナー130は、小切手勘定テーブル32がIP 115aに関連するコサーバ102a内に格納されており、預金勘定テーブルがIP 115bに関連するコサーバ102b内に格納されてと判断する(図8及び9参照)。
【0041】
インタバルメッセージ120が、コサーバ102dからコサーバ102a及び102c上のIPへ定期的に送り出される。各IPは、閉止メッセージ125でインタバルメッセージ120に返答する。例えば、図10に示すように、コサーバ102dはインタバルメッセージ120−1cをコサーバ102cへ送り、コサーバ102cは閉止メッセージ125−1cで応答する。
勘定振替トランザクションの例では、メッセージはコサーバ102a、102b、102c、及び102dの間で伝送される。両コサーバ102a及び102bはヘルパーであるので、コサーバ102a及び102bへの、及びこれらからのメッセージは同じである。従って、簡略化のためにコサーバ102bへの、及びそれからのメッセージは図10には示してない。またこの例は、マスタインタバル#4で開始されているが、これらの原理は早めの、または遅めのインタバルにも適用することができる。
【0042】
マスタインタバル#4の閉止を要求するIC 110からのインタバルメッセージ120−1aに応答してIP 115aは、コサーバ102a上の時点Xから開始してそのローカルインタバルキー155aをローカルインタバル#5に将にセットしたところである。IP 115aは、閉止メッセージ125−1aでIC 110に応答しようとしている。図10及び11の(A)に示すように、時点XにIP 115aはトランザクションログ64aをフラッシュし、それによってローカルインタバル#4の閉止のログ記録160をディスク24aへ書き込む。
引き続き図9、10、及び11の(A)を参照する。小切手勘定テーブル32の貸方操作処理を実行するために、オーナー130は、ローカルインタバル#5の間に要求メッセージ140aをコサーバ102aへ伝送する。IP 115aがそのローカルインタバルキーを丁度セットしているから、オーナー130らの要求メッセージ140aはローカルインタバル#5の間にコサーバ102aに到着する。
【0043】
時点Aに貸方操作処理の実行を完了したコサーバ102aは、ログ記録161をトランザクションログ64a内に入力する。ログ記録161は、トランザクション識別(ID)コード及びエントリ55の古い値及び新しい値のような操作処理を元に戻すか、またはやり直すのに十分な情報を含んでいる。ログ記録161はメモリ22a内に留まってはいるが、未だディスク24aへフラッシュされてはいない。
コサーバ102aは、ログ記録161をトランザクションログ64a内に入力した後に、完了メッセージ145aをコサーバ102c上のオーナー130へ送る。完了メッセージは、コサーバ102a上のローカルインタバルキー155aの現在の値(即ち、ローカルインタバル#5)に等しくセットされたトランザクションタグを含む。
【0044】
図10には示してないが、前述したように、他のヘルパー及びオーナーは要求メッセージ及び完了メッセージを交換して預金勘定テーブル42上で借方操作処理を実行する。しかしながら、もし借方操作処理によって勘定が0以下になれば借方操作処理は失敗し、ヘルパーはそのトランザクションが誤りをもたらすことを表すメッセージをオーナー130へ送る。もし借方操作処理に成功すればヘルパーはオーナーへ完了メッセージを送り、コサーバ102bはログ記録を、トランザクションID、借方操作処理を完了したローカルインタバル、及びエントリ56(図4参照)の古い値及び新しい値と共に、ログ64b(図8参照)内に入力する。
図9に戻って、オーナー130は各完了メッセージ145a及び145bを調べ、誤りが戻されてきたか否かを決定する。もしヘルパー135a及び135bから誤りを受信していれば、オーナー130はそのトランザクションを打切られるものとしてマークする。完了メッセージ145bの前に完了メッセージ145aがオーナー130に到着したものとすれば、オーナー130は完了メッセージ145aからのトランザクションインタバルタグをメモリ22a内に格納する。次の完了メッセージ145bがオーナー130に到着すると、オーナー130は完了メッセージ145bからの新しいトランザクションインタバルタグと、完了メッセージ145aからのトランザクションインタバルタグとを比較する。もし受信した新しいタグが、格納されている古いタグよりも大きければ、格納されているタグは新たに受信したタグに置換される。この例では、コサーバ102a及び102bの両者が、ローカルインタバル#5の間に完了メッセージを送っている。従って、オーナー130は格納されるトランザクションインタバルタグとして完了メッセージ145aからのローカルインタバル#5を格納する。完了メッセージ145bが到着しても、格納されたトランザクションインタバルタグには変化はもたらされない。
【0045】
次にオーナー130は、格納されているトランザクションインタバルタグと、ローカルインタバルキー155cとを比較する。もしローカルインタバルキー155cが、格納されているトランザクションインタバルタグに等しいか、または大きければ、オーナー130はそのトランザクションをコミット可としてマークする。この例では、格納されているトランザクションインタバルタグ、及びオーナー130のローカルインタバルは共にインタバル#5にセットされている。ローカルインタバルが、格納されているトランザクションインタバルタグに等しいので、このトランザクションはコミット可としてマークされる。
ある状況では、格納されているトランザクションインタバルタグが、ローカルインタバルよりも大きいことがあり得る。あるインタバルの始まりにIC 110がインタバルメッセージを、操作処理の実行に繁忙なヘルパーへ送ることを考えよう。オーナー130がICからオーナーへのインタバルメッセージの処理を完了する前に、ヘルパーが操作処理を完了してその完了メッセージ145aをオーナー130へ送るかも知れない。この場合、オーナーは未だそのローカルインタバルキーを増数させていないから、トランザクションインタバルタグはローカルインタバルキーよりも大きくなる。もしこのようなことが発生すれば、オーナー130はその次のローカルインタバルの終わりにコミット要求を提出する。
【0046】
IP 155cが閉止メッセージ125−2cを作成する時、IP 155cは勘定振替トランザクションがコミット可であることに注目し、そのトランザクションをコミットに適格であるとして注目するコミット要求を、閉止メッセージ125−2cに追加する。
図10及び11の(B)を参照する。IP 115aが閉止メッセージ125−2aを送る前の時点Bに、IP 115aはトランザクションログ64aをフラッシュしてログ記録161をディスク上に配置する。次いでIP 115aは、ローカルインタバル#5の閉止を表すログ記録162をバッファ22aに追加する。
IC 110は閉止メッセージ125−2cを受信すると、その勘定振替トランザクションがコミットに適格であることを決定する。マスタインタバル#6の終わりに、IC 110は、そのインタバルに閉止メッセージを送ったIPのリストと、そのトランザクションに関与した関係者のリストとを比較する。図10に示すように、コサーバ102aに関連するIP 115a及びコサーバ102cに関連するIP 115cは共に、それぞれインタバルメッセージ120−2a及び120−2cに応答して閉止メッセージ125−2a及び125−2cを送っている。コサーバ102b上のIP 115bも、閉止メッセージをIC110へ送っているものとすれば、勘定振替トランザクションは、揮発性メモリ22d内のトランザクション状態リスト170(図8)内にコミット済みとしてマークされよう。
【0047】
図21を参照する。メモリ22d内のトランザクション状態リスト170は、トランザクション記録410のリストである。各トランザクション記録410は少なくとも、オーナーIDコード411、トランザクションIDコード412、トランザクションインタバルタグ413、トランザクション状態414、及びトランザクション関係者リスト415を含む。例えば、上例の勘定振替トランザクションでは、オーナーIDコードは# 102c、トランザクションIDコードは# 312、インタバルタグはインタバル#5、状態はコミット、そしてトランザクションの関係者リストはコサーバ102a−102cである。
図10に示すように、マスタインタバル#6の終わりにIC 110はインタバルメッセージ120−3aと120−3cとをアセンブルする。インタバルメッセージ120−3aと120−3cとをアセンブルすると、IC 110はトランザクション状態リスト170(図8参照)をディスク24dへフラッシュする。この時点で、トランザクションはコミットされる。後刻故障が発生しても(非揮発性記憶装置が実際に破壊された場合を除く)、打切られたトランザクションを元に戻し、コミットされたトランザクションをやり直すことによって一貫性データベース30を得ることができる。IP 115a−115cは、データベースエントリの古い値及び新しい値の記録が成功裏にディスクへフラッシュされた後に閉止メッセージ内に送っているから、IC 110がそのトランザクションをコミット済みとしてマークする時、データベース30を再構成するのに必要な情報は、既に非揮発性記憶装置内に保管されている。
【0048】
IC 110がマスタインタバル#7の始まりにトランザクション状態リストをディスク24dへフラッシュすると、インタバルメッセージが各IP 115a−115gへ伝送される。インタバルメッセージ120−3a及び120−3cは、コミットされたトランザクション、及び打切られたトランザクションのリストを含んでいよう。勘定振替トランザクション(トランザクション# 312)はコミットリスト内にあろう。
図10及び11の(B)に示すように、IP 115aはインタバルメッセージ120−3aを受信した後に、トランザクションIDコード# 312がコミットされたことを知らせるログ記録163をトランザクションログ64a内に入力する。
【0049】
図10及び11の(C)を参照する。IP 115aがその閉止メッセージをIC 110へ送る前の時点Cに、IP 115aはログ64aをディスク24aへフラッシュし、次いでローカルインタバル#6の閉止を表すログ記録164をバッファ22aに追加する。しかしながら、もし最後のローカルインタバル中にトランザクションログ記録が書き込まれていれば、IPはそのログをフラッシュすることを要求するだけである。これは、分散データベースシステム5の分散したトランザクションコミットプロトコルを意図しているのである。
据置き制約検査はコミットと同じような手法で遂行することができる。ユーザが据置き制約検査を受けたトランザクションのコミットを要求する場合、トランザクションオーナーは、IC 110がそのトランザクションのコミットを処理する前に、これらの据置き制約の評価を開始することを要求しよう。閉止メッセージ125内のこの据置き制約検査要求を受けたIC 110は、幾つかの行動を起こす。第1に、そのトランザクションを、別の制約検査を必要とするトランザクションのリストに追加する。このリストは、関係者が制約検査を完了したことを追跡するのに使用される。第2に、ICはリスト170内のトランザクションの状態を「据置き」に変化させる。第3に、全ての関係者が、そのトランザクションのインタバルタグ値によって表されるインタバルの閉止メッセージを送ってしまうと、ICは次のインタバルメッセージ120内にそのトランザクションについての検査要求を含ませる。
【0050】
各関係者は、インタバルメッセージ120で検査要求を受けると、指定されたトランザクションの据置き制約を評価する。制約検査を完了するためには、複数のローカルインタバルが必要であるが、各関係者は完了するとその成果を閉止メッセージ内へ挿入する。もしIC 110がある関係者から制約を侵したことを受信すると、そのトランザクションは打切られたとしてマークされる。もしどの関係者も制約を侵していなければ、全ての関係者が返答すると、そのトランザクションはコミットされるものとしてマークされ、そのトランザクションプロトコルは上述したように続行される。
メッセージ交換
図12及び13は、IC 110とIP 115a−115gとの間で伝送可能な考え得るメッセージの構造を示している。
【0051】
図12に示すように、IC 110から1またはそれ以上のIP 115a−115gへのどのメッセージも、1バイトのメッセージの型200で始まる。通常のメッセージの型は「トランザクション」であり、IPに閉止メッセージで応答させる通常の要求を表している。ICがIPへ送ることができる他の考え得るメッセージの型は以下のものを含む。
「返答可」:もしIPが、IC 110へ「使用可」メッセージを送れば、IC 110は現マスタインタバルタグ202を含む「返答可」メッセージで応答する。
「IC使用可」:もしIC 110が故障して使用不能であったのであれば、IC 110は復旧した時に全てのIP 115へ「IC使用可」メッセージを同報(または放送)する。これは、IC 110が再び使用可能であり、及び各IPの状態を確認する必要があることをIPに通告する。例えばもしバックアップICが制御を行っていればIC 110の位置が変化しているかも知れない。従って「IC使用可」メッセージは、IC 110を走らせている現コサーバの識別をも含む。
【0052】
「更新」:もしIPが、IC 110へ「更新要求」メッセージを送れば、IC 110は指定されたIPに「更新」メッセージで応答する。このメッセージは、マスタインタバルタグと、そのコサーバが関係者であった全てのトランザクションの状態の状態リストとを含む。
「復旧返答」:もし特定のIPが故障し、後に復旧すれば、それはIC 110へ「復旧」メッセージを送る。それに応答してIC 110はIPへ「復旧返答」を送る。このメッセージは、マスタインタバルタグと、そのコサーバが関係者であった全てのトランザクションの状態の状態リストとを含む。
「延期」:このメッセージは、あるIPからの最後の閉止メッセージ以降、閉じたインタバルが多過ぎるために、IC 110がそのIPへの「トランザクション」メッセージを延期していることをそのIPに通告する。
【0053】
図12に示すインタバルメッセージ120においては、4バイトのマスタインタバルタグ202が状態200に続いている。マスタインタバルタグ202は、マスタインタバルキー150から入手した最新の閉止インタバルである。タグ202の後には、単一の1バイトのフィールドを占める4つのフラグ204−207が続いている。これらのフラグは、インタバルメッセージ120が、何れかのトランザクションを、コミットするか否か(フラグ204)、打切るか否か(フラグ205)、または制約検査を遂行するか否か(フラグ206)を表している。フラグ207は、何れかのコサーバが故障したことをIC 110が知らされたか否かを表す。
フラグ204−207の次に続くのは、順番に、コミットリスト210、打切りリスト212、制約検査リスト214、及び故障(ダウン)したコサーバリスト216である。コミットリスト210、打切りリスト212、及び制約検査リスト214は全て同一の編成を有している。各リストは、リスト内のトランザクションオーナーの2バイトのカウント220で始まる。次いで、各オーナー毎に、2バイトのオーナーID 222、2バイトのそのオーナーのトランザクションの数のカウント224、及びそのオーナーのトランザクションIDリスト226が続く。トランザクションIDリスト226は、トランザクション当たり4バイトを使用する。
【0054】
インタバルメッセージ120は、他のグローバルデータベースシステム関連情報をも含む。例えば、日のグローバル時間の値を、いろいろなコサーバ上の時計を粗く同期させるために分配することができる。勿論、メッセージの上述したフィールドサイズは単なる例示に過ぎず、本発明に必須ではない。フィールドサイズは、所与のコンピュータネットワークのトランザクション処理能力を反映している。
図13に示すように、IPからICへのどのメッセージも1バイトのメッセージの型250で始まる。通常のメッセージの型は「トランザクション」であり、これはICへの通常の閉止応答を指示している。しかしながら、他の考え得るメッセージの型は、以下のものを含む。
【0055】
「復旧」:IPは「復旧」メッセージをIC 110へ送って現トランザクション情報を入手する。
「使用可」:もしあるIPが静止していたが今は使用可能であれば、そのIPは「使用可」メッセージをIC 110へ送る。これは、そのIPがトランザクション処理に使用できることをIC 110に通告する。
「更新要求」:あるIPは、「延期」メッセージをIC 110から受信した後に「更新要求」メッセージをIC 110へ送る。
「遊休」:特定のIP 115aは、「遊休」メッセージを送ることによって遊休に入ることをIC 110に通告する。あるIPは、かなりの数のローカルインタバルが推移しても、そのIPに関連するコサーバに目立った活動的なトランザクション、即ちトランザクションアクティビティが存在しない場合に遊休になる。
【0056】
「IC更新」:IC 110からの「IC使用可」メッセージに応答して、あるIPは、そのIPからICへの先行トランザクションメッセージで伝送した情報を含む「IC更新」メッセージを送る。この情報は、IC 110が故障していために到着しなかったかも知れない。
「復旧完了」:故障に続いて、開いているどのトランザクションも、IPによって解消され、インタバル閉記録がディスクにフラッシュされた後に、IPはIC 110へ「復旧完了」メッセージを送る。次いでIC 110は、特定のIPが閉じたことを示すように全ての格納されたインタバル閉記録を変更し、関与したトランザクションからそのIPを除去するようにトランザクション状態リストを変更する。
【0057】
図13に示す閉止メッセージでは、型250の後に4バイトのローカルインタバルタグ252が続いている。ローカルインタバルタグ252は、ローカルインタバルキーから得たインタバルである。タグ252の次は2バイトのインタバル関係者ID 254である。インタバル関係者ID 254の次は、4つのフラグ256−259であり、1バイトを占めている。これらのフラグは、インタバルメッセージが、コミットに適格な何等かのトランザクションを含むか否か(フラグ256)、打切ることを要求されているか否か(フラグ257)、またはどれが制約検査を要求しているか(フラグ258)を表している。フラグ259は制約検査に対する返答を表している。
フラグ256−259の後に、順番に、適格コミットリスト260、打切りリスト262、制約検査リスト264、及び制約返答リスト266が続く。コミットリスト260、打切りリスト262、及び制約検査リスト264は、全て同じ編成を有している。各リストは、2バイトのリスト内のトランザクションの数のカウント270から始まる。次いで各トランザクション毎に、4バイトのトランザクションID 272、2バイトのトランザクションの関係者の数のカウント274、及びそのトランザクションの関係者リスト276が続く。コサーバの数が 40 より少ないシステムの場合には、関係者リスト276は、各ビットが1つのコサーバを表しているようなビットマップであろう。コサーバの数が 40 より多いシステムの場合には、関係者リスト276は、ビットマップまたは関係者当たり2バイトの関係者IDのリストの何れかであり、何れにしてもバイトの数は少なくて済む。関係者リスト276の第1のビット277は、どのフォーマットが使用されているかを表している。
【0058】
IPインタバル閉止メッセージ125は、トランザクション関係者による据置き制約の評価の結果を有する返答リスト266をも含んでいる。返答リスト266は若干異なる構造を有している。返答リスト266は、2バイトのリスト内のトランザクションの数のカウント280から始まる。次いで各トランザクション毎に、2バイトのトランザクションオーナーID 282、4バイトのトランザクションID 284、及び制約検査が成功したか、または失敗したかを表す1バイトのフラグ286が続く。
閉止メッセージ125はインタバルタグ252を含むので、IC 110は閉止メッセージが伝送されたローカルインタバルを知る。インタバルタグ252は、閉止メッセージ125のリスト260、262、264、及び266内に識別されている各トランザクションにグローバルに適用される。
【0059】
リスト260内の打切られたトランザクションのID、及びリスト262内のコミットに適格であるトランザクションのIDは、IC 110によって最新のトランザクションとして、メモリ22d(図8参照)に維持されているトランザクション状態リスト170に追加される。IC 110は、次のインタバルメッセージ120を作成する時にトランザクション状態リスト170を参照する。
インタバルコーディネータ及びインタバル関係者
図14に示すように、各マスタインタバル中に、IC 110は以下の諸段階を実行する。
1.タイマの終わりを待機 (段階301)
2.待ち行列内のメッセージを処理 (段階302)
3.待ち行列が空か否かを決定 (段階303)
4.トランザクション状態リストを処理 (段階304)
5.トランザクション状態リストをディスクへフラッシュ (段階305)
6.インタバルメッセージを伝送 (段階306)
7.マスタインタバルキーを増数 (段階307)
IC 110は、メモリ22d内のタイマ185(図21参照)が時間切れになるのを待って段階301における新しいマスタインタバルを始動する。タイマ185が時間切れになるのを待機することによって、IPは先行マスタインタバル中に送られたインタバルメッセージ120に応答し、閉止メッセージ125でIC 110に返答することが可能になる。IC 110に到着した各閉止メッセージは、メモリ22d内の待ち行列180(図8及び19参照)内に配置される。タイマ185は、先行インタバルの始まりから 100msのような最短時間が経過するのを保証するようにセットされる。タイマ185が時間切れになるか、またはタイマ185が既に時間切れであれば、現時点に 100msのような最短時間を付加することによってリセットされる。
【0060】
IC 110は、IPからのメッセージを増加的に処理することもできる。この場合、IC 110は、新しい閉止メッセージが到着するのを待つか、または現マスタインタバルのためのタイマ185が時間切れになるのを待機するだけである。
タイマ185が時間切れになった後、段階302においてIC 110は、待ち行列180(図8参照)内の何れかの閉止メッセージを処理し始める。IC110が処理している間に、IP 115a−115gからさらなる閉止メッセージが到着することが考えられる。これらの閉止メッセージ125は、待ち行列の後尾に配置され、順番に処理される。
IC 110は、段階303によって決定されるように、待ち行列180が空になるまで閉止メッセージを処理し続ける。各IPは、1つの閉止メッセージだけを送り、IC 110からの新しいインタバルメッセージを待機するであろうから(図19の段階351参照)、待ち行列180には有限数の閉止メッセージだけが累積する。例えば、もしIP(コサーバ)115aが故障であるか、または他のある源からの大量の負荷を処理中であることによって、IP 115aのようなIPが時間通りに閉止メッセージをIC 110へ送ることができないこともあり得る。このような場合には、IC 110はそのインタバルを閉じることはできず(但し上述したように、そのインタバルを終わらせる)、IC 110はそのインタバル中に応答しないコサーバのビットマップを格納する。
【0061】
処理段階302の詳細に関しては図15及び16を参照して後述するが、要約すれば、この処理段階中に閉止メッセージ125が調べられ、コミットリスト260、打切りリスト262、検査リスト264、及び返答リスト266内のトランザクションがトランザクション状態リスト170内へ配置される。更に、インタバルメッセージ120のために打切りリスト212がアセンブルされる。
待ち行列180内の全ての閉止メッセージが処理されてしまうと、作成されたばかりのトランザクション状態リスト170が処理される。処理段階304の詳細に関しては図17及び18を参照して後述するが、要約すれば、この段階中にICは、そのトランザクションをコミットするか否かを評価する。更に、段階304において、インタバルメッセージ120のためにコミットリスト210及び検査リスト214がアセンブルされる。
【0062】
段階305において、IC 110はクリティカルトランザクション情報をディスク24d(図8参照)へフラッシュする。この情報は、マスタインタバルキー150、トランザクション状態リスト170、どの関係者が閉止メッセージを送ったか否を示すインタバル開アレイ425(図21、後述)、及びローカルインタバルタグの最後のタグアレイ435(図21)を含む。アレイ435は、各コサーバ102a−102g毎のエントリ436を含む。各エントリ436は、適切なコサーバから受信した最新のローカルインタバルタグ252を含む。
もし、分散データベースシステム5がバックアップICを含んでいれば、処理段階304とフラッシュ段階305との間に、クリティカルトランザクション情報のコピーがIC 110から活動バックアップICへ送られる。バックアップICの使用に関しては図23を参照して後述する。
【0063】
トランザクション情報がディスク24dへフラッシュされてしまうと、段階306においてインタバルメッセージ120がIP 115a−115gへ伝送される。好ましい実施例では、同じインタバルメッセージが各IPへ送られる。しかしながら、ICに付加的な処理負荷を追加することによって、各IP毎に独自に最適化された異なるインタバルメッセージを送ることができる。
メッセージを複数のサイトへ送るには多くの方法が存在する。インタバルメッセージは直列に、即ち一時に1つのIPへ送ることができる。好ましくは、もしハードウェアによってサポートされるならば、単一のインタバルメッセージ120を同報する、即ち全てのIP 115a−115gへ同時に送ることができる。また、同報はソフトウェアによってシミュレートすることができる。代替として、特にもし多数のIPが存在すれば、樹木伝送を使用することができる。本発明はインタバルメッセージ120を全てのIP 115a−115gへ伝送するどのような方法にも適用される。
【0064】
段階306において送られるインタバルメッセージは、マスタインタバルから得たマスタインタバルタグ202を含み、これはIP 115a−115gがそれらのローカルインタバルキー155a−155gをリセットするのに使用される。これは、ローカルインタバルキーのグローバルな一貫性を保証する。好ましくない実施例では、各IPは各インタバルメッセージ120に応答してそれ自体のローカルインタバルキーを増数することができる。
最後に、段階307において、IC 110はマスタインタバルキー150を増数させて新しいマスタインタバルの始動を表し、段階301へループバックして段階306で送られたインタバルメッセージに応答する閉止メッセージの到着を待機する。
【0065】
要約すれば、IC 110は分散トランザクションのコミット及び打切り、及びデータベースシステム5内の据置き制約検査の中央調整に応答する。IC 110はコミットインタバルを始動させ、トランザクションがコミットまたは打切られる時点を決定して記録し、マスタインタバルキーを維持し、分散した据置き制約検査を管理し、分散した全てのトランザクションのコミットまたは打切り状態を維持し、そして、全ての関係者の状態をデータベースシステム5内に維持する。
図15に示すように、段階302においてICは、待ち行列180内のこの閉止メッセージ125を処理する。段階310においてIC 110は、最新のインタバルメッセージ120にどのコサーバが応答したかを追跡し始める。
【0066】
各マスタインタバルの始まりに(例えば、段階301において)、IC 110はインタバル開アレイ425内にインタバル記録420を作成する(図21参照)。インタバル記録420は、現マスタインタバルキー150にセットされるインタバルタグ421を含む。インタバル記録420は、データベースシステム5内のコサーバの数に等しいビット数を有するインタバルビットマップ422をも含む(図21参照)。例えば、データベースシステム5が7つのコサーバを含むものとすれば、インタバルビットマップ422も7ビットを有する。インタバルビットマップ422が作成される時、各活動コサーバ毎のビットは「オン」にセットされ、中断(もしくは延期)されたコサーバのためのビットは「オフ」にセットされる。段階310において、IC 110は閉止メッセージ125からのインタバル関係者ID 252に注目し、インタバルビットマップ422内のそのコサーバのためのビットをオフにする。各マスタインタバルの終わりに、もし全てのコサーバが閉止メッセージを送っていればそのインタバルは閉じられ、IC 110はインタバル記録420を消去できる。そうでなければ、マスタインタバルは開き続け、IC 110はインタバル開アレイ425内にインタバル記録420を格納する。
【0067】
次に、段階311においてIC 110は、閉止メッセージ125内のトランザクションの処理を終了したか否かを決定する。もしリスト260、262、264、及び266が空であれば、この終了は直ちに発生する。そうでなければ、IC 110は各トランザクションを調べて処理した後に限って終了させる。
閉止メッセージ125内に処理すべきトランザクションが未だ存在しているものとすれば、段階312においてICは、そのトランザクションが検査返答リスト266からのものか否かを決定する。もしこれが検査返答リストトランザクションであれば、段階313においてICは、図16を参照して後述する検査返答サブルーチンを遂行する。
もしトランザクションが検査返答でなければ、段階314においてICは、トランザクション記録410をトランザクション状態リスト170に追加する。図13及び21を参照する。オーナーID 411がオーナーID 254から入手され、トランザクションID 412がトランザクションID 272から入手され、トランザクションインタバルタグ413がローカルインタバルタグ252から入手され、そして、関係者リスト415がリスト276から入手される。関係者のリストは、各コサーバ毎に1ビットのビットマップの形状である。関係者であるコサーバは、ビットマップ415内に「オン」にスイッチしているビットを有している。トランザクションの状態414は、フラグ256−258によって始めにコミット要求、打切り、または検査要求として決定されるが、以下に説明するようにIC 110によって変えることができる。
【0068】
図15に戻る。段階315においてICは、そのトランザクションがコミットリスト260からのものか否かを決定する。もしそうであれば、IC 110は段階320において次のトランザクションを続行し、何等の行動も起こさない。もしそうでなければ、段階316においてICは、そのトランザクションが閉止メッセージ125の打切りリスト262からのものか否かを決定する。もしこれが打切りトランザクションであれば、段階317において、打切りリスト262内のトランザクションが次のインタバルメッセージ120のための打切りリスト212へ追加される(オーナーだけが打切りを行うことができるような好ましい実施例を想定している)。本発明の代替例では、トランザクション関係者はICへの打切り要求を一方的に行うことができる。このような場合ICは、マスタインタバルの終わりを待ち、コミットに適格のトランザクションのリストに対する打切りの候補であるトランザクションのリストを検査しなければならない。ICは、そのトランザクションに対するコミット処理が既に開始されていない場合に限って、要求に応じて打切り処理を開始する。もしICがトランザクションを打ち切ることを決定すれば、そのトランザクションは打切りリスト212に追加される。打切りリスト(もしあれば)が更新されてしまうと、IC 110は段階320へ移動する。
【0069】
もしトランザクションが打切りリスト262からのものでなければ、段階318においてIC 110は、そのトランザクションが制約検査リスト264に関する要求からのものか否かを決定する。もし諾であれば、段階319においてICは、返答記録440を検査返答アレイ445へ追加する。検査返答アレイ445はIC 110によって維持されており、トランザクションへの全ての関係者が据置き制約検査を完了したか否かを決定する。IC 110がテーブル440内のトランザクション(例えば、#312 )を指定する返答リスト266を含む閉止メッセージ125を受信する度に、IC 110はその関係者に関連するビットを返答したとしてマークする。トランザクションへの全ての関係者が返答し、制約障害が報告されていなければ、そのトランザクションはコミットするこができる。各返答記録440は、トランザクションID 441と、関係者のビットマップリスト442とを含む。ビットマップ442が作成される時、関係者のビットはオンにセットされ、非関係者のビットはオフにセットされる。例えば、図21に示すように、もし勘定振替トランザクションに関して据置き検査が要求されれば、コサーバ102a−102cはそれらのビットが未だオンにセットされ、コサーバ102d−102gのビットがオフにセットされていることが予測されているが、未だそのようにはなっていない。後述するように、ある関係者が制約検査返答を送る度に、その関係者のビットはオフにセットされる。ビットマップ442内の全てのビットがオフになると、制約障害はないものと見做されてトランザクションはコミットすることができる。返答記録440が返答検査アレイ445へ追加された後、IC 110は段階320において閉止メッセージの処理を続行する。
【0070】
トランザクションがどのリストからのものかには関係なく、段階320ではICは、次のトランザクションメッセージへ移動する。そうでなければIC 110は、その閉止メッセージで終了し、段階303へ進んで待ち行列180内の次のメッセージへ移動する。
図16及び21を参照する。もしトランザクションが検査返答リスト266内にリストされていたならば、段階321においてICは、故障が発生したか否かを決定する。もし返答リスト266内のトランザクションのためのフラグ286が故障を示していれば、段階322においてトランザクション状態リスト170内の状態414が「打切り」に変えられ、段階323においてそのトランザクションが打切りリスト212に追加される。次いでICは閉止メッセージ125の処理を続行する。
【0071】
もし閉止メッセージ125を送った関係者における制約検査を通れば、段階324において、閉止メッセージ125を送ったコサーバに対応するビットマップ442内のビットが前述したようにオフにされる。次いで段階325においてICは、全ての関係者が制約検査を完了したか否かを決定する。もし返答ビットマップ442内の全てのビットがオフであれば、返答ビットマップ442は0に等しく、そのトランザクションはコミットされるように進むことができる。段階326においてそのトランザクションの状態414が「コミット」に変えられ、段階327においてそのトランザクションがコミットリスト210に追加される。もしビットマップ422が何等かのオンビットを含んでいれば、ICは閉止メッセージの処理を続行する。
【0072】
図17及び18に示すように、段階304においてICは、トランザクション状態リスト170を処理してトランザクションをコミットし、コミットリスト210及び検査リスト214を作成する。各トランザクション毎に、段階330においてIC 110は、インタバルアレイ425の底(最も古い記録)から開始する。次いで段階331においてIC 110は、トランザクションタグ413とインタバル開タグ421とを比較する。もしトランザクションタグ413がインタバル開タグ421よりも大きければ、そのトランザクションはリスト170内で変更されないままにされる。
もしトランザクションタグ413が、インタバル開タグ421に等しいか、または小さければ、段階332においてICは、そのトランザクションの全ての関係者がそのインタバルの閉止メッセージを送ったか否かを決定する。これはビットマップの比較によって遂行される。トランザクションエントリ410のための関係者リスト415は、関係者ビットマップの形状で格納されている(そのトランザクションに関与している各コサーバはオンにセットされたビットで表され、関与していないコサーバはオフにセットされたビットで表されている)。関係者ビットマップ415は、インタバルビットマップと「論理積」される。即ち、関係者ビットマップとインタバルビットマップとのブールのAND演算が遂行される。
【0073】
例えば、図21に示すように、勘定振替トランザクションにおいては、関係者ビットマップ415はコサーバ102a、102b、及び102cのための3つのオンビットを有し、コサーバ102d−102gのための4つのオフビットを有していよう。インタバルビットマップ422がマスタインタバル#6のために作成される時、それは7つのオンビット(各コサーバ102a−102g毎に1つ)を有していよう。IC 110が閉止メッセージ125を受信すると、インタバルビットマップ422内の対応するビットがオフにセットされる。例えば、IC 110がインタバル#6のための閉止メッセージ125−2aを受信すると、コサーバ102aのためのビットがオフにセットされる。コサーバ102a−102cが閉止メッセージを伝送するものとすれば、図21に示すように、インタバル#6のためのビットマップ422内のこれらのコサーバのためのビットはオフにセットされる。このような場合、AND演算の結果7つのビットがオフ、即ち0になる。もし1またはそれ以上のコサーバ102a−102cが応答しなければ、オンビット、即ち非0ビットを含むことになる。
【0074】
図17に示すように、段階335において、もしAND演算の結果が0であれば、そのトランザクションの全ての関係者は指定されたインタバル421を閉じており、トランザクションは状態を変えることができる。この場合、IC 110はトランザクションの処理を続行する。
段階340(図18)においてICは、トランザクション状態がそのトランザクションをコミットする、または打切ることを表しているか否かを決定する。もしトランザクション状態414が「コミット」または「打切り」であれば、段階341において、そのトランザクションはリスト170から除去される。トランザクションに関与しているIPは、それらのローカルトランザクションログ64a−64cへコミットまたは打切りログ記録を有することが保証され、またこれらのログ記録がディスクへフラッシュされているので、これらのトランザクションはリスト170から除去できるのである。全てのローカルトランザクションログがこれらのコミットまたは打切り記録で更新されてしまうと、IC 110は最早トランザクションの状態を思い出す必要はない。全てのトランザクション関係者のコサーバは、ICからのさらなる援助がなくてもこれらのトランザクションの最終状態に関する曖昧さを局部的に解消できることを保証されているので、IC 110はこれらのコミットされたトランザクションに関して「忘れる」ことができる。
【0075】
もしトランザクション状態414が「コミット」または「打切り」でなければ、段階342においてICは、据置き制約検査が要求されているか否かを決定する。もしトランザクション状態414が「検査要求」であれば、段階343において状態が「据置き」に変えられ、段階344においてそのトランザクションが検査リスト214に追加される。代替実施例においては、この点において、段階302(図15)の一部としてではなく、返答記録440を検査返答アレイ445に追加することができる。
もしトランザクション状態414が「検査要求」であれば、段階345においてICは、IPがトランザクションのコミットを要求したか否かを決定する。もしトランザクション状態414が「コミット要求」であれば、段階346においてリスト170内の状態がコミットに変えられる。次いで段階347において、トランザクション状態リスト170内のトランザクションタグ413が改訂される。即ち、トランザクションタグ413は、それが現マスタインタバルキー150プラス(+)ある遅延値、即ち1に等しくなるように改訂される。410内のコミットされたトランザクションのためのインタバルタグ413のこのセッティングは、IC 110がトランザクションを「忘れる」ことができる(情報が、関係者内の非揮発性記憶装置内に格納されているから)時点を指示する。段階348において、トランザクションはコミットリスト210に追加される。
【0076】
IPは閉止メッセージを送る前にそのディスクをフラッシュするから、任意のインタバルNに関連するデータベースシステム5内の全てのログ記録は、IC110がインタバルNを閉じる時までにディスクへフラッシュされている。従って、インタバルNに、またはそれより早くトリガされるコミット要求状態を有するトランザクションは、インタバルNが閉じられると、即ち全てのIPが閉止メッセージを送ると、IC 110によってコミットすることができる。
段階338において、もしトランザクション状態が「コミット要求」でなければ、何等の行動も起こされない。他の全てのトランザクション状態は無視され、この時点、即ち段階349において、ICは明示された動作を要求しない。
最後に、段階336においてICは、トランザクション状態リスト170内のさらなるトランザクションの存否を決定する。もしIC 110が最後のトランザクションを処理すれば、段階305へ進められる。もしさらなるトランザクションが存在すれば、段階337においてICは、次のトランザクション記録410を処理し、段階330へループバックする。
【0077】
もしトランザクションタグ413がインタバルタグ421より大きいか、またはANDの結果が非0であれば、段階333においてIC 110は、インタバル開アレイ425内の最後の(最も古い)記録420を解析したか否かを決定する。もし否であれば、段階334においてICは、次のインタバル開へ移動し、段階331へ戻ってプロセスを繰り返す。
図19に示すように、各ローカルインタバル中に、各IPは以下の諸段階を実行する。
1.トランザクションログバッファのフラッシュを開始 (段階351)
2.インタバルメッセージを解析 (段階352)
3.閉止メッセージを作成 (段階353)
4.インタバル閉ログ記録を書き込み (段階354)
5.ログバッファのディスクへのフラッシュを待機 (段階355)
6.閉止メッセージを送る (段階356)
7.トランザクションセッションを目覚めさせる (段階357)
8.ICからのインタバルメッセージを待機 (段階358)
9.ローカルインタバルキーを更新 (段階359)
オーナーが新しい分散したトランザクションを開始させる度に、またはヘルパーが要求メッセージを受信する度に、トランザクションは、記録470としてローカルトランザクション状態テーブル480内へ入力される。トランザクション状態テーブルは、ハッシュテーブルとしてフォーマットすることができる。図22に示すように、ハッシュテーブル480内の各記録470は、グローバルトランザクションID 471、ローカルトランザクションID 472、トランザクションが最後に状態を変えたローカルインタバルを示すタグ473、トランザクションの状態を「コミット要求」、「コミット済」、「打切り済」、「検査要求」、または「据置き」として識別するフィールド474、及びセッションID475を含み、トランザクションが状態を変える時を通告する。セッションID 475は、ICからのインタバル閉止メッセージ120の結果としてのトランザクションの状態の変化をIPから知らされるべき正しいトランザクション関係者を内部的に識別するために使用される。ハッシュテーブル480は、そのコサーバが関係者であるような活動トランザクションのリストとして役立つ。
【0078】
IP 115aのようなIPは、図19の段階358においてICからのインタバル閉止メッセージを受信することによってローカルインタバルを開始する。段階359においてIPは、ICからの閉止メッセージ内に含まれるマスタインタバルの値を、そのローカルインタバルキーに割当てる。次に、段階351においてIPは、バッファ60a内のトランザクションログ64aの内容を非同期的にディスク24aへフラッシュし始める。トランザクションログフラッシュは、ディスク書き込みの遅れと、IPがインタバル閉止メッセージを処理する時点とが重なるように直ちに要求される。
ディスク24aへのフラッシュを開始した後に、段階352においてIP 115aは、それが受信したインタバルメッセージ120を解析する。処理段階352の詳細に関しては図20を参照して後述するが、要約すれば、この処理段階中にインタバルメッセージ120が調べられ、そのコサーバが関与しているコミットリスト210、打切りリスト212、検査リスト214、及び故障リスト216内の何等かのトランザクションが処理される。段階352の間に、IPのトランザクション状態テーブルが更新され、ICから今受信したばかりのインタバル閉止メッセージの結果として状態を変えるであろうトランザクションを表す。また、段階352においては、一時的に変化した状態スタック465が作成される。これは段階357において、状態を変えたトランザクションに関連する特定関係者に通告するのに使用される。これらのトランザクションのコミッッテイング及び打切りに加えてIP 115a−115gは、直接またはトランザクション関係者を介して、マークされたトランザクションのためのローカルロックを解除する。
【0079】
段階353においてIPは、コミット要求リスト260、打切りリスト262、検査要求リスト264、及び検査返答リスト266と、必要な見出し情報(メッセージの型250、ローカルタグ252、IP識別254、及びフラグ256−259)とを組合わせることによって閉止めメッセージ125を作成する。
コミットリスト260、打切りリスト262、及び検査要求リスト264は、トランザクションオーナーの代わりにそのIPによって作成される。検査返答リスト266は、トランザクション関係者に代わって作成される。トランザクションオーナーまたは関係者が、そのICのための特定トランザクション関係者に関する命令または情報を入手する度に、トランザクションオーナーはIP内のルーチンを呼出してそのトランザクションを適切なリストへ追加する。
【0080】
トランザクションオーナーが、各関係者セッションから完了メッセージ145を受信すると、トランザクションは、暗示的に、またはユーザからの明示的な要求に基づいて、コミット評価を開始できる点にある。もしそのトランザクションが据置き制約評価を要求しなければ、トランザクションオーナーはIP 115c内のルーチンを呼出してそのトランザクションをコミット要求リスト260に追加する。
図10を参照する。例えば、オーナー130がコサーバ102aから完了メッセージ145aを受信し、そのトランザクションをコミットする要求を受信すると、IP 115cは据置き制約が存在しないことに注目し、トランザクションの状態をコミット要求に変え、その勘定振替トランザクションを閉止メッセージ125−2c内のコミット要求リスト260へ追加する。
【0081】
同様に、もしユーザがトランザクションを打切ることを決定するか、またはもし制約検査に失敗すれば、トランザクションオーナーはIP 115c内のルーチンを呼出してそのトランザクションを打切りリスト262へ追加する。
もしコミットは要求されているが据置き制約が存在すれば、トランザクションオーナーはルーチンを呼出してそのトランザクションを検査要求リスト264へ追加する。次いで制約検査要求が、コミットまたは打切りのための要求の同じようにIC 110へ送られる。次いでIC 110はそのトランザクション内の全ての関係者へ検査メッセージを送り、制約検査を遂行して結果を報告するように関係者に命令する。もしどのコサーバも制約を侵していなければ、IC 110はオーナー130が要求を明示しなくとも、そのトランザクションをコミットする。
【0082】
トランザクションオーナーを含むトランザクション関係者は、IC 110からの検査要求に応答して制約検査を完了する。その検査が成功であっても、または不成功であっても、トランザクション関係者はルーチンを呼出してそのトランザクションを検査返答リスト266へ追加する。
図19へ戻って、閉止メッセージ125を作成した後、段階354においてIPは、IPがICに応答してそのインタバルを閉じたことを表す「インタバル閉」ログ記録をトランザクションログ内に入力する。インタバル閉ログ記録は、インタバル番号と、そのインタバルにおいてコミットされたトランザクションのリスト455とを含む。書き込み段階354が作成段階353の後に発生するように示してあるが、書き込み段階354は目覚め段階357の前のどの時点に発生しても差し支えない。代替実施例では、書き込み段階354及び待機段階355は、作成段階353の前に配置されている。
【0083】
段階355においてIPは、最後のローカルインタバルに関するログ記録を含むバッファ60cがディスク24cへフラッシュされるのを待つ。フラッシュは段階351に開始されたのであるが、段階355の前に完了していないかも知れない。続行する前にバッファ60cのフラッシュを待つことによって、IP 115cが閉止メッセージを送る時点が確保され、そのローカルインタバルに関する全てのログ記録は非揮発性記憶装置内に格納され、障害が起こっても失われなくなる。次いで、段階356においてIPは、閉止メッセージ125をIC 110へ送る。
段階356において閉止メッセージ125をIC 110へ送った後、段階357においてIPは、トランザクションの状態が変化しているトランザクション関係者に通告する。IPは、変化した状態スタック465内の各記録を調べて適切なトランザクション関係者へ通報するので、その関係者は、例えばトランザクションがコミットされたことをユーザに知らせるような適切な行動を起こすことができる。分離したデータ構造として示してあるが、変化した状態スタック465は単に、状態が変化したトランザクションを接続するトランザクション状態テーブル480内の1組のリンクであってよい。各リンクは、記録470内のポインタ(別の記録470を指し示す)であることができる。このような場合IPは、リンクを辿ってハッシュテーブル480を通って移動することによってトランザクション関係者に通告する。
【0084】
通告されたトランザクション関係者は、もしそのトランザクションが打切られていれば、その操作処理を元に戻し、トランザクションログ64c内に打切りログ記録を入力する。もしトランザクションがコミットされていれば、トランザクション関係者はトランザクションログ64c内にコミットログ記録を入力する。もし新しい状態が「検査要求」であれば、トランザクション関係者は制約検査を開始することができる。
上述したように、トランザクションが制約検査に成功すれば、そのトランザクションは検査返答リスト266内の次の閉止メッセージ125内へ含まれる。もしトランザクションが制約検査に成功しなければ、そのトランザクションは検査返答リスト266内の次の閉止メッセージ125内へ障害として含まれる。
【0085】
待機段階358においてIPは、IC 110からの次のインタバルメッセージを、時間を決めずに待機する。データベースシステム5はバックアップIC(図23を参照して後述する)を使用してIC 110内の障害を検出し、応答する。
段階358における待機状態がIPの初期状態であることは理解されよう。インタバルメッセージを受信した後に限って、IPは、待機状態から脱してインタバル処理を開始する。
IP 115aのようなIPがIC 110からインタバルメッセージを受信した後、段階359においてIPは、インタバルメッセージ120内に指定されているマスタインタバルタグ202を用いてローカルインタバルキー155aをリセットする。次いでIPは、段階351へループバックしてトランザクションログのフラッシュを要求することによって、新しいローカルインタバルを開始する。
【0086】
要約すれば各IPは、IC 110からのインタバルメッセージ120に応答して閉止メッセージ125を送り、インタバル閉ログ記録を書き込み、ローカルインタバルキーを維持し、そしてトランザクションの状態が変化するとトランザクション関係者に通告する。トランザクション関係者は制約検査に応答し、コミット及び打切りログ記録をトランザクションログ64a−64cへ書き込む。
図20に示すように、段階352においてIPは、インタバルメッセージ120を解析する。段階371においてIP 115cのようなIPは、トランザクション状態テーブル480内のトランザクションを調べ、コサーバ102cがインタバル閉止メッセージ120内の次のトランザクション内の関係者であるか否かを決定する。もしコサーバ102cがそのトランザクションに関与していなければ、IP 115cはインタバルメッセージ120内の次のトランザクションへ移動する。
【0087】
もしコサーバ102cがそのトランザクションに関与していれば、段階372においてIP 115はハッシュテーブル480内の状態474を変える。詳しく説明すれば、トランザクションがコミットリスト210、打切りリスト212、または検査要求リスト214内にあるか否かに依存して、状態474はそれぞれ「コミット」、「打切り」、または「検査要求」に変化する。
状態474を変化させた後、段階373においてコミットされた、及び打切られたトランザクションはトランザクション状態テーブルから除去され、変化した状態スタック465に追加される。据置き制約検査に関与したトランザクション関係者は、制約検査が開始されたことを通告される。
コサーバ102cがトランザクションに関係したものとすれば、段階374においてIPは、トランザクション状態が「コミット」に変化したか否かを決定する。もしそのように変化していれば、段階375においてそのトランザクションは、コミット記録450としてコミットリスト455(図22参照)に追加される。コミットリスト455は、インタバル閉記録の一部としてトランザクションログ及びディスク24cへコピーされる。
【0088】
段階376においてIPは、トランザクションが完了したか否かを決定する。ICメッセージのリスト内に「コミット」または「打切り」として分類されているトランザクションは完了と見做され、「据置き検査」として分類されているものは未だに活動のトランザクションであると見做される。もしトランザクションが完了ならば、段階377においてトランザクション記録470をハッシュテーブル480から除去することができる。
もしさらなるトランザクションが存在しないことが段階378によって決定されれば、IPはその解析を完了したのであり、段階353へ移動する。
繁忙なシステムでは、コサーバ102d上で走るIP 115dは、閉止メッセージ120にタイムリに応答できないかも知れない。例えばコサーバ102dが、その処理能力一杯の極めて複雑な1組の操作処理を実行しているかも知れない。もしIP 115dがインタバルのしきい値数(例えば、 50 乃至 100インタバル)をミスすれば、IC 110は、IP 115dを延期にし、インタバルメッセージをIP 115dへ送るのを中断する。もしIP 115dが「延期」メッセージを送れば、それは不活動としてマークされる。IP 115dが応答できるようになるとIPは「更新要求」メッセージをIC 110へ送ることができ、ICは「更新」メッセージで応答する。これによりIP 115dは、それがミスした全てのインタバル閉止メッセージを処理することなく現インタバルを取り戻すことができる。
【0089】
IP 115dを延期し、後刻それを更新できるようにすると、コサーバが所与の時間内に全てのインタバルメッセージを処理できるようになった時に発生する2つの費用が緩和される。第1の費用は、そのようになっていなければ、全ての介在インタバルメッセージを現在にするためにIP 115dが処理する必要があることである。第2の費用は、IPが応答しなかった全てのインタバルに関する記録をIC 110が維持しなければならないことである。
IP 115a−115gが不活動である場合、ネットワーク資源を保存するためにIC 110は遊休状態に入ることができる。IP 115aのようなIPは、分散したトランザクションがコサーバ102a上で実行され始めた時から、IP 115aが「遊休」メッセージを送るか、IC 110によって延期されるか、または故障してラインから外されるまで活動であると見做される。IPは、もしそれが指定された時間(例えば、100 インタバル)にわたってトランザクション関係者でなければ「遊休」に入ることができ、「遊休」メッセージをICに送る。正常な動作状態の下では、待機段階301呼出しが自動的にタイマを失効させる。IC 110は、もし活動IPが存在しなければ遊休状態に入ることができる。遊休状態では、IC 110はインタバル処理を中止し、代わりにIPからのメッセージを、時間を定めずに待機する。IC 110は、IC 110の健全性を監視するためにそのバックアップIC(図23を参照して後述する)へメッセージを送るのに十分な頻度で目覚める。
【0090】
復旧
2つの障害シナリオ、即ちIC 110を走らせているコサーバの故障、またはデータベースシステムの完全な故障が、IC 110に直接影響を与える。両方の故障に対して保護するために、クリティカル情報は、各マスタインタバルが閉じる時にIC 110によってディスク24dへ書き込まれる(説明の目的から、IC 110がコサーバ102d上で走っているものとする)。
データベースシステム5においては、トランザクション状態リスト170がIC 110によって非揮発性記憶装置へコピーされると、トランザクションはコミットされる。しかしながら、IC 110はコミット記録を恒久的に保持する必要はない。後述するように、IC 110は、(このようなトランザクション状態を伝統的にロッギングして恒久的に格納するのではなく)先行マスタインタバルに関するトランザクション状態の「スナップショット」だけを保持することが好ましい。トランザクションがコミットまたは打切られたことをIC 110がIP 115a−115gに通報すると、関係者はその情報をそれらのトランザクションログ内に格納する。IC 110が各関係者から閉止メッセージを受信すると、IC 110はコミットまたは打切り記録が、所与のトランザクションに関係する全てのコサーバのディスク24a−24g上のそれぞれのログへフラッシュされたことを知る。従って、各コサーバはICをさらに参照することなく所与のトランザクションの最終状態を持続的に解消することができる。この点において、ICは最早トランザクションの最終状態をディスク24d上のシステムのトランザクション状態の「スナップショット」内に維持する必要はなくなる。従って、データベースシステム5においては、IC 110は、各関係者があるトランザクションの状態のログ記録をフラッシュするまで、そのトランザクションの状態の記録を維持する責を負い、一方個々のIPはコサーバ及び打切り記録をそれらのローカルトランザクションログ内に恒久的にログする責を負う。
【0091】
IC 110は、ディスク上にシステムの現トランザクション状態の完全且つ正確なコピーが常に存在することを保証するために、二重バッファリング方式を使用する。例えば、もしIC 110がマスタインタバル#5に関するログ記録をディスク上の1つの位置へフラッシュすれば、IC 110はマスタインタバル#6を閉じる時そのログ記録をディスク上の異なる位置へ書き込む。ログ記録がフラッシュされてしまえば、マスタインタバル#5に関するデータは古いものとしてマークされるので、そのディスクスペースはマスタインタバル#7のために使用することができる。もしマスタインタバル#7中にディスクへの書き込みに失敗するか、またはもしマスタインタバル#7のログ記録を書き込んでいる間にデータベースシステム5がクラッシュすれば、マスタインタバル#6のログ記録は未だにIC 110の次の適切な操作処理のために完全、正確、且つ十分である。
【0092】
システム内の全てのコサーバは、現IC、活動バックアップIC、またはリザーブバックアップICの何れかを含むことができる。図23に示すように、もしデータベースネットワーク100が2またはそれ以上のコサーバを有していれば、データベースシステム5は活動バックアップIC 520を含んでいよう。活動バックアップIC 520がコサーバ102e上で走るように示してあるが、活動バックアップICは、IC 110が走っているコサーバ102cを除くどのコサーバ上でも走ることができる。もし、ネットワーク100が3またはそれ以上のコサーバを有していれば、データベースシステム5は活動バックアップIC 520、及び1またはそれ以上のリザーブバックアップIC 525a、525bを含むであろう。リザーブバックアップIC 525a、b、d、f、及びgは、未だIC 110及び活動バックアップIC 520が走っていない例えばそれぞれコサーバ102a及び102gのようなどのコサーバ上でも走ることができる。もし活動バックアップIC 520が何時か故障すれば、リザーブICが活動化される。これにより、IC 110が使用不能になった場合に素早いレスポンスが得られる。
【0093】
各マスタインタバルの終わりに、トランザクション情報リスト170内のトランザクション状態情報が、「バックアップメッセージ」530の形状で、IC110から活動バックアップIC 520へ送られる。活動バックアップIC520はこの情報をローカル揮発性バッファ22eへコピーし、「承認(またはアクノリッジ)メッセージ」535をIC 110へ送る。承認メッセージ535は、活動バックアップIC 520がトランザクション状態情報を受信したことをIC 110へ通告する。しかしながら活動バックアップIC 520は、そのトランザクション情報をコサーバ102eのディスク22eへ書き込まない。IC 110は、それが活動バックアップIC 520から承認メッセージ535を受信するまで、且つIC 110がトランザクション状態情報をディスク22dへ書き込むまで、IP 115a−115gへ閉止メッセージ120を送らない。もしIC 110が承認メッセージ535を待たなければ、活動バックアップIC 520内の情報が、IPの情報と矛盾するかも知れず、復旧には無用になるであろう。
【0094】
IC 110及び活動バックアップIC 550の両方が故障の場合には、ディスク22d上のマスタインタバル情報577は、再始動したIC 110、再始動したバックアップIC 550による、またはリザーブバックアップIC525a−525gの1つの活動化によるシステムのトランザクション状態の回復及び再初期化に使用される。
もしIC 110が指定された時間(例えば、3秒)内に承認メッセージ535を受信しなければ、IC 110は、活動バックアップIC 520が故障して、リザーブバックアップIC 525の1つが昇格しているものと考えることができる。同様にもし活動バックアップIC 520が指定された時間内に次のバックアップICメッセージ530を受信しなければ、活動バックアップIC520は、IC 110が故障しているものと見做し、その任務を引き継ごうと試みる。
【0095】
データベースシステム5は、IC位置の変化及びバックアップICの昇格を処理する構成管理者540(例えば、コサーバ102g上で走る)を含む。IC110の位置を変えるという構成管理者540への要求は、活動バックアップIC 520からしか到来しない。もしコサーバ102eが活動バックアップICとして管理者に認識されれば要求は承認され、コサーバ102e上のバックアップICがIC 110になる。次いで、リザーブバックアップICが活動バックアップICとして昇格する。もし要求者が要求時に活動バックアップICでなければ(例えば、もしそれがコーディネータにより早めに降格されていれば)、その要求は拒否され、コサーバ102aはリザーブバックアップICとして登録される。
【0096】
本発明の好ましい実施例では、リザーブバックアップICだけが、活動バックアップICになる中間段階を経て、IC 110に直接昇格することができる。リザーブバックアップICは、メッセージ530を通してグローバルトランザクション状態を受信することによって、または先にログされた故障IC 110のグローバルトランザクション状態577を受信することによって、活動バックアップICになることができる。代替実施例では、リザーブバックアップICは、システムの現グローバルトランザクション状態を集めるためにIPと「IC使用可」及び「IC更新」メッセージを交換することによってIC 110になることもできる。
活動バックアップIC 520がIC 110になると、それはメモリ22e内の情報を使用してその構造を最新のトランザクション状態で初期化し、情報をディスクへ書き込み、「IC使用可」メッセージを全てのIP 115a−115gへ送ってIC 110の位置が変わったことを通告する。IPからの「IC更新」応答が、新しいIC 110のグローバルトランザクション状態を確認するために使用される。これで、トランザクション処理を続行することが可能になる。
【0097】
リザーブされたバックアップICを、IC 110または活動バックアップICに指名変えできるのは構成管理者540だけである。先に説明したリザーブバックアップICの活動バックアップICへの昇格、及び活動バックアップICのIC 110への昇格の両方に関しては、構成管理者が唯一の決定者になっている。この構成管理者とのインタラクションは、2つの独立したインタバルコーディネータからインタバルメッセージを受信することを防ぐために必要である。このような事態は、もしIC 110が、活動バックアップIC 520は死んでいると信じて新しい活動バックアップICを要求し、IC 110は故障であると活動バックアップIC 520が考えて自分自身をインタバルコーディネータに昇格させると発生し得る。
【0098】
ある時点にコサーバ102aのようなコサーバが故障すると、そのコサーバはIC 110によって登録抹消される。コサーバ102aが復旧すると、それはディスク24a上のトランザクションログ64a内に格納されている全ての操作処理を再生することによってロールフォワードする。
もしIP 102aがトランザクションログ64aに基づいてそのロールフォワードを完了した後に開いたトランザクションが残っていれば、IC 110はどのようにしてそれらを解消するかを決定する。IP 115aはIC 110へ「復旧」メッセージを送り、IC 110はメモリ60d内のトランザクション状態リスト170にアクセスしてIP115aが関係者であったトランザクションを見出すことによって応答する。次いでIC 110はコミットしたトランザクションをリストしている「復旧返答」メッセージをIP 115aへ送る。「復旧返答」メッセージによって伝送された情報に対して行動が起こされた後も開いたままのトランザクションは打切られる。コサーバ102aが復旧を完了した後、IP 115aはそのトランザクションログ64aをディスク24aへフラッシュし、「復旧完了」メッセージをIC 110へ送る。IC 110はコサーバ102aに関するトランザクション情報を、トランザクション状態リスト170からクリヤする。全てのトランザクションが解消され、最初の分散したトランザクションが実行され始めると、IP 115aは「使用可」メッセージをIC 110へ送り、IC 110はコサーバ102aを再登録する。
【0099】
上述した構成では、データベースシステム5は以下に説明する故障シナリオから復旧することができる。
図9を参照する。もしIC 110によるトランザクションが完了する前にオーナー130が故障すれば、IC 110は次のインタバルメッセージ内にコサーバ102cの未解消トランザクションの打切りを含ませ、そのトランザクションは全ての関係者コサーバ上で打切られる。復旧中に、コサーバ102cはそのトランザクションを打切る。
もしトランザクションがIC 110によってコミットされた後に故障すればトランザクションの他の関係者は、そのトランザクションが正常にコミットされたことを通報される。しかしながら、IC 110はコサーバ102cが復旧するまで、コサーバ102cに関する記録をトランザクション状態リスト170内に格納している。結局は、復旧プロセス中に、コサーバ102cはIC 110へメッセージを送って何等かの未解消トランザクションの最終状態を要求する。IC 110は、リスト170内の情報に基づいて、オーナー130が開始したトランザクションがコミットされたことをIPへ通報する。そこでコサーバ102cはコミットログ記録をトランザクションログ64c内へ書き込む。
【0100】
もし、インタバル閉ログ記録がディスク24cへフラッシュされた後にオーナー130が故障すれば、復旧中に、コサーバ102cはトランザクションログ64c内の情報を使用するだけでトランザクションのローカルコミット処理を完了する。コサーバ102cとICとのインタラクションは必要としない。
もし、完了メッセージ140aがオーナー130へ送られる前にヘルパー135aが故障すれば、コサーバ102cはコサーバ102aが故障したことを通知し、そのトランザクションは打切られる。コサーバ102eがトランザクションの打切りをIC 110へ通知すると、IC 110は前述したように、102aを除くトランザクションの全ての関係者にトランザクションの打切りを通知する。復旧中に、コサーバ102aはそのトランザクションを打切る。
【0101】
もし、完了メッセージ140aがオーナー130へ送られた後ではあるが、IC 110がそのログ記録をディスクへフラッシュすることによってそのトランザクションをコミットする前にヘルパー135aが故障すれば、それでもそのトランザクションは他のコサーバ102b−102g上で進行することができる。もしオーナー130が、コサーバ102aの故障を通知する前にコミットを要求されなければ、オーナー130はそのトランザクションを打切る。これは、通常のトランザクション打切りとして処理される。もしオーナー130が既にコミットを要求されていれば、IC 110は、コサーバ102aが故障したことを通知された時にそのトランザクションを打切りとしてマークする。両方の場合に、コサーバ102aは、復旧処理の一部としてそのトランザクションを打切る。
【0102】
もし、IC 110がそのトランザクションをコミットした後ではあるが、トランザクションログ64a内のコミットログ記録がディスクへフラッシュされる前にヘルパ135aが故障すれば、トランザクション内の他の関係者はそのトランザクションが通常通りコミットされたことを通報される。しかしながら、もしIC 110は、コサーバ102aが復旧するまでリスト170内にそのトランザクションを格納する。結局は、復旧プロセス中に、コサーバ102aはIC110へメッセージを送ってその未解消トランザクションの最終状態を要求する。IC 110はリスト170へアクセスし、そのトランザクションがコミットされたことをコサーバ102aに通報する。そこで、コサーバ102aはコミットログ記録をトランザクションログ64a内に書き込む。
【0103】
もし、コミットログ記録がディスク22aへフラッシュされた後にヘルパ135aが故障すれば、コサーバ102aは、自分自身のトランザクションログ64aを使用してそのトランザクションがコミットされたか否かを決定する。ICとインタラクトする必要はない。
もしIC 110が故障し、活動バックアップICがコーディネータまたはコサーバのホスティングの役割を果たすまで、分散したトランザクションをコミットまたは打切ることができなければ、コーディネータがラインに戻される。何れの場合も、保管されていたグローバルトランザクション状態が復元され、「IC使用可」メッセージがICに登録された全ての関係者へ送られる。
もしオーナー130及びヘルパー135aが故障すれば、その状況は一方または他方が故障した場合と同じように処理される。
【0104】
もし全システムが故障(全てのコサーバ102a−102gが故障)すれば、データベースシステム5が復旧した時に、リスト170内に保管されていたトランザクション状態577がディスク22dから復元され、IC 110は、クラッシュ時に活動または遊休として登録されていた全てのコサーバへ「IC使用可」メッセージを送る。次いでIC 110は返答を待つ。各コサーバは復旧情報に関する要求を送り、その復旧のロールフォワード段階を完了した後も開き続けているトランザクションを解消する。
活動バックアップICが使用不能であり、IC 110を走らせているコサーバが故障すれば、以下の2つの動作の一方が行われる。もしデータベースシステム5がコサーバ再始動をサポートしていれば、分散した全てのトランザクションの終止は、ICが再始動できるまで遅らされる。もしコサーバの再始動が不可能であれば、データベースシステム5は、IC 110またはバックアップICが再始動するまでトランザクションを処理することはできない。
【0105】
若干のトランザクションは、複数のデータベースシステムにわたっている。このようなトランザクションの場合には、本発明のデータベースシステムは外部データベースシステムとインタラクトしなければならない。外部データベースシステムは、標準2相コミットプロトコルのような異なるコミットメントプロトコルを使用しているかも知れない。外部データベースシステムとインタラクトするデータベースシステム100を必要とするトランザクションを、外部トランザクションと呼ぶ。外部トランザクションの場合には、本発明のコミットメントプロトコルは、2相コミットにおける関係者のセマンティック要求を満足できなければならない。
データベースシステム100は、2つの例外を除いて、外部トランザクションを通常の内部トランザクションとして処理することができる。第1は、データベースシステム100は、外部データベースシステムが使用しているグローバル外部トランザクション識別子と、データベースシステム100のIP及びICが使用している内部識別子との間で写像(またはマッピング)を行うことである。
【0106】
第2は、もし外部トランザクションが「コミット要求」状態に入っていれば、外部トランザクション内の各内部関係者が閉止メッセージを送った後に、ICが外部トランザクションを「休止」状態に置く。外部トランザクションが「休止」状態に入った後に、データベースシステム100は、外部トランザクションを準備するための外部要求に応答して成功状態を取り戻すことができる。続いて、外部要求に応答して、ICは外部トランザクションの状態を「打切り」または「コミット」に変えることができる。
復習すれば、本発明はコンピュータネットワーク上の分散データベースシステム内に分散したトランザクションをコミットする方法である。分散データベースシステムは、コサーバと呼ぶ複数のデータベースサーバからなる。コンピュータネットワーク内のコンピュータまたはノード上には1より多くのコサーバが存在し得る。インタバルコーディネータ(IC)はコサーバの1つに存在し、インタバル関係者(IP)は各コサーバに存在する。ICは「インタバルメッセージ」と呼ぶメッセージを各IPへ定期的に送出する。インタバルメッセージは、連続する各インタバル毎にICによって増加させられるインタバル識別子を含み、新しいインタバルが開始されたことをIPに通告する。各IPは、そのローカルインタバルを指定するインタバルカウンタを維持している。インタバルメッセージに応答して、IPはそのインタバルカウンタをインタバル識別子からの値にセットし、そのコサーバに関連するトランザクションログを非揮発性記憶装置へフラッシュする。ログをフラッシュした後、IPは「閉止メッセージ」と呼ぶメッセージをICへ送り返す。
【0107】
分散トランザクションに関与している各コサーバはそのトランザクション内の関係者である。トランザクションを発した関係者を「オーナー」と呼び、他の関係者を「ヘルパー」と呼ぶ。ヘルパーはデータベース更新を完了すると、そのインタバルカウンタの値でタグを付けられた応答メッセージをオーナーへ送る。
オーナーは何れかの関係者によるトランザクションの更新に関連する最新のタグを格納する。ユーザ(即ち、トランザクションオーナー)がトランザクションをコミットすることを要求する場合、オーナーはトランザクションのコミット要求を、格納したタグ及びトランザクションに関係しているコミットのリストと共にICへ伝送する。この要求は、次の閉止メッセージ中に送ることができる。
ICは、全てのIPがあるインタバルのための閉止メッセージを送るまで、そのインタバルに関する記録を格納する。ICは、そのトランザクション内の関係者の全てがあるインタバル(そのトランザクションに関して格納したタグに等しいか、またはより新しいインタバル)のための閉止メッセージを送ったと決定すると、そのトランザクションをコミットすることができる。トランザクションをコミットできるとICが決定すると、ICはそのトランザクションに関するコミット記録をICのログへ書き込む。コミットされたトランザクションのリストは、次のインタバルメッセージ内に含まれる。ICのログは、インタバルメッセージが送られる前に非揮発性記憶装置へフラッシュされるから、トランザクションをコミットするためのICの復旧可能性が保証される。
【0108】
コミットするトランザクションのリストを含むインタバルメッセージの受信に応答して、各コサーバは、それが関係者であった各トランザクション毎のトランザクションログ内にコサーバログ記録を入力する。トランザクション内の全ての関係者がそのインタバルのための閉止メッセージ(トランザクションのコミット通知を含む)を送ってしまうと、ICはそのトランザクションを忘れることができる。
このコミットプロトコルは、特にマルチノード並列処理コンピュータにおいて、交換されるメッセージの数を大幅に減少させ、それによって分散データベースシステムの性能を改善する。
以上に本発明の好ましい実施例に関して説明した。しかしながら、本発明はこの実施例に限定されるものではない。本発明の範囲は特許請求の範囲によってのみ限定されるものである。
【図面の簡単な説明】
【図1】コンピュータネットワークの概要図である。
【図2】コサーバネットワークの概要図である。
【図3】あるネットワークに接続されている2台のコンピュータのブロック線図である。
【図4】コンピュータデータベースの例である。
【図5】分散データベースのブロック線図である。
【図6】分散データベースが使用する2つのトランザクションログの例である。
【図7】本発明によりインタバルコーディネータ及び複数のインタバル関係者が走っているコサーバネットワークの概要図である。
【図8】本発明による分散データベースシステムの概要図である。
【図9】本発明によりインタバル関係者とインタバルコーディネータとの間のメッセージの交換を示すブロック線図である。
【図10】オーナー、ヘルパー、及びインタバルコーディネータの間のメッセージの交換を示す時間線である。
【図11】(A)、(B)、及び(C)は、図10の時点A、B、及びCに本発明の分散データベースによって維持されるコサーバログの例である。
【図12】インタバルメッセージの概要図である。
【図13】閉止メッセージの概要図である。
【図14】インタバルコーディネータのプロセスの流れ図である。
【図15】待ち行列内のメッセージを処理する方法の流れ図の一部である。
【図16】図15の流れ図の続きである。
【図17】トランザクション状態リストを処理する方法の流れ図の一部である。
【図18】図17の流れ図の続きである。
【図19】インタバル関係者のプロセスの流れ図である。
【図20】インタバルメッセージを解析する方法の流れ図である。
【図21】インタバルコーディネータが使用するデータ構造のブロック図である。
【図22】インタバル関係者が使用するデータ構造のブロック図である。
【図23】バックアップ内部コーディネータを使用する分散データシステムのブロック線図である。
【符号の説明】
5 分散データベースシステム
10 コンピュータネットワーク
12 コンピュータ
14 ネットワークライン
16 サーバ
18 プリンタ
20 CPU
22 メモリ
24 記憶装置
26 バス
30 データベース
32 小切手勘定テーブル
42 預金勘定テーブル
60 トランザクションバッファ
64 トランザクションログ
70−74 ログ記録
100 分散データベースプログラム
102 コサーバ
110 インタバルコーディネータ
115 インタバル関係者
120 インタバルメッセージ
125 閉止メッセージ
130 オーナー
135 ヘルパー
140 要求メッセージ
150 マスタインタバルキー
155 ローカルインタバルキー
160 ログ記録
170 トランザクション状態リスト
180 待ち行列
185 タイマ
425 インタバルアレイ
435 最後のタグアレイ
445 検査返答アレイ
455 コミットリスト
465 変化した状態スタック
470 トランザクション状態テーブル
520 活動バックアップIC
525 リザーブIC
540 構成管理者
Claims (8)
- 分散データベースシステムにおいて、オーナーとヘルパーとを含む分散したトランザクションをコミットする方法であって、
インタバルコーディネータを走らせる段階と、
複数のコサーバ、第1のコサーバに関連付けられている上記オーナー、及び第2のコサーバに関連付けられている上記ヘルパーを走らせる段階と、
上記コサーバを、少なくとも1つのトランザクションログに関連付ける段階と、
一連のインタバルメッセージを、上記インタバルコーディネータから上記各コサーバへ送る段階と、
上記インタバルメッセージの1つの受信に応答して、上記トランザクションログを、非揮発性記憶装置へフラッシュする段階と、
最も新しく受信したインタバルメッセージを識別する状態を、上記各コサーバ内に維持する段階と、
上記トランザクションログをフラッシュした後に、閉止メッセージを、上記各コサーバから上記インタバルコーディネータへ伝送する段階と、
上記第2のコサーバに実行させる上記分散したトランザクション内の操作処理を識別する要求メッセージを、上記オーナーから上記ヘルパーへ伝送する段階と、
上記処理操作を実行した後に、上記第2のコサーバの上記最も新しく受信したインタバルメッセージを識別するタグを含む完了メッセージを、上記ヘルパーから上記オーナーへ伝送する段階と、
上記完了メッセージを受信した後に、上記トランザクションについての適格性メッセージを、上記オーナーから上記インタバルコーディネータへ伝送する段階と、
上記オーナーから上記適格性メッセージを受信し、且つ上記ヘルパーから閉止メッセージを受信した後に、上記トランザクションに関するコミット状態を、安定した記憶装置へ書き込む段階と、
上記コミット状態を書き込んだ後に、上記トランザクションのコミットメッセージを、上記インタバルコーディネータから上記オーナー及び上記ヘルパーへ送る段階と、
を備えていることを特徴とする方法。 - 上記コミットメッセージは、上記インタバルメッセージを伴っている請求項1に記載の方法。
- 上記適格性メッセージは、上記閉止メッセージを伴っている請求項1に記載の方法。
- もし上記オーナーの状態が、上記タグと同一のインタバルメッセージを識別していれば、または上記オーナーの状態が、上記タグより早めのインタバルメッセージを識別していれば、上記適格性メッセージが送られるようにした請求項1に記載の方法。
- 上記トランザクションは複数のヘルパーを含み、上記オーナーは複数の要求メッセージを上記複数のヘルパーへ伝送し、上記各ヘルパーは完了メッセージを上記オーナーへ伝送し、上記インタバルコーディネータは上記各ヘルパーから閉止メッセージを受信した後にコミットメッセージを上記オーナー及び上記各ヘルパーへ送る請求項1に記載の方法。
- 上記コミットメッセージは、コミット命令である請求項1に記載の方法。
- 上記コミットメッセージは、打切り命令である請求項1に記載の方法。
- 上記各コサーバは、トランザクションログを有している請求項1に記載の方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/552058 | 1995-11-02 | ||
US08/552,058 US5799305A (en) | 1995-11-02 | 1995-11-02 | Method of commitment in a distributed database transaction |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH09251412A JPH09251412A (ja) | 1997-09-22 |
JP3790589B2 true JP3790589B2 (ja) | 2006-06-28 |
Family
ID=24203771
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP29185696A Expired - Fee Related JP3790589B2 (ja) | 1995-11-02 | 1996-11-01 | 分散データベーストランザクションのコミットメント方法 |
Country Status (7)
Country | Link |
---|---|
US (1) | US5799305A (ja) |
EP (1) | EP0772136B1 (ja) |
JP (1) | JP3790589B2 (ja) |
AU (1) | AU711220B2 (ja) |
BR (1) | BR9605407A (ja) |
CA (1) | CA2189307C (ja) |
DE (1) | DE69623229T2 (ja) |
Families Citing this family (147)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6006239A (en) * | 1996-03-15 | 1999-12-21 | Microsoft Corporation | Method and system for allowing multiple users to simultaneously edit a spreadsheet |
AT1751U1 (de) | 1996-09-30 | 1997-10-27 | Kuehn Eva | Koordinations-system |
US5914938A (en) * | 1996-11-19 | 1999-06-22 | Bay Networks, Inc. | MAC address table search unit |
US6035379A (en) * | 1997-01-09 | 2000-03-07 | Microsoft Corporation | Transaction processing for user data employing both logging and shadow copying |
EP1015997A4 (en) * | 1997-02-28 | 2006-03-29 | Siebel Systems Inc | PARTLY REPLICATED DISTRIBUTED DATABASE WITH MULTIPLE LEVELS FROM REMOTE CLIENTS |
SE521041C2 (sv) * | 1997-05-28 | 2003-09-23 | Ericsson Telefon Ab L M | Metod för optimering av transaktionsprotokoll inom en distribuerad databas |
US5953728A (en) * | 1997-07-25 | 1999-09-14 | Claritech Corporation | System for modifying a database using a transaction log |
US6144959A (en) * | 1997-08-18 | 2000-11-07 | Novell, Inc. | System and method for managing user accounts in a communication network |
US5999712A (en) * | 1997-10-21 | 1999-12-07 | Sun Microsystems, Inc. | Determining cluster membership in a distributed computer system |
US6236995B1 (en) * | 1997-11-13 | 2001-05-22 | Electronic Data Systems Corporation | Distributed object system with deadlock prevention |
US6009430A (en) * | 1997-12-19 | 1999-12-28 | Alcatel Usa Sourcing, L.P. | Method and system for provisioning databases in an advanced intelligent network |
US6202067B1 (en) * | 1998-04-07 | 2001-03-13 | Lucent Technologies, Inc. | Method and apparatus for correct and complete transactions in a fault tolerant distributed database system |
US6247023B1 (en) * | 1998-07-21 | 2001-06-12 | Internationl Business Machines Corp. | Method for providing database recovery across multiple nodes |
US6438582B1 (en) * | 1998-07-21 | 2002-08-20 | International Business Machines Corporation | Method and system for efficiently coordinating commit processing in a parallel or distributed database system |
US6728958B1 (en) * | 1998-07-31 | 2004-04-27 | Hewlett-Packard Development Company, L.P. | Volatile resource manager with pre-prepare notification |
US6138143A (en) * | 1999-01-28 | 2000-10-24 | Genrad, Inc. | Method and apparatus for asynchronous transaction processing |
US6941360B1 (en) * | 1999-02-25 | 2005-09-06 | Oracle International Corporation | Determining and registering participants in a distributed transaction in response to commencing participation in said distributed transaction |
US6411981B1 (en) | 1999-03-12 | 2002-06-25 | Compaq Computer Corporation | Method and apparatus for conducting a transaction between homogeneous and/or heterogeneous transaction processing systems using asynchronous pull of a transaction transfer |
US6560606B1 (en) * | 1999-05-04 | 2003-05-06 | Metratech | Method and apparatus for processing data with multiple processing modules and associated counters |
US7290056B1 (en) | 1999-09-09 | 2007-10-30 | Oracle International Corporation | Monitoring latency of a network to manage termination of distributed transactions |
US7206805B1 (en) * | 1999-09-09 | 2007-04-17 | Oracle International Corporation | Asynchronous transcription object management system |
US6578054B1 (en) | 1999-10-04 | 2003-06-10 | Microsoft Corporation | Method and system for supporting off-line mode of operation and synchronization using resource state information |
US6536000B1 (en) * | 1999-10-15 | 2003-03-18 | Sun Microsystems, Inc. | Communication error reporting mechanism in a multiprocessing computer system |
US6802022B1 (en) | 2000-04-14 | 2004-10-05 | Stratus Technologies Bermuda Ltd. | Maintenance of consistent, redundant mass storage images |
US6842823B1 (en) | 2000-04-14 | 2005-01-11 | Stratus Technologies Bermuda Ltd | Methods and apparatus for persistent volatile computer memory |
AU2001251617A1 (en) * | 2000-04-14 | 2001-10-30 | Stratus Technologies Bermuda Ltd. | Methods and apparatus for persistent volatile computer memory and related applications thereof |
US7421541B2 (en) * | 2000-05-12 | 2008-09-02 | Oracle International Corporation | Version management of cached permissions metadata |
US7389493B1 (en) | 2000-05-12 | 2008-06-17 | Oracle International Corporation | Categories on a per instance basis |
US7987217B2 (en) * | 2000-05-12 | 2011-07-26 | Oracle International Corporation | Transaction-aware caching for document metadata |
US7203709B2 (en) * | 2000-05-12 | 2007-04-10 | Oracle International Corporation | Transaction-aware caching for access control metadata |
US7185005B1 (en) | 2000-05-12 | 2007-02-27 | Oracle International Corporation | Nested transactions in a file system |
US7725878B1 (en) | 2000-05-12 | 2010-05-25 | Oracle International Corporation | Property bundles on a per instance basis |
US7325046B1 (en) | 2000-05-31 | 2008-01-29 | International Business Machines Corporation | Method, system and program products for managing processing groups of a distributed computing environment |
SG99941A1 (en) * | 2000-08-30 | 2003-11-27 | Ibm | Transaction support on logical disks |
US6801921B2 (en) * | 2000-09-08 | 2004-10-05 | Hitachi, Ltd. | Method and system for managing multiple database storage units |
US7349940B1 (en) | 2000-11-03 | 2008-03-25 | Agere Systems Inc. | Communication protocol for data exchange via shared files |
US7555500B2 (en) * | 2001-02-15 | 2009-06-30 | Teradata Us, Inc. | Optimized end transaction processing |
US7103586B2 (en) * | 2001-03-16 | 2006-09-05 | Gravic, Inc. | Collision avoidance in database replication systems |
US7177866B2 (en) * | 2001-03-16 | 2007-02-13 | Gravic, Inc. | Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only |
US6662196B2 (en) * | 2001-03-16 | 2003-12-09 | Iti, Inc. | Collision avoidance in bidirectional database replication |
US7146524B2 (en) | 2001-08-03 | 2006-12-05 | Isilon Systems, Inc. | Systems and methods for providing a distributed file system incorporating a virtual hot spare |
US7685126B2 (en) | 2001-08-03 | 2010-03-23 | Isilon Systems, Inc. | System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system |
US7028030B2 (en) * | 2001-08-30 | 2006-04-11 | Bea Systems, Inc. | Cluster caching with concurrency checking |
US6799188B2 (en) * | 2001-08-31 | 2004-09-28 | Borland Software Corporation | Transaction processing system providing improved methodology for two-phase commit decision |
US6909910B2 (en) * | 2002-02-01 | 2005-06-21 | Microsoft Corporation | Method and system for managing changes to a contact database |
US6901499B2 (en) * | 2002-02-27 | 2005-05-31 | Microsoft Corp. | System and method for tracking data stored in a flash memory device |
US7010662B2 (en) * | 2002-02-27 | 2006-03-07 | Microsoft Corporation | Dynamic data structures for tracking file system free space in a flash memory device |
US7533214B2 (en) * | 2002-02-27 | 2009-05-12 | Microsoft Corporation | Open architecture flash driver |
US7085879B2 (en) * | 2002-02-27 | 2006-08-01 | Microsoft Corporation | Dynamic data structures for tracking data stored in a flash memory device |
US7222136B1 (en) * | 2002-05-23 | 2007-05-22 | Oracle International Corporation | Communicating data dictionary information of database objects through a redo stream |
US20040039781A1 (en) * | 2002-08-16 | 2004-02-26 | Lavallee David Anthony | Peer-to-peer content sharing method and system |
AU2003291014A1 (en) | 2002-11-14 | 2004-06-15 | Isilon Systems, Inc. | Systems and methods for restriping files in a distributed file system |
US7093101B2 (en) * | 2002-11-21 | 2006-08-15 | Microsoft Corporation | Dynamic data structures for tracking file system free space in a flash memory device |
EP1603051A4 (en) * | 2003-01-27 | 2012-01-18 | Panasonic Corp | DISTRIBUTION SYSTEM FOR DIGITAL CONTENT |
US7707181B2 (en) * | 2003-02-19 | 2010-04-27 | Microsoft Corporation | System and method of distributing replication commands |
US7424653B2 (en) | 2003-05-09 | 2008-09-09 | Hewlett-Packard Development Company, L.P. | System and method for error capture and logging in computer systems |
US7120828B2 (en) * | 2003-05-09 | 2006-10-10 | Hewlett-Packard Development Company, L.P. | System and method for in-order queue draining |
US20040230862A1 (en) * | 2003-05-16 | 2004-11-18 | Arif Merchant | Redundant data assigment in a data storage system |
US7152077B2 (en) * | 2003-05-16 | 2006-12-19 | Hewlett-Packard Development Company, L.P. | System for redundant storage of data |
US7761421B2 (en) * | 2003-05-16 | 2010-07-20 | Hewlett-Packard Development Company, L.P. | Read, write, and recovery operations for replicated data |
US7213029B2 (en) * | 2003-05-29 | 2007-05-01 | International Business Machines Corporation | Quiescing work bounded by application transactions consisting of multiple relational database transactions |
US8533254B1 (en) * | 2003-06-17 | 2013-09-10 | F5 Networks, Inc. | Method and system for replicating content over a network |
EP1498815A3 (en) * | 2003-06-30 | 2006-11-29 | Gravic, Inc. | Methods for ensuring referential integrity in multi-threaded replication engines |
JP4291060B2 (ja) * | 2003-07-01 | 2009-07-08 | 富士通株式会社 | トランザクション処理方法,トランザクション制御装置およびトランザクション制御プログラム |
US7480658B2 (en) * | 2003-07-16 | 2009-01-20 | Joltid Ltd. | Distributed database system and method having nodes co-ordinated in a decentralized manner |
JP4291077B2 (ja) * | 2003-07-29 | 2009-07-08 | 株式会社日立製作所 | 分散ストレージ装置のファイル管理方法及び分散ストレージシステム |
US7644376B2 (en) | 2003-10-23 | 2010-01-05 | Microsoft Corporation | Flexible architecture for notifying applications of state changes |
JP4273934B2 (ja) * | 2003-11-13 | 2009-06-03 | 株式会社日立製作所 | ファイルシステム |
US7478400B1 (en) | 2003-12-31 | 2009-01-13 | Symantec Operating Corporation | Efficient distributed transaction protocol for a distributed file sharing system |
WO2005104444A2 (en) * | 2004-04-22 | 2005-11-03 | Pape William R | Method and system for private data networks for sharing food ingredient item attribute and event data across multiple enterprises and multiple stages of production transformation |
US7523204B2 (en) * | 2004-06-01 | 2009-04-21 | International Business Machines Corporation | Coordinated quiesce of a distributed file system |
US7809690B2 (en) * | 2004-07-13 | 2010-10-05 | Oracle International Corporation | Performance metric-based selection of one or more database server instances to perform database recovery |
US8051425B2 (en) | 2004-10-29 | 2011-11-01 | Emc Corporation | Distributed system with asynchronous execution systems and methods |
US8238350B2 (en) * | 2004-10-29 | 2012-08-07 | Emc Corporation | Message batching with checkpoints systems and methods |
US8055711B2 (en) * | 2004-10-29 | 2011-11-08 | Emc Corporation | Non-blocking commit protocol systems and methods |
WO2006057061A1 (ja) * | 2004-11-29 | 2006-06-01 | Fujitsu Limited | 分散トランザクション処理方法、装置、及びプログラム |
US7483987B2 (en) * | 2004-11-30 | 2009-01-27 | International Business Machines Corporation | Registering a resource that delegates commit voting |
US20070208753A1 (en) * | 2004-12-30 | 2007-09-06 | Ncr Corporation | Routing database requests among multiple active database systems |
US7827262B2 (en) * | 2005-07-14 | 2010-11-02 | Cisco Technology, Inc. | Approach for managing state information by a group of servers that services a group of clients |
US8190588B1 (en) | 2005-09-19 | 2012-05-29 | Amazon Technologies, Inc. | Providing a distributed transaction information storage service |
US7441230B2 (en) * | 2005-10-07 | 2008-10-21 | Lucasfilm Entertainment Company Ltd. | Method of utilizing product proxies with a dependency graph |
US9047306B1 (en) | 2005-10-17 | 2015-06-02 | Hewlett-Packard Development Company, L.P. | Method of writing data |
US7551572B2 (en) | 2005-10-21 | 2009-06-23 | Isilon Systems, Inc. | Systems and methods for providing variable protection |
US7917474B2 (en) | 2005-10-21 | 2011-03-29 | Isilon Systems, Inc. | Systems and methods for accessing and updating distributed data |
US7788303B2 (en) | 2005-10-21 | 2010-08-31 | Isilon Systems, Inc. | Systems and methods for distributed system scanning |
US7797283B2 (en) | 2005-10-21 | 2010-09-14 | Isilon Systems, Inc. | Systems and methods for maintaining distributed data |
US7827144B1 (en) | 2005-11-17 | 2010-11-02 | Hewlett-Packard Development Company, L.P. | Methods of reading and writing data |
US7725446B2 (en) * | 2005-12-19 | 2010-05-25 | International Business Machines Corporation | Commitment of transactions in a distributed system |
US7839876B1 (en) * | 2006-01-25 | 2010-11-23 | Marvell International Ltd. | Packet aggregation |
US7848261B2 (en) | 2006-02-17 | 2010-12-07 | Isilon Systems, Inc. | Systems and methods for providing a quiescing protocol |
US7756898B2 (en) | 2006-03-31 | 2010-07-13 | Isilon Systems, Inc. | Systems and methods for notifying listeners of events |
US7647454B2 (en) | 2006-06-12 | 2010-01-12 | Hewlett-Packard Development Company, L.P. | Transactional shared memory system and method of control |
US7886099B2 (en) | 2006-06-16 | 2011-02-08 | Superspeed Llc | Systems and methods for providing a personal computer with non-volatile system memory |
US8539056B2 (en) | 2006-08-02 | 2013-09-17 | Emc Corporation | Systems and methods for configuring multiple network interfaces |
US7680836B2 (en) | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7680842B2 (en) * | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7752402B2 (en) * | 2006-08-18 | 2010-07-06 | Isilon Systems, Inc. | Systems and methods for allowing incremental journaling |
US7899800B2 (en) | 2006-08-18 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7882071B2 (en) | 2006-08-18 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7953704B2 (en) | 2006-08-18 | 2011-05-31 | Emc Corporation | Systems and methods for a snapshot of data |
US7822932B2 (en) | 2006-08-18 | 2010-10-26 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7590652B2 (en) | 2006-08-18 | 2009-09-15 | Isilon Systems, Inc. | Systems and methods of reverse lookup |
US7676691B2 (en) | 2006-08-18 | 2010-03-09 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US8286029B2 (en) | 2006-12-21 | 2012-10-09 | Emc Corporation | Systems and methods for managing unavailable storage devices |
US7593938B2 (en) | 2006-12-22 | 2009-09-22 | Isilon Systems, Inc. | Systems and methods of directory entry encodings |
US7509448B2 (en) | 2007-01-05 | 2009-03-24 | Isilon Systems, Inc. | Systems and methods for managing semantic locks |
US8966080B2 (en) | 2007-04-13 | 2015-02-24 | Emc Corporation | Systems and methods of managing resource utilization on a threaded computer system |
US7779048B2 (en) | 2007-04-13 | 2010-08-17 | Isilon Systems, Inc. | Systems and methods of providing possible value ranges |
US7900015B2 (en) | 2007-04-13 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods of quota accounting |
US7949692B2 (en) | 2007-08-21 | 2011-05-24 | Emc Corporation | Systems and methods for portals into snapshot data |
US7966289B2 (en) | 2007-08-21 | 2011-06-21 | Emc Corporation | Systems and methods for reading objects in a file system |
US7882068B2 (en) | 2007-08-21 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for adaptive copy on write |
US7870110B2 (en) * | 2008-02-27 | 2011-01-11 | International Business Machines Corporation | Method and system for generating a transaction-bound sequence of records in a relational database table |
US7984324B2 (en) | 2008-03-27 | 2011-07-19 | Emc Corporation | Systems and methods for managing stalled storage devices |
US7953709B2 (en) | 2008-03-27 | 2011-05-31 | Emc Corporation | Systems and methods for a read only mode for a portion of a storage system |
US7949636B2 (en) | 2008-03-27 | 2011-05-24 | Emc Corporation | Systems and methods for a read only mode for a portion of a storage system |
US7870345B2 (en) | 2008-03-27 | 2011-01-11 | Isilon Systems, Inc. | Systems and methods for managing stalled storage devices |
US8447745B2 (en) * | 2008-09-12 | 2013-05-21 | Salesforce.Com, Inc. | Synchronizing field values in an on-demand database prior to committing a change |
US8495261B2 (en) * | 2008-12-12 | 2013-07-23 | International Business Machines Corporation | Redispatching suspended tasks after completion of I/O operations absent I/O interrupts |
US20100185714A1 (en) * | 2009-01-15 | 2010-07-22 | Microsoft Corporation | Distributed communications between database instances |
US9098383B1 (en) * | 2009-09-23 | 2015-08-04 | Nvidia Corporation | Consolidated crossbar that supports a multitude of traffic types |
US8266126B2 (en) * | 2010-03-24 | 2012-09-11 | Matrixx Software, Inc. | System with multiple conditional commit databases |
US8880486B2 (en) * | 2010-07-27 | 2014-11-04 | Sap Ag | Distributed database system utilizing an extended two-phase-commit process |
US9507841B2 (en) * | 2011-06-16 | 2016-11-29 | Sap Se | Consistent backup of a distributed database system |
US9870384B2 (en) * | 2012-03-30 | 2018-01-16 | International Business Machines Corporation | Database system transaction management |
US8812744B1 (en) | 2013-03-14 | 2014-08-19 | Microsoft Corporation | Assigning priorities to data for hybrid drives |
CN103268318B (zh) * | 2013-04-16 | 2016-04-13 | 华中科技大学 | 一种强一致性的分布式键值数据库系统及其读写方法 |
US9626126B2 (en) | 2013-04-24 | 2017-04-18 | Microsoft Technology Licensing, Llc | Power saving mode hybrid drive access management |
US9946495B2 (en) | 2013-04-25 | 2018-04-17 | Microsoft Technology Licensing, Llc | Dirty data management for hybrid drives |
US9110601B2 (en) | 2013-06-24 | 2015-08-18 | Sap Se | Backup lifecycle management |
US10185631B2 (en) * | 2013-07-04 | 2019-01-22 | Data Deposit Box Inc. | System and method of performing continuous backup of a data file on a computing device |
US10044835B1 (en) | 2013-12-11 | 2018-08-07 | Symantec Corporation | Reducing redundant transmissions by polling clients |
US10474493B2 (en) * | 2014-02-28 | 2019-11-12 | Red Hat, Inc. | Systems and methods for semi-durable transaction log storage in two-phase commit protocol transaction processing |
US10296371B2 (en) * | 2014-03-17 | 2019-05-21 | International Business Machines Corporation | Passive two-phase commit system for high-performance distributed transaction execution |
US10282228B2 (en) * | 2014-06-26 | 2019-05-07 | Amazon Technologies, Inc. | Log-based transaction constraint management |
CN104516959B (zh) * | 2014-12-18 | 2018-01-02 | 杭州华为数字技术有限公司 | 一种管理数据库日志的方法及装置 |
US10216820B1 (en) * | 2016-12-14 | 2019-02-26 | Gravic, Inc. | Method and apparatus for resolving constraint violations in a database replication system |
US11940990B1 (en) | 2017-06-16 | 2024-03-26 | Amazon Technologies, Inc. | Global clock values for consistent queries to replicated data |
US11314717B1 (en) * | 2017-06-23 | 2022-04-26 | Amazon Technologies, Inc. | Scalable architecture for propagating updates to replicated data |
US10268502B2 (en) * | 2017-06-29 | 2019-04-23 | Intel Corporation | Methods and apparatus to perform atomic transactions in nonvolatile memory under hardware transactional memory |
WO2019008158A1 (en) * | 2017-07-06 | 2019-01-10 | Chromaway Ab | METHOD AND SYSTEM OF DISTRIBUTED COMPUTER SYSTEM |
CN110196759B (zh) | 2018-06-20 | 2022-12-06 | 腾讯科技(深圳)有限公司 | 分布式事务处理方法和装置、存储介质及电子装置 |
US10642826B1 (en) * | 2018-08-30 | 2020-05-05 | Gravic, Inc. | Mixed-mode method for combining active/active and validation architectures utilizing a check integrity module |
CN110209734B (zh) * | 2019-05-05 | 2022-11-18 | 深圳市腾讯计算机系统有限公司 | 数据复制方法、装置、计算机设备及存储介质 |
US11880385B1 (en) | 2020-09-29 | 2024-01-23 | Amazon Technologies, Inc. | Ordering updates to secondary indexes using conditional operations |
US11250022B1 (en) | 2020-09-29 | 2022-02-15 | Amazon Technologies, Inc. | Offline index builds for database tables |
US11748212B1 (en) | 2021-06-28 | 2023-09-05 | Gravic, Inc. | Method and apparatus for resolving automatic transaction facility (ATF) failures |
Family Cites Families (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS60500232A (ja) * | 1983-02-09 | 1985-02-21 | インタ−ナシヨナル・ビジネス・マシ−ンズ・コ−ポレ−シヨン | 障害がない場合に最適化される、複数プロセッサの合意を得る方法 |
US5065311A (en) * | 1987-04-20 | 1991-11-12 | Hitachi, Ltd. | Distributed data base system of composite subsystem type, and method fault recovery for the system |
US4881166A (en) * | 1987-07-24 | 1989-11-14 | Amoco Corporation | Method for consistent multidatabase transaction processing |
US4949251A (en) * | 1988-07-18 | 1990-08-14 | Digital Equipment Corporation | Exactly-once semantics in a TP queuing system |
US5170480A (en) * | 1989-09-25 | 1992-12-08 | International Business Machines Corporation | Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time |
CA2025131A1 (en) * | 1989-09-28 | 1991-03-29 | John W. White | Portable and dynamic distributed applications architecture |
US5193162A (en) * | 1989-11-06 | 1993-03-09 | Unisys Corporation | Cache memory with data compaction for use in the audit trail of a data processing system having record locking capabilities |
US5257366A (en) * | 1990-03-27 | 1993-10-26 | International Business Machines Corporation | Query language execution on heterogeneous database servers using a bind-file bridge between application and database languages |
US5201044A (en) * | 1990-04-16 | 1993-04-06 | International Business Machines Corporation | Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory |
JPH0415840A (ja) * | 1990-05-10 | 1992-01-21 | Toshiba Corp | 分散型データベース管理装置 |
US5165031A (en) * | 1990-05-16 | 1992-11-17 | International Business Machines Corporation | Coordinated handling of error codes and information describing errors in a commit procedure |
US5212788A (en) * | 1990-05-22 | 1993-05-18 | Digital Equipment Corporation | System and method for consistent timestamping in distributed computer databases |
US5363121A (en) * | 1990-06-29 | 1994-11-08 | International Business Machines Corporation | Multiple protocol communication interface for distributed transaction processing |
JP2837288B2 (ja) * | 1990-09-17 | 1998-12-14 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 連鎖分散データトランザクションシステムにおけるワーク単位識別子の管理方法 |
AU9030391A (en) * | 1990-10-16 | 1992-05-20 | Consilium, Inc. | Object-oriented architecture for factory floor management |
US5329626A (en) * | 1990-10-23 | 1994-07-12 | Digital Equipment Corporation | System for distributed computation processing includes dynamic assignment of predicates to define interdependencies |
US5263155A (en) * | 1991-02-21 | 1993-11-16 | Texas Instruments Incorporated | System for selectively registering and blocking requests initiated by optimistic and pessimistic transactions respectively for shared objects based upon associated locks |
US5390302A (en) * | 1991-02-21 | 1995-02-14 | Digital Equipment Corporation | Transaction control |
US5287496A (en) * | 1991-02-25 | 1994-02-15 | International Business Machines Corporation | Dynamic, finite versioning for concurrent transaction and query processing |
US5212787A (en) * | 1991-03-12 | 1993-05-18 | International Business Machines Corporation | Method and apparatus for accessing a relational database without exiting an object-oriented environment |
US5333303A (en) * | 1991-03-28 | 1994-07-26 | International Business Machines Corporation | Method for providing data availability in a transaction-oriented system during restart after a failure |
US5258982A (en) * | 1991-05-07 | 1993-11-02 | International Business Machines Corporation | Method of excluding inactive nodes from two-phase commit operations in a distributed transaction processing system |
US5280612A (en) * | 1991-11-26 | 1994-01-18 | International Business Machines Corporation | Multiple version database concurrency control system |
US5241675A (en) * | 1992-04-09 | 1993-08-31 | Bell Communications Research, Inc. | Method for enforcing the serialization of global multidatabase transactions through committing only on consistent subtransaction serialization by the local database managers |
US5452445A (en) * | 1992-04-30 | 1995-09-19 | Oracle Corporation | Two-pass multi-version read consistency |
US5414840A (en) * | 1992-06-25 | 1995-05-09 | Digital Equipment Corporation | Method and system for decreasing recovery time for failed atomic transactions by keeping copies of altered control structures in main memory |
US5335343A (en) * | 1992-07-06 | 1994-08-02 | Digital Equipment Corporation | Distributed transaction processing using two-phase commit protocol with presumed-commit without log force |
US5432926A (en) * | 1992-12-04 | 1995-07-11 | International Business Machines Corporation | Method and apparatus for improving database reliability and response time in a distributed transaction processing system |
US5581749A (en) * | 1992-12-21 | 1996-12-03 | Thedow Chemical Company | System and method for maintaining codes among distributed databases using a global database |
JPH07225707A (ja) * | 1994-02-10 | 1995-08-22 | Fujitsu Ltd | アプリケーションのテスト方法及びそのテスト支援装置 |
-
1995
- 1995-11-02 US US08/552,058 patent/US5799305A/en not_active Expired - Fee Related
-
1996
- 1996-10-31 CA CA002189307A patent/CA2189307C/en not_active Expired - Fee Related
- 1996-11-01 AU AU70536/96A patent/AU711220B2/en not_active Ceased
- 1996-11-01 BR BR9605407A patent/BR9605407A/pt active Search and Examination
- 1996-11-01 JP JP29185696A patent/JP3790589B2/ja not_active Expired - Fee Related
- 1996-11-04 EP EP96203054A patent/EP0772136B1/en not_active Expired - Lifetime
- 1996-11-04 DE DE69623229T patent/DE69623229T2/de not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
BR9605407A (pt) | 1998-08-04 |
EP0772136B1 (en) | 2002-08-28 |
EP0772136A3 (en) | 1997-11-05 |
AU711220B2 (en) | 1999-10-07 |
JPH09251412A (ja) | 1997-09-22 |
US5799305A (en) | 1998-08-25 |
DE69623229T2 (de) | 2003-03-27 |
AU7053696A (en) | 1997-05-08 |
CA2189307C (en) | 2004-07-20 |
CA2189307A1 (en) | 1997-05-03 |
DE69623229D1 (de) | 2002-10-02 |
EP0772136A2 (en) | 1997-05-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3790589B2 (ja) | 分散データベーストランザクションのコミットメント方法 | |
US7962458B2 (en) | Method for replicating explicit locks in a data replication engine | |
US20220276994A1 (en) | Multi-database log with multi-item transaction support | |
US11397709B2 (en) | Automated configuration of log-coordinated storage groups | |
US10296606B2 (en) | Stateless datastore—independent transactions | |
EP0950955B1 (en) | Method and apparatus for correct and complete transactions in a fault tolerant distributed database system | |
US20090313311A1 (en) | Mixed mode synchronous and asynchronous replication system | |
US8868492B2 (en) | Method for maximizing throughput and minimizing transactions response times on the primary system in the presence of a zero data loss standby replica | |
Hammer et al. | Reliability mechanisms for SDD-1: A system for distributed databases | |
Strom et al. | Volatile logging in n-fault-tolerant distributed systems | |
US7188273B2 (en) | System and method for failover | |
EP1649397B1 (en) | One-phase commit in a shared-nothing database system | |
US6338146B1 (en) | Method and apparatus for fault-tolerant, scalable and non-blocking three-phase flushing for committing database transactions in a cluster of multiprocessors | |
US20070220059A1 (en) | Data processing node | |
US5734896A (en) | Recovery of a remotely initiated distributed prepared transaction by status report from a second database to an external coordinator | |
Polyzois et al. | Evaluation of remote backup algorithms for transaction-processing systems | |
US20230110826A1 (en) | Log execution method and apparatus, computer device and storage medium | |
EP0834122A1 (en) | Synchronisation procedure in a routing node | |
AU2015336250C1 (en) | Recovery and fault-tolerance under computational indeterminism | |
US6092084A (en) | One system of a multisystem environment taking over log entries owned by another system | |
US20030191918A1 (en) | Data processing arrangement and method | |
US6076095A (en) | Method of one system of a multisystem environment taking over log entries owned by another system | |
JP4604032B2 (ja) | 非共有データベースシステムにおける1段階コミット | |
JP2569063B2 (ja) | 複合サブシステム形オンラインシステムの障害回復方法 | |
as Bartha | Rollback recovery in distributed systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 19970131 |
|
A625 | Written request for application examination (by other person) |
Free format text: JAPANESE INTERMEDIATE CODE: A625 Effective date: 20031031 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031128 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040227 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20040227 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040227 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060314 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060403 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090407 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100407 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |