JP3578385B2 - コンピュータ、及びレプリカ同一性保持方法 - Google Patents
コンピュータ、及びレプリカ同一性保持方法 Download PDFInfo
- Publication number
- JP3578385B2 JP3578385B2 JP30100798A JP30100798A JP3578385B2 JP 3578385 B2 JP3578385 B2 JP 3578385B2 JP 30100798 A JP30100798 A JP 30100798A JP 30100798 A JP30100798 A JP 30100798A JP 3578385 B2 JP3578385 B2 JP 3578385B2
- Authority
- JP
- Japan
- Prior art keywords
- change
- replica
- change request
- request
- data
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- 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/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- 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/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Communication Control (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、各コンピュータが共有データのレプリカを有し、データ変更をコンピュータ相互に通知しあうことによりレプリカの内容の同一性を保持するシステムに関し、より詳しくは、レプリカ更新動作の順序制御に関する。
【０００２】
【従来の技術】
従来の情報共有システムでは、以下のような方法でレプリカの更新の順序が決定されていた。
（１）コンピュータ間の通信回線が常に接続されていることを前提とする情報共有システムの場合、データの更新を、当該更新が発生する度に通知しあう機構を有していることが多い。この場合、レプリカの更新はデータ変更が起きるたびに変更の順序と同じ順序で行われることが保証される。以下、このような順序をＦＩＦＯ順序と呼ぶ。しかし、オフィス等に設置されたコンピュータ内のデータを、オフィス外で携帯端末に取り込み、閲覧・編集するような場合も存在する。この携帯端末等の場合によく用いられる無線公衆回線は、通常のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）と比較すると回線の品質が悪く、パケット転送の失敗が頻繁に起こる。一般に転送順序に関する制約が強ければ強いほど、転送オーバーヘッドも大きくなる。最も強い制約を伴うＦＩＦＯ順序での転送は、大きな転送オーバーヘッドがかかる。無線公衆回線は回線使用料も高価なので、この転送オーバーヘッドは大きな問題である。
（２）Ｌｏｔｕｓ Ｎｏｔｅｓ（Ｌｏｔｕｓ社の商標）のような、回線の非接続時の操作を仮定した情報共有システムでは、レプリカの更新は、バッチ処理のように全ての更新が一括して行われる。このようなシステムでは、更新中データにアクセスできない。通信回線の切断等によりレプリカの更新が途中で中断された場合、更新の順序は一般に不定である。すなわち、更新がどこまで実行されたか分からなくなってしまう。
【０００３】
ＥＰ０７９４６４６（特開平９−２４６４２号）は、以下の事項を開示している。移動通信ネットワークを介して接続可能な複数のコンピュータ・システム上に保持される、共用データ・ファイルのコピーを管理するデータ管理システムであって、当該データ管理システムは、共用データ・ファイルの各コピーに関連付けられ、そのコピーに対して実行される変更の記録を保持するロギング手段と、移動通信ネットワークへの接続を介して、共用データ・ファイルの他のコピーに対して保持される記録を取り出すための取り出し手段と、取り出された記録を併合し、変更の順序を生成する併合手段と、予め定義された規則を変更順序に適用し、変更順序内での衝突を解決する衝突解決手段と、衝突解決済みの変更順序にもとづき、共用ファイルのコピーを変更する手段とを含む。なお、ここでいう衝突とは、同一の版のデータに対して並列に行われる複数のデータ変更を意味すると考えられる。また、衝突の解決とは、衝突を生じている複数のデータ変更を一定の順番に並べ直すことを意味すると考えられる。このシステムは変更の衝突を解決するためのシステムであり、変更の衝突を解決するためには衝突が発生したか否か判断する時までに全ての変更に関する情報がそろっていなければならない。すなわち、変更の衝突を解決した後でなければ、共用ファイルのコピーを変更することができない。よって、１つでも変更に関する情報を取得できなければ変更処理を実行することはできない。また、受信した変更に関する情報を記憶するためのメモリについての負担も大きくなる。これは携帯端末のように通信に使用できるメモリ容量が少ない場合には大きな問題となる。さらに、メモリ容量が足りないために行われる再送の問題も生じる。
【０００４】
【発明が解決しようとする課題】
以上のように従来技術では、レプリカの更新の際の通信効率、メモリ使用量、及び途中で通信回線が切断した時の処理に問題があった。
【０００５】
よって、本発明の目的は、レプリカの更新の際の通信効率を改善する方法及び装置を提供することである。
【０００６】
また、レプリカの更新の際のメモリ使用量を削減する方法及び装置を提供することも目的である。
【０００７】
さらに、レプリカの更新のための通信が途中で切断された場合であっても、変更要求によるレプリカの更新がどこまで実行されたか確認することができる方法及び装置を提供することも目的である。
【０００８】
さらに、レプリカ更新の順序を明示的に指定できるようにすることも目的である。
【０００９】
【課題を解決するための手段】
本発明は、共有データのレプリカを有し、データ変更を他のコンピュータと相互に通知しあうことによりレプリカの内容の同一性保持を図るコンピュータであって、他のコンピュータからレプリカ内のデータの変更要求を受信する手段と、変更要求の受信順番にかかわらず、受信した変更要求によるレプリカの更新実行のタイミングを、変更要求に含まれる情報を用いて、変更要求の受信毎に制御する制御手段とを有する。変更要求の受信順番、すなわち、他のコンピュータの送信順番とは無関係に、変更要求によるレプリカの更新実行のタイミングを決定できるため、通信効率も改善され且つメモリ使用量も削減される。
【００１０】
上記の変更要求に含まれる情報は、変更順番の指定なし（実施例におけるオーディナリ）、当該変更要求より前の全ての変更要求を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行するという第１の指定（実施例におけるフォワード・フラッシュ）、当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第２の指定（実施例におけるバックワード・フラッシュ）、又は当該変更要求より前の全ての変更を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行し且つ当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第３の指定（２ウエー・フラッシュ）を含むようにすることができる。このようにレプリカ更新の順序を明示的に指定することもできる。
【００１１】
上記の変更要求に含まれる情報は、これまでに生成された、第２又は第３の指定を含む変更要求の数（第１の数：実施例におけるＢＴ数）、及び最後に第２又は第３の指定を含む変更要求が生成された後に生成された変更要求の数（第２の数：実施例におけるＳＢＴ数）、をさらに含むようにすることも考えられる。このようにすると、途中で通信回線が切断されてもどの変更要求まで、受信され且つ更新を実行されたか確認できる機構を構築することができるようになる。
【００１２】
また、上記制御手段は、第１及び第２の数にそれぞれ対応し、レプリカの更新実行のタイミングを規定する第１及び第２の管理値（実施例における処理中ＢＴ数及び処理中ＳＢＴ数）を保持するようにすることも可能である。より簡単に更新実行のタイミングを決定できるようになる。
【００１３】
さらに、上記制御手段は、変更要求によるレプリカの更新が実行された場合に、当該変更要求に含まれる第１及び第２の数を第３の数及び第４の数（実施例では応答予定ＢＴ数及び応答予定ＳＢＴ数）として記憶するように構成することも可能である。さらに、上記のコンピュータが、他のコンピュータへレプリカ内のデータの変更要求を送信する手段をさらに含み、上記制御手段は、送信する変更要求に、第３の数及び第４の数を含ませるように構成することも考えられる。このようにすれば、通信回線が途中で切断された場合であっても、送信元はどの変更要求を再送すればよいか判断することができ、さらに、送信元はどの変更要求を破棄してもよいかということを判断することも可能になる。
【００１４】
以上は受信側のコンピュータの構成であった。送信側のコンピュータは、レプリカ内のデータの変更を命令し、当該データの変更に対して変更順序に関する情報を指定する手段と、データの変更の命令に対応し且つ変更順序に関する情報を含む変更要求を生成する手段と、変更要求の生成順序と送信順序の一致を保証しないような態様で、変更要求を送信する手段とを有する。このようにデータの変更ごとに変更順序に関する情報を明示的に指定し、受信側でその情報を使用可能なように変更要求に含めて送る。また、通信効率を上げるため、変更要求の生成順序と送信順序の一致を保証しないような態様で送信する。途中で回線が切断され、再接続及び再送するような場合も含む。
【００１５】
上記変更要求は、上で述べた変更要求に含まれる情報と同一の情報を含むようにすることも可能である。
【００１６】
また、上記コンピュータは、他のコンピュータからレプリカ内のデータの変更要求を受信する手段をさらに含み、受信した変更要求が、送信した変更要求によるレプリカの更新が送信先の他のコンピュータで実行されたことを示す応答情報（実施例では応答予定ＢＴ数及び応答予定ＳＢＴ数）を含むように構成することもできる。これにより、再送する必要の無い変更要求を確定することができる。すなわち、応答情報を参照して、送信した変更要求を削除するか判断する手段をさらに含むようにすることができる。
【００１７】
１つのコンピュータは以上述べた送信側及び受信側双方の構成を有することも可能であり、且つそのようなコンピュータにより情報共有システムを構築することもできる。
【００１８】
以上はコンピュータの装置構成を示したわけであるが、以上のようなコンピュータにおいて実施される処理は、プログラムとして実施することも可能である。この場合、プログラムは、フロッピーディスクやＣＤ−ＲＯＭ、その他の記憶媒体に記憶される。
【００１９】
【発明の実施の形態】
図１に本発明の情報共有システム全体の構成図を示す。情報共有システム１００は、コンピュータＡ（１）及びコンピュータＢ（３）から構成されている。コンピュータの数は２に限定されないが、以下の説明を分かりやすくするためにここでは２つであるとする。また、本発明に係る構成要素はコンピュータＡ（１）及びコンピュータＢ（３）で同一であり、図１では代表してコンピュータＡ（１）に各構成要素を示している。各コンピュータは、１以上のアプリケーション５とレプリカ・コントローラ７と送信キュー９と受信キュー１１とパケット送信機１３とパケット受信機１５とデータ格納装置１７とを含む。
【００２０】
アプリケーション５は、レプリカ・コントローラ７に対して、データの生成、検索、参照、及び削除等の処理の要求を行う。そして、このデータの生成及び削除等、データを変更する要求の際には、レプリカの更新順序の指定を行う。本発明におけるレプリカの更新順序の指定は、オーディナリ（Ｏｒｄｉｎａｒｙ）、フォワード・フラッシュ（Ｆｏｒｗａｒｄ Ｆｌｕｓｈ）、バックワード・フラッシュ（Ｂａｃｋｗａｒｄ Ｆｌｕｓｈ）、２ウエー・フラッシュ（Ｔｗｏ ｗａｙ Ｆｌｕｓｈ）のいずれかである。データの変更以外のアクセスは、通常のデータベースのアクセスと同じであるから、詳しい説明は省略する。
【００２１】
オーディナリは、当該変更の際に、対応するレプリカの更新順序に関する制約はないということを示すためのものである。フォワード・フラッシュは、当該データ変更に対応したレプリカの更新は、この変更以前に行われた全ての変更をレプリカに反映させた後に行うということを示すためのものである。バックワード・フラッシュは、当該データ変更より後のデータ変更は、この変更をレプリカに反映させた後に、レプリカに反映するということを示すためのものである。２ウエー・フラッシュは、フォワード・フラッシュ及びバックワード・フラッシュの両方の制約を指定するためのものである。メッセージ送信／受信の順序の指定という点では、上記のような４種類の指定は、例えば ”Ａｎ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ Ｆ−ｃｈａｎｎｅｌｓ，” Ｍｏｈａｎ Ａｈｕｊａ， ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｐａｒａｌｅｌｌ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ， Ｖｏｌ． ４， Ｎｏ． ６， Ｊｕｎｅ １９９３． に記載されている。しかし、この論文はその内容の情報共有システムへの適用は何ら記載も示唆もしていないし、以下に述べる送信キュー及び受信キューに係る部分などを何ら記載も示唆もしていない。
【００２２】
レプリカ・コントローラ７は、アプリケーション５からのアクセス要求に基づき、データ格納装置１７中のデータへのアクセス、及び送信キュー９へのパケット送信要求の追加を行う。さらに、受信キュー７の状態を参照して、受信キュー１１内に格納されている変更要求に対応して、レプリカの更新を指定のタイミングで実行する。レプリカ・コントローラ７は、データ格納装置１７へのアクセスを行う部分と、アクセスの内容等を指示する部分とに分けることも可能である。本発明は、複数のアプリケーション５による衝突、及びアプリケーション５によるデータの変更と受信キュー１１内のデータ変更要求との衝突は取り扱わず、アプリケーション５によるデータ変更の実行と受信キュー１１内のデータ変更要求の実行とは、独立に実施されるものとして扱う。もし、衝突の問題が生じた場合には、従来技術の手法を用いて解決しても、いずれかを無視してもよい。
【００２３】
データ格納装置１７は、レプリカを格納しており、通常のデータベースと同様の機能を有している。すなわち、レプリカ・コントローラ７からの要求に従って、データの作成、検索、参照、及び削除等を行う。
【００２４】
送信キュー９は、パケット送信要求を管理するためのキューである。パケット送信要求は、アプリケーション５により実施されたデータ変更の種類及び内容、更新順序の指定、送信要求作成時のＢＴ数及びＳＢＴ数を含む。このＢＴ数及びＳＢＴ数は、キューを管理するためのデータとして、送信キュー９に含まれる。ＢＴ数は、これまでにアプリケーション５から受けたデータ変更（データ変更要求とも言う）であって、更新順序の指定がバックワード・フラッシュ又は２ウエー・フラッシュであるデータ変更の数であり、レプリカ・コントローラ７が管理する。ＳＢＴ数は、最後にバックワード・フラッシュ又は２ウエー・フラッシュの指定があったデータ変更から現在までのデータ変更の数であり、同じくレプリカ・コントローラ７が管理する。
【００２５】
また、その他の情報としては、ここではコンピュータＢ（３）において受信され且つレプリカの更新実行がなされた最新のデータ変更に係るＢＴ数を管理するための応答確認済みＢＴ数と、同じくコンピュータＢ（３）において受信され且つレプリカの更新実行がなされた最新のデータ変更に係るＳＢＴ数を管理するための応答確認済みＳＢＴ数を含む。これらの情報は、パケット受信装置１５により管理される。
【００２６】
受信キュー１１は、受信したが更新処理を完了していないパケット中の変更要求を管理するためのキューである。変更要求の他に、現在実行可能な変更要求のＢＴ数である処理中ＢＴ数及び現在実行可能な変更要求のＳＢＴ数である処理中ＳＢＴ数、レプリカ・コントローラ７が実行した最新の変更要求に含まれるＢＴ数を表す応答予定ＢＴ数及びレプリカ・コントローラ７が実行した最新の変更要求に含まれるＳＢＴ数を表す応答予定ＳＢＴ数とがある。これらは、レプリカ・コントローラ７により管理される。
【００２７】
パケット送信機１３は、送信キュー９及び受信キュー１１を監視し、必要なパケットを生成して、通信媒体１９にパケットを送信する。パケット送信機１３は、送信キュー９に格納されている送信要求を順次送信するが、従来技術のように送信キュー９内の順番（生成順番）でコンピュータＢ（３）が受信することを保証しない様な態様で送信する。すなわち、送信要求の生成順番で１つのパケットが受信されるのを確認した後に次のパケットを送信するわけではなく、次々に送信してゆき、送信先のコンピュータＢ（３）が受信に失敗した場合には、受信に失敗したパケットを再送する。又は、受信し且つ更新処理が実施されるということが分かるまで、同じパケットを何度も送信するようにしてもよい。その際には、応答確認済みＢＴ数及び応答確認済みＳＢＴ数を使用するとよい。また、送信順番は、送信要求の生成順番に全く無関係になっていてもよい。
【００２８】
パケット送信機１３は、送信キュー９のパケット送信要求を１つ選び、受信キュー１１内の応答予定ＢＴ数及び応答予定ＳＢＴ数と共に、パケットを作成して送信する。応答予定ＢＴ数及び応答予定ＳＢＴ数は、送信先であるコンピュータＢ（３）の送信キューに格納されている応答確認済みＢＴ数及びＳＢＴ数を変更するために用いられる。なお、送信すべき送信要求が送信キュー９に無い場合には、応答予定ＢＴ数及び応答予定ＳＢＴ数のみを送信する。
【００２９】
パケット受信機１５は、パケットを受信し、パケットの内容、送信キュー、及び受信キューの状態を参照して、送信キュー及び受信キューの更新を行う。すなわち、受信したパケットの応答予定ＢＴ数及び応答予定ＳＢＴ数を用いて、送信キュー９の応答確認済みＢＴ数応答確認済みＳＢＴ数を更新する。この更新は、応答予定ＢＴ数＞応答確認済みＢＴ数であれば、応答確認済みＢＴ数及び応答確認済みＳＢＴ数を応答予定ＢＴ数及び応答予定ＳＢＴ数でそれぞれ更新する。もし、応答予定ＢＴ数＝応答確認済みＢＴ数であれば、応答予定ＳＢＴ＞応答確認済みＳＢＴかどうか判断する。もし、この条件が満たされれば、応答確認済みＳＢＴを応答予定ＳＢＴで更新する。以上の条件以外の場合には、応答確認済みＢＴ及びＳＢＴの更新は行わない。
【００３０】
受信したパケットには、重複が存在するかもしれない。よって、パケット受信機１５は、受信したパケットの変更要求に含まれるＢＴ数及びＳＢＴ数を参照して、受信キュー９に既に格納されている変更要求で同じＢＴ数及びＳＢＴ数の変更要求が存在する場合には、後から送られてきたパケット内の変更要求を破棄する。
【００３１】
さらに、受信したパケットに係る変更要求を既に実行してしまった場合も存在する。よって、受信キュー１１を参照して、応答予定ＢＴ数より小さいＢＴ数を含む変更要求、及び応答予定ＢＴ数と同じＢＴ数を含む変更要求であって応答予定ＳＢＴ数より小さいＳＢＴ数を含む変更要求を破棄する。
【００３２】
なお、応答確認済みＢＴ≧送信要求内のＢＴ、又は応答確認済みＢＴ＝送信要求内のＢＴ且つ応答確認済みＳＢＴ≧送信要求内のＳＢＴとなっている送信要求は送信キュー９から削除することができる。この削除を実行するのは、パケット受信機１５又はパケット送信機１３のいずれでもよい。
【００３３】
また、受信したパケットに係る変更要求のＢＴ及びＳＢＴを参照して、受信キュー１１内の変更要求の順番をＳＢ及びＳＢＴの小さい順で並び替える動作を行うが、これもパケット受信機１５又はレプリカ・コントローラ７のいずれが実施してもよい。
【００３４】
通信媒体１９は、無線でも有線でも構わない。また、これらの組み合わせでもよい。本発明の特徴として、信頼性の低いネットワークを介しての通信でも対処することができる。
【００３５】
以上説明したＢＴ数、ＳＢＴ数、応答予定ＢＴ数、応答予定ＳＢＴ数、応答確認済みＢＴ数、及び応答確認済みＳＢＴ数の関係及び更新について、図２を用いてまとめておく。
【００３６】
図２では、コンピュータＡ（１）の受信キュー１１Ａ（ＡはコンピュータＡ内の構成要素であることを示す。同じくＢはコンピュータＢ内の構成要素であることを示す）に格納されたパケット１に係る変更要求をレプリカ・コントローラ７Ａが実行したところからの動作を示している。変更要求を実行するとレプリカ・コントローラ７は、受信キュー１１Ａの応答予定ＢＴ数及び応答予定ＳＢＴ数をパケット１のＢＴ数及びＳＢＴ数で変更する（ステップ１０００）。この更新された応答予定ＢＴ数及び応答予定ＳＢＴ数は、コンピュータＡ（１）が次にコンピュータＢ（３）に送信すべく送信キュー９Ａ内に用意しているパケット２に取り込まれる（ステップ１１００）。パケット送信機１３Ａがこのパケット２を送信すると（ステップ１２００）、コンピュータＢ（３）のパケット受信機１５Ｂがこれを受信し、パケット２'として受信キュー１１Ｂに取り込む。ここで、パケット受信機１５Ｂは、上で述べたように、パケット２'内の変更要求に係る応答予定ＢＴ数及び応答予定ＳＢＴ数により、送信キュー９Ｂの応答確認済みＢＴ数及び応答確認済みＳＢＴ数を更新すべきかを判断する。ここでは、上で述べた条件のいずれかが満たされたとして、応答確認済みＢＴ数及び応答確認済みＳＢＴ数は更新される（ステップ１３００）。今度は、応答確認済みＢＴ数と送信キュー９Ｂ内の変更要求のＢＴ数、応答確認済みＳＢＴ数と送信キュー９Ｂ内の変更要求のＳＢＴ数が比較され（ステップ１４００）、両者共に一致するパケット１'が破棄される（ステップ１５００）。このように、送信キュー９Ｂからパケット１'が破棄されると、二度とコンピュータＡ（１）に送信されなくなる。
【００３７】
次に、図３乃至図６を用いてレプリカ・コントローラ７が受信キュー１１内の変更要求をいかに実行していくか、について説明する。まず、図３を用いてＢＴ数とＳＢＴ数の付け方について説明しておく。図３では、変更要求に含まれる更新順序の指定がオーディナリである場合にはＯ、バックワード・フラッシュの場合にはＢ、２ウエー・フラッシュの場合にはＴ、フォワード・フラッシュの場合にはＦと記している。また、各指定における出現順番を添字にしている。最初は、ＢＴ数及びＳＢＴ数とも０で初期化されている。そして、（１）でアプリケーション５がオーディナリを指定すると、データ変更Ｏ１には（０，０）が付される。なお（ＢＴ，ＳＢＴ）である。そうすると、ＳＢＴ数は１インクリメントされる。（２）で、再度オーディナリが指定されると、データ変更Ｏ２には（０，１）が付される。これによりＳＢＴ数はさらに１インクリメントされる。よって、（３）でバックワード・フラッシュが指定されると、データ変更Ｂ１には（０，２）が付される。バックワード・フラッシュが発生するとＳＢＴ数はクリアされ、ＢＴ数が１インクリメントされる。
【００３８】
（４）で２ウエー・フラッシュが指定されると、データ変更Ｔ１には（１，０）が付される。２ウエー・フラッシュが指定された場合も、ＳＢＴ数をクリアして、ＢＴ数を１インクリメントする。（５）でオーディナリが指定されると、データ変更Ｏ３には（２，０）が付される。この指定によりＳＢＴ数は１インクリメントされる。（６）でさらにオーディナリが指定されると、データ変更Ｏ４には（２，１）が付される。さらにＳＢＴ数は１インクリメントされる。（７）でフォワード・フラッシュが指定されると、データ変更Ｆ１には（２，２）が付される。定義より、ＳＢＴ数は１インクリメントされる。
【００３９】
図３のようなデータ変更要求を含むパケットがパケット送信機１３から送信され、コンピュータＢ（３）で受信された場合の処理を、図４を用いて説明する。パケット受信機１５Ｂがパケットを受信した順番は、図４に示すように、Ｏ１，Ｂ１，Ｏ２，Ｔ１，Ｏ４，Ｆ１、Ｏ３の順である。但し、図４の例では１つずつデータ変更要求を受信し、処理していくものとする。もし、複数のデータ変更要求が受信キュー１１Ｂに貯まった場合には、上で述べたようにＢＴ数及びＳＢＴ数の小さい順にデータ変更要求を並び替える。図４は単なる例であっていくつかのパケットをまとめて受信するようなことがあってもよい。
【００４０】
最初に、処理中ＢＴ数及び処理中ＳＢＴ数を共に０に初期化しておく。そして（１）で、パケット受信機１５Ｂはデータ変更Ｏ１を受信して受信キュー１１Ｂに入れる。受信キュー１１Ｂの状態は、図５の（１）の左側の状態になる。そして、処理中ＢＴ数及び処理中ＳＢＴ数、並びにデータ変更Ｏ１のＢＴ数及びＳＢＴ数を用いて、データ変更Ｏ１を実行してよいのかをレプリカ・コントローラ７Ｂが判断する。判断基準は以下のとおりである。
（ａ）データ変更要求の更新順序の指定がオーディナリ又はバックワード・フラッシュの場合
データ変更要求のＢＴ数≦処理中ＢＴ数
であれば実行可能である。
（ｂ）データ変更要求の更新順序の指定がフォワード・フラッシュ又は２ウエー・フラッシュの場合
データ変更要求のＢＴ数＝処理中ＢＴ数 且つ
データ変更要求のＳＢＴ数＝処理中ＳＢＴ数
であれば実行可能である。
【００４１】
上のような判断基準を図４の（１）に当てはめてみると、オーディナリの指定でデータ変更要求のＢＴ数は０で処理中ＢＴ数も０であるから実行可能である。よって、レプリカ・コントローラ７Ｂはデータ変更Ｏ１を実行する。図４の（１）では「変更実行」の行に○が記されている。
【００４２】
次に当該データ変更Ｏ１を受信キュー１１Ｂから削除してもよいか判断する。この判断は、データ変更要求のＢＴ数＝処理中ＢＴ数、且つデータ変更要求のＳＢＴ数＝処理中ＳＢＴ数であるかにより行われる。もし、上記条件が満たされた場合には、処理中ＢＴ数及び処理中ＳＢＴ数の値も更新する。更新方法は、以下のとおりである。
（ａ）データ変更要求の更新順序の指定が、オーディナリ又はフォワード・フラッシュの場合
処理中ＳＢＴ数＝処理中ＳＢＴ数＋１
（ｂ）データ変更要求の更新順序の指定が、バックワード・フラッシュ又は２ウエー・フラッシュの場合
処理中ＢＴ数＝処理中ＢＴ数＋１
処理中ＳＢＴ数＝０
【００４３】
上記判断基準を満たしているので、レプリカ・コントローラ７Ｂはデータ変更Ｏ１を受信キュー１１Ｂから削除することができる。よって図４では「削除」の欄に○が記されている。そして、データ変更Ｏ１はオーディナリなので、上記更新方法のように処理中ＳＢＴ数が１インクリメントされる。図５の（１）の矢印の先に示したように、受信キュー１１Ｂにデータ変更要求は無くなる。
【００４４】
次に（２）で、パケット受信機１５Ｂはデータ変更Ｂ１を受信する。バックワード・フラッシュであるから、データ変更Ｂ１のＢＴ数と処理中ＢＴ数を比較して、上記判断基準を満たしていると判断できる。よって、レプリカ・コントローラ７Ｂはデータ変更Ｂ１を実行する（図４の（２）の「変更実行」の行に○が記されている）。しかし，データ変更Ｂ１のＳＢＴ数と処理中ＳＢＴ数は異なるので、当該データ変更Ｂ１を受信キュー１１Ｂから削除することはできない。図５の（２）に示したように、パケット受信機１５Ｂにより受信されたデータ変更Ｂ１は受信キュー１１Ｂに残る。しかし、データ変更Ｂ１の全てを受信キュー１１Ｂに残しておく必要はない。データ変更要求は実行したわけであるから、データ変更に直接関係するデータは削除することができ、それ以外のＢＴ数及びＳＢＴ数及び更新順番の指定等のデータ変更要求の基本的情報部分のみを残せばよい。図５ではそのような場合には点線の四角を用いる。よってＢ１が点線で囲まれている。
【００４５】
（３）で、パケット受信機１５Ｂはデータ変更Ｏ２を受信する。データ変更Ｏ２のＢＴ数は０だがＳＢＴ数は１であるから、データ変更Ｂ１のＳＢＴ数より小さい。よって、図５の（３）で示したように、パケット受信機１５Ｂはデータ変更Ｏ２を最初にデータ変更Ｂ１を２番目にするように受信キュー１１Ｂを更新する。レプリカ・コントローラ７Ｂは、データ変更Ｏ２のＢＴ数が０で処理中ＢＴ数の０であるから、データ変更Ｏ２を実行可能と判断し、実行する（図４の（３）の「変更実行」に○が記されている）。さらに、レプリカ・コントローラ７Ｂは、データ変更Ｏ２のＢＴ数と処理中ＢＴ数が一致し、且つデータ変更Ｏ２のＳＢＴ数と処理中ＳＢＴ数が一致するため、データ変更Ｏ２を削除する（図４の（３）の「削除」の行には○が記されている）。
【００４６】
さらに、更新順序の指定がオーディナリであり、且つＢＴ数と処理中ＢＴ数及びＳＢＴ数と処理中ＳＢＴ数が一致するので、処理中ＳＢＴ数が１インクリメントされる。ここでは、処理中ＢＴ数０、処理中ＳＢＴ数２となる。これにより、受信キュー１１Ｂに残ったデータ変更Ｂ１のＢＴ数とＳＢＴ数がそれぞれ処理中ＢＴ数及び処理中ＳＢＴ数に一致するようになる。そこで、レプリカ・コントローラ７Ｂはデータ変更Ｂ１についても受信キュー１１Ｂから削除する。図４の（３）から（２）への矢印にてデータ変更Ｂ１が削除されることを示している。また、図５の（３）の右側で受信キュー１１Ｂが空になったことを示している。さらに、削除されたデータ変更の更新順序の指定がバックワード・フラッシュであり、且つＢＴ数と処理中ＢＴ数及びＳＢＴ数と処理中ＳＢＴ数が一致するので、レプリカ・コントローラ７Ｂは処理中ＢＴ数を１インクリメントし、処理中ＳＢＴ数をクリアする。
【００４７】
（４）でパケット受信機１５Ｂはデータ変更Ｔ１を受信する。レプリカ・コントローラ７Ｂは、データ変更Ｔ１のＢＴ数と処理中ＢＴ数が一致し、且つデータ変更Ｔ１のＳＢＴ数と処理中ＳＢＴ数が一致するので、データ変更Ｔ１を実行する（図４の（４）の「変更実行」の行には、○が記されている）。さらに、データ変更Ｔ１を削除することも可能であることが分かるので、レプリカ・コントローラ７Ｂはデータ変更Ｔ１を受信キュー１１Ｂから削除する（図４の（４）の「削除」の行にも○が記されている）。図５の（４）でも、一旦受信キュー１１Ｂに入れられたデータ変更Ｔ１が削除されて、受信キュー１１Ｂが空になる様子を示している。データ変更Ｔ１は２ウエー・フラッシュであるから、処理中ＢＴ数を１インクリメントし、処理中ＳＢＴ数をクリアする。
【００４８】
（５）において、パケット受信機１５Ｂはデータ変更Ｏ４を受信する。レプリカ・コントローラ７Ｂは、更新順番の指定がオーディナリであり、データ変更Ｏ４のＢＴ数が２で処理中ＢＴ数も２であるから、データ変更Ｏ４を実行する（図４の（５）の「変更実行」の行に○が記されている）。しかし、処理中ＳＢＴ数とデータ変更Ｏ４のＳＢＴ数は一致しないので、受信キュー１１Ｂからこのデータ変更Ｏ４を削除することはできない。図５の（５）では、実行は行ったので点線で囲まれたデータ変更Ｏ４が受信キュー１１Ｂに残ることを示している。
【００４９】
（６）において、パケット受信機１５Ｂはデータ変更Ｆ１を受信する。パケット受信機１５Ｂはデータ変更Ｆ１のＢＴ数及びＳＢＴ数から、受信キュー１１Ｂにおいてデータ変更Ｏ４の後ろにデータ変更Ｆ１を追加する。レプリカ・コントローラ７Ｂは、データ変更Ｆ１の実行が可能かどうか検査するが、データ変更Ｆ１のＳＢＴ数と処理中ＳＢＴ数が一致しないので、実行することができない。当然受信キュー１１Ｂから削除することもできない。図５の（６）には、受信キュー１１Ｂに２つのデータ変更要求が貯まった状態を示している。
【００５０】
（７）において、パケット受信機１５Ｂはデータ変更Ｏ３を受信する。パケット受信機１５Ｂは、データ変更Ｏ３のＢＴ数及びＳＢＴ数から、受信キュー１１Ｂの順番を入れ替える。図５の（７）に示したように、データ変更Ｏ３が１番目、データ変更Ｏ４が２番目、データ変更Ｆ１が３番目に並べられる（図５の（７）の一番左側参照）。レプリカ・コントローラ７Ｂは、データ変更Ｏ３のＢＴ数と処理中ＢＴ数が一致するため、データ変更Ｏ３を実行する（図４の（７）の「変更実行」の行に○が記されている）。また、データ変更Ｏ３のＳＢＴ数と処理中ＳＢＴ数も一致するため、レプリカ・コントローラ７Ｂはデータ変更Ｏ３を削除する（図５の（７）の左から２番目参照）。図４の（７）の「削除」の行には○が記されている。データ変更Ｏ３の更新順序の指定はオーディナリであり、ＢＴ数と処理中ＢＴ数並びにＳＢＴ数と処理中ＳＢＴ数が一致するので、レプリカ・コントローラ７Ｂは処理中ＳＢＴ数を１インクリメントする。そうすると、受信キュー１１Ｂ内のデータ変更Ｏ４のＢＴ数及びＳＢＴ数にそれぞれ一致するようになる。そこで、レプリカ・コントローラ７Ｂは、受信キュー１１Ｂからデータ変更Ｏ４を削除する（図５の（７）の左から３番目参照）。図４では（７）から（５）への矢印で削除が可能になったことを示している。
【００５１】
さらに、データ変更Ｏ４のＢＴ数と処理中ＢＴ数、並びにデータ変更Ｏ４のＳＢＴ数と処理中ＳＢＴ数が一致し、データ変更Ｏ３の更新順序の指定はオーディナリであるから、レプリカ・コントローラ７Ｂは処理中ＳＢＴ数を１インクリメントする。そうすると、（６）で実行することができなかったデータ変更Ｆ１のＢＴ数及びＳＢＴ数と処理中ＢＴ数及び処理中ＳＢＴ数がそれぞれ一致するようになる。レプリカ・コントローラ７Ｂはデータ変更Ｆ１を実行し、且つ実行後データ変更Ｆ１を受信キュー１１Ｂから削除する。図５の（７）の右端は最後には受信キュー１１Ｂが空になることを示している。また、図４の（７）から（６）への点線矢印が、実行が可能になり且つ削除も可能になったことを示している。
【００５２】
以上の処理を、図６にまとめて示している。まず、受信キュー１１中の今受信した変更要求又はステップ２２００により指示を受けた場合にはステップ２２００で指定された変更要求が実行可能か否か判断する（ステップ２１００）。これは、変更要求に含まれる更新順番の指定とＢＴ数及びＳＢＴ数により決定される。もし、実行不可能であれば、受信キュー１１の次の変更要求へ移行する（ステップ２２００）。受信キュー１１に次の変更要求が存在しない場合には、受信するまで待つ。図６では明示していないが、受信キュー１１内は変更要求を受信するごとに、ＢＴ数及びＳＢＴ数の小さい順に並び替える。もし、変更要求が実行可能であれば、当該変更要求を実行する（ステップ２３００）。そして、受信キュー１１から削除可能な変更要求があるか判断する（ステップ２４００）。もし、削除可能な変更要求がある場合には、当該変更要求を削除する（ステップ２６００）。このステップ２６００においては、レプリカ・コントローラ７は受信キュー１１内の応答予定ＢＴ数及び応答予定ＳＢＴ数の更新も、削除した変更要求のＢＴ数及びＳＢＴ数を用いて実施する。削除した場合には、処理中ＢＴ数及び処理中ＳＢＴ数を必要に応じて変更する。もし、削除可能な変更要求がない場合には、ステップ２２００に移行する。削除を実行した後に、処理が完了したか判断し、処理が終了していない場合にはステップ２２００に移行する。処理が完了したと判断される場合には、ステップ２７００で処理を終了する。
【００５３】
以上のように、パケット受信機１１は、レプリカ・コントローラ７は変更要求を受信するごとに受信キュー内の順番を更新し、且つ実行可能な変更要求か判断することにより各変更要求実行のタイミング／順序を決定している。この動作は受信順番に全く関係ない。例え変更要求がその生成順に受信されなくとも、実行できる変更要求を判別且つ実行することができるので、より処理効率も高くなる。また、実行した変更要求は受信キュー１１から削除できる場合もあるので、メモリの使用効率も向上する。また、実行した変更要求で削除できない場合であっても、当該変更要求の基本的情報のみを残しておくようにすれば、さらにメモリ効率は向上する。
【００５４】
図１の情報共有システムでは、２つのコンピュータしか示していないが、３以上設けることも可能である。但し、本発明を実施するには、各コンピュータ対ごとに上記の構成を必要とする。
【００５５】
以上の実施例は様々に変更可能である。各構成要素は同一のコンピュータ上になくともよい。パケット受信機１５とレプリカ・コントローラ７の機能は必要に応じていずれかの要素に含めることができ、一体化することも可能である。同様に、データ格納装置１７とレプリカ・コントローラ７が一体化されていてもよい。また、上の実施例では変更要求の実行と削除を独立に処理していたが、同時に行うように変形することも可能である。この際には、応答予定ＢＴ数及び応答予定ＳＢＴ数の更新のために別途ＢＴ数及びＳＢＴ数を保存しておく必要が生じ得る。また、応答確認済みＢＴ数及び応答確認済みＳＢＴ数を管理しないで、応答予定ＢＴ数及び応答予定ＳＢＴ数を受信するごとに、同じ数のＢＴ数及びＳＢＴ数を有する変更要求を削除するように変形することも可能である。送信及び受信キューはメインメモリ上に設けても、専用のメモリを用いてもよい。また、実行済の変更要求は受信キューには置かず、別のキュー又は表を用いて処理中ＢＴ数泳ぎ処理中ＳＢＴ数を更新してもよい。さらに、処理中ＳＢＴ数を管理しないで必要に応じて受信キュー中の同一のＢＴ数を持つ変更要求を数えてもよい。
【００５６】
【効果】
レプリカの更新の際の通信効率を改善する方法及び装置を提供することができた。
【００５７】
また、レプリカの更新の際のメモリ使用量を削減する方法及び装置を提供することもできた。
【００５８】
さらに、レプリカの更新のための通信が途中で切断された場合であっても、変更要求によるレプリカの更新がどこまで実行されたか確認することができる方法及び装置を提供することもできた。
【００５９】
さらに、レプリカ更新の順序を明示的に指定できるようにすることもできた。
【００６０】
例えば大画像データを複数枚リプリケートし、１つの画像データ内のデータを複数に分割してデータ転送を行う例を考える。この場合、同一の画像データ内の転送順序を制御する必要は無いが、リプリケート中に通信回線が意図的又は不意に切断された場合でも、全てのデータがリプリケートされている画像データをなるべく多く得ることが望ましい。従来技術のＦＩＦＯ順序でリプリケートされる場合には各画像データの末尾のデータがリプリケートされればその画像データはリプリケートされていることがわかるが、転送オーバーヘッドが多大である。また、リプリケート全体がバッチ処理的にリプリケートされる場合でも、途中で回線が切断されると、どの画像データについても全てのデータがそろったことが保証できない。本発明では、１つの画像データの末尾でフォワード・フラッシュを指定すれば同一画像内のデータ転送については送信順番に制約はなく、画像間のデータ転送順序を制御することも可能になる。この場合、末尾データの更新が実行されれば、当該画像データ全体がリプリケートされたことを保証することができるようになる。
【００６１】
また、セールスマンの個人情報とそのセールスマンの月例売上表をリプリケートする例を考える。個人情報には、社員番号、氏名、所属部課、電話番号が含まれ、月例売上表には、社員番号と毎日の売上高が含まれるものとする。売上表出力プログラムは、月売上表から社員番号を得てその社員番号から個人情報を検索し、対応する氏名、所属部課、電話番号を出力する。このような例で、月例売上表があるのに、対応する個人情報が存在しないと出力プログラムは月例売上表に対応する氏名等を出力することができない。このように依存関係がある複数のデータをリプリケートする場合、リプリケート中に回線が切断されても依存関係に矛盾が生じないように、依存関係があるデータ間のリプリケートの順序を保証したい場合がある。従来技術のＦＩＦＯ順序でリプリケートする場合、個人情報、月例売上表の順でデータを生成することにより、リプリケートの順を保証することができる。しかし、転送順序を保証する必要の無い他のデータのリプリケートもＦＩＦＯ順序で行われることになり、不必要な転送オーバヘッドを生じる、また、リプリケート全体がバッチ処理される場合、リプリケートが完全に終了せずに回線が切断された時にその時点でのリプリケートの順序を保証することができない。本発明を利用して、最後の個人情報の生成時に２ウエー・フラッシュを指定し、その後に月例売上表を生成することにより個人情報と月例売上表のリプリケートの順序を保証することができる。その際に生じる転送オーバヘッドも必要最小限ですむ。
【図面の簡単な説明】
【図１】本発明の情報共有システムを示す図である。
【図２】変更要求のＢＴ数及びＳＢＴ数、応答予定ＢＴ数及び応答予定ＳＢＴ数、応答確認済みＢＴ数及び応答確認済みＳＢＴ数の関係を表すフロー図である。
【図３】ＢＴ数及びＳＢＴ数の変更要求への付け方を示す図である。
【図４】変更要求及び削除の実行を説明するための例を示す図である。
【図５】図４の場合の受信キューのようすを示す図である。
【図６】変更要求の実行及び削除の実行の処理フローを示す図である。
【符号の説明】
１００ 情報共有システム
１ コンピュータＡ
３ コンピュータＢ
５ アプリケーション
７ レプリカ・コントローラ
９ 送信キュー
１１ 受信キュー
１３ パケット送信機
１５ パケット受信機
１７ データ格納装置
１９ 通新媒体
【発明の属する技術分野】
本発明は、各コンピュータが共有データのレプリカを有し、データ変更をコンピュータ相互に通知しあうことによりレプリカの内容の同一性を保持するシステムに関し、より詳しくは、レプリカ更新動作の順序制御に関する。
【０００２】
【従来の技術】
従来の情報共有システムでは、以下のような方法でレプリカの更新の順序が決定されていた。
（１）コンピュータ間の通信回線が常に接続されていることを前提とする情報共有システムの場合、データの更新を、当該更新が発生する度に通知しあう機構を有していることが多い。この場合、レプリカの更新はデータ変更が起きるたびに変更の順序と同じ順序で行われることが保証される。以下、このような順序をＦＩＦＯ順序と呼ぶ。しかし、オフィス等に設置されたコンピュータ内のデータを、オフィス外で携帯端末に取り込み、閲覧・編集するような場合も存在する。この携帯端末等の場合によく用いられる無線公衆回線は、通常のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）と比較すると回線の品質が悪く、パケット転送の失敗が頻繁に起こる。一般に転送順序に関する制約が強ければ強いほど、転送オーバーヘッドも大きくなる。最も強い制約を伴うＦＩＦＯ順序での転送は、大きな転送オーバーヘッドがかかる。無線公衆回線は回線使用料も高価なので、この転送オーバーヘッドは大きな問題である。
（２）Ｌｏｔｕｓ Ｎｏｔｅｓ（Ｌｏｔｕｓ社の商標）のような、回線の非接続時の操作を仮定した情報共有システムでは、レプリカの更新は、バッチ処理のように全ての更新が一括して行われる。このようなシステムでは、更新中データにアクセスできない。通信回線の切断等によりレプリカの更新が途中で中断された場合、更新の順序は一般に不定である。すなわち、更新がどこまで実行されたか分からなくなってしまう。
【０００３】
ＥＰ０７９４６４６（特開平９−２４６４２号）は、以下の事項を開示している。移動通信ネットワークを介して接続可能な複数のコンピュータ・システム上に保持される、共用データ・ファイルのコピーを管理するデータ管理システムであって、当該データ管理システムは、共用データ・ファイルの各コピーに関連付けられ、そのコピーに対して実行される変更の記録を保持するロギング手段と、移動通信ネットワークへの接続を介して、共用データ・ファイルの他のコピーに対して保持される記録を取り出すための取り出し手段と、取り出された記録を併合し、変更の順序を生成する併合手段と、予め定義された規則を変更順序に適用し、変更順序内での衝突を解決する衝突解決手段と、衝突解決済みの変更順序にもとづき、共用ファイルのコピーを変更する手段とを含む。なお、ここでいう衝突とは、同一の版のデータに対して並列に行われる複数のデータ変更を意味すると考えられる。また、衝突の解決とは、衝突を生じている複数のデータ変更を一定の順番に並べ直すことを意味すると考えられる。このシステムは変更の衝突を解決するためのシステムであり、変更の衝突を解決するためには衝突が発生したか否か判断する時までに全ての変更に関する情報がそろっていなければならない。すなわち、変更の衝突を解決した後でなければ、共用ファイルのコピーを変更することができない。よって、１つでも変更に関する情報を取得できなければ変更処理を実行することはできない。また、受信した変更に関する情報を記憶するためのメモリについての負担も大きくなる。これは携帯端末のように通信に使用できるメモリ容量が少ない場合には大きな問題となる。さらに、メモリ容量が足りないために行われる再送の問題も生じる。
【０００４】
【発明が解決しようとする課題】
以上のように従来技術では、レプリカの更新の際の通信効率、メモリ使用量、及び途中で通信回線が切断した時の処理に問題があった。
【０００５】
よって、本発明の目的は、レプリカの更新の際の通信効率を改善する方法及び装置を提供することである。
【０００６】
また、レプリカの更新の際のメモリ使用量を削減する方法及び装置を提供することも目的である。
【０００７】
さらに、レプリカの更新のための通信が途中で切断された場合であっても、変更要求によるレプリカの更新がどこまで実行されたか確認することができる方法及び装置を提供することも目的である。
【０００８】
さらに、レプリカ更新の順序を明示的に指定できるようにすることも目的である。
【０００９】
【課題を解決するための手段】
本発明は、共有データのレプリカを有し、データ変更を他のコンピュータと相互に通知しあうことによりレプリカの内容の同一性保持を図るコンピュータであって、他のコンピュータからレプリカ内のデータの変更要求を受信する手段と、変更要求の受信順番にかかわらず、受信した変更要求によるレプリカの更新実行のタイミングを、変更要求に含まれる情報を用いて、変更要求の受信毎に制御する制御手段とを有する。変更要求の受信順番、すなわち、他のコンピュータの送信順番とは無関係に、変更要求によるレプリカの更新実行のタイミングを決定できるため、通信効率も改善され且つメモリ使用量も削減される。
【００１０】
上記の変更要求に含まれる情報は、変更順番の指定なし（実施例におけるオーディナリ）、当該変更要求より前の全ての変更要求を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行するという第１の指定（実施例におけるフォワード・フラッシュ）、当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第２の指定（実施例におけるバックワード・フラッシュ）、又は当該変更要求より前の全ての変更を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行し且つ当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第３の指定（２ウエー・フラッシュ）を含むようにすることができる。このようにレプリカ更新の順序を明示的に指定することもできる。
【００１１】
上記の変更要求に含まれる情報は、これまでに生成された、第２又は第３の指定を含む変更要求の数（第１の数：実施例におけるＢＴ数）、及び最後に第２又は第３の指定を含む変更要求が生成された後に生成された変更要求の数（第２の数：実施例におけるＳＢＴ数）、をさらに含むようにすることも考えられる。このようにすると、途中で通信回線が切断されてもどの変更要求まで、受信され且つ更新を実行されたか確認できる機構を構築することができるようになる。
【００１２】
また、上記制御手段は、第１及び第２の数にそれぞれ対応し、レプリカの更新実行のタイミングを規定する第１及び第２の管理値（実施例における処理中ＢＴ数及び処理中ＳＢＴ数）を保持するようにすることも可能である。より簡単に更新実行のタイミングを決定できるようになる。
【００１３】
さらに、上記制御手段は、変更要求によるレプリカの更新が実行された場合に、当該変更要求に含まれる第１及び第２の数を第３の数及び第４の数（実施例では応答予定ＢＴ数及び応答予定ＳＢＴ数）として記憶するように構成することも可能である。さらに、上記のコンピュータが、他のコンピュータへレプリカ内のデータの変更要求を送信する手段をさらに含み、上記制御手段は、送信する変更要求に、第３の数及び第４の数を含ませるように構成することも考えられる。このようにすれば、通信回線が途中で切断された場合であっても、送信元はどの変更要求を再送すればよいか判断することができ、さらに、送信元はどの変更要求を破棄してもよいかということを判断することも可能になる。
【００１４】
以上は受信側のコンピュータの構成であった。送信側のコンピュータは、レプリカ内のデータの変更を命令し、当該データの変更に対して変更順序に関する情報を指定する手段と、データの変更の命令に対応し且つ変更順序に関する情報を含む変更要求を生成する手段と、変更要求の生成順序と送信順序の一致を保証しないような態様で、変更要求を送信する手段とを有する。このようにデータの変更ごとに変更順序に関する情報を明示的に指定し、受信側でその情報を使用可能なように変更要求に含めて送る。また、通信効率を上げるため、変更要求の生成順序と送信順序の一致を保証しないような態様で送信する。途中で回線が切断され、再接続及び再送するような場合も含む。
【００１５】
上記変更要求は、上で述べた変更要求に含まれる情報と同一の情報を含むようにすることも可能である。
【００１６】
また、上記コンピュータは、他のコンピュータからレプリカ内のデータの変更要求を受信する手段をさらに含み、受信した変更要求が、送信した変更要求によるレプリカの更新が送信先の他のコンピュータで実行されたことを示す応答情報（実施例では応答予定ＢＴ数及び応答予定ＳＢＴ数）を含むように構成することもできる。これにより、再送する必要の無い変更要求を確定することができる。すなわち、応答情報を参照して、送信した変更要求を削除するか判断する手段をさらに含むようにすることができる。
【００１７】
１つのコンピュータは以上述べた送信側及び受信側双方の構成を有することも可能であり、且つそのようなコンピュータにより情報共有システムを構築することもできる。
【００１８】
以上はコンピュータの装置構成を示したわけであるが、以上のようなコンピュータにおいて実施される処理は、プログラムとして実施することも可能である。この場合、プログラムは、フロッピーディスクやＣＤ−ＲＯＭ、その他の記憶媒体に記憶される。
【００１９】
【発明の実施の形態】
図１に本発明の情報共有システム全体の構成図を示す。情報共有システム１００は、コンピュータＡ（１）及びコンピュータＢ（３）から構成されている。コンピュータの数は２に限定されないが、以下の説明を分かりやすくするためにここでは２つであるとする。また、本発明に係る構成要素はコンピュータＡ（１）及びコンピュータＢ（３）で同一であり、図１では代表してコンピュータＡ（１）に各構成要素を示している。各コンピュータは、１以上のアプリケーション５とレプリカ・コントローラ７と送信キュー９と受信キュー１１とパケット送信機１３とパケット受信機１５とデータ格納装置１７とを含む。
【００２０】
アプリケーション５は、レプリカ・コントローラ７に対して、データの生成、検索、参照、及び削除等の処理の要求を行う。そして、このデータの生成及び削除等、データを変更する要求の際には、レプリカの更新順序の指定を行う。本発明におけるレプリカの更新順序の指定は、オーディナリ（Ｏｒｄｉｎａｒｙ）、フォワード・フラッシュ（Ｆｏｒｗａｒｄ Ｆｌｕｓｈ）、バックワード・フラッシュ（Ｂａｃｋｗａｒｄ Ｆｌｕｓｈ）、２ウエー・フラッシュ（Ｔｗｏ ｗａｙ Ｆｌｕｓｈ）のいずれかである。データの変更以外のアクセスは、通常のデータベースのアクセスと同じであるから、詳しい説明は省略する。
【００２１】
オーディナリは、当該変更の際に、対応するレプリカの更新順序に関する制約はないということを示すためのものである。フォワード・フラッシュは、当該データ変更に対応したレプリカの更新は、この変更以前に行われた全ての変更をレプリカに反映させた後に行うということを示すためのものである。バックワード・フラッシュは、当該データ変更より後のデータ変更は、この変更をレプリカに反映させた後に、レプリカに反映するということを示すためのものである。２ウエー・フラッシュは、フォワード・フラッシュ及びバックワード・フラッシュの両方の制約を指定するためのものである。メッセージ送信／受信の順序の指定という点では、上記のような４種類の指定は、例えば ”Ａｎ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ Ｆ−ｃｈａｎｎｅｌｓ，” Ｍｏｈａｎ Ａｈｕｊａ， ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｐａｒａｌｅｌｌ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ， Ｖｏｌ． ４， Ｎｏ． ６， Ｊｕｎｅ １９９３． に記載されている。しかし、この論文はその内容の情報共有システムへの適用は何ら記載も示唆もしていないし、以下に述べる送信キュー及び受信キューに係る部分などを何ら記載も示唆もしていない。
【００２２】
レプリカ・コントローラ７は、アプリケーション５からのアクセス要求に基づき、データ格納装置１７中のデータへのアクセス、及び送信キュー９へのパケット送信要求の追加を行う。さらに、受信キュー７の状態を参照して、受信キュー１１内に格納されている変更要求に対応して、レプリカの更新を指定のタイミングで実行する。レプリカ・コントローラ７は、データ格納装置１７へのアクセスを行う部分と、アクセスの内容等を指示する部分とに分けることも可能である。本発明は、複数のアプリケーション５による衝突、及びアプリケーション５によるデータの変更と受信キュー１１内のデータ変更要求との衝突は取り扱わず、アプリケーション５によるデータ変更の実行と受信キュー１１内のデータ変更要求の実行とは、独立に実施されるものとして扱う。もし、衝突の問題が生じた場合には、従来技術の手法を用いて解決しても、いずれかを無視してもよい。
【００２３】
データ格納装置１７は、レプリカを格納しており、通常のデータベースと同様の機能を有している。すなわち、レプリカ・コントローラ７からの要求に従って、データの作成、検索、参照、及び削除等を行う。
【００２４】
送信キュー９は、パケット送信要求を管理するためのキューである。パケット送信要求は、アプリケーション５により実施されたデータ変更の種類及び内容、更新順序の指定、送信要求作成時のＢＴ数及びＳＢＴ数を含む。このＢＴ数及びＳＢＴ数は、キューを管理するためのデータとして、送信キュー９に含まれる。ＢＴ数は、これまでにアプリケーション５から受けたデータ変更（データ変更要求とも言う）であって、更新順序の指定がバックワード・フラッシュ又は２ウエー・フラッシュであるデータ変更の数であり、レプリカ・コントローラ７が管理する。ＳＢＴ数は、最後にバックワード・フラッシュ又は２ウエー・フラッシュの指定があったデータ変更から現在までのデータ変更の数であり、同じくレプリカ・コントローラ７が管理する。
【００２５】
また、その他の情報としては、ここではコンピュータＢ（３）において受信され且つレプリカの更新実行がなされた最新のデータ変更に係るＢＴ数を管理するための応答確認済みＢＴ数と、同じくコンピュータＢ（３）において受信され且つレプリカの更新実行がなされた最新のデータ変更に係るＳＢＴ数を管理するための応答確認済みＳＢＴ数を含む。これらの情報は、パケット受信装置１５により管理される。
【００２６】
受信キュー１１は、受信したが更新処理を完了していないパケット中の変更要求を管理するためのキューである。変更要求の他に、現在実行可能な変更要求のＢＴ数である処理中ＢＴ数及び現在実行可能な変更要求のＳＢＴ数である処理中ＳＢＴ数、レプリカ・コントローラ７が実行した最新の変更要求に含まれるＢＴ数を表す応答予定ＢＴ数及びレプリカ・コントローラ７が実行した最新の変更要求に含まれるＳＢＴ数を表す応答予定ＳＢＴ数とがある。これらは、レプリカ・コントローラ７により管理される。
【００２７】
パケット送信機１３は、送信キュー９及び受信キュー１１を監視し、必要なパケットを生成して、通信媒体１９にパケットを送信する。パケット送信機１３は、送信キュー９に格納されている送信要求を順次送信するが、従来技術のように送信キュー９内の順番（生成順番）でコンピュータＢ（３）が受信することを保証しない様な態様で送信する。すなわち、送信要求の生成順番で１つのパケットが受信されるのを確認した後に次のパケットを送信するわけではなく、次々に送信してゆき、送信先のコンピュータＢ（３）が受信に失敗した場合には、受信に失敗したパケットを再送する。又は、受信し且つ更新処理が実施されるということが分かるまで、同じパケットを何度も送信するようにしてもよい。その際には、応答確認済みＢＴ数及び応答確認済みＳＢＴ数を使用するとよい。また、送信順番は、送信要求の生成順番に全く無関係になっていてもよい。
【００２８】
パケット送信機１３は、送信キュー９のパケット送信要求を１つ選び、受信キュー１１内の応答予定ＢＴ数及び応答予定ＳＢＴ数と共に、パケットを作成して送信する。応答予定ＢＴ数及び応答予定ＳＢＴ数は、送信先であるコンピュータＢ（３）の送信キューに格納されている応答確認済みＢＴ数及びＳＢＴ数を変更するために用いられる。なお、送信すべき送信要求が送信キュー９に無い場合には、応答予定ＢＴ数及び応答予定ＳＢＴ数のみを送信する。
【００２９】
パケット受信機１５は、パケットを受信し、パケットの内容、送信キュー、及び受信キューの状態を参照して、送信キュー及び受信キューの更新を行う。すなわち、受信したパケットの応答予定ＢＴ数及び応答予定ＳＢＴ数を用いて、送信キュー９の応答確認済みＢＴ数応答確認済みＳＢＴ数を更新する。この更新は、応答予定ＢＴ数＞応答確認済みＢＴ数であれば、応答確認済みＢＴ数及び応答確認済みＳＢＴ数を応答予定ＢＴ数及び応答予定ＳＢＴ数でそれぞれ更新する。もし、応答予定ＢＴ数＝応答確認済みＢＴ数であれば、応答予定ＳＢＴ＞応答確認済みＳＢＴかどうか判断する。もし、この条件が満たされれば、応答確認済みＳＢＴを応答予定ＳＢＴで更新する。以上の条件以外の場合には、応答確認済みＢＴ及びＳＢＴの更新は行わない。
【００３０】
受信したパケットには、重複が存在するかもしれない。よって、パケット受信機１５は、受信したパケットの変更要求に含まれるＢＴ数及びＳＢＴ数を参照して、受信キュー９に既に格納されている変更要求で同じＢＴ数及びＳＢＴ数の変更要求が存在する場合には、後から送られてきたパケット内の変更要求を破棄する。
【００３１】
さらに、受信したパケットに係る変更要求を既に実行してしまった場合も存在する。よって、受信キュー１１を参照して、応答予定ＢＴ数より小さいＢＴ数を含む変更要求、及び応答予定ＢＴ数と同じＢＴ数を含む変更要求であって応答予定ＳＢＴ数より小さいＳＢＴ数を含む変更要求を破棄する。
【００３２】
なお、応答確認済みＢＴ≧送信要求内のＢＴ、又は応答確認済みＢＴ＝送信要求内のＢＴ且つ応答確認済みＳＢＴ≧送信要求内のＳＢＴとなっている送信要求は送信キュー９から削除することができる。この削除を実行するのは、パケット受信機１５又はパケット送信機１３のいずれでもよい。
【００３３】
また、受信したパケットに係る変更要求のＢＴ及びＳＢＴを参照して、受信キュー１１内の変更要求の順番をＳＢ及びＳＢＴの小さい順で並び替える動作を行うが、これもパケット受信機１５又はレプリカ・コントローラ７のいずれが実施してもよい。
【００３４】
通信媒体１９は、無線でも有線でも構わない。また、これらの組み合わせでもよい。本発明の特徴として、信頼性の低いネットワークを介しての通信でも対処することができる。
【００３５】
以上説明したＢＴ数、ＳＢＴ数、応答予定ＢＴ数、応答予定ＳＢＴ数、応答確認済みＢＴ数、及び応答確認済みＳＢＴ数の関係及び更新について、図２を用いてまとめておく。
【００３６】
図２では、コンピュータＡ（１）の受信キュー１１Ａ（ＡはコンピュータＡ内の構成要素であることを示す。同じくＢはコンピュータＢ内の構成要素であることを示す）に格納されたパケット１に係る変更要求をレプリカ・コントローラ７Ａが実行したところからの動作を示している。変更要求を実行するとレプリカ・コントローラ７は、受信キュー１１Ａの応答予定ＢＴ数及び応答予定ＳＢＴ数をパケット１のＢＴ数及びＳＢＴ数で変更する（ステップ１０００）。この更新された応答予定ＢＴ数及び応答予定ＳＢＴ数は、コンピュータＡ（１）が次にコンピュータＢ（３）に送信すべく送信キュー９Ａ内に用意しているパケット２に取り込まれる（ステップ１１００）。パケット送信機１３Ａがこのパケット２を送信すると（ステップ１２００）、コンピュータＢ（３）のパケット受信機１５Ｂがこれを受信し、パケット２'として受信キュー１１Ｂに取り込む。ここで、パケット受信機１５Ｂは、上で述べたように、パケット２'内の変更要求に係る応答予定ＢＴ数及び応答予定ＳＢＴ数により、送信キュー９Ｂの応答確認済みＢＴ数及び応答確認済みＳＢＴ数を更新すべきかを判断する。ここでは、上で述べた条件のいずれかが満たされたとして、応答確認済みＢＴ数及び応答確認済みＳＢＴ数は更新される（ステップ１３００）。今度は、応答確認済みＢＴ数と送信キュー９Ｂ内の変更要求のＢＴ数、応答確認済みＳＢＴ数と送信キュー９Ｂ内の変更要求のＳＢＴ数が比較され（ステップ１４００）、両者共に一致するパケット１'が破棄される（ステップ１５００）。このように、送信キュー９Ｂからパケット１'が破棄されると、二度とコンピュータＡ（１）に送信されなくなる。
【００３７】
次に、図３乃至図６を用いてレプリカ・コントローラ７が受信キュー１１内の変更要求をいかに実行していくか、について説明する。まず、図３を用いてＢＴ数とＳＢＴ数の付け方について説明しておく。図３では、変更要求に含まれる更新順序の指定がオーディナリである場合にはＯ、バックワード・フラッシュの場合にはＢ、２ウエー・フラッシュの場合にはＴ、フォワード・フラッシュの場合にはＦと記している。また、各指定における出現順番を添字にしている。最初は、ＢＴ数及びＳＢＴ数とも０で初期化されている。そして、（１）でアプリケーション５がオーディナリを指定すると、データ変更Ｏ１には（０，０）が付される。なお（ＢＴ，ＳＢＴ）である。そうすると、ＳＢＴ数は１インクリメントされる。（２）で、再度オーディナリが指定されると、データ変更Ｏ２には（０，１）が付される。これによりＳＢＴ数はさらに１インクリメントされる。よって、（３）でバックワード・フラッシュが指定されると、データ変更Ｂ１には（０，２）が付される。バックワード・フラッシュが発生するとＳＢＴ数はクリアされ、ＢＴ数が１インクリメントされる。
【００３８】
（４）で２ウエー・フラッシュが指定されると、データ変更Ｔ１には（１，０）が付される。２ウエー・フラッシュが指定された場合も、ＳＢＴ数をクリアして、ＢＴ数を１インクリメントする。（５）でオーディナリが指定されると、データ変更Ｏ３には（２，０）が付される。この指定によりＳＢＴ数は１インクリメントされる。（６）でさらにオーディナリが指定されると、データ変更Ｏ４には（２，１）が付される。さらにＳＢＴ数は１インクリメントされる。（７）でフォワード・フラッシュが指定されると、データ変更Ｆ１には（２，２）が付される。定義より、ＳＢＴ数は１インクリメントされる。
【００３９】
図３のようなデータ変更要求を含むパケットがパケット送信機１３から送信され、コンピュータＢ（３）で受信された場合の処理を、図４を用いて説明する。パケット受信機１５Ｂがパケットを受信した順番は、図４に示すように、Ｏ１，Ｂ１，Ｏ２，Ｔ１，Ｏ４，Ｆ１、Ｏ３の順である。但し、図４の例では１つずつデータ変更要求を受信し、処理していくものとする。もし、複数のデータ変更要求が受信キュー１１Ｂに貯まった場合には、上で述べたようにＢＴ数及びＳＢＴ数の小さい順にデータ変更要求を並び替える。図４は単なる例であっていくつかのパケットをまとめて受信するようなことがあってもよい。
【００４０】
最初に、処理中ＢＴ数及び処理中ＳＢＴ数を共に０に初期化しておく。そして（１）で、パケット受信機１５Ｂはデータ変更Ｏ１を受信して受信キュー１１Ｂに入れる。受信キュー１１Ｂの状態は、図５の（１）の左側の状態になる。そして、処理中ＢＴ数及び処理中ＳＢＴ数、並びにデータ変更Ｏ１のＢＴ数及びＳＢＴ数を用いて、データ変更Ｏ１を実行してよいのかをレプリカ・コントローラ７Ｂが判断する。判断基準は以下のとおりである。
（ａ）データ変更要求の更新順序の指定がオーディナリ又はバックワード・フラッシュの場合
データ変更要求のＢＴ数≦処理中ＢＴ数
であれば実行可能である。
（ｂ）データ変更要求の更新順序の指定がフォワード・フラッシュ又は２ウエー・フラッシュの場合
データ変更要求のＢＴ数＝処理中ＢＴ数 且つ
データ変更要求のＳＢＴ数＝処理中ＳＢＴ数
であれば実行可能である。
【００４１】
上のような判断基準を図４の（１）に当てはめてみると、オーディナリの指定でデータ変更要求のＢＴ数は０で処理中ＢＴ数も０であるから実行可能である。よって、レプリカ・コントローラ７Ｂはデータ変更Ｏ１を実行する。図４の（１）では「変更実行」の行に○が記されている。
【００４２】
次に当該データ変更Ｏ１を受信キュー１１Ｂから削除してもよいか判断する。この判断は、データ変更要求のＢＴ数＝処理中ＢＴ数、且つデータ変更要求のＳＢＴ数＝処理中ＳＢＴ数であるかにより行われる。もし、上記条件が満たされた場合には、処理中ＢＴ数及び処理中ＳＢＴ数の値も更新する。更新方法は、以下のとおりである。
（ａ）データ変更要求の更新順序の指定が、オーディナリ又はフォワード・フラッシュの場合
処理中ＳＢＴ数＝処理中ＳＢＴ数＋１
（ｂ）データ変更要求の更新順序の指定が、バックワード・フラッシュ又は２ウエー・フラッシュの場合
処理中ＢＴ数＝処理中ＢＴ数＋１
処理中ＳＢＴ数＝０
【００４３】
上記判断基準を満たしているので、レプリカ・コントローラ７Ｂはデータ変更Ｏ１を受信キュー１１Ｂから削除することができる。よって図４では「削除」の欄に○が記されている。そして、データ変更Ｏ１はオーディナリなので、上記更新方法のように処理中ＳＢＴ数が１インクリメントされる。図５の（１）の矢印の先に示したように、受信キュー１１Ｂにデータ変更要求は無くなる。
【００４４】
次に（２）で、パケット受信機１５Ｂはデータ変更Ｂ１を受信する。バックワード・フラッシュであるから、データ変更Ｂ１のＢＴ数と処理中ＢＴ数を比較して、上記判断基準を満たしていると判断できる。よって、レプリカ・コントローラ７Ｂはデータ変更Ｂ１を実行する（図４の（２）の「変更実行」の行に○が記されている）。しかし，データ変更Ｂ１のＳＢＴ数と処理中ＳＢＴ数は異なるので、当該データ変更Ｂ１を受信キュー１１Ｂから削除することはできない。図５の（２）に示したように、パケット受信機１５Ｂにより受信されたデータ変更Ｂ１は受信キュー１１Ｂに残る。しかし、データ変更Ｂ１の全てを受信キュー１１Ｂに残しておく必要はない。データ変更要求は実行したわけであるから、データ変更に直接関係するデータは削除することができ、それ以外のＢＴ数及びＳＢＴ数及び更新順番の指定等のデータ変更要求の基本的情報部分のみを残せばよい。図５ではそのような場合には点線の四角を用いる。よってＢ１が点線で囲まれている。
【００４５】
（３）で、パケット受信機１５Ｂはデータ変更Ｏ２を受信する。データ変更Ｏ２のＢＴ数は０だがＳＢＴ数は１であるから、データ変更Ｂ１のＳＢＴ数より小さい。よって、図５の（３）で示したように、パケット受信機１５Ｂはデータ変更Ｏ２を最初にデータ変更Ｂ１を２番目にするように受信キュー１１Ｂを更新する。レプリカ・コントローラ７Ｂは、データ変更Ｏ２のＢＴ数が０で処理中ＢＴ数の０であるから、データ変更Ｏ２を実行可能と判断し、実行する（図４の（３）の「変更実行」に○が記されている）。さらに、レプリカ・コントローラ７Ｂは、データ変更Ｏ２のＢＴ数と処理中ＢＴ数が一致し、且つデータ変更Ｏ２のＳＢＴ数と処理中ＳＢＴ数が一致するため、データ変更Ｏ２を削除する（図４の（３）の「削除」の行には○が記されている）。
【００４６】
さらに、更新順序の指定がオーディナリであり、且つＢＴ数と処理中ＢＴ数及びＳＢＴ数と処理中ＳＢＴ数が一致するので、処理中ＳＢＴ数が１インクリメントされる。ここでは、処理中ＢＴ数０、処理中ＳＢＴ数２となる。これにより、受信キュー１１Ｂに残ったデータ変更Ｂ１のＢＴ数とＳＢＴ数がそれぞれ処理中ＢＴ数及び処理中ＳＢＴ数に一致するようになる。そこで、レプリカ・コントローラ７Ｂはデータ変更Ｂ１についても受信キュー１１Ｂから削除する。図４の（３）から（２）への矢印にてデータ変更Ｂ１が削除されることを示している。また、図５の（３）の右側で受信キュー１１Ｂが空になったことを示している。さらに、削除されたデータ変更の更新順序の指定がバックワード・フラッシュであり、且つＢＴ数と処理中ＢＴ数及びＳＢＴ数と処理中ＳＢＴ数が一致するので、レプリカ・コントローラ７Ｂは処理中ＢＴ数を１インクリメントし、処理中ＳＢＴ数をクリアする。
【００４７】
（４）でパケット受信機１５Ｂはデータ変更Ｔ１を受信する。レプリカ・コントローラ７Ｂは、データ変更Ｔ１のＢＴ数と処理中ＢＴ数が一致し、且つデータ変更Ｔ１のＳＢＴ数と処理中ＳＢＴ数が一致するので、データ変更Ｔ１を実行する（図４の（４）の「変更実行」の行には、○が記されている）。さらに、データ変更Ｔ１を削除することも可能であることが分かるので、レプリカ・コントローラ７Ｂはデータ変更Ｔ１を受信キュー１１Ｂから削除する（図４の（４）の「削除」の行にも○が記されている）。図５の（４）でも、一旦受信キュー１１Ｂに入れられたデータ変更Ｔ１が削除されて、受信キュー１１Ｂが空になる様子を示している。データ変更Ｔ１は２ウエー・フラッシュであるから、処理中ＢＴ数を１インクリメントし、処理中ＳＢＴ数をクリアする。
【００４８】
（５）において、パケット受信機１５Ｂはデータ変更Ｏ４を受信する。レプリカ・コントローラ７Ｂは、更新順番の指定がオーディナリであり、データ変更Ｏ４のＢＴ数が２で処理中ＢＴ数も２であるから、データ変更Ｏ４を実行する（図４の（５）の「変更実行」の行に○が記されている）。しかし、処理中ＳＢＴ数とデータ変更Ｏ４のＳＢＴ数は一致しないので、受信キュー１１Ｂからこのデータ変更Ｏ４を削除することはできない。図５の（５）では、実行は行ったので点線で囲まれたデータ変更Ｏ４が受信キュー１１Ｂに残ることを示している。
【００４９】
（６）において、パケット受信機１５Ｂはデータ変更Ｆ１を受信する。パケット受信機１５Ｂはデータ変更Ｆ１のＢＴ数及びＳＢＴ数から、受信キュー１１Ｂにおいてデータ変更Ｏ４の後ろにデータ変更Ｆ１を追加する。レプリカ・コントローラ７Ｂは、データ変更Ｆ１の実行が可能かどうか検査するが、データ変更Ｆ１のＳＢＴ数と処理中ＳＢＴ数が一致しないので、実行することができない。当然受信キュー１１Ｂから削除することもできない。図５の（６）には、受信キュー１１Ｂに２つのデータ変更要求が貯まった状態を示している。
【００５０】
（７）において、パケット受信機１５Ｂはデータ変更Ｏ３を受信する。パケット受信機１５Ｂは、データ変更Ｏ３のＢＴ数及びＳＢＴ数から、受信キュー１１Ｂの順番を入れ替える。図５の（７）に示したように、データ変更Ｏ３が１番目、データ変更Ｏ４が２番目、データ変更Ｆ１が３番目に並べられる（図５の（７）の一番左側参照）。レプリカ・コントローラ７Ｂは、データ変更Ｏ３のＢＴ数と処理中ＢＴ数が一致するため、データ変更Ｏ３を実行する（図４の（７）の「変更実行」の行に○が記されている）。また、データ変更Ｏ３のＳＢＴ数と処理中ＳＢＴ数も一致するため、レプリカ・コントローラ７Ｂはデータ変更Ｏ３を削除する（図５の（７）の左から２番目参照）。図４の（７）の「削除」の行には○が記されている。データ変更Ｏ３の更新順序の指定はオーディナリであり、ＢＴ数と処理中ＢＴ数並びにＳＢＴ数と処理中ＳＢＴ数が一致するので、レプリカ・コントローラ７Ｂは処理中ＳＢＴ数を１インクリメントする。そうすると、受信キュー１１Ｂ内のデータ変更Ｏ４のＢＴ数及びＳＢＴ数にそれぞれ一致するようになる。そこで、レプリカ・コントローラ７Ｂは、受信キュー１１Ｂからデータ変更Ｏ４を削除する（図５の（７）の左から３番目参照）。図４では（７）から（５）への矢印で削除が可能になったことを示している。
【００５１】
さらに、データ変更Ｏ４のＢＴ数と処理中ＢＴ数、並びにデータ変更Ｏ４のＳＢＴ数と処理中ＳＢＴ数が一致し、データ変更Ｏ３の更新順序の指定はオーディナリであるから、レプリカ・コントローラ７Ｂは処理中ＳＢＴ数を１インクリメントする。そうすると、（６）で実行することができなかったデータ変更Ｆ１のＢＴ数及びＳＢＴ数と処理中ＢＴ数及び処理中ＳＢＴ数がそれぞれ一致するようになる。レプリカ・コントローラ７Ｂはデータ変更Ｆ１を実行し、且つ実行後データ変更Ｆ１を受信キュー１１Ｂから削除する。図５の（７）の右端は最後には受信キュー１１Ｂが空になることを示している。また、図４の（７）から（６）への点線矢印が、実行が可能になり且つ削除も可能になったことを示している。
【００５２】
以上の処理を、図６にまとめて示している。まず、受信キュー１１中の今受信した変更要求又はステップ２２００により指示を受けた場合にはステップ２２００で指定された変更要求が実行可能か否か判断する（ステップ２１００）。これは、変更要求に含まれる更新順番の指定とＢＴ数及びＳＢＴ数により決定される。もし、実行不可能であれば、受信キュー１１の次の変更要求へ移行する（ステップ２２００）。受信キュー１１に次の変更要求が存在しない場合には、受信するまで待つ。図６では明示していないが、受信キュー１１内は変更要求を受信するごとに、ＢＴ数及びＳＢＴ数の小さい順に並び替える。もし、変更要求が実行可能であれば、当該変更要求を実行する（ステップ２３００）。そして、受信キュー１１から削除可能な変更要求があるか判断する（ステップ２４００）。もし、削除可能な変更要求がある場合には、当該変更要求を削除する（ステップ２６００）。このステップ２６００においては、レプリカ・コントローラ７は受信キュー１１内の応答予定ＢＴ数及び応答予定ＳＢＴ数の更新も、削除した変更要求のＢＴ数及びＳＢＴ数を用いて実施する。削除した場合には、処理中ＢＴ数及び処理中ＳＢＴ数を必要に応じて変更する。もし、削除可能な変更要求がない場合には、ステップ２２００に移行する。削除を実行した後に、処理が完了したか判断し、処理が終了していない場合にはステップ２２００に移行する。処理が完了したと判断される場合には、ステップ２７００で処理を終了する。
【００５３】
以上のように、パケット受信機１１は、レプリカ・コントローラ７は変更要求を受信するごとに受信キュー内の順番を更新し、且つ実行可能な変更要求か判断することにより各変更要求実行のタイミング／順序を決定している。この動作は受信順番に全く関係ない。例え変更要求がその生成順に受信されなくとも、実行できる変更要求を判別且つ実行することができるので、より処理効率も高くなる。また、実行した変更要求は受信キュー１１から削除できる場合もあるので、メモリの使用効率も向上する。また、実行した変更要求で削除できない場合であっても、当該変更要求の基本的情報のみを残しておくようにすれば、さらにメモリ効率は向上する。
【００５４】
図１の情報共有システムでは、２つのコンピュータしか示していないが、３以上設けることも可能である。但し、本発明を実施するには、各コンピュータ対ごとに上記の構成を必要とする。
【００５５】
以上の実施例は様々に変更可能である。各構成要素は同一のコンピュータ上になくともよい。パケット受信機１５とレプリカ・コントローラ７の機能は必要に応じていずれかの要素に含めることができ、一体化することも可能である。同様に、データ格納装置１７とレプリカ・コントローラ７が一体化されていてもよい。また、上の実施例では変更要求の実行と削除を独立に処理していたが、同時に行うように変形することも可能である。この際には、応答予定ＢＴ数及び応答予定ＳＢＴ数の更新のために別途ＢＴ数及びＳＢＴ数を保存しておく必要が生じ得る。また、応答確認済みＢＴ数及び応答確認済みＳＢＴ数を管理しないで、応答予定ＢＴ数及び応答予定ＳＢＴ数を受信するごとに、同じ数のＢＴ数及びＳＢＴ数を有する変更要求を削除するように変形することも可能である。送信及び受信キューはメインメモリ上に設けても、専用のメモリを用いてもよい。また、実行済の変更要求は受信キューには置かず、別のキュー又は表を用いて処理中ＢＴ数泳ぎ処理中ＳＢＴ数を更新してもよい。さらに、処理中ＳＢＴ数を管理しないで必要に応じて受信キュー中の同一のＢＴ数を持つ変更要求を数えてもよい。
【００５６】
【効果】
レプリカの更新の際の通信効率を改善する方法及び装置を提供することができた。
【００５７】
また、レプリカの更新の際のメモリ使用量を削減する方法及び装置を提供することもできた。
【００５８】
さらに、レプリカの更新のための通信が途中で切断された場合であっても、変更要求によるレプリカの更新がどこまで実行されたか確認することができる方法及び装置を提供することもできた。
【００５９】
さらに、レプリカ更新の順序を明示的に指定できるようにすることもできた。
【００６０】
例えば大画像データを複数枚リプリケートし、１つの画像データ内のデータを複数に分割してデータ転送を行う例を考える。この場合、同一の画像データ内の転送順序を制御する必要は無いが、リプリケート中に通信回線が意図的又は不意に切断された場合でも、全てのデータがリプリケートされている画像データをなるべく多く得ることが望ましい。従来技術のＦＩＦＯ順序でリプリケートされる場合には各画像データの末尾のデータがリプリケートされればその画像データはリプリケートされていることがわかるが、転送オーバーヘッドが多大である。また、リプリケート全体がバッチ処理的にリプリケートされる場合でも、途中で回線が切断されると、どの画像データについても全てのデータがそろったことが保証できない。本発明では、１つの画像データの末尾でフォワード・フラッシュを指定すれば同一画像内のデータ転送については送信順番に制約はなく、画像間のデータ転送順序を制御することも可能になる。この場合、末尾データの更新が実行されれば、当該画像データ全体がリプリケートされたことを保証することができるようになる。
【００６１】
また、セールスマンの個人情報とそのセールスマンの月例売上表をリプリケートする例を考える。個人情報には、社員番号、氏名、所属部課、電話番号が含まれ、月例売上表には、社員番号と毎日の売上高が含まれるものとする。売上表出力プログラムは、月売上表から社員番号を得てその社員番号から個人情報を検索し、対応する氏名、所属部課、電話番号を出力する。このような例で、月例売上表があるのに、対応する個人情報が存在しないと出力プログラムは月例売上表に対応する氏名等を出力することができない。このように依存関係がある複数のデータをリプリケートする場合、リプリケート中に回線が切断されても依存関係に矛盾が生じないように、依存関係があるデータ間のリプリケートの順序を保証したい場合がある。従来技術のＦＩＦＯ順序でリプリケートする場合、個人情報、月例売上表の順でデータを生成することにより、リプリケートの順を保証することができる。しかし、転送順序を保証する必要の無い他のデータのリプリケートもＦＩＦＯ順序で行われることになり、不必要な転送オーバヘッドを生じる、また、リプリケート全体がバッチ処理される場合、リプリケートが完全に終了せずに回線が切断された時にその時点でのリプリケートの順序を保証することができない。本発明を利用して、最後の個人情報の生成時に２ウエー・フラッシュを指定し、その後に月例売上表を生成することにより個人情報と月例売上表のリプリケートの順序を保証することができる。その際に生じる転送オーバヘッドも必要最小限ですむ。
【図面の簡単な説明】
【図１】本発明の情報共有システムを示す図である。
【図２】変更要求のＢＴ数及びＳＢＴ数、応答予定ＢＴ数及び応答予定ＳＢＴ数、応答確認済みＢＴ数及び応答確認済みＳＢＴ数の関係を表すフロー図である。
【図３】ＢＴ数及びＳＢＴ数の変更要求への付け方を示す図である。
【図４】変更要求及び削除の実行を説明するための例を示す図である。
【図５】図４の場合の受信キューのようすを示す図である。
【図６】変更要求の実行及び削除の実行の処理フローを示す図である。
【符号の説明】
１００ 情報共有システム
１ コンピュータＡ
３ コンピュータＢ
５ アプリケーション
７ レプリカ・コントローラ
９ 送信キュー
１１ 受信キュー
１３ パケット送信機
１５ パケット受信機
１７ データ格納装置
１９ 通新媒体
Claims (11)
- 共有データのレプリカを有し、データ変更を他のコンピュータと相互に通知しあうことにより前記レプリカの内容の同一性保持を図るコンピュータであって、
他のコンピュータから前記レプリカ内のデータの変更要求を受信する手段と、
前記変更要求の受信順番にかかわらず、受信した前記変更要求によるレプリカの更新実行のタイミングを、前記変更要求に含まれる情報を用いて、前記変更要求の受信毎に制御する制御手段とを有し、
前記変更要求に含まれる情報は、
変更順番の指定なし、当該変更要求より前の全ての変更要求を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行するという第１の指定、当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第２の指定、又は当該変更要求より前の全ての変更を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行し且つ当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第３の指定を含む、コンピュータ。 - 前記変更要求に含まれる情報は、
これまでに生成された、前記第２又は第３の指定を含む変更要求の数（第１の数）、及び最後に前記第２又は第３の指定を含む変更要求が生成された後に生成された変更要求の数（第２の数）をさらに含む、請求項１記載のコンピュータ。 - 前記制御手段は、
前記第１及び第２の数にそれぞれ対応し、レプリカの更新実行のタイミングを規定する第１及び第２の管理値を保持している、請求項２記載のコンピュータ。 - 前記制御手段は、
前記変更要求によるレプリカの更新が実行された場合に、当該変更要求に含まれる前記第１及び第２の数を第３の数及び第４の数として記憶する、請求項２記載のコンピュータ。 - 他のコンピュータへ前記レプリカ内のデータの変更要求を送信する手段をさらに有し、
前記制御手段は、
送信する変更要求に、前記第３の数及び第４の数を含ませる、請求項４記載のコンピュータ。 - 共有データのレプリカを有し、データ変更を他のコンピュータと相互に通知しあうことにより前記レプリカの内容の同一性保持を図るコンピュータであって、
前記レプリカ内のデータの変更を命令し、当該データの変更に対して変更順序に関する情報を指定する手段と、
前記データの変更の命令に対応し且つ前記変更順序に関する情報を含む変更要求を生成する手段と、
前記変更要求の生成順序と送信順序の一致を保証しないような態様で、前記変更要求を送信する手段とを有し、
前記変更順序に関する情報は、
変更順番の指定なし、当該変更要求より前の全ての変更要求を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行するという第１の指定、当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第２の指定、又は当該変更要求より前の全ての変更を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行し且つ当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第３の指定を含む、コンピュータ。 - 前記変更要求に関する情報は、 これまでに生成された、前記第２又は第３の指定を含む変更要求の数（第１の数）、及び最後に前記第２又は第３の指定を含む変更要求が生成された後に生成された変更要求の数（第２の数）をさらに含む、請求項８記載のコンピュータ。
- 他のコンピュータから前記レプリカ内のデータの変更要求を受信する手段をさらに有し、
受信した前記変更要求は、
送信した変更要求によるレプリカの更新が送信先の他のコンピュータで実行されたことを示す応答情報を含む、請求項６記載のコンピュータ。 - 前記応答情報を参照して、前記送信した変更要求を削除するか判断する手段をさらに有する、請求項８記載のコンピュータ。
- 前記変更要求の受信順番にかかわらず、受信した前記変更要求によるレプリカの更新実行のタイミングを、前記変更順序に関する情報を用いて、前記変更要求の受信毎に制御する制御手段をさらに有する、請求項６記載のコンピュータ。
- 共有データのレプリカを有するコンピュータにおいて、データ変更を他のコンピュータと相互に通知しあうことにより前記レプリカの内容の同一性保持を図るレプリカ同一性保持方法であって、
他のコンピュータから前記レプリカ内のデータの変更要求を受信するステップと、
前記変更要求の受信順番にかかわらず、受信した前記変更要求によるレプリカの更新実行のタイミングを、前記変更要求に含まれる情報を用いて、前記変更要求の受信毎に制御するステップとを含み、
前記変更要求に含まれる情報は、
変更順番の指定なし、当該変更要求より前の全ての変更要求を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行するという第１の指定、当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第２の指定、又は当該変更要求より前の全ての変更を前記レプリカに反映した後に当該変更要求によるレプリカの更新を実行し且つ当該変更要求より後の変更要求を当該変更要求によるレプリカの更新実行の後に実行するという第３の指定を含む、レプリカ同一性保持方法。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30100798A JP3578385B2 (ja) | 1998-10-22 | 1998-10-22 | コンピュータ、及びレプリカ同一性保持方法 |
| IL13171099A IL131710A (en) | 1998-10-22 | 1999-09-02 | A method for maintaining consistency in copying |
| KR1019990039168A KR100359960B1 (ko) | 1998-10-22 | 1999-09-14 | 레프리카의 동일성을 유지하는 컴퓨터와 데이타 공유 시스템 및 그 방법 |
| CN99120897A CN1114869C (zh) | 1998-10-22 | 1999-10-08 | 维持复制一致性的计算机、数据共享***和方法 |
| US09/425,559 US6571278B1 (en) | 1998-10-22 | 1999-10-22 | Computer data sharing system and method for maintaining replica consistency |
| TW088118127A TW505852B (en) | 1998-10-22 | 1999-11-04 | Computer, data sharing system, and method for maintaining replica consistency |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30100798A JP3578385B2 (ja) | 1998-10-22 | 1998-10-22 | コンピュータ、及びレプリカ同一性保持方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000132443A JP2000132443A (ja) | 2000-05-12 |
| JP3578385B2 true JP3578385B2 (ja) | 2004-10-20 |
Family
ID=17891717
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP30100798A Expired - Fee Related JP3578385B2 (ja) | 1998-10-22 | 1998-10-22 | コンピュータ、及びレプリカ同一性保持方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6571278B1 (ja) |
| JP (1) | JP3578385B2 (ja) |
| KR (1) | KR100359960B1 (ja) |
| CN (1) | CN1114869C (ja) |
| IL (1) | IL131710A (ja) |
| TW (1) | TW505852B (ja) |
Families Citing this family (56)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6859821B1 (en) * | 1999-07-19 | 2005-02-22 | Groove Networks, Inc. | Method and apparatus for prioritizing data change requests and maintaining data consistency in a distributed computer system equipped for activity-based collaboration |
| US7200869B1 (en) * | 2000-09-15 | 2007-04-03 | Microsoft Corporation | System and method for protecting domain data against unauthorized modification |
| CA2436517C (en) * | 2000-10-09 | 2011-09-20 | Maximum Availability Limited | Method and apparatus for data processing |
| KR100637990B1 (ko) * | 2001-03-26 | 2006-10-23 | 듀아키시즈 가부시키가이샤 | 프로토콜 이중화 장치 및 프로토콜 이중화 방법 |
| US6745303B2 (en) * | 2002-01-03 | 2004-06-01 | Hitachi, Ltd. | Data synchronization of multiple remote storage |
| US7139932B2 (en) * | 2002-01-03 | 2006-11-21 | Hitachi, Ltd. | Data synchronization of multiple remote storage after remote copy suspension |
| JP3500379B1 (ja) * | 2002-06-28 | 2004-02-23 | 株式会社コナミコンピュータエンタテインメント東京 | ゲーム装置、プログラム及びゲーム装置の制御方法 |
| US8374966B1 (en) | 2002-08-01 | 2013-02-12 | Oracle International Corporation | In memory streaming with disk backup and recovery of messages captured from a database redo stream |
| JP4227399B2 (ja) * | 2002-11-29 | 2009-02-18 | キヤノン株式会社 | 情報処理方法及び装置 |
| US7739240B2 (en) * | 2002-12-09 | 2010-06-15 | Hewlett-Packard Development Company, L.P. | Replication and replica management in a wide area file system |
| GB0229572D0 (en) * | 2002-12-19 | 2003-01-22 | Cognima Ltd | Quality of service provisioning |
| US7516204B2 (en) * | 2003-02-28 | 2009-04-07 | Canon Kabushiki Kaisha | Information processing method and apparatus |
| US20050262513A1 (en) * | 2004-04-23 | 2005-11-24 | Waratek Pty Limited | Modified computer architecture with initialization of objects |
| US20060095483A1 (en) * | 2004-04-23 | 2006-05-04 | Waratek Pty Limited | Modified computer architecture with finalization of objects |
| US7707179B2 (en) * | 2004-04-23 | 2010-04-27 | Waratek Pty Limited | Multiple computer architecture with synchronization |
| US20050257219A1 (en) * | 2004-04-23 | 2005-11-17 | Holt John M | Multiple computer architecture with replicated memory fields |
| US7844665B2 (en) * | 2004-04-23 | 2010-11-30 | Waratek Pty Ltd. | Modified computer architecture having coordinated deletion of corresponding replicated memory locations among plural computers |
| US7849452B2 (en) * | 2004-04-23 | 2010-12-07 | Waratek Pty Ltd. | Modification of computer applications at load time for distributed execution |
| WO2006110937A1 (en) * | 2005-04-21 | 2006-10-26 | Waratek Pty Limited | Modified computer architecture with coordinated objects |
| US7680793B2 (en) | 2005-10-07 | 2010-03-16 | Oracle International Corporation | Commit-time ordered message queue supporting arbitrary read and dequeue patterns from multiple subscribers |
| US20070100828A1 (en) * | 2005-10-25 | 2007-05-03 | Holt John M | Modified machine architecture with machine redundancy |
| US7958322B2 (en) * | 2005-10-25 | 2011-06-07 | Waratek Pty Ltd | Multiple machine architecture with overhead reduction |
| US8015236B2 (en) * | 2005-10-25 | 2011-09-06 | Waratek Pty. Ltd. | Replication of objects having non-primitive fields, especially addresses |
| US7660960B2 (en) * | 2005-10-25 | 2010-02-09 | Waratek Pty, Ltd. | Modified machine architecture with partial memory updating |
| US7581069B2 (en) * | 2005-10-25 | 2009-08-25 | Waratek Pty Ltd. | Multiple computer system with enhanced memory clean up |
| US7761670B2 (en) * | 2005-10-25 | 2010-07-20 | Waratek Pty Limited | Modified machine architecture with advanced synchronization |
| US7849369B2 (en) * | 2005-10-25 | 2010-12-07 | Waratek Pty Ltd. | Failure resistant multiple computer system and method |
| US7801856B2 (en) | 2006-08-09 | 2010-09-21 | Oracle International Corporation | Using XML for flexible replication of complex types |
| US20080130652A1 (en) * | 2006-10-05 | 2008-06-05 | Holt John M | Multiple communication networks for multiple computers |
| US20080140970A1 (en) * | 2006-10-05 | 2008-06-12 | Holt John M | Advanced synchronization and contention resolution |
| US20080134189A1 (en) * | 2006-10-05 | 2008-06-05 | Holt John M | Job scheduling amongst multiple computers |
| US20100121935A1 (en) * | 2006-10-05 | 2010-05-13 | Holt John M | Hybrid replicated shared memory |
| WO2008040085A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Network protocol for network communications |
| WO2008040082A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Multiple computer system with dual mode redundancy architecture |
| US20080114899A1 (en) * | 2006-10-05 | 2008-05-15 | Holt John M | Switch protocol for network communications |
| JP5318768B2 (ja) * | 2006-10-05 | 2013-10-16 | ワラテック プロプライエタリー リミテッド | 高度な競合検出 |
| US7852845B2 (en) * | 2006-10-05 | 2010-12-14 | Waratek Pty Ltd. | Asynchronous data transmission |
| US20080133691A1 (en) * | 2006-10-05 | 2008-06-05 | Holt John M | Contention resolution with echo cancellation |
| US20080126506A1 (en) * | 2006-10-05 | 2008-05-29 | Holt John M | Multiple computer system with redundancy architecture |
| WO2008040066A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Redundant multiple computer architecture |
| WO2008040071A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Contention detection |
| WO2008040069A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Hybrid replicated shared memory |
| US7949837B2 (en) * | 2006-10-05 | 2011-05-24 | Waratek Pty Ltd. | Contention detection and resolution |
| US20080130631A1 (en) * | 2006-10-05 | 2008-06-05 | Holt John M | Contention detection with modified message format |
| WO2008040083A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Adding one or more computers to a multiple computer system |
| US20080120478A1 (en) * | 2006-10-05 | 2008-05-22 | Holt John M | Advanced synchronization and contention resolution |
| WO2008040084A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Cyclic redundant multiple computer architecture |
| US20080155127A1 (en) * | 2006-10-05 | 2008-06-26 | Holt John M | Multi-path switching networks |
| US20080151902A1 (en) * | 2006-10-05 | 2008-06-26 | Holt John M | Multiple network connections for multiple computers |
| US20080140975A1 (en) * | 2006-10-05 | 2008-06-12 | Holt John M | Contention detection with data consolidation |
| WO2008040080A1 (en) * | 2006-10-05 | 2008-04-10 | Waratek Pty Limited | Silent memory reclamation |
| US20080140633A1 (en) * | 2006-10-05 | 2008-06-12 | Holt John M | Synchronization with partial memory replication |
| US20080250221A1 (en) * | 2006-10-09 | 2008-10-09 | Holt John M | Contention detection with data consolidation |
| US8316190B2 (en) | 2007-04-06 | 2012-11-20 | Waratek Pty. Ltd. | Computer architecture and method of operation for multi-computer distributed processing having redundant array of independent systems with replicated memory and code striping |
| US9197486B2 (en) * | 2008-08-29 | 2015-11-24 | Google Inc. | Adaptive accelerated application startup |
| CN105071839B (zh) * | 2015-08-17 | 2018-02-23 | 贵阳朗玛信息技术股份有限公司 | 蓝牙设备通信方法及装置 |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH01200457A (ja) * | 1988-02-05 | 1989-08-11 | Hitachi Ltd | 分散システムでのノード間メッセージ追い越し処理方式 |
| JP3020539B2 (ja) * | 1990-03-07 | 2000-03-15 | 株式会社日立製作所 | 並列動作型データベース管理方式 |
| KR940005779B1 (ko) * | 1991-12-31 | 1994-06-23 | 재단법인 한국전자통신연구소 | 캐쉬데이타의 공유상태 및 변경상태를 알리는 회로 |
| JPH06110759A (ja) * | 1992-09-30 | 1994-04-22 | Toshiba Corp | ファイルシステム |
| JP3182000B2 (ja) * | 1992-10-20 | 2001-07-03 | 富士通株式会社 | 複合情報処理システムにおける拡張記憶装置 |
| US5446871A (en) * | 1993-03-23 | 1995-08-29 | International Business Machines Corporation | Method and arrangement for multi-system remote data duplexing and recovery |
| JP2557192B2 (ja) * | 1993-03-15 | 1996-11-27 | インターナショナル・ビジネス・マシーンズ・コーポレイション | トランザクション処理の同期方法、トランザクション処理のモニタ方法及びトランザクションのコミット処理方法 |
| US5796999A (en) * | 1994-04-15 | 1998-08-18 | International Business Machines Corporation | Method and system for selectable consistency level maintenance in a resilent database system |
| US5434994A (en) * | 1994-05-23 | 1995-07-18 | International Business Machines Corporation | System and method for maintaining replicated data coherency in a data processing system |
| US5581753A (en) * | 1994-09-28 | 1996-12-03 | Xerox Corporation | Method for providing session consistency guarantees |
| JPH08123714A (ja) * | 1994-10-21 | 1996-05-17 | Hitachi Ltd | ファイル形式を集中変換するシステム |
| JPH0981430A (ja) * | 1995-09-05 | 1997-03-28 | Internatl Business Mach Corp <Ibm> | ファイル・システム |
| US5978813A (en) * | 1995-09-25 | 1999-11-02 | International Business Machines Corporation | System for providing synchronization between a local area network and a distributing computer environment |
| US5819020A (en) * | 1995-10-16 | 1998-10-06 | Network Specialists, Inc. | Real time backup system |
| US5765171A (en) * | 1995-12-29 | 1998-06-09 | Lucent Technologies Inc. | Maintaining consistency of database replicas |
| GB9604987D0 (en) | 1996-03-08 | 1996-05-08 | Ibm | Data management system and method for replicated data |
| US5787262A (en) * | 1996-06-26 | 1998-07-28 | Microsoft Corporation | System and method for distributed conflict resolution between data objects replicated across a computer network |
| US5893116A (en) * | 1996-09-30 | 1999-04-06 | Novell, Inc. | Accessing network resources using network resource replicator and captured login script for use when the computer is disconnected from the network |
| US6049809A (en) * | 1996-10-30 | 2000-04-11 | Microsoft Corporation | Replication optimization system and method |
| JPH10154094A (ja) * | 1996-11-22 | 1998-06-09 | Nec Corp | マスタメンテナンス集中更新方式 |
| US6052718A (en) * | 1997-01-07 | 2000-04-18 | Sightpath, Inc | Replica routing |
| JPH11127188A (ja) * | 1997-10-20 | 1999-05-11 | Fujitsu Ltd | 蓄積交換型電子会議システムにおける情報伝達装置及び方法並びに情報伝達プログラムを記録した媒体 |
-
1998
- 1998-10-22 JP JP30100798A patent/JP3578385B2/ja not_active Expired - Fee Related
-
1999
- 1999-09-02 IL IL13171099A patent/IL131710A/en not_active IP Right Cessation
- 1999-09-14 KR KR1019990039168A patent/KR100359960B1/ko not_active IP Right Cessation
- 1999-10-08 CN CN99120897A patent/CN1114869C/zh not_active Expired - Fee Related
- 1999-10-22 US US09/425,559 patent/US6571278B1/en not_active Expired - Fee Related
- 1999-11-04 TW TW088118127A patent/TW505852B/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| KR20000028662A (ko) | 2000-05-25 |
| IL131710A (en) | 2002-12-01 |
| CN1252568A (zh) | 2000-05-10 |
| TW505852B (en) | 2002-10-11 |
| JP2000132443A (ja) | 2000-05-12 |
| IL131710A0 (en) | 2001-03-19 |
| CN1114869C (zh) | 2003-07-16 |
| KR100359960B1 (ko) | 2002-11-04 |
| US6571278B1 (en) | 2003-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3578385B2 (ja) | コンピュータ、及びレプリカ同一性保持方法 | |
| CA2205725C (en) | Preventing conflicts in distributed systems | |
| JP4160642B2 (ja) | ネットワークデータ転送方法 | |
| US6256634B1 (en) | Method and system for purging tombstones for deleted data items in a replicated database | |
| CA2100533C (en) | Method and system for synchronizing computer mail user directories | |
| JP3532854B2 (ja) | ネットワーク全体にわたって電子メールを同期させるシステムおよび方法 | |
| US7584174B2 (en) | Update dependency control for multi-master replication | |
| US5005122A (en) | Arrangement with cooperating management server node and network service node | |
| US7231461B2 (en) | Synchronization of group state data when rejoining a member to a primary-backup group in a clustered computer system | |
| JP3526474B2 (ja) | ネットワークにおける配布情報管理システム | |
| US20010039548A1 (en) | File replication system, replication control method, and storage medium | |
| JP5049834B2 (ja) | データ受信装置、データ受信方法およびデータ処理プログラム | |
| JP2004302713A (ja) | 記憶システム及びその制御方法 | |
| EP0617373A2 (en) | A method and system for parallel, system managed storage for objects on multiple servers | |
| JP4066617B2 (ja) | データの完全性を伴いデータネットワークに接続される記憶装置システム | |
| US20080086658A1 (en) | Backup control device and system for data processing system | |
| JP4512386B2 (ja) | バックアップシステムおよび方法 | |
| JP4997784B2 (ja) | データ記憶システム、データ記憶方法、データ記憶プログラム | |
| JPH113368A (ja) | 分散環境におけるスケジュールデータ管理方法及びシステム及びスケジュールデータ管理プログラムを格納した記憶媒体 | |
| US7533132B2 (en) | Parallel replication mechanism for state information produced by serialized processing | |
| KR100608394B1 (ko) | 데이터베이스 동기화 인터페이스 장치 및 방법 | |
| JP2009199281A (ja) | データ送信装置 | |
| US20240220131A1 (en) | Request-based content services replication | |
| JP3212891B2 (ja) | ファイル転送システムおよびファイル転送方法 | |
| JPH086834A (ja) | ファイル資源管理システムおよびその方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20040706 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040709 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |