JPH08241236A - 書き込み衝突解決プロセス - Google Patents

Abstract

(57)【要約】 【課題】 データベースへの書き込み衝突を解決する。 【解決手段】一貫性の弱い複製されたデータベースシス
テムに対する書き込み動作は、アプリケーション固有の
内在するプロシジャーを有し、関連する書き込み動作が
そのようなデータベースの所与のインスタンスの現行状
態と衝突することが見いだされる場合は常に、衝突を解
決するために該プロシジャーが呼び出される。該プロシ
ジャーは、プロシジャーを与えるアプリケーションの要
求を満足するよう構成された方法でそのような衝突を解
決するよう調整される任意のプロシジャーである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複製された、一貫
性の弱いデータ記憶システムに関し、より詳細には、そ
のようなシステムにおいてアプリケーション固有の衝突
解決を実施する自動化された方法に関する。

【０００２】

【従来の技術及び発明が解決しようとする課題】複製さ
れた、一貫性の弱いデータベースシステムは、低速もし
くは間欠通信リンクによって複数のユーザ間でデータを
共有することを含むアプリケーションに適している。例
えば、これらアプリケーションは、理想的なネットワー
ク接続性に乏しいポータブルマシンを含む移動コンピュ
ータ環境においてランすることが可能である。ユーザー
のコンピュータは、ネットワークインフラストラクチャ
に依存するセルモデムもしくはパケット無線トランシー
バのような無線通信デバイスであることが可能であり、
該ネットワークインフラストラクチャは、大域的に有効
でないこと及び／又は非常に費用がかかる欠点を有す
る。そのようなコンピュータは、特定の商用パーソナル
デジタルアシスタント（ＰＤＡ）で有効な赤外線”ビー
ム”ポートのようなショートレンジの見通し内通信を使
用することが可能である。これとは別に、該コンピュー
タは従来のモデムを有することが可能であり、該モデム
は、データを送信及び受信する場合に電話回線に物理的
に接続されることが要求されるか、もしくは、ドッキン
グステーションに挿入される場合にシステムの残りの部
分と通信することのみが可能である。実際、コンピュー
タの唯一の通信デバイスがディスケットであることが可
能であり、人間によってマシン間で転送される。従っ
て、移動コンピュータは、該コンピュータがデータ共有
を望む多くのもしくは全ての他のデバイスからの派生的
で時に不本意な通信断を被る可能性がある。

【０００３】現実的に、移動ユーザーは、間欠的なネッ
トワーク接続性にも係わらず、彼らのアポイントメント
カレンダー、文献データベース、ミィーティングノー
ト、開発設計ドキュメント、ニュース掲示板、及び他の
タイプのデータを共有することを所望する可能性があ
る。従って、移動クライアントが共有データの読み出し
及び書き込みを活発に行うことを可能とするシステムに
対する要求が存在する。そのようなシステムは、ほとん
ど確実に所望の及び不本意な通信断を処理しなければな
らないにも係わらず、ユーザーから見た場合に、可能な
限り、中央集約化された高度に有効なデータベースサー
ビスのように動作しなければならない。

【０００４】

【課題を解決するための手段】従って、本発明により、
一貫性の弱い複製されたデータベースシステムに対する
書き込み動作は、アプリケーション固有の内在するプロ
シジャーを有し、関連する書き込み動作がそのようなデ
ータベースの所与のインスタンスの現行状態と衝突する
ことが見いだされる場合は常に、衝突を解決するために
該プロシジャーが呼び出される。該プロシジャーは、プ
ロシジャーを与えるアプリケーションの要求を満足する
よう構成された方法でそのような衝突を解決するよう調
整される任意のプロシジャーである。

【０００５】

【発明の実施の形態】

Ａ．一般的環境 ＰＤＡ（パーソナルデジタルアシスタント）のような特
定のコンピュータツールは、それらのユーザーがアクセ
スを所望するデータの全てもしくはいづれかのコピーを
保持する充分な記憶容量を有していない。このため、本
発明は、図１に示されるように、データを記憶するサー
バ１１−１３と、サーバによって管理されるデータを読
み出し及び書き込みするクライアント１５、１６との間
で機能を分割するよう構成されたシステムによって実施
される。サーバは、１もしくはそれより多くのデータベ
ースの完全なコピーを保持する任意のマシンである。用
語”データベース”は、本明細書においてデータ項目の
集合を示すために概略的に使用され、データが関係デー
タベースとして管理されるかされないかに係わらず、デ
ータベースは単純に従来のファイルシステムに記憶さ
れ、もしくは任意の他のデータモデルに一致する。クラ
イアントは通信可能な任意のサーバに内在するデータに
アクセス可能であり、逆に言えば、パーソナルラップト
ップを含む、データベースのコピーを有する任意のマシ
ンは、クライアントからの読み出し及び書き込みリクエ
ストに対してサービスを提供することを所望しているこ
とが期待される。

【０００６】ポータブルコンピュータは、特定のデータ
ベースに対してサーバであることが可能であり、他のコ
ンピュータに対してクライアントであることが可能であ
る。例えば、クライアントは、一緒に業務出張している
同僚グループのような、活動的に協動する一方でシステ
ムの残りの部分から通信断状態にあるユーザーの要求を
満足するサーバとなることが可能である。通信断状態に
あるワーキンググループのメンバーに対して彼のパーソ
ナルマシンへコピーする予定のデータへのアクセスを単
に与えるよりもむしろ、図１のサーバ／クライアントモ
デルは、任意のグループメンバーに対してグループ内で
有効な任意のデータへのアクセスを可能とする充分な柔
軟性を提供する。

【０００７】理解されるように、ポータブルマシン上に
サーバを存在させることを可能とする概念は、Ｌｏｔｕ
ｓＮｏｔｅｓやＦｉｃｕｓのような現存のシステム内で
移動性をサポートするためにとられるアプローチに類似
する。

【０００８】データベースの複製は、非接続ユーザーに
対して共通データベースへのアクセスを可能とするため
に必要とされる。不幸にして、全ての有効なコピーを自
動的にアップデートすることによって強いデータの一貫
性を維持することに基づくような、複製データを管理す
る多くのアルゴリズムは、例示される実施例に対して意
図されるような分割されたネットワーク内では充分に機
能せず、特に、サイトの不具合は信頼性を有して検出さ
れない。特定タイプのネットワーク分割を受容可能なＱ
ｕｏｒｕｍベースの方法は、通信断状態にある個々もし
くは小グループに対して充分に機能しない。更に、悲観
的なロッキングに基づくアルゴリズムは、移動環境にお
ける一般的ケースのように、メッセージコストが高い場
合に有効性を極度に限定し性能が乏しい。

【０００９】従って、コンピュータ環境の残りの部分か
ら完全に通信断状態にある場合でもクライアントの読み
出し及び書き込み能力を最大とするために、任意読み出
し／任意書き込み複製方式が好ましい。これは、２１−
２３のようにユーザーがデータベースの任意のコピーを
読み出し、また２５のようにデータベースの任意のコピ
ーへ書き込むことを可能とする。２６及び２７のように
データベースの他の全ての複製へ書き込みが伝搬する時
間的スケジュールは、これら複製物の内のいくつかとの
通信が現在不可能である可能性があるため、保証されな
い。従って、複製されるデータベースは弱い一貫性を有
するのみとなる。複製データに対してそれらの有効性だ
けでなくスケーリング性及び簡潔性を高めるサポートと
なる、一貫性の弱い複製データを管理する方法が従来シ
ステムの多くで利用されてきた。

【００１０】図２にいくぶん詳細に示されるように、１
１及び１２のようなサーバは、”アンチ−エントロピ
ー”プロトコルを使用して一般的データベース３０のコ
ピー間で２６のように書き込みを伝搬する。アンチ−エ
ントロピーは、データベース３０の全てのコピーが同じ
状態へ収束し、新たなアップデートがない場合に最終的
に同一の状態へ収束することを保証する。これを達成す
るために、サーバ１１及び１２だけでなく他の全てのサ
ーバは、全ての書き込みを受信しなければならないだけ
でなく、それらを一貫して順序付けなければならない。

【００１１】対等なアンチ−エントロピーが使用され
て、通信可能な任意の２つのサーバが両者間でアップデ
ートを伝搬可能となることが保証される。このアプロー
チ下において、直接通信不可能なマシンでさえも仲介を
通じてアップデートを交換可能となる。各サーバは、２
６のようなペア間の書き込み交換の相手となる他の一方
のサーバを周期的に選択し、該他の一方のサーバは、そ
の有効性だけでなく予想コスト及び利益に依存して選択
される。当該プロセスの終了時において、サーバ１１及
び１２の両者はデータベース３０の同一のコピーを有す
る。即ち、当該プロセスの終了時において、サーバ１１
及び１２のは、同じ順序で実効的に行われた同じ書き込
みを有する。アンチ−エントロピーは減分的プロセスと
して構成されることが可能であり、非常に間欠的もしく
は非対称な通信状態にあるサーバであってもそれらのデ
ータベースを最終的に相互に一貫した状態とすることが
可能となる。 Ｂ．セッション保証 任意読み出し／任意書き込み複製を使用することの潜在
的欠点は、単一のユーザーもしくはアプリケーションの
みがデータ修正を行っている場合でさえも所与のデータ
ベース３０の異なるインスタンス内で一貫性が欠落する
可能性があることである。例えば、移動クライアント
は、サーバ１２のような１サーバにおいて書き込みを行
った後それと異なるサーバ１１において読み出しを行う
可能性がある。これら２つの動作実行の間の特定な時間
においてこれら２つのサーバが相互にもしくは共通の中
間連鎖を通じてアンチ−エントロピーを実行しない限
り、クライアントは一貫性の欠落した結果を得ることが
想定される。

【００１２】このような問題を緩和するためにセッショ
ン保証が提供される。”セッション”は、アプリケーシ
ョンの実行中に当該セッションの１もしくはそれより多
くの参加者によってデータベース３０のようなデータベ
ースで行われる読み出し及び書き込み動作のシーケンス
に対する抽象概念である。以下の４つの保証の内の１も
しくはそれより多くが、セッション毎ベースでセッショ
ンマネージャー３２もしくは３３に要求される。 ・書き込みの読み出し − セッションの主要期間中に
おいて、参加者による読み出し動作は、当該参加者によ
る過去の全ての書き込みを反映する。

【００１３】・単調な読み出し − 参加者による連続
的読み出しは、セッション全体を通して非減少書き込み
セットを反映する。

【００１４】・読み出しに続く書き込み − セッショ
ン期間中において、参加者による書き込みは、それらが
依存する読み出しの後に伝搬される。

【００１５】・単調な書き込み − セッション期間中
において、参加者による書き込みは、論理的にそれらに
先行する書き込みの後に伝搬される。 潜在的に一貫性の欠落した多くのサーバに対してアプリ
ケーションが読み出し及び書き込みを行う場合でさえ、
これら保証が呼び出されて個々のアプリケーションに対
して当該アプリケーションの作用と一貫性のあるデータ
ベース３０の見通しが与えられることが可能である。異
なるアプリケーションは、一貫性についての異なる要
求、及び一貫性の欠落したデータに対する異なる許容度
を有する。このため、アプリケーションに対して必要十
分なセッション保証を当該アプリケーションが選択する
ことを可能とするよう規定が設けられる。セッション保
証を要求することについての主なコストは、有効性の潜
在的な減少である。なぜなら、保証をミートする充分最
新なサーバのセットは、全ての有効なサーバよりも数が
少ないことが予想されるからである。これらセッション
保証に関する更に多くの情報は、Ｄｏｕｇｌａｓ Ｂ．
Ｔｅｒｒｙ他による文献”Ｓｅｓｓｉｏｎ Ｇｕａｒａ
ｎｔｅｅｓ ｆｏｒ Ｗｅａｋｌｙ Ｃｏｎｓｉｓｔｅ
ｎｎｔ Ｒｅｐｌｉｃａｔｅｄ Ｄａｔａ”（Ｐｒｏｃ
ｅｅｄｉｎｇｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎ
ｆｅｒｅｎｃｅ ｏｎ Ｐａｒａｌｌｅｌ ａｎｄ Ｄ
ｉｓｔｒｉｂｕｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙ
ｓｔｅｍｓ（ＰＤＩＳ），Ａｕｓｔｉｎ，ＴＸ，Ｓｅｐ
ｔｅｍｂｅｒ １９９４，ｐｐ．１４０−１４９）によ
り得られる。 Ｃ．アップデート衝突のアプリケーション固有の検出 特定のクライアントは異なるサーバに対して同時書き込
みを行う可能性があり、また古いコピーの読み出しに基
づいて特定のデータをアップデートする可能性があるた
め、任意読み出し／任意書き込み複製方式においてアッ
プデート衝突は回避不可能である。これらの衝突は２つ
の基本的形態を有する。即ち、複数のクライアントが同
じデータ項目（もしくはデータ項目セット）を互換性の
ない方法でアップデートする場合に生じる書き込み−書
き込み衝突、及び、第２のクライアントによって同時に
アップデートされる他のデータ項目値の読み出しに基づ
く特定のデータを第１のクライアントがアップデートす
る場合（もしくは、潜在的に、現在読みだされているサ
ーバと異なるサーバ上で過去にアップデートされたデー
タ項目に読み出しが向けられる場合）に生じる読み出し
−書き込み衝突である。

【００１６】バージョンベクトルもしくは単純なタイム
スタンプが一般的に使用されて書き込み−書き込み衝突
が検出される。一方、読み出し−書き込み衝突は、アプ
リケーションの読み出しセットを記録してチェックする
ことで検出可能である。しかし、これらの方法全てはア
プリケーションのセマンテクスを無視するものである。
例えば、時間のブロックを選択することによりユーザー
が対話的にミーティングをスケジューリングするカレン
ダーマネージャーを考える。カレンダーデータを有する
ファイルを２ユーザーが同時にエディットするという単
純な理由から、アプリケーションから見て衝突は発生し
ない。むしろ、同一の参加者を対象として２ユーザーが
同時にミーティングをスケジューリングする場合に衝突
が起こる。

【００１７】従って、アプリケーション固有の方法でア
ップデート衝突を検出することがより有用となる。アプ
リケーションに関連する方法においてデータベースの状
態が書き込み動作によって期待される状態と異なる場合
に書き込み衝突が起こる。従って、書き込み動作は、書
き込まれるデータかもしくはアップデートされるデータ
（即ちアップデートセット）だけでなく従属状態セット
も含む。従属状態セットは、アプリケーションによって
与えられた照会及びそれらの期待結果の集合である。デ
ータベースの現行コピーに対してサーバ上で照会がラン
しており、照会が期待結果をリターンしない場合に衝突
が検出される。

【００１８】これら動作、検出される任意の衝突の解
決、及び、書き込み動作を実行しているサーバ上のデー
タベースコピーに対する任意の適正なアップデートのア
プリケーションは、その特定なデータベース上でサーバ
が実行する他の全ての読み出し及び書き込みの視点から
自動的に達成される。この実施例の目的のため、データ
ベースは関係データベースであることが仮定される。

【００１９】より標準的もしくはほとんど標準的でない
実行に対処することにおいて、アップデートセットはア
ップデートレコードのシーケンスから構成される。アッ
プデートレコードは、（ａ）アップデート動作（即ち、
挿入、削除、もしくは修正）を特定し、（ｂ）特定され
たアップデート動作が適用されるデータベース関係を指
定し、（ｃ）指定された動作に従って指定されたデータ
ベース関係に適用されるべき要素セットを包含する。挿
入動作の実行は関連する要素セットを指定された関係に
追加する。一方、削除及び修正動作は、指定されたデー
タベース関係に現在ある要素を検査し、特定された要素
セット内の任意の要素の基本キーで整合する任意の要素
を削除もしくは置換する。

【００２０】従属状態セットはゼロもしくはそれより多
くの従属状態レコードのシーケンスであり、従属状態セ
ットの各々はデータベースに対してランする照会を要素
セットと共に有し、該要素セットは、衝突がない場合の
データベースに対して当該照会をランすることの期待結
果を特定する。先に述べたように、データベースの現行
コピーに対してサーバ上で任意の照会がランしており、
該照会が期待結果をリターンしない場合に衝突が検出さ
れる。

【００２１】図３に示されるように、衝突検出プロセス
４３によって衝突が検出されなかったことが４２におい
て確認された後にのみ４１のように書き込み動作がデー
タベースに適用される。衝突の存在が発見される場合、
その存在が報告されるか、もしくは４４のように該衝突
を解決するステップが取られる。

【００２２】図４を参照すると、アプリケーション固有
の衝突検出プロセス４３は、書き込みを実行しているサ
ーバのデータベースの現行バージョンに対する特定の書
き込み動作についての全ての従属状態照会を逐次にラン
する。従って、４５においてインデックスＫは、所与の
書き込み動作に対する従属状態セットによって特定され
る従属状態照会数に等しい値に初期化される。Ｋが０値
に初期化される場合、従属状態チェックがないことが４
６で決定され、従って、衝突が発見されないことが４７
で提示される。しかし、所与の書き込み動作に１もしく
はそれより多くの従属状態チェックが内在することが４
６で決定される場合、これらチェックの内の第１のチェ
ックについての照会がデータベースに対して４８でラン
され、該ランのリターン結果が当該ランの期待結果と４
９で比較される。実際の及び期待される結果が整合する
場合、インデックスＫは５１で再度評価され、追加の従
属状態チェックが行われるかどうかが決定される。追加
のチェックが行われる場合、インデックスＫは５２で減
分され、次の従属状態チェックが４８及び４９で行われ
る。

【００２３】任意の従属状態照会に応答してデータベー
スによってリターンされた実際の結果が期待結果に整合
しないことが４９で見いだされる場合、衝突検出プロセ
ス４３は５３で”衝突”状態を結論する。一方、所与の
書き込み動作に対する従属状態チェックの全てが満足さ
れる場合、衝突検出プロセスは５４で”非衝突”状態を
結論する。

【００２４】明らかに、要求されたアップデートが依存
する読み出された任意のデータのバージョンスタンプを
従属状態照会がチェックすることによって、従属状態セ
ットは従来の楽観的な同時性制御を提供可能である。し
かし、従属状態チェックメカニズムはより一般的であ
る。例えば、従属状態チェックは”ブラインド”書き込
みを可能とし、その場合クライアントはデータベースの
任意のコピーへのアクセスを有さないで特定の条件が維
持されている仮定のもとにデータベースアップデート要
求を行う。例えば、クライアントはラップトップコンピ
ュータを使用して特定ルームでのミーティングのスケジ
ューリングを所望する場合があり、この場合、ルームカ
レンダーのコピーへのアクセスをクライアントが現在有
していなくとも当該ルームは所望の時間に空いているこ
とが仮定される。このケースにおいて、ミーティングル
ームカレンダーをアップデートしてルーム予約を試みる
書き込み動作は従属状態照会を含むことが想定され、該
従属状態照会は、サーバによる書き込み動作の実行に先
立ちランされ、当該ミーティングに対して特定されたタ
イムスロットにおいて当該ルームが空いているかどうか
を決定することが想定される。 Ｄ．アップデート衝突のアプリケーション固有の解決 有利にも、当該システムはアップデート衝突を検出する
だけでなく任意の検出された衝突を解決する。楽観的同
時性制御を有するデータベースシステムにおいて頻繁に
取られる衝突解決の１つのアプローチは、衝突するトラ
ンザクションの各々を単に中止することである。他のシ
ステムは、それらが検出した衝突の解決を人間に依存す
る。しかし、人間に依る解決は移動コンピュータ環境に
おいて不利である。なぜなら、アンチ−エントロピーを
介して書き込みがバックグラウンドを伝搬している間
に、ユーザーがアップデートを特定のサーバへ送出して
通信を断つ可能性があるからである。従って、書き込み
衝突が検出される時（即ち、従属状態チェックが失敗し
た場合）ユーザーはアクセス不可能である場合がある。

【００２５】例示された実施例において、同時に要求さ
れた書き込み動作の順序が問題とならないかもしくはデ
ータベースのコピーを維持する各サーバにおいてアプリ
ケーション固有の方法で適切に処理可能であるような非
常に多くのアプリケーションが存在するという仮定に基
づき衝突を自動的に解決する方法を書き込みが特定可能
とするよう規定が設けられる。この衝突解決プロセスを
達成するために、図５に示されるように、各書き込み動
作は”マージプロシジャー”と呼ばれるアプリケーショ
ン固有のプロシジャーを含み、該プロシジャーは、図５
に示されるように、書き込み衝突が５３で検出される場
合に（図４参照）呼び出される。このプロシジャーは、
実行サーバに存在するデータベースコピーを読み出し、
５７のように現行データベース内容に対して適正である
代替アップデートセットを５６のように生成することに
よって衝突を解決する。

【００２６】マージプロシジャーの実行によって生成さ
れたリバイズされたアップデートセットは、データベー
スに適用される新たな要素セットから構成されることが
可能であり、該要素セットは、ヌル要素セットか（即ち
なにも適用されない）、データベースの特別なエラーロ
グ関係に適用される１もしくはそれより多くの要素セッ
トか、もしくは前記要素セットの組み合わせである。

【００２７】クライアントで発生し、サーバへ送られ、
５８のように保護された環境で実行されるという点でマ
ージプロシジャーは移動エージェントに類似する。しか
し、より一般的エージェントとは異なり、該エージェン
トはサーバのデータベースを読み出し及び書き込み可能
であるのみである。マージプロシジャーの実行は、デー
タベース内容の、及びマージプロシジャーの静的データ
の決定論的関数でなければならない。

【００２８】通常、これらマージプロシジャーの実行に
対して”保護された環境”を提供するために、マージプ
ロシジャーの各々は関数であり、該関数は、Ｔｃｌのよ
うな適切な言語で書かれ、マージプロシジャーを実行す
るサーバのアドレス空間にある新たに作成されたインタ
プリタでランされる。インタプリタは、マージプロシジ
ャーをランした後に終了する。

【００２９】マージプロシジャー関数は入力パラメータ
を取らないが、出力として新たなアップデートセットを
生成する。より詳細には、マージプロシジャーは、デー
タベースの現行状態に対するリードオンリーデータベー
ス照会の結果を呼び出し及び受信することが可能であ
る。しかし、このこと以外は、マージプロシジャーは、
それらの周囲の存在に関する情報を取得不可能であり、
（それらが生成するアップデートセットをリターンする
ことによって以外は）それらの周囲の存在に影響を及ぼ
すことが不可能である。特に、マージプロシジャーは、
現在時間、もしくはサーバの多くの他のリソースの状
態、もしくはサーバがランするホストのような非決定論
的変数について照会不可能である。なぜなら、そのよう
な照会は非決定論的結果を生成する可能性があるからで
ある。適切には、禁止動作を棄却するために使用される
Ｔｃｌインタプリタを修正することによってこれら制限
が実行される。そのような”安全な”インタプリタは当
業者には周知である。

【００３０】ディレクトリをファイルする同時アップデ
ートの自動的解決が過去に提案され、ＦｉｃｕｓやＣｏ
ｄａのようなシステムで現在利用されている。これらの
システムは、マージプロシジャーに類似の、アプリケー
ション固有の解決プロシジャーのサポートの追加を近年
行っており、該プロシジャーはサーバに登録され、衝突
発生時に自動的に呼び出される。しかし、これら既存の
システムにおいて、呼び出される適正な解決プロシジャ
ーは、アップデートされるファイルのタイプのようなフ
ァイル特性に基づき選択される。マージプロシジャー
は、アプリケーションのセマンティクスに基づき、また
特定の書き込みについての意図した効果に基づき各書き
込み動作に対してカスタマイズされることが可能である
ため、より柔軟である。例えば、前述のカレンダーアプ
リケーションにおいて、第１の選択がすでになされてい
る場合、マージプロシジャーは代替ミーティング時間リ
ストを含むことが可能である。

【００３１】要約すると、瞬間的システムにおいて、書
き込み動作は、要求されたアップデート、従属状態セッ
ト、及びマージプロシジャーから構成される。従属状態
セット及びマージプロシジャーの両者は、アプリケーシ
ョンのセマンティクスによって指示され、アプリケーシ
ョンによって要求される各書き込み動作に対して変化す
ることが可能である。従属状態チェックの検証、マージ
プロシジャーの実行、及びアップデートセットの適用
は、サーバ上の他のデータベースアクセスに関して自動
的に実行される。 Ｅ．書き込みの安定化 本システムが意図する複製データベースの弱い一貫性と
は、書き込み動作は１つのサーバにおいて所望のアップ
デートを生成可能であるが、該動作は他の１つのサーバ
において衝突として検出され得ることを意味し、従っ
て、そのマージプロシジャーの実行結果として全く異な
るアップデートが生成される。また、マージプロシジャ
ーの実行は現行データベース状態に依存する可能性があ
るため、書き込みのマージプロシジャーは異なるサーバ
において異なる結果を生成する可能性がある。特に、過
去の書き込みから成る異なるセットをサーバが見る場
合、もしくは、サーバが書き込みを異なる順序で処理す
る場合、変化する結果か生成され得る。最終的一貫性を
達成するために、サーバは全ての書き込みを受信しなけ
ればならないだけでなく、これら書き込みを適用する順
序に整合しなければならない。本文中において示される
ように、アンチ−エントロピーを介して得られる特定の
書き込みは、先行して得られた他の書き込みの前に順序
付けられる必要が生じる可能性があり、従って、先行す
る書き込みが取り消され、サーバのデータベースコピー
へ再適用される可能性がある。書き込みの再適用によっ
て、該書き込みの過去の実行によって生成されたアップ
デートとは異なる方法で該書き込みがデータベースをア
ップデートする可能性がある。

【００３２】データベースに対する書き込みの効果が不
変である場合、即ち、未来において決して取消及び再実
行されることがない場合、書き込みは”安定化”された
と認識される。所与の書き込みの安定性を検出する１つ
の方法は、各サーバに関する充分な情報を収集し、所与
の書き込みに先行して順序付けられた他の書き込みが存
在しないこと、及びそのような書き込みが未来において
許容されないことを決定することである。不幸にして、
このような形態で書き込みが安定化するレートは、アン
チ−エントロピーが全てのサーバ間で情報を伝搬するレ
ートに依存する。例えば、超過期間に対して通信断とさ
れるサーバは、極度に安定化を遅延させ、多数の書き込
みを後にロールバックさせることが予想される。

【００３３】書き込みログ６０の概略によって図６に示
されるように、例示される実施例は書き込みを明示的
に”コミット”する概念を含む。書き込みがコミットさ
れると、全ての他のコミットされた書き込みに関する当
該書き込みの順序は固定され、コミットされていない書
き込みは当該書き込みの前に順序付けられず、従って、
当該書き込みは安定となる。まだコミットされていない
書き込みは”テンタティブ”と呼ばれる。

【００３４】クライアントは、所与の書き込みがコミッ
トされているかテンタティブであるかについて照会可能
である。例示されるシステムは、所望の場合にクライア
ントがテンタティブデータを読み出すことを可能とす
る。しかし、テンタティブデータ及び固有の不安定性を
処理するよう作成されていないアプリケーションは、そ
れらの要求を単にコミットデータをリターンすることに
限定する可能性がある。この選択は、他のシステムによ
って過去に実施されてきた硬直したルーズな読み出し動
作に類似する。本質的に、各サーバはデータベースの２
つの視野を維持する。１つは、コミットデータを反映す
るだけのコピーであり、もう１つは、現在サーバに対し
て既知であるテンタティブな書き込みも反映する”フ
ル”コピーである。フルコピーは、テンタティブな書き
込みが基本サーバに到達する場合にデータベースが含む
こととなる推定物である。

【００３５】書き込みをコミットする１つの方法は、サ
ーバの大部分において特定の種類のコンセンサスプロト
コルをランすることである。しかし、移動コンピュータ
間で発生するネットワーク分割のタイプに対しては充分
に機能しない。

【００３６】この代わりに、瞬間的システムにおいて、
各データベースは１つの識別されたサーバ、即ち”基
本”サーバを有し、該サーバはデータベースへの書き込
みをコミットする責任を負う。この他の”２次的”サー
バは書き込みをテンタティブに受信し、アンチ−エント
ロピーを介してそれらを基本サーバへ伝搬する。２次的
サーバが基本サーバと通信し、それらのテンタティブな
書き込みを基本サーバへ伝搬した後、基本サーバはこれ
ら書き込みをコミットされた書き込みへ変換する。コミ
ットされた書き込みの情報及びそれらの順序は、再びア
ンチ−エントロピーを介して基本サーバから２次的サー
バへ伝搬して戻される。基本サーバの存在は、他の２次
的サーバが通信断状態のままであっても書き込みをコミ
ット可能とする。多くの場合、基本サーバはアップデー
ト活動領域付近に配置されることが可能であり、従っ
て、より短時間で書き込みをコミット可能となる。

【００３７】より詳細には、前述のタイプの明示的コミ
ットプロセスの使用を介して書き込みを安定化するため
に、クライアントアプリケーションからサーバが受信す
る書き込み動作は、この他のサーバから受信されたもの
とは異なる形態で処理される。図７に示されるように、
クライアントから受信された書き込みは、６１のように
最初に唯一のＩＤをアサインされる。新たな書き込みが
常にサーバの書き込みログ端で順序づけられるような方
法で各サーバによって唯一のＩＤが選択される。次に、
書き込みが意図されるデータベースに対するサーバ内の
書き込みログ（図６）のテール即ち”若い”端部に対し
て６２のように書き込みが追加される。更に、６３のよ
うに書き込みが実行されてデータベースの現行状態がア
ップデートされる。

【００３８】一方、図８に示されるように、新たな書き
込み（即ち、６４で決定される、書き込みログ６０にな
い書き込み）がアンチ−エントロピーを介して他のサー
バから受信される場合、該書き込みは書き込みログ６０
の若い端部に必ずしも追加されない。その代わりに、ソ
ートキーが用いられて６５のように該書き込みが書き込
みログにソートされた順序で挿入される。コミットされ
た書き込みを順序付けるためのソートキーとしてコミッ
トシーケンスナンバー（ＣＳＮ）が使用され、一方、テ
ンタティブな書き込みを順序付けるためのソートキーと
して書き込みＩＤが使用される。これらソートキー及び
それらが書き込みにアサインされる方法は以下により詳
細に説明される。しかし、現時点において、テンタティ
ブな書き込み及びコミットされた書き込みの両者が、書
き込みもしくはそれらの任意のサブセットを有する全て
のサーバにおいてこの２つの異なるクラス化形態で一貫
して順序付けられることは理解されるべきである。しか
し、サーバのテンタティブな書き込みの内の１つがコミ
ットされたことを該サーバが認識する時に発生する書き
込みのクラス化は、該書き込みが他の１つもしくはそれ
より多くのテンタティブな書き込みに対して再順序づけ
されることを必要とする。なぜならば、コミットされた
書き込みに対しては異なる異なるソートキーが使用され
るからである。本文中において明らかとなるように、再
順序付けの頻度及び大きさを低減するために好ましくは
特定の処理ステップが取られる。このような処理ステッ
プは再順序付けを実行するコンピュータコストのために
必要であるが、特定の再順序付けは依然として予想され
る。

【００３９】他のサーバから受信された書き込みを６５
でサーバが書き込みログへ挿入する場合、書き込みが書
き込みログ６０の若い端部に挿入されるのかもしくはそ
の他の特定な位置に挿入されるのかをサーバは常に決定
する。書き込みがログの若い端部に単に追加されること
が見いだされる場合、書き込みは６３で実行されてデー
タベースの現行状態がアップデートされる（図３参
照）。書き込みが書き込みログ６０の他の任意の位置に
ソートされる場合、６８のようにロールバックプロシジ
ャーが呼び出され、新たな書き込みが書き込みログ６０
に挿入される位置に対応する状態までデータベースがロ
ールバックされ、次に、新たな書き込みに対する挿入位
置と書き込みログ６０の若い端部との間の書き込みログ
内に位置する全ての書き込みがソートされた順序でシー
ケンシャルに再実行される。

【００４０】先に説明したように、書き込みはそれがコ
ミットされた後にのみ安定である。更に、書き込みがコ
ミットされると、それは再実行される必要はない。従っ
て、サーバはどの書き込みがコミットされたかを識別す
る規定を有することのみを必要とし、コミットされるこ
とがわかっている書き込み動作を全て記憶する必要はな
い。従って、特定の記憶容量セービングが実現可能とな
る。

【００４１】書き込みをコミットし、任意の所与のデー
タベースに対して全てのコミットされた書き込みの一貫
した順序付けが存在することを保証するために、各デー
タベースは同時に１つのサーバ（”基本サーバ”）のみ
に依存する。この基本サーバは、最初に書き込みを受信
する場合（即ち、書き込みがクライアントアプリケーシ
ョンから受信されるかもしくは他のサーバから受信され
る場合）にこれら書き込みの各々をコミットし、コミッ
トされた書き込み状態は次にアンチ−エントロピーによ
って全ての他のサーバへ伝搬される。図９は、クライア
ントから書き込みを受信する場合の基本サーバの動作を
示す。基本サーバがクライアントから受信する各書き込
みは、６１のように唯一の書き込みＩＤをアサインさ
れ、６９のように標準カウント順序で次の有効なＣＳＮ
をアサインされる。次に、７０のように書き込みログ
（コミットされた書き込みのみを有するログ）のテール
に書き込みが追加され、６３のように書き込みが実行さ
れる。

【００４２】図１０に示されるように、２次的サーバが
アンチ−エントロピーを介して他のサーバから受信する
書き込みが９０で検査され、それらが当該サーバに対す
る書き込みログ６０内の適正位置にあるかどうかが決定
される。適正位置にある場合、９１のように書き込みは
無視される。しかし、これ以外の場合、書き込みは図８
に従って９２で更に処理されて新たな書き込みであるか
どうかが決定され、新たな書き込みである場合、サーバ
の書き込みログの適正なテンタティブ位置に挿入され、
フルデータベースに適用される。更に、書き込みはまた
９３で検査され、基本サーバによってコミットされたか
どうかが決定される。書き込みが有効なＣＳＮを有する
ことが９３で見いだされる場合、２次的サーバで該書き
込みをコミットし、且つ、書き込みをコミットすること
が再順序づけを必要とする場合に該書き込み及び全ての
テンタティブな書き込みを再実行するプロセスが９４で
呼び出される。

【００４３】図１１を参照すると、他のサーバから受信
された書き込みをコミットする一方で、７１のように２
次的サーバは該サーバが有する任意の過去の書き込みレ
コードを該サーバのテンタティブな書き込みから除去
し、７２のようにその書き込みログのコミットされた書
き込み部分の若い端部に当該書き込みを追加する。書き
込みログ６０内の書き込みの順序付けがこの再クラス化
によって影響されないことが７３で決定される場合、こ
れ以上の動作は必要とされない。しかし、再クラス化が
書き込みの順序付けを変化させる場合、７３のようにデ
ータベースは書き込みログ６０内の新たな書き込み位置
に対応する状態までロールバックされ、該位置と書き込
みログ６０のテンタティブ部分の若い端部との間の全て
の書き込みは６３で再実行される。

【００４４】データベースの”ロールバック”及び”ロ
ールフォワード”プロシジャーは、データベースシステ
ムアーキテクチャに対する周知のツールである。しか
し、完全性のために、適切なロールバックプロシジャー
が図１１に示される。図に示されるように、該プロシジ
ャーは、（１）７５のように書き込みレコードの書き込
みログ内のロールバックされる位置ロケーションに対し
てポジションインデックスｐを設定すること、及び、
（２）７６のように書き込みログ内の書き込みレコード
の総数に対してポインタｋ及びスレショルドカウントｎ
を設定することによって初期化される。繰り返し取消プ
ロセスが次に７７においてデータベース上でランされ、
データベースに対する最新の書き込みの影響が逐次的に
取り消され、これと同時に、これら書き込みの各々の影
響が取り消された後にポインタインデックスｋが７８で
減分され、取り消される必要のある書き込みがまだある
かどうかを７９で決定するチェックが行われる。（デー
タベースに適用されていない書き込みの取消は行われ
ず、書き込みは該書き込みがデータベースに適用された
順序とは異なる順序で取り消されることが可能であ
る。）このプロセス７７−７９は、ポインタインデック
スｋがポジションインデックスｐと同一の書き込みログ
内の位置を示すことが７９で決定されるまで継続する。
このことが発生すると、ポインタｋがその時に示してい
る書き込みが６３で実行される（図３）。書き込みログ
６０の若い端部の書き込みレコード以外の任意の書き込
みレコードをポインタｋが示していることが８１で決定
される場合、ポインタｋは８２で減分され、ログの若い
端部へ向かう順序で次の書き込みが６３で実行される。
ポインタｋが書き込みログ６０（図６）の若い端部を示
していることが８１で決定されるまで、この書き込み再
実行プロシジャー６３，８１−８２は次の書き込み命令
に従い実行される。

【００４５】図１３は、書き込みの再順序付けを発生す
るタイプのシナリオを示しており、図１４は、図１３の
シナリオを追跡し、書き込みを有する現行ログ及び書き
込みをサーバが受信する状態を示す。例示を簡単にする
ために、該シナリオは、サーバＳ１−Ｓn の各々が初期
状態として単一のコミットされた書き込みＷ０を保持す
ることを仮定する。サーバＳn は基本サーバであること
が意図され、従って該サーバは書き込みＷ１及びＷ２の
コミットに対して唯一責任を負う。

【００４６】先の説明から理解されるように、コミット
された書き込みはそれらのコミットシーケンスナンバー
（ＣＳＮ）に従って順序付けられる。一方、テンタティ
ブな書き込みは、それらが最初に受信された時間を示す
タイムスタンプによって最初に順序付けられ、それらが
最初に受信されたサーバのＩＤによって２次的に順序付
けられる。タイムスタンプとサーバＩＤの両者はＩＤに
含められる。サーバＩＤは、同一のタイムスタンプ値を
有するテンタティブな書き込みの順序づけを明確にする
ための２次的ソートキーとして使用される。 Ｆ．クライアント及び通信断グループによるテンタティ
ブデータの読み出し 書き込みを要求するクライアントは、一般的に、データ
ベースに対する後続の読み出し要求をこれらアップデー
トに反映させることを所望する。更に、これらクライア
ントの内の特定のクライアントは、彼らの過去の書き込
みを読み出すことに依存する書き込みさえも要求する可
能性がある。クライアントが基本サーバと通信断状態に
あってアップデートが直ちにコミット不可能な場合でさ
えも、この可能性は確実に存在する。いづれにしても、
可能な限り、クライアントは彼らのアップデートがテン
タティブであるこを認識しないべきであり、アップデー
トが後にコミットする場合に変化を観測しないべきであ
る。即ち、テンタティブな結果は可能な限り常にコミッ
トされた結果に等しくなるべきである。

【００４７】２つの２次的サーバがアンチ−エントロピ
ーを介してテンタティブな書き込みを交換する場合、彼
らはこの書き込みに対する”テンタティブな”順序付け
に同意する。先の説明から理解されるように、順序は第
１にタイムスタンプに基づき、該タイムスタンプは当該
書き込みを最初に受信したサーバによって各当該書き込
みにアサインされる。従って、異なるタイムスタンプを
有する同一の書き込みセットを有する任意の２サーバは
それら書き込みを同一に順序付ける。従って、基本サー
バから通信断状態にあるサーバグループは、書き込みを
どのように順序付け内部衝突をどのように解決するかに
関して同意に達する。この書き込み順序付けは、書き込
みをコミットするために基本サーバが使用する順序とは
異なるという点でテンタティブである。しかし、通信断
グループ以外のクライアントが衝突アップデートを実行
しないケースにおいては、書き込みは、テンタティブな
順序で基本サーバによってコミットされることが可能で
あり、また最終的にそのようにコミットされ、該書き込
みがテンタティブなデータベースに対して有した影響と
同一の影響をコミットされたデータベースに与えること
が可能である。 結論 本発明により提供されるアーキテクチャは、個別にもし
くはグループとして他のユーザから通信断状態となる可
能性のあるユーザーによって読み出し及びアップデート
が可能な共有データベースをサポートする。このアーキ
テクチャの特定の態様は、同様のもしくは異なる要求を
有する他のシステムにおいて使用可能である。例えば、
本文中に記載されたアプリケーション固有の衝突検出
は、検出された衝突の解決を人間による解決に依存する
システムにおいて使用可能である。同様に、アプリケー
ション固有の衝突解決方法論は、衝突検出にバージョン
ベクトルを利用するシステムにおいて使用可能である。

【００４８】書き込み動作を処理するステップは、以下
のように要約される。 ０．ユーザーもしくは他のサーバから書き込み動作を受
信する。 １．ユーザーから受信する場合、＜サーバＩＤ，タイム
スタンプ＞の形態の唯一の識別子（ＩＤ）を書き込みに
アサインし、コミットシーケンスナンバー（ＣＳＮ）に
ＩＮＦＩＮＩＴＹ（無限大）をアサインする。無限大の
ＣＳＮ値は当該書き込みがテンタティブであることを示
す。 ２．基本サーバから受信する場合、（最後にアサインさ
れたＣＳＮ＋１）をＣＳＮにアサインする。 ３．ログ内の全ての書き込みが、最初にＣＳＮによっ
て、次にタイムスタンプによって、最後にサーバＩＤに
よって順序付けられるよう、当該書き込みをサーバの書
き込みログに挿入する。 ４．当該書き込みが過去にログ内に存在していた場合、
該書き込みはログのコミット部分にエンターされ、前の
インスタンスを削除して新たな書き込みログを生成す
る。 ５．当該書き込みが書き込みログの終端でない場合、新
たな書き込みの直前までサーバのデータベースをロール
バックする。 ６．新たな書き込みからログのテールまでの各書き込み
に対して以下を実行する。

【００４９】６．１ データベース上で従属状態照会を
ランして結果をえる。 ６．２ 該結果が期待結果に等しくない場合、ステップ
６．５へ進む。

【００５０】６．３ 期待されたアップデートをデータ
ベースで実行する。 ６．４ 次のステップをスキップしてステップ６．へ戻
る。

【００５１】６．５ マージプロシジャーを実行してリ
バイズされたデータを得る。 ６．６ リバイズされたアップデートをデータベースで
実行する。 ４．当該書き込みがログのコミット部分にエンターされ
る時に該書き込みが過去からログ内に存在していた場
合、前のインスタンスを削除して新たな書き込みログを
生成する。 ５．当該書き込みが書き込みログの終端でない場合、新
たな書き込みの直前位置までサーバのデータベースをロ
ールバックする。 ６．新たな書き込みからログのテールまでのログ内の各
書き込みに対して以下を実行する。

【００５２】６．１ データベース上で従属状態照会を
ランし、結果を取得する。 ６．２ 取得結果が期待結果に等しくない場合、ステッ
プ６．５に進む。

【００５３】６．３ 期待されたアップデートをデータ
ベースに実行する。 ６．４ 次の各ステップをスキップしてステップ６．に
進む。

【００５４】６．５ マージプロシジャーを実行し、リ
バイズされたアップデートを取得する。

【００５５】６．６ リバイズされたアップデートをデ
ータベースに実行する。 前記に要約されたプロセスの衝突する書き込み部分のア
プリケーション固有の検出を利用するために、 −前記に要約されたプロセスのステップ２を除去し、 −ステップ６．５及び６．６を新たなステップ”６．５
書き込み動作を中止し、及び／又は衝突をユーザーに
報告する。”で置き換える。また、このプロセス自体に
よってもしくは特定の他のプロセスにおける検出された
書き込み衝突のアプリケーション固有の解決を利用する
ために、 −ステップ２を除去し、 −ステップ６．１及び６．２を新たなステップ”６．１
バージョンベクトルの比較もしくは特定の方法によっ
て衝突が検出された場合、ステップ６．５に進む。”で
置き換える。最後に、コミットされたデータ及びテンタ
ティブなデータの２つのデータクラスを維持する概念を
利用するために、 −ステップ６．１及び６．２を除去し、 −ステップ６．４、６．５、及び６．６を除去する。

【００５６】

【発明の効果】以上説明したように、本発明により、他
のユーザから通信断状態となる可能性のあるユーザによ
って読み出し及びアップデートが可能な共有データベー
スをサポートするアーキテクチャが提供される。

【図面の簡単な説明】

【図１】本発明を実施するために使用可能なクライアン
ト／サーバアーキテクチャのブロック図。

【図２】選択されたセッション保証をクライアントに代
わって実施するセッションマネージャーを含むよう図１
のアーキテクチャが拡張された図。

【図３】書き込み実行プロセスのフロー図。

【図４】アプリケーション固有の衝突検出プロセスのフ
ロー図。

【図５】アプリケーション固有の衝突解決プロセスのフ
ロー図。

【図６】コミットされた書き込みとテンタティブな書き
込みとを区別し、安定なデータを有するデータベー
ス（”コミットされたデータベース”）と潜在的に不安
定なデータを有するデータベース（”フルデータベー
ス”）とを識別する書き込みログの概略図。

【図７】クライアントアプリケーションから受信された
書き込みを処理するプロセスのフロー図。

【図８】アンチ−エントロピーを介して他のサーバから
受信された書き込みを処理するプロセスのフロー図。

【図９】基本サーバによってクライアントアプリケーシ
ョンから受信された書き込みを処理するプロセスのフロ
ー図。

【図１０】アンチ−エントロピーを介して２次的サーバ
において他のサーバから受信された書き込みを処理する
プロセスを示す、図８を拡張した図。

【図１１】２次的サーバにおいて書き込みをコミットす
るプロセスを示す、図１０を拡張した図。

【図１２】データベースのロールバックプロセスを示す
フロー図。

【図１３】書き込みの再順序付けを発生するタイプのシ
ナリオを示す図。

【図１４】図１３のシナリオの追跡を示す図。

【符号の説明】

１１ サーバ １５ クライアント ３０ データベース ３２ セッションマネージャー

───────────────────────────────────────────────────── フロントページの続き (72)発明者 カリン ピーターセン アメリカ合衆国 94025 カリフォルニア 州 メンロ パーク シャロン パーク ドライヴ 350 ナンバー エヌ307 (72)発明者 マイケル ジェイ．スプレイツァー アメリカ合衆国 95376 カリフォルニア 州 トレイシー ブリストルコーン ドラ イヴ 1941 (72)発明者 ダグラス ビー．テリー アメリカ合衆国 94070 カリフォルニア 州 サン カルロス ビバリー ドライヴ 240 (72)発明者 マーヴィン エム．セイマー アメリカ合衆国 94043 カリフォルニア 州 マウンテン ビュー アルヴィン ス トリート 2447 (72)発明者 ブレント ビー．ウェルチ アメリカ合衆国 94043 カリフォルニア 州 マウンテン ビュー デル アヴェニ ュー 2540

Claims (1)

【特許請求の範囲】
1. 【請求項１】 データベースのインスタンスと、前記デ
   ータベースの前記インスタンスをアップデートするため
   に提示される書き込みとの間に存在することが見いださ
   れる衝突を解決する、アプリケーション固有のプロセス
   であって、 前記アプリケーションによって特定される任意のマージ
   プロシジャーを前記書き込み動作の各々に関係づけるス
   テップを備え、マージプロシジャーの実行の影響は、前
   記マージプロシジャーが実行される任意の時点において
   前記データベースの前記インスタンスの任意の所与の状
   態に対して決定論的であり、 所与の書き込み動作が前記データベースの前記インスタ
   ンスと衝突する場合は常に、所与の書き込み動作に関係
   するマージプロシジャーを実行するステップを備え、前
   記マージプロシジャーは、所与の書き込み動作によって
   本来意図される任意のアップデートに代わって前記デー
   タベースに適用されるアップデートセットを生成する、
   書き込み衝突解決プロセス。