JP2000132443A

JP2000132443A - コンピュータ、情報共有システム、及びレプリカ同一性保持方法

Info

Publication number: JP2000132443A
Application number: JP10301007A
Authority: JP
Inventors: Yasushi Negishi; 康根岸; Aaja Mohan; モハン・アージャ; Kazuya Tago; 和哉田胡
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-10-22
Filing date: 1998-10-22
Publication date: 2000-05-12
Anticipated expiration: 2018-10-22
Also published as: IL131710A0; IL131710A; KR20000028662A; US6571278B1; CN1252568A; JP3578385B2; KR100359960B1; CN1114869C; TW505852B

Abstract

(57)【要約】【課題】レプリカ更新時における通信効率を改善し、メ
モリ使用量を削減する。【解決手段】共有データのレプリカを有し、データ変更
を他のコンピュータと相互に通知しあうことによりレプ
リカの内容の同一性保持を図るコンピュータであって、
他のコンピュータからレプリカ内のデータの変更要求を
受信する手段と、変更要求の受信順番にかかわらず、受
信した変更要求によるレプリカの更新実行のタイミング
を、変更要求に含まれる情報を用いて、変更要求の受信
毎に制御する制御手段とを有する。よって、変更要求の
受信順番、すなわち、他のコンピュータの送信順番とは
無関係に、変更要求によるレプリカの更新実行のタイミ
ング／順序を決定できる。さらに、例え変更要求がその
生成順に受信されなくとも、実行できる変更要求を判別
且つ実行することができるので、より処理効率も高くな
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、各コンピュータが
共有データのレプリカを有し、データ変更をコンピュー
タ相互に通知しあうことによりレプリカの内容の同一性
を保持するシステムに関し、より詳しくは、レプリカ更
新動作の順序制御に関する。

【０００２】

【従来の技術】従来の情報共有システムでは、以下のよ
うな方法でレプリカの更新の順序が決定されていた。（１）コンピュータ間の通信回線が常に接続されている
ことを前提とする情報共有システムの場合、データの更
新を、当該更新が発生する度に通知しあう機構を有して
いることが多い。この場合、レプリカの更新はデータ変
更が起きるたびに変更の順序と同じ順序で行われること
が保証される。以下、このような順序をＦＩＦＯ順序と
呼ぶ。しかし、オフィス等に設置されたコンピュータ内
のデータを、オフィス外で携帯端末に取り込み、閲覧・
編集するような場合も存在する。この携帯端末等の場合
によく用いられる無線公衆回線は、通常のＬＡＮ（Loca
l Area Network）と比較すると回線の品質が悪く、パケ
ット転送の失敗が頻繁に起こる。一般に転送順序に関す
る制約が強ければ強いほど、転送オーバーヘッドも大き
くなる。最も強い制約を伴うＦＩＦＯ順序での転送は、
大きな転送オーバーヘッドがかかる。無線公衆回線は回
線使用料も高価なので、この転送オーバーヘッドは大き
な問題である。（２）ＬｏｔｕｓＮｏｔｅｓ（Lotus社の商標）のよう
な、回線の非接続時の操作を仮定した情報共有システム
では、レプリカの更新は、バッチ処理のように全ての更
新が一括して行われる。このようなシステムでは、更新
中データにアクセスできない。通信回線の切断等により
レプリカの更新が途中で中断された場合、更新の順序は
一般に不定である。すなわち、更新がどこまで実行され
たか分からなくなってしまう。

【０００３】ＥＰ０７９４６４６（特開平９−２４６４
２号）は、以下の事項を開示している。移動通信ネット
ワークを介して接続可能な複数のコンピュータ・システ
ム上に保持される、共用データ・ファイルのコピーを管
理するデータ管理システムであって、当該データ管理シ
ステムは、共用データ・ファイルの各コピーに関連付け
られ、そのコピーに対して実行される変更の記録を保持
するロギング手段と、移動通信ネットワークへの接続を
介して、共用データ・ファイルの他のコピーに対して保
持される記録を取り出すための取り出し手段と、取り出
された記録を併合し、変更の順序を生成する併合手段
と、予め定義された規則を変更順序に適用し、変更順序
内での衝突を解決する衝突解決手段と、衝突解決済みの
変更順序にもとづき、共用ファイルのコピーを変更する
手段とを含む。なお、ここでいう衝突とは、同一の版の
データに対して並列に行われる複数のデータ変更を意味
すると考えられる。また、衝突の解決とは、衝突を生じ
ている複数のデータ変更を一定の順番に並べ直すことを
意味すると考えられる。このシステムは変更の衝突を解
決するためのシステムであり、変更の衝突を解決するた
めには衝突が発生したか否か判断する時までに全ての変
更に関する情報がそろっていなければならない。すなわ
ち、変更の衝突を解決した後でなければ、共用ファイル
のコピーを変更することができない。よって、１つでも
変更に関する情報を取得できなければ変更処理を実行す
ることはできない。また、受信した変更に関する情報を
記憶するためのメモリについての負担も大きくなる。こ
れは携帯端末のように通信に使用できるメモリ容量が少
ない場合には大きな問題となる。さらに、メモリ容量が
足りないために行われる再送の問題も生じる。

【０００４】

【発明が解決しようとする課題】以上のように従来技術
では、レプリカの更新の際の通信効率、メモリ使用量、
及び途中で通信回線が切断した時の処理に問題があっ
た。

【０００５】よって、本発明の目的は、レプリカの更新
の際の通信効率を改善する方法及び装置を提供すること
である。

【０００６】また、レプリカの更新の際のメモリ使用量
を削減する方法及び装置を提供することも目的である。

【０００７】さらに、レプリカの更新のための通信が途
中で切断された場合であっても、変更要求によるレプリ
カの更新がどこまで実行されたか確認することができる
方法及び装置を提供することも目的である。

【０００８】さらに、レプリカ更新の順序を明示的に指
定できるようにすることも目的である。

【０００９】

【課題を解決するための手段】本発明は、共有データの
レプリカを有し、データ変更を他のコンピュータと相互
に通知しあうことによりレプリカの内容の同一性保持を
図るコンピュータであって、他のコンピュータからレプ
リカ内のデータの変更要求を受信する手段と、変更要求
の受信順番にかかわらず、受信した変更要求によるレプ
リカの更新実行のタイミングを、変更要求に含まれる情
報を用いて、変更要求の受信毎に制御する制御手段とを
有する。変更要求の受信順番、すなわち、他のコンピュ
ータの送信順番とは無関係に、変更要求によるレプリカ
の更新実行のタイミングを決定できるため、通信効率も
改善され且つメモリ使用量も削減される。

【００１０】上記の変更要求に含まれる情報は、変更順
番の指定なし（実施例におけるオーディナリ）、当該変
更要求より前の全ての変更要求を前記レプリカに反映し
た後に当該変更要求によるレプリカの更新を実行すると
いう第１の指定（実施例におけるフォワード・フラッシ
ュ）、当該変更要求より後の変更要求を当該変更要求に
よるレプリカの更新実行の後に実行するという第２の指
定（実施例におけるバックワード・フラッシュ）、又は
当該変更要求より前の全ての変更を前記レプリカに反映
した後に当該変更要求によるレプリカの更新を実行し且
つ当該変更要求より後の変更要求を当該変更要求による
レプリカの更新実行の後に実行するという第３の指定
（２ウエー・フラッシュ）を含むようにすることができ
る。このようにレプリカ更新の順序を明示的に指定する
こともできる。

【００１１】上記の変更要求に含まれる情報は、これま
でに生成された、第２又は第３の指定を含む変更要求の
数（第１の数：実施例におけるＢＴ数）、及び最後に第
２又は第３の指定を含む変更要求が生成された後に生成
された変更要求の数（第２の数：実施例におけるＳＢＴ
数）、をさらに含むようにすることも考えられる。この
ようにすると、途中で通信回線が切断されてもどの変更
要求まで、受信され且つ更新を実行されたか確認できる
機構を構築することができるようになる。

【００１２】また、上記制御手段は、第１及び第２の数
にそれぞれ対応し、レプリカの更新実行のタイミングを
規定する第１及び第２の管理値（実施例における処理中
ＢＴ数及び処理中ＳＢＴ数）を保持するようにすること
も可能である。より簡単に更新実行のタイミングを決定
できるようになる。

【００１３】さらに、上記制御手段は、変更要求による
レプリカの更新が実行された場合に、当該変更要求に含
まれる第１及び第２の数を第３の数及び第４の数（実施
例では応答予定ＢＴ数及び応答予定ＳＢＴ数）として記
憶するように構成することも可能である。さらに、上記
のコンピュータが、他のコンピュータへレプリカ内のデ
ータの変更要求を送信する手段をさらに含み、上記制御
手段は、送信する変更要求に、第３の数及び第４の数を
含ませるように構成することも考えられる。このように
すれば、通信回線が途中で切断された場合であっても、
送信元はどの変更要求を再送すればよいか判断すること
ができ、さらに、送信元はどの変更要求を破棄してもよ
いかということを判断することも可能になる。

【００１４】以上は受信側のコンピュータの構成であっ
た。送信側のコンピュータは、レプリカ内のデータの変
更を命令し、当該データの変更に対して変更順序に関す
る情報を指定する手段と、データの変更の命令に対応し
且つ変更順序に関する情報を含む変更要求を生成する手
段と、変更要求の生成順序と送信順序の一致を保証しな
いような態様で、変更要求を送信する手段とを有する。
このようにデータの変更ごとに変更順序に関する情報を
明示的に指定し、受信側でその情報を使用可能なように
変更要求に含めて送る。また、通信効率を上げるため、
変更要求の生成順序と送信順序の一致を保証しないよう
な態様で送信する。途中で回線が切断され、再接続及び
再送するような場合も含む。

【００１５】上記変更要求は、上で述べた変更要求に含
まれる情報と同一の情報を含むようにすることも可能で
ある。

【００１６】また、上記コンピュータは、他のコンピュ
ータからレプリカ内のデータの変更要求を受信する手段
をさらに含み、受信した変更要求が、送信した変更要求
によるレプリカの更新が送信先の他のコンピュータで実
行されたことを示す応答情報（実施例では応答予定ＢＴ
数及び応答予定ＳＢＴ数）を含むように構成することも
できる。これにより、再送する必要の無い変更要求を確
定することができる。すなわち、応答情報を参照して、
送信した変更要求を削除するか判断する手段をさらに含
むようにすることができる。

【００１７】１つのコンピュータは以上述べた送信側及
び受信側双方の構成を有することも可能であり、且つそ
のようなコンピュータにより情報共有システムを構築す
ることもできる。

【００１８】以上はコンピュータの装置構成を示したわ
けであるが、以上のようなコンピュータにおいて実施さ
れる処理は、プログラムとして実施することも可能であ
る。この場合、プログラムは、フロッピーディスクやＣ
Ｄ−ＲＯＭ、その他の記憶媒体に記憶される。

【００１９】

【発明の実施の形態】図１に本発明の情報共有システム
全体の構成図を示す。情報共有システム１００は、コン
ピュータＡ（１）及びコンピュータＢ（３）から構成さ
れている。コンピュータの数は２に限定されないが、以
下の説明を分かりやすくするためにここでは２つである
とする。また、本発明に係る構成要素はコンピュータＡ
（１）及びコンピュータＢ（３）で同一であり、図１で
は代表してコンピュータＡ（１）に各構成要素を示して
いる。各コンピュータは、１以上のアプリケーション５
とレプリカ・コントローラ７と送信キュー９と受信キュ
ー１１とパケット送信機１３とパケット受信機１５とデ
ータ格納装置１７とを含む。

【００２０】アプリケーション５は、レプリカ・コント
ローラ７に対して、データの生成、検索、参照、及び削
除等の処理の要求を行う。そして、このデータの生成及
び削除等、データを変更する要求の際には、レプリカの
更新順序の指定を行う。本発明におけるレプリカの更新
順序の指定は、オーディナリ（Ordinary）、フォワード
・フラッシュ（Forward Flush）、バックワード・フラ
ッシュ（Backward Flush）、２ウエー・フラッシュ（Tw
o way Flush）のいずれかである。データの変更以外の
アクセスは、通常のデータベースのアクセスと同じであ
るから、詳しい説明は省略する。

【００２１】オーディナリは、当該変更の際に、対応す
るレプリカの更新順序に関する制約はないということを
示すためのものである。フォワード・フラッシュは、当
該データ変更に対応したレプリカの更新は、この変更以
前に行われた全ての変更をレプリカに反映させた後に行
うということを示すためのものである。バックワード・
フラッシュは、当該データ変更より後のデータ変更は、
この変更をレプリカに反映させた後に、レプリカに反映
するということを示すためのものである。２ウエー・フ
ラッシュは、フォワード・フラッシュ及びバックワード
・フラッシュの両方の制約を指定するためのものであ
る。メッセージ送信／受信の順序の指定という点では、
上記のような４種類の指定は、例えば "An Implementat
ion of F-channels," Mohan Ahuja, IEEE Transactions
on Paralell and Distributed Systems, Vol. 4, No.
6, June 1993. に記載されている。しかし、この論文は
その内容の情報共有システムへの適用は何ら記載も示唆
もしていないし、以下に述べる送信キュー及び受信キュ
ーに係る部分などを何ら記載も示唆もしていない。

【００２２】レプリカ・コントローラ７は、アプリケー
ション５からのアクセス要求に基づき、データ格納装置
１７中のデータへのアクセス、及び送信キュー９へのパ
ケット送信要求の追加を行う。さらに、受信キュー７の
状態を参照して、受信キュー１１内に格納されている変
更要求に対応して、レプリカの更新を指定のタイミング
で実行する。レプリカ・コントローラ７は、データ格納
装置１７へのアクセスを行う部分と、アクセスの内容等
を指示する部分とに分けることも可能である。本発明
は、複数のアプリケーション５による衝突、及びアプリ
ケーション５によるデータの変更と受信キュー１１内の
データ変更要求との衝突は取り扱わず、アプリケーショ
ン５によるデータ変更の実行と受信キュー１１内のデー
タ変更要求の実行とは、独立に実施されるものとして扱
う。もし、衝突の問題が生じた場合には、従来技術の手
法を用いて解決しても、いずれかを無視してもよい。

【００２３】データ格納装置１７は、レプリカを格納し
ており、通常のデータベースと同様の機能を有してい
る。すなわち、レプリカ・コントローラ７からの要求に
従って、データの作成、検索、参照、及び削除等を行
う。

【００２４】送信キュー９は、パケット送信要求を管理
するためのキューである。パケット送信要求は、アプリ
ケーション５により実施されたデータ変更の種類及び内
容、更新順序の指定、送信要求作成時のＢＴ数及びＳＢ
Ｔ数を含む。このＢＴ数及びＳＢＴ数は、キューを管理
するためのデータとして、送信キュー９に含まれる。Ｂ
Ｔ数は、これまでにアプリケーション５から受けたデー
タ変更（データ変更要求とも言う）であって、更新順序
の指定がバックワード・フラッシュ又は２ウエー・フラ
ッシュであるデータ変更の数であり、レプリカ・コント
ローラ７が管理する。ＳＢＴ数は、最後にバックワード
・フラッシュ又は２ウエー・フラッシュの指定があった
データ変更から現在までのデータ変更の数であり、同じ
くレプリカ・コントローラ７が管理する。

【００２５】また、その他の情報としては、ここではコ
ンピュータＢ（３）において受信され且つレプリカの更
新実行がなされた最新のデータ変更に係るＢＴ数を管理
するための応答確認済みＢＴ数と、同じくコンピュータ
Ｂ（３）において受信され且つレプリカの更新実行がな
された最新のデータ変更に係るＳＢＴ数を管理するため
の応答確認済みＳＢＴ数を含む。これらの情報は、パケ
ット受信装置１５により管理される。

【００２６】受信キュー１１は、受信したが更新処理を
完了していないパケット中の変更要求を管理するための
キューである。変更要求の他に、現在実行可能な変更要
求のＢＴ数である処理中ＢＴ数及び現在実行可能な変更
要求のＳＢＴ数である処理中ＳＢＴ数、レプリカ・コン
トローラ７が実行した最新の変更要求に含まれるＢＴ数
を表す応答予定ＢＴ数及びレプリカ・コントローラ７が
実行した最新の変更要求に含まれるＳＢＴ数を表す応答
予定ＳＢＴ数とがある。これらは、レプリカ・コントロ
ーラ７により管理される。

【００２７】パケット送信機１３は、送信キュー９及び
受信キュー１１を監視し、必要なパケットを生成して、
通信媒体１９にパケットを送信する。パケット送信機１
３は、送信キュー９に格納されている送信要求を順次送
信するが、従来技術のように送信キュー９内の順番（生
成順番）でコンピュータＢ（３）が受信することを保証
しない様な態様で送信する。すなわち、送信要求の生成
順番で１つのパケットが受信されるのを確認した後に次
のパケットを送信するわけではなく、次々に送信してゆ
き、送信先のコンピュータＢ（３）が受信に失敗した場
合には、受信に失敗したパケットを再送する。又は、受
信し且つ更新処理が実施されるということが分かるま
で、同じパケットを何度も送信するようにしてもよい。
その際には、応答確認済みＢＴ数及び応答確認済みＳＢ
Ｔ数を使用するとよい。また、送信順番は、送信要求の
生成順番に全く無関係になっていてもよい。

【００２８】パケット送信機１３は、送信キュー９のパ
ケット送信要求を１つ選び、受信キュー１１内の応答予
定ＢＴ数及び応答予定ＳＢＴ数と共に、パケットを作成
して送信する。応答予定ＢＴ数及び応答予定ＳＢＴ数
は、送信先であるコンピュータＢ（３）の送信キューに
格納されている応答確認済みＢＴ数及びＳＢＴ数を変更
するために用いられる。なお、送信すべき送信要求が送
信キュー９に無い場合には、応答予定ＢＴ数及び応答予
定ＳＢＴ数のみを送信する。

【００２９】パケット受信機１５は、パケットを受信
し、パケットの内容、送信キュー、及び受信キューの状
態を参照して、送信キュー及び受信キューの更新を行
う。すなわち、受信したパケットの応答予定ＢＴ数及び
応答予定ＳＢＴ数を用いて、送信キュー９の応答確認済
みＢＴ数応答確認済みＳＢＴ数を更新する。この更新
は、応答予定ＢＴ数＞応答確認済みＢＴ数であれば、応
答確認済みＢＴ数及び応答確認済みＳＢＴ数を応答予定
ＢＴ数及び応答予定ＳＢＴ数でそれぞれ更新する。も
し、応答予定ＢＴ数＝応答確認済みＢＴ数であれば、応
答予定ＳＢＴ＞応答確認済みＳＢＴかどうか判断する。
もし、この条件が満たされれば、応答確認済みＳＢＴを
応答予定ＳＢＴで更新する。以上の条件以外の場合に
は、応答確認済みＢＴ及びＳＢＴの更新は行わない。

【００３０】受信したパケットには、重複が存在するか
もしれない。よって、パケット受信機１５は、受信した
パケットの変更要求に含まれれるＢＴ数及びＳＢＴ数を
参照して、受信キュー９に既に格納されている変更要求
で同じＢＴ数及びＳＢＴ数の変更要求が存在する場合に
は、後から送られてきたパケット内の変更要求を破棄す
る。

【００３１】さらに、受信したパケットに係る変更要求
を既に実行してしまった場合も存在する。よって、受信
キュー１１を参照して、応答予定ＢＴ数より小さいＢＴ
数を含む変更要求、及び応答予定ＢＴ数と同じＢＴ数を
含む変更要求であって応答予定ＳＢＴ数より小さいＳＢ
Ｔ数を含む変更要求を破棄する。

【００３２】なお、応答確認済みＢＴ≧送信要求内のＢ
Ｔ、又は応答確認済みＢＴ＝送信要求内のＢＴ且つ応答
確認済みＳＢＴ≧送信要求内のＳＢＴとなっている送信
要求は送信キュー９から削除することができる。この削
除を実行するのは、パケット受信機１５又はパケット送
信機１３のいずれでもよい。

【００３３】また、受信したパケットに係る変更要求の
ＢＴ及びＳＢＴを参照して、受信キュー１１内の変更要
求の順番をＳＢ及びＳＢＴの小さい順で並び替える動作
を行うが、これもパケット受信機１５又はレプリカ・コ
ントローラ７のいずれが実施してもよい。

【００３４】通信媒体１９は、無線でも有線でも構わな
い。また、これらの組み合わせでもよい。本発明の特徴
として、信頼性の低いネットワークを介しての通信でも
対処することができる。

【００３５】以上説明したＢＴ数、ＳＢＴ数、応答予定
ＢＴ数、応答予定ＳＢＴ数、応答確認済みＢＴ数、及び
応答確認済みＳＢＴ数の関係及び更新について、図２を
用いてまとめておく。

【００３６】図２では、コンピュータＡ（１）の受信キ
ュー１１Ａ（ＡはコンピュータＡ内の構成要素であるこ
とを示す。同じくＢはコンピュータＢ内の構成要素であ
ることを示す）に格納されたパケット１に係る変更要求
をレプリカ・コントローラ７Ａが実行したところからの
動作を示している。変更要求を実行するとレプリカ・コ
ントローラ７は、受信キュー１１Ａの応答予定ＢＴ数及
び応答予定ＳＢＴ数をパケット１のＢＴ数及びＳＢＴ数
で変更する（ステップ１０００）。この更新された応答
予定ＢＴ数及び応答予定ＳＢＴ数は、コンピュータＡ
（１）が次にコンピュータＢ（３）に送信すべく送信キ
ュー９Ａ内に用意しているパケット２に取り込まれる
（ステップ１１００）。パケット送信機１３Ａがこのパ
ケット２を送信すると（ステップ１２００）、コンピュ
ータＢ（３）のパケット受信機１５Ｂがこれを受信し、
パケット２'として受信キュー１１Ｂに取り込む。ここ
で、パケット受信機１５Ｂは、上で述べたように、パケ
ット２'内の変更要求に係る応答予定ＢＴ数及び応答予
定ＳＢＴ数により、送信キュー９Ｂの応答確認済みＢＴ
数及び応答確認済みＳＢＴ数を更新すべきかを判断す
る。ここでは、上で述べた条件のいずれかが満たされた
として、応答確認済みＢＴ数及び応答確認済みＳＢＴ数
は更新される（ステップ１３００）。今度は、応答確認
済みＢＴ数と送信キュー９Ｂ内の変更要求のＢＴ数、応
答確認済みＳＢＴ数と送信キュー９Ｂ内の変更要求のＳ
ＢＴ数が比較され（ステップい１４００）、両者共に一
致するパケット１'が破棄される（ステップ１５０
０）。このように、送信キュー９Ｂからパケット１'が
破棄されると、二度とコンピュータＡ（１）に送信され
なくなる。

【００３７】次に、図３乃至図６を用いてレプリカ・コ
ントローラ７が受信キュー１１内の変更要求をいかに実
行していくか、について説明する。まず、図３を用いて
ＢＴ数とＳＢＴ数の付け方について説明しておく。図３
では、変更要求に含まれる更新順序の指定がオーディナ
リである場合にはＯ、バックワード・フラッシュの場合
にはＢ、２ウエー・フラッシュの場合にはＴ、フォワー
ド・フラッシュの場合にはＦと記している。また、各指
定における出現順番を添字にしている。最初は、ＢＴ数
及びＳＢＴ数とも０で初期化されている。そして、
（１）でアプリケーション５がオーディナリを指定する
と、データ変更Ｏ₁には（０，０）が付される。なお（B
T，SBT）である。そうすると、ＳＢＴ数は１インクリメ
ントされる。（２）で、再度オーディナリが指定される
と、データ変更Ｏ₂には（０，１）が付される。これに
よりＳＢＴ数はさらに１インクリメントされる。よっ
て、（３）でバックワード・フラッシュが指定される
と、データ変更Ｂ₁には（０，２）が付される。バック
ワード・フラッシュが発生するとＳＢＴ数はクリアさ
れ、ＢＴ数が１インクリメントされる。

【００３８】（４）で２ウエー・フラッシュが指定され
ると、データ変更Ｔ₁には（１，０）が付される。２ウ
エー・フラッシュが指定された場合も、ＳＢＴ数をクリ
アして、ＢＴ数を１インクリメントする。（５）でオー
ディナリが指定されると、データ変更Ｏ₃には（２，
０）が付される。この指定によりＳＢＴ数は１インクリ
メントされる。（６）でさらにオーディナリが指定され
ると、データ変更Ｏ₄には（２，１）が付される。さら
にＳＢＴ数は１インクリメントされる。（７）でフォワ
ード・フラッシュが指定されると、データ変更Ｆ₁には
（２，２）が付される。定義より、ＳＢＴ数は１インク
リメントされる。

【００３９】図３のようなデータ変更要求を含むパケッ
トがパケット送信機１３から送信され、コンピュータＢ
（３）で受信された場合の処理を、図４を用いて説明す
る。パケット受信機１５Ｂがパケットを受信した順番
は、図４に示すように、Ｏ₁，Ｂ₁，Ｏ₂，Ｔ₁，Ｏ₄，
Ｆ₁、Ｏ₃の順である。但し、図４の例では１つずつデー
タ変更要求を受信し、処理していくものとする。もし、
複数のデータ変更要求が受信キュー１１Ｂに貯まった場
合には、上で述べたようにＢＴ数及びＳＢＴ数の小さい
順にデータ変更要求を並び替える。図４は単なる例であ
っていくつかのパケットをまとめて受信するようなこと
があってもよい。

【００４０】最初に、処理中ＢＴ数及び処理中ＳＢＴ数
を共に０に初期化しておく。そして（１）で、パケット
受信機１５Ｂはデータ変更Ｏ₁を受信して受信キュー１
１Ｂに入れる。受信キュー１１Ｂの状態は、図５の
（１）の左側の状態になる。そして、処理中ＢＴ数及び
処理中ＳＢＴ数、並びにデータ変更Ｏ₁のＢＴ数及びＳ
ＢＴ数を用いて、データ変更Ｏ₁を実行してよいのかを
レプリカ・コントローラ７Ｂが判断する。判断基準は以
下のとおりである。（ａ）データ変更要求の更新順序の指定がオーディナリ
又はバックワード・フラッシュの場合データ変更要求のＢＴ数≦処理中ＢＴ数であれば実行可能である。（ｂ）データ変更要求の更新順序の指定がフォワード・
フラッシュ又は２ウエー・フラッシュの場合データ変更要求のＢＴ数＝処理中ＢＴ数且つデータ変更要求のＳＢＴ数＝処理中ＳＢＴ数であれば実行可能である。

【００４１】上のような判断基準を図４の（１）に当て
はめてみると、オーディナリの指定でデータ変更要求の
ＢＴ数は０で処理中ＢＴ数も０であるから実行可能であ
る。よって、レプリカ・コントローラ７Ｂはデータ変更
Ｏ₁を実行する。図４の（１）では「変更実行」の行に
○が記されている。

【００４２】次に当該データ変更Ｏ₁を受信キュー１１
Ｂから削除してもよいか判断する。この判断は、データ
変更要求のＢＴ数＝処理中ＢＴ数、且つデータ変更要求
のＳＢＴ数＝処理中ＳＢＴ数であるかにより行われる。
もし、上記条件が満たされた場合には、処理中ＢＴ数及
び処理中ＳＢＴ数の値も更新する。更新方法は、以下の
とおりである。（ａ）データ変更要求の更新順序の指定が、オーディナ
リ又はフォワード・フラッシュの場合処理中ＳＢＴ数＝処理中ＳＢＴ数＋１（ｂ）データ変更要求の更新順序の指定が、バックワー
ド・フラッシュ又は２ウエー・フラッシュの場合処理中ＢＴ数＝処理中ＢＴ数＋１処理中ＳＢＴ数＝０

【００４３】上記判断基準を満たしているので、レプリ
カ・コントローラ７Ｂはデータ変更Ｏ₁を受信キュー１
１Ｂから削除することができる。よって図４では「削
除」の欄に○が記されている。そして、データ変更Ｏ₁
はオーディナリなので、上記更新方法のように処理中Ｓ
ＢＴ数が１インクリメントされる。図５の（１）の矢印
の先に示したように、受信キュー１１Ｂにデータ変更要
求は無くなる。

【００４４】次に（２）で、パケット受信機１５Ｂはデ
ータ変更Ｂ₁を受信する。バックワード・フラッシュで
あるから、データ変更Ｂ₁のＢＴ数と処理中ＢＴ数を比
較して、上記判断基準を満たしていると判断できる。よ
って、レプリカ・コントローラ７Ｂはデータ変更Ｂ₁を
実行する（図４の（２）の「変更実行」の行に○が記さ
れている）。しかし，データ変更Ｂ₁のＳＢＴ数と処理
中ＳＢＴ数は異なるので、当該データ変更Ｂ₁を受信キ
ュー１１Ｂから削除することはできない。図５の（２）
に示したように、パケット受信機１５Ｂにより受信され
たデータ変更Ｂ ₁は受信キュー１１Ｂに残る。しかし、
データ変更Ｂ₁の全てを受信キュー１１Ｂに残しておく
必要はない。データ変更要求は実行したわけであるか
ら、データ変更に直接関係するデータは削除することが
でき、それ以外のＢＴ数及びＳＢＴ数及び更新順番の指
定等のデータ変更要求の基本的情報部分のみを残せばよ
い。図５ではそのような場合には点線の四角を用いる。
よってＢ₁が点線で囲まれている。

【００４５】（３）で、パケット受信機１５Ｂはデータ
変更Ｏ₂を受信する。データ変更Ｏ₂のＢＴ数は０だがＳ
ＢＴ数は１であるから、データ変更Ｂ₁のＳＢＴ数より
小さい。よって、図５の（３）で示したように、パケッ
ト受信機１５Ｂはデータ変更Ｏ₂を最初にデータ変更Ｂ₁
を２番目にするように受信キュー１１Ｂを更新する。レ
プリカ・コントローラ７Ｂは、データ変更Ｏ₂のＢＴ数
が０で処理中ＢＴ数の０であるから、データ変更Ｏ₂を
実行可能と判断し、実行する（図４の（３）の「変更実
行」に○が記されている）。さらに、レプリカ・コント
ローラ７Ｂは、データ変更Ｏ₂のＢＴ数と処理中ＢＴ数
が一致し、且つデータ変更Ｏ₂のＳＢＴ数と処理中ＳＢ
Ｔ数が一致するため、データ変更Ｏ₂を削除する（図４
の（３）の「削除」の行には○が記されている）。

【００４６】さらに、更新順序の指定がオーディナリで
あり、且つＢＴ数と処理中ＢＴ数及びＳＢＴ数と処理中
ＳＢＴ数が一致するので、処理中ＳＢＴ数が１インクリ
メントされる。ここでは、処理中ＢＴ数０、処理中ＳＢ
Ｔ数２となる。これにより、受信キュー１１Ｂに残った
データ変更Ｂ₁のＢＴ数とＳＢＴ数がそれぞれ処理中Ｂ
Ｔ数及び処理中ＳＢＴ数に一致するようになる。そこ
で、レプリカ・コントローラ７Ｂはデータ変更Ｂ₁につ
いても受信キュー１１Ｂから削除する。図４の（３）か
ら（２）への矢印にてデータ変更Ｂ₁が削除されること
を示している。また、図５の（３）の右側で受信キュー
１１Ｂが空になったことを示している。さらに、削除さ
れたデータ変更の更新順序の指定がバックワード・フラ
ッシュであり、且つＢＴ数と処理中ＢＴ数及びＳＢＴ数
と処理中ＳＢＴ数が一致するので、レプリカ・コントロ
ーラ７Ｂは処理中ＢＴ数を１インクリメントし、処理中
ＳＢＴ数をクリアする。

【００４７】（４）でパケット受信機１５Ｂはデータ変
更Ｔ₁を受信する。レプリカ・コントローラ７Ｂは、デ
ータ変更Ｔ₁のＢＴ数と処理中ＢＴ数が一致し、且つデ
ータ変更Ｔ₁のＳＢＴ数と処理中ＳＢＴ数が一致するの
で、データ変更Ｔ₁を実行する（図４の（４）の「変更
実行」の行には、○が記されている）。さらに、データ
変更Ｔ₁を削除することも可能であることが分かるの
で、レプリカ・コントローラ７Ｂはデータ変更Ｔ₁を受
信キュー１１Ｂから削除する（図４の（４）の「削除」
の行にも○が記されている）。図５の（４）でも、一旦
受信キュー１１Ｂに入れられたデータ変更Ｔ₁が削除さ
れて、受信キュー１１Ｂが空になる様子を示している。
データ変更Ｔ₁は２ウエー・フラッシュであるから、処
理中ＢＴ数を１インクリメントし、処理中ＳＢＴ数をク
リアする。

【００４８】（５）において、パケット受信機１５Ｂは
データ変更Ｏ₄を受信する。レプリカ・コントローラ７
Ｂは、更新順番の指定がオーディナリであり、データ変
更Ｏ ₄のＢＴ数が２で処理中ＢＴ数も２であるから、デ
ータ変更Ｏ₄を実行する（図４の（５）の「変更実行」
の行に○が記されている）。しかし、処理中ＳＢＴ数と
データ変更Ｏ₄のＳＢＴ数は一致しないので、受信キュ
ー１１Ｂからこのデータ変更Ｏ₄を削除することはでき
ない。図５の（５）では、実行は行ったので点線で囲ま
れたデータ変更Ｏ₄が受信キュー１１Ｂに残ることを示
している。

【００４９】（６）において、パケット受信機１５Ｂは
データ変更Ｆ₁を受信する。パケット受信機１５Ｂはデ
ータ変更Ｆ₁のＢＴ数及びＳＢＴ数から、受信キュー１
１Ｂにおいてデータ変更Ｏ₄の後ろにデータ変更Ｆ₁を追
加する。レプリカ・コントローラ７Ｂは、データ変更Ｆ
₁の実行が可能かどうか検査するが、データ変更Ｆ₁のＳ
ＢＴ数と処理中ＳＢＴ数が一致しないので、実行するこ
とができない。当然受信キュー１１Ｂから削除すること
もできない。図５の（６）には、受信キュー１１Ｂに２
つのデータ変更要求が貯まった状態を示している。

【００５０】（７）において、パケット受信機１５Ｂは
データ変更Ｏ₃を受信する。パケット受信機１５Ｂは、
データ変更Ｏ₃のＢＴ数及びＳＢＴ数から、受信キュー
１１Ｂの順番を入れ替える。図５の（７）に示したよう
に、データ変更Ｏ₃が１番目、データ変更Ｏ₄が２番目、
データ変更Ｆ₁が３番目に並べられる（図５の（７）の
一番左側参照）。レプリカ・コントローラ７Ｂは、デー
タ変更Ｏ₃のＢＴ数と処理中ＢＴ数が一致するため、デ
ータ変更Ｏ₃を実行する（図４の（７）の「変更実行」
の行に○が記されている）。また、データ変更Ｏ₃のＳ
ＢＴ数と処理中ＳＢＴ数も一致するため、レプリカ・コ
ントローラ７Ｂはデータ変更Ｏ₃を削除する（図５の
（７）の左から２番目参照）。図４の（７）の「削除」
の行には○が記されている。データ変更Ｏ₃の更新順序
の指定はオーディナリであり、ＢＴ数と処理中ＢＴ数並
びにＳＢＴ数と処理中ＳＢＴ数が一致するので、レプリ
カ・コントローラ７Ｂは処理中ＳＢＴ数を１インクリメ
ントする。そうすると、受信キュー１１Ｂ内のデータ変
更Ｏ₄のＢＴ数及びＳＢＴ数にそれぞれ一致するように
なる。そこで、レプリカ・コントローラ７Ｂは、受信キ
ュー１１Ｂからデータ変更Ｏ₄を削除する（図５の
（７）の左から３番目参照）。図４では（７）から
（５）への矢印で削除が可能になったことを示してい
る。

【００５１】さらに、データ変更Ｏ₄のＢＴ数と処理中
ＢＴ数、並びにデータ変更Ｏ₄のＳＢＴ数と処理中ＳＢ
Ｔ数が一致し、データ変更Ｏ₃の更新順序の指定はオー
ディナリであるから、レプリカ・コントローラ７Ｂは処
理中ＳＢＴ数を１インクリメントする。そうすると、
（６）で実行することができなかったデータ変更Ｆ₁の
ＢＴ数及びＳＢＴ数と処理中ＢＴ数及び処理中ＳＢＴ数
がそれぞれ一致するようになる。レプリカ・コントロー
ラ７Ｂはデータ変更Ｆ₁を実行し、且つ実行後データ変
更Ｆ₁を受信キュー１１Ｂから削除する。図５の（７）
の右端は最後には受信キュー１１Ｂが空になることを示
している。また、図４の（７）から（６）への点線矢印
が、実行が可能になり且つ削除も可能になったことを示
している。

【００５２】以上の処理を、図６にまとめて示してい
る。まず、受信キュー１１中の今受信した変更要求又は
ステップ２２００により指示を受けた場合にはステップ
２２００で指定された変更要求が実行可能か否か判断す
る（ステップ２１００）。これは、変更要求に含まれる
更新順番の指定とＢＴ数及びＳＢＴ数により決定され
る。もし、実行不可能であれば、受信キュー１１の次の
変更要求へ移行する（ステップ２２００）。受信キュー
１１に次の変更要求が存在しない場合には、受信するま
で待つ。図６では明示していないが、受信キュー１１内
は変更要求を受信するごとに、ＢＴ数及びＳＢＴ数の小
さい順に並び替える。もし、変更要求が実行可能であれ
ば、当該変更要求を実行する（ステップ２３００）。そ
して、受信キュー１１から削除可能な変更要求があるか
判断する（ステップ２４００）。もし、削除可能な変更
要求がある場合には、当該変更要求を削除する（ステッ
プ２６００）。このステップ２６００においては、レプ
リカ・コントローラ７は受信キュー１１内の応答予定Ｂ
Ｔ数及び応答予定ＳＢＴ数の更新も、削除した変更要求
のＢＴ数及びＳＢＴ数を用いて実施する。削除した場合
には、処理中ＢＴ数及び処理中ＳＢＴ数を必要に応じて
変更する。もし、削除可能な変更要求がない場合には、
ステップ２２００に移行する。削除を実行した後に、処
理が完了したか判断し、処理が終了していない場合には
ステップ２２００に移行する。処理が完了したと判断さ
れる場合には、ステップ２７００で処理を終了する。

【００５３】以上のように、パケット受信機１１は、レ
プリカ・コントローラ７は変更要求を受信するごとに受
信キュー内の順番を更新し、且つ実行可能な変更要求か
判断することにより各変更要求実行のタイミング／順序
を決定している。この動作は受信順番に全く関係ない。
例え変更要求がその生成順に受信されなくとも、実行で
きる変更要求を判別且つ実行することができるので、よ
り処理効率も高くなる。また、実行した変更要求は受信
キュー１１から削除できる場合もあるので、メモリの使
用効率も向上する。また、実行した変更要求で削除でき
ない場合であっても、当該変更要求の基本的情報のみを
残しておくようにすれば、さらにメモリ効率は向上す
る。

【００５４】図１の情報共有システムでは、２つのコン
ピュータしか示していないが、３以上設けることも可能
である。但し、本発明を実施するには、各コンピュータ
対ごとに上記の構成を必要とする。

【００５５】以上の実施例は様々に変更可能である。各
構成要素は同一のコンピュータ上になくともよい。パケ
ット受信機１５とレプリカ・コントローラ７の機能は必
要に応じていずれかの要素に含めることができ、一体化
することも可能である。同様に、データ格納装置１７と
レプリカ・コントローラ７が一体化されていてもよい。
また、上の実施例では変更要求の実行と削除を独立に処
理していたが、同時に行うように変形することも可能で
ある。この際には、応答予定ＢＴ数及び応答予定ＳＢＴ
数の更新のために別途ＢＴ数及びＳＢＴ数を保存してお
く必要が生じ得る。また、応答確認済みＢＴ数及び応答
確認済みＳＢＴ数を管理しないで、応答予定ＢＴ数及び
応答予定ＳＢＴ数を受信するごとに、同じ数のＢＴ数及
びＳＢＴ数を有する変更要求を削除するように変形する
ことも可能である。送信及び受信キューはメインメモリ
上に設けても、専用のメモリを用いてもよい。また、実
行済の変更要求は受信キューには置かず、別のキュー又
は表を用いて処理中ＢＴ数泳ぎ処理中ＳＢＴ数を更新し
てもよい。さらに、処理中ＳＢＴ数を管理しないで必要
に応じて受信キュー中の同一のＢＴ数を持つ変更要求を
数えてもよい。

【００５６】

【効果】レプリカの更新の際の通信効率を改善する方法
及び装置を提供することができた。

【００５７】また、レプリカの更新の際のメモリ使用量
を削減する方法及び装置を提供することもできた。

【００５８】さらに、レプリカの更新のための通信が途
中で切断された場合であっても、変更要求によるレプリ
カの更新がどこまで実行されたか確認することができる
方法及び装置を提供することもできた。

【００５９】さらに、レプリカ更新の順序を明示的に指
定できるようにすることもできた。

【００６０】例えば大画像データを複数枚リプリケート
し、１つの画像データ内のデータを複数に分割してデー
タ転送を行う例を考える。この場合、同一の画像データ
内の転送順序を制御する必要は無いが、リプリケート中
に通信回線が意図的又は不意に切断された場合でも、全
てのデータがリプリケートされている画像データをなる
べく多く得ることが望ましい。従来技術のＦＩＦＯ順序
でリプリケートされる場合には各画像データの末尾のデ
ータがリプリケートされればその画像データはリプリケ
ートされていることがわかるが、転送オーバーヘッドが
多大である。また、リプリケート全体がバッチ処理的に
リプリケートされる場合でも、途中で回線が切断される
と、どの画像データについても全てのデータがそろった
ことが保証できない。本発明では、１つの画像データの
末尾でフォワード・フラッシュを指定すれば同一画像内
のデータ転送については送信順番に制約はなく、画像間
のデータ転送順序を制御することも可能になる。この場
合、末尾データの更新が実行されれば、当該画像データ
全体がリプリケートされたことを保証することができる
ようになる。

【００６１】また、セールスマンの個人情報とそのセー
ルスマンの月例売上表をリプリケートする例を考える。
個人情報には、社員番号、氏名、所属部課、電話番号が
含まれ、月例売上表には、社員番号と毎日の売上高が含
まれるものとする。売上表出力プログラムは、月売上表
から社員番号を得てその社員番号から個人情報を検索
し、対応する氏名、所属部課、電話番号を出力する。こ
のような例で、月例売上表があるのに、対応する個人情
報が存在しないと出力プログラムは月例売上表に対応す
る氏名等を出力することができない。このように依存関
係がある複数のデータをリプリケートする場合、リプリ
ケート中に回線が切断されても依存関係に矛盾が生じな
いように、依存関係があるデータ間のリプリケートの順
序を保証したい場合がある。従来技術のＦＩＦＯ順序で
リプリケートする場合、個人情報、月例売上表の順でデ
ータを生成することにより、リプリケートの順を保証す
ることができる。しかし、転送順序を保証する必要の無
い他のデータのリプリケートもＦＩＦＯ順序で行われる
ことになり、不必要な転送オーバヘッドを生じる、ま
た、リプリケート全体がバッチ処理される場合、リプリ
ケートが完全に終了せずに回線が切断された時にその時
点でのリプリケートの順序を保証することができない。
本発明を利用して、最後の個人情報の生成時に２ウエー
・フラッシュを指定し、その後に月例売上表を生成する
ことにより個人情報と月例売上表のリプリケートの順序
を保証することができる。その際に生じる転送オーバヘ
ッドも必要最小限ですむ。

【図面の簡単な説明】

【図１】本発明の情報共有システムを示す図である。

【図２】変更要求のＢＴ数及びＳＢＴ数、応答予定ＢＴ
数及び応答予定ＳＢＴ数、応答確認済みＢＴ数及び応答
確認済みＳＢＴ数の関係を表すフロー図である。

【図３】ＢＴ数及びＳＢＴ数の変更要求への付け方を示
す図である。

【図４】変更要求及び削除の実行を説明するための例を
示す図である。

【図５】図４の場合の受信キューのようすを示す図であ
る。

【図６】変更要求の実行及び削除の実行の処理フローを
示す図である。

【符号の説明】

１００情報共有システム１コンピュータＡ３コンピュータＢ５アプリケーション７レプリカ・コントローラ９送信キュー１１受信キュー１３パケット送信機１５パケット受信機１７データ格納装置１９通新媒体

───────────────────────────────────────────────────── フロントページの続き (72)発明者根岸康神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内 (72)発明者モハン・アージャ神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内 (72)発明者田胡和哉神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社東京基礎研究所内Ｆターム(参考） 5B082 GB02 GB06 HA03

Claims

【特許請求の範囲】

【請求項１】共有データのレプリカを有し、データ変更
を他のコンピュータと相互に通知しあうことにより前記
レプリカの内容の同一性保持を図るコンピュータであっ
て、他のコンピュータから前記レプリカ内のデータの変更要
求を受信する手段と、前記変更要求の受信順番にかかわらず、受信した前記変
更要求によるレプリカの更新実行のタイミングを、前記
変更要求に含まれる情報を用いて、前記変更要求の受信
毎に制御する制御手段と、を有するコンピュータ。
【請求項２】前記変更要求に含まれる情報は、変更順番の指定なし、当該変更要求より前の全ての変更
要求を前記レプリカに反映した後に当該変更要求による
レプリカの更新を実行するという第１の指定、当該変更
要求より後の変更要求を当該変更要求によるレプリカの
更新実行の後に実行するという第２の指定、又は当該変
更要求より前の全ての変更を前記レプリカに反映した後
に当該変更要求によるレプリカの更新を実行し且つ当該
変更要求より後の変更要求を当該変更要求によるレプリ
カの更新実行の後に実行するという第３の指定、を含む
請求項１記載のコンピュータ。
【請求項３】前記変更要求に含まれる情報は、これまでに生成された、前記第２又は第３の指定を含む
変更要求の数（第１の数）、及び最後に前記第２又は第
３の指定を含む変更要求が生成された後に生成された変
更要求の数（第２の数）、をさらに含む、請求項２記載
のコンピュータ。
【請求項４】前記制御手段は、前記第１及び第２の数にそれぞれ対応し、レプリカの更
新実行のタイミングを規定する第１及び第２の管理値を
保持している、請求項３記載のコンピュータ。
【請求項５】前記制御手段は、前記変更要求によるレプリカの更新が実行された場合
に、当該変更要求に含まれる前記第１及び第２の数を第
３の数及び第４の数として記憶する、請求項３記載のコンピュータ。
【請求項６】他のコンピュータへ前記レプリカ内のデー
タの変更要求を送信する手段をさらに含み、前記制御手段は、送信する変更要求に、前記第３の数及び第４の数を含ま
せる、請求項５記載のコンピュータ。
【請求項７】共有データのレプリカを有し、データ変更
を他のコンピュータと相互に通知しあうことにより前記
レプリカの内容の同一性保持を図るコンピュータであっ
て、前記レプリカ内のデータの変更を命令し、当該データの
変更に対して変更順序に関する情報を指定する手段と、前記データの変更の命令に対応し且つ前記変更順序に関
する情報を含む変更要求を生成する手段と、前記変更要求の生成順序と送信順序の一致を保証しない
ような態様で、前記変更要求を送信する手段と、を有するコンピュータ。
【請求項８】前記変更順序に関する情報が、変更順番の指定なし、当該変更要求より前の全ての変更
要求を前記レプリカに反映した後に当該変更要求による
レプリカの更新を実行するという第１の指定、当該変更
要求より後の変更要求を当該変更要求によるレプリカの
更新実行の後に実行するという第２の指定、又は当該変
更要求より前の全ての変更を前記レプリカに反映した後
に当該変更要求によるレプリカの更新を実行し且つ当該
変更要求より後の変更要求を当該変更要求によるレプリ
カの更新実行の後に実行するという第３の指定、を含む
請求項７記載のコンピュータ。
【請求項９】前記変更要求は、これまでに生成された、前記第２又は第３の指定を含む
変更要求の数（第１の数）、及び最後に前記第２又は第
３の指定を含む変更要求が生成された後に生成された変
更要求の数（第２の数）、をさらに含む、請求項８記載
のコンピュータ。
【請求項１０】他のコンピュータから前記レプリカ内の
データの変更要求を受信する手段、をさらに含み、受信した前記変更要求は、送信した変更要求によるレプリカの更新が送信先の他の
コンピュータで実行されたことを示す応答情報を含む、請求項７記載のコンピュータ。
【請求項１１】前記応答情報を参照して、前記送信した
変更要求を削除するか判断する手段をさらに含む請求項
１０記載のコンピュータ。
【請求項１２】前記変更要求の受信順番にかかわらず、
受信した前記変更要求によるレプリカの更新実行のタイ
ミングを、前記変更順序に関する情報を用いて、前記変
更要求の受信毎に制御する制御手段をさらに含む請求項
７記載のコンピュータ。
【請求項１３】共有データのレプリカを有し、データ変
更を他のコンピュータと相互に通知しあうことにより前
記レプリカの内容の同一性保持を図るコンピュータであ
って、他のコンピュータから前記レプリカ内のデータの変更要
求を受信する手段と、前記変更要求の受信順番にかかわらず、受信した前記変
更要求によるレプリカの更新実行のタイミングを、前記
変更要求に含まれる情報を用いて、前記変更要求の受信
毎に制御する制御手段と、前記レプリカ内のデータの変更を命令し、当該データの
変更に対して変更順序に関する情報を指定する手段と、前記データの変更の命令に対応し且つ前記変更順序に関
する情報を含む変更要求を生成する手段と、前記変更要求の生成順序と送信順序の一致を保証しない
ような態様で、前記変更要求を送信する手段と、を有するコンピュータ。
【請求項１４】各コンピュータは共有データのレプリカ
を有し、データ変更を前記コンピュータ間で相互に通知
しあうことにより前記レプリカの内容の同一性保持を図
る情報共有システムであって、前記コンピュータは、他のコンピュータから前記レプリカ内のデータの変更要
求を受信する手段と、前記変更要求の受信順番にかかわらず、受信した前記変
更要求によるレプリカの更新実行のタイミングを、前記
変更要求に含まれる情報を用いて、前記変更要求の受信
毎に制御する制御手段と、前記レプリカ内のデータの変更を命令し、当該データの
変更に対して変更順序に関する情報を指定する手段と、前記データの変更の命令に対応し且つ前記変更順序に関
する情報を含む変更要求を生成する手段と、前記変更要求の生成順序と送信順序の一致を保証しない
ような態様で、前記変更要求を送信する手段と、を有する、情報共有システム。
【請求項１５】共有データのレプリカを有するコンピュ
ータにおいて、データ変更を他のコンピュータと相互に
通知しあうことにより前記レプリカの内容の同一性保持
を図るレプリカ同一性保持方法であって、他のコンピュータから前記レプリカ内のデータの変更要
求を受信するステップと、前記変更要求の受信順番にかかわらず、受信した前記変
更要求によるレプリカの更新実行のタイミングを、前記
変更要求に含まれる情報を用いて、前記変更要求の受信
毎に制御するステップと、を含むレプリカ同一性保持方法。
【請求項１６】共有データのレプリカを有するコンピュ
ータにおいて、データ変更を他のコンピュータと相互に
通知しあうことにより前記レプリカの内容の同一性保持
を図るレプリカ同一性保持方法であって、前記レプリカ内のデータの変更を命令し、当該データの
変更に対して変更順序に関する情報を指定するステップ
と、前記データの変更の命令に対応し且つ前記変更順序に関
する情報を含む変更要求を生成するステップと、前記変更要求の生成順序と送信順序の一致を保証しない
ような態様で、前記変更要求を送信するステップと、を含むレプリカ同一性保持方法。
【請求項１７】共有データのレプリカを有するコンピュ
ータにおいて、データ変更を他のコンピュータと相互に
通知しあうことにより前記レプリカの内容の同一性保持
を図るためのプログラムを記憶した記憶媒体であって、前記プログラムは、前記コンピュータに、他のコンピュータによる前記レプリカ内のデータの変更
要求の受信順番にかかわらず、受信した前記変更要求に
よるレプリカの更新実行のタイミングを、前記変更要求
に含まれる情報を用いて、前記変更要求の受信毎に決定
するステップと、決定されたタイミングで、前記変更要求によるレプリカ
の更新を実行するように命ずるステップと、を実行させる、記憶媒体。
【請求項１８】共有データのレプリカを有するコンピュ
ータにおいて、データ変更を他のコンピュータと相互に
通知しあうことにより前記レプリカの内容の同一性保持
を図るためのプログラムを格納した記憶媒体であって、前記プログラムは、前記コンピュータに、前記レプリカ内のデータの変更を命令し、当該データの
変更に対して変更順序に関する情報を指定するステップ
と、前記データの変更の命令に対応し且つ前記変更順序に関
する情報を含む変更要求を生成するステップと、を実行させる、記憶媒体。