JPH05143373A - 共有データ制御方式 - Google Patents

Abstract

(57)【要約】 【目的】 操作権の明示的な取得および解放を要するこ
となく、共有データに矛盾が生じないようにし、しかも
非矛盾性の保証のための通信量の増大が生じないように
する。 【構成】 サーバプロセス４は、複数のクライアントプ
ロセス１〜３とプロセス間通信５〜７によって結合さ
れ、共有データに関するタイムスタンプ１４を保持して
いる。サーバプロセス４は、クライアントプロセス１〜
３の中の１つ（クライアントプロセス１とする）からの
変更要求に対し、クライアントプロセス１内のタイムス
タンプ１１とタイムスタンプ１４とが同一の場合にのみ
クライアントプロセス１に許可通知を返送する。また、
サーバプロセス４は、１つのクライアントプロセス（ク
ライアントプロセス１とする）内のデータ８の変更を他
のクライアントプロセス２および３内のデータ９および
１０に反映させる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、計算機システムにおけ
るデータ制御方式に関し、特に複数の異なるクライアン
トプロセス（計算機システムの各利用者に対応しデータ
の保持を担当するプロセス）により共有されるデータ
（共有データ）の制御を行う共有データ制御方式に関す
る。

【０００２】

【従来の技術】次のような状況における共有データ制御
方式について考える。 複数のクライアントプロセスのそれぞれは、共有デ
ータ（データベースシステム等において管理されている
共有データ）のコピーのデータを保持している。 あるクライアントプロセス内のデータの変更（非同
期な変更）はそのクライアントプロセス以外のクライア
ントプロセス群に実時間で通知され、全てのクライアン
トプロセス内のデータ（共有データのコピーのデータ）
の内容が常に一致するように保たれる。 複数のクライアントプロセスによる共有データの変
更の要求に対して、１つのクライアントプロセスにのみ
変更が許可され、複数のクライアントプロセス内のデー
タ（共有データのコピーのデータ）の間に矛盾が生じる
ことを防ぐための排他制御が行われる。

【０００３】このような状況は、例えば、計算機ネット
ワークが利用された電子会議システムを実現する際に現
出する。すなわち、電子会議システムによって行われる
会議の複数の参加者に対応する複数のクライアントプロ
セスは、それぞれ文書を示すデータ（共有データのコピ
ーのデータ）を保持している。そして、どの参加者が文
書の内容を変更してもその変更が他の全ての参加者に対
応するクライアントプロセス内のデータに実時間で反映
されなければならない。

【０００４】このような電子会議システムでは、全ての
クライアントプロセス内の文書を示すデータは常に同じ
内容になるように管理されることになり、会議の全ての
参加者に「自分が他の参加者と同じ文書を共有しており
他の参加者と共同でその文書を変更している」という感
覚を与えることができる。

【０００５】上述のような状況で共有データに関する制
御を行う従来の共有データ制御方式では、ある時点にお
いては複数のクライアントプロセスの中の１つのクライ
アントプロセスだけが共有データの変更の権利を持ち
（この権利を「操作権」という）、操作権を複数のクラ
イアントプロセスの間で交換することで各クライアント
プロセスが保持するデータの間に不一致（矛盾）が生じ
ることを防ぐという方式が採用されていた（このような
方式を「操作権方式」ということにする）。

【０００６】なお、共有データの制御に関する他の方式
としては、各クライアントプロセスが保持するコピーの
データの間に矛盾が生じないように、「最初にコピーの
データを保持したクライアントプロセスがそのデータを
共有データに書き戻すまで次のクライアントプロセスが
その共有データのコピーのデータを取得できないように
する」という排他制御が行われる方式が存在する（この
ような方式を「ロック方式」ということにする）。

【０００７】

【発明が解決しようとする課題】上述した従来の共有デ
ータ制御方式等（共有データに関する制御が行われない
方式およびロック方式を含む）には、次のような問題点
があった。

【０００８】 共有データに関する一切の制御を行わ
ない場合の問題点 この場合には、複数のクライアントプロセスが同時に同
一の共有データに対して異なる変更を加えたときに、共
有データの間に矛盾が生じる可能性がある。例えば、あ
るクライアントプロセスＡが共有データの一部を削除す
る変更を行おうとしており、別のクライアントプロセス
ＢがクライアントプロセスＡによって削除されようとし
ている共有データの内容を別の内容に変更しようとして
いるとする。このときに、クライアントプロセスＡから
の削除の要求が先に処理されると、クライアントプロセ
スＢからの変更の要求に対してはすでに存在しなくなっ
た共有データの一部に関する変更が行われることにな
り、結果として矛盾した共有データが生じることにな
る。

【０００９】 操作権方式（従来の共有データ制御方
式）による場合の問題点 この場合には、上述のの場合のような矛盾は生じな
い。なぜならば、ある瞬間に共有データのコピーのデー
タを変更することができるのは、１つのクライアントプ
ロセスに限られているからである。しかし、操作権方式
による場合には、次のような別の問題点がある。すなわ
ち、最初に操作権を取得したクライアントプロセスがデ
ータ（共有データのコピーのデータ）を変更した後も操
作権を持ち続けていると他のクライアントプロセスはい
つまでも自己のデータ（共有データのコピーのデータ）
を変更することができないので、操作権はできるだけ速
やかに１つのクライアントプロセスから解放されるべき
であるという要請がある。一方、１つの変更の要求毎に
毎回操作権の取得および解放が行われるのでは、データ
の変更のための通信の他に操作権の制御のための余計な
通信が必要になる（これによりこの方式が採用される計
算機システムにおける処理の効率が低下してしまう）の
で、操作権の取得および解放は少ない方が望ましいとい
う要請がある。操作権方式（従来の共有データ制御方
式）では、このような２つの相反する要請を適切に満た
して、「いつ操作権を解放すべきか」（「あるクライア
ントプロセスにいつまで操作権を保持させるべきか」）
という困難な決定が必要になるという問題点がある。

【００１０】 ロック方式による場合の問題点 この場合には、複数の利用者が実時間で共有データのコ
ピーのデータを変更するためには、共有データのコピー
および共有データへの書戻しを頻繁に繰り返す必要が生
じ、この方式が採用される計算機システムの処理の効率
が悪くなる。逆にいうと、ロック方式は複数のクライア
ントプロセスが実時間で共有データのコピーのデータを
変更しあうような計算機システム（電子会議システム
等）の応用には適していないといえる。

【００１１】本発明の目的は、上述の点に鑑み、共有デ
ータに矛盾が起きるような変更要求を確実に拒否して複
数のクライアントプロセス内のデータ（共有データのコ
ピーのデータ）に矛盾が生じないことを保証することが
でき（しかも、その非矛盾性の保証のための余計な通信
を不要にする）、操作権の明示的な取得および解放の必
要がなくなる（「あるクライアントプロセスにいつまで
操作権を保持させるべきか」の決定が不要になる）共有
データ制御方式を提供することにある。

【００１２】

【課題を解決するための手段】本発明の共有データ制御
方式は、共有データのコピーのデータとそのデータに関
するタイムスタンプとを保持するクライアントプロセス
と、複数の前記クライアントプロセスとプロセス間通信
によって結合され当該共有データに関するタイムスタン
プを保持し複数の前記クライアントプロセスの中の１つ
の前記クライアントプロセスからの変更要求に対して当
該１つの前記クライアントプロセス内のタイムスタンプ
と自己の保持するタイムスタンプとが同一の場合にのみ
当該１つの前記クライアントプロセスに許可通知を発行
し複数の前記クライアントプロセスの中の１つの前記ク
ライアントプロセス内のデータの変更を当該１つの前記
クライアントプロセス以外の前記クライアントプロセス
内のデータに反映させるサーバプロセスとを有する。

【００１３】

【作用】本発明の共有データ制御方式では、クライアン
トプロセスが共有データのコピーのデータとそのデータ
に関するタイムスタンプとを保持し、複数のクライアン
トプロセスとプロセス間通信によって結合されており当
該共有データに関するタイムスタンプを保持しているサ
ーバプロセスが複数のクライアントプロセスの中の１つ
のクライアントプロセスからの変更要求に対して当該１
つのクライアントプロセス内のタイムスタンプと自己の
保持するタイムスタンプとが同一の場合にのみ当該１つ
のクライアントプロセスに許可通知を発行し複数のクラ
イアントプロセスの中の１つのクライアントプロセス内
のデータの変更を当該１つのクライアントプロセス以外
のクライアントプロセス内のデータに反映させる。

【００１４】

【実施例】次に、本発明について図面を参照して詳細に
説明する。

【００１５】図１は、本発明の共有データ制御方式の一
実施例の構成を示すブロック図である。本実施例の共有
データ制御方式は、クライアントプロセス１〜３と、プ
ロセス間通信５〜７によってクライアントプロセス１〜
３と通信を行うサーバプロセス４と、プロセス間通信５
〜７とを含んで構成されている。

【００１６】クライアントプロセス１は、データ８と、
データ８に関するタイムスタンプ１１とを保持してい
る。

【００１７】クライアントプロセス２は、データ９と、
データ９に関するタイムスタンプ１２とを保持してい
る。

【００１８】クライアントプロセス３は、データ１０
と、データ１０に関するタイムスタンプ１３とを保持し
ている。

【００１９】サーバプロセス４は、データ８〜１０に係
る共有データ（データ８〜１０はその共有データのコピ
ーのデータに該当する）に関するタイムスタンプ１４を
保持している。

【００２０】図２は、クライアントプロセス１〜３がサ
ーバプロセス４に変更要求を発行する際の処理を示す流
れ図である。この処理は、変更要求等送信ステップ２１
と、返事待機ステップ２２と、返事判定ステップ２３
と、タイムスタンプセットステップ２４と、変更要求デ
ータ反映ステップ２５とからなる。

【００２１】図３は、クライアントプロセス１〜３がサ
ーバプロセス４からの変更通知を受け付ける際の処理を
示す流れ図である。この処理は、変更通知受付けステッ
プ３１と、タイムスタンプセットステップ３２と、変更
通知データ反映ステップ３３とからなる。

【００２２】図４は、サーバプロセス４がクライアント
プロセス１〜３の変更要求を受け付ける際の処理を示す
流れ図である。この処理は、変更要求受付けステップ４
１と、タイムスタンプ判定ステップ４２と、タイムスタ
ンプ増加ステップ４３と、許可通知等返送ステップ４４
と、変更要求等通知ステップ４５と、不許可通知返送ス
テップ４６とからなる。

【００２３】図５は、本実施例の共有データ制御方式の
具体的な動作を説明するためのブロック図（複数のクラ
イアントプロセス（クライアントプロセス１および３）
が同時に変更要求を発行する場合の本実施例の共有デー
タ制御方式の動作を説明するためのブロック図）であ
る。

【００２４】次に、このように構成された本実施例の共
有データ制御方式の動作について説明する。なお、以下
の説明では、プロセス間通信５〜７については言及しな
いが、クライアントプロセス１〜３とサーバプロセス４
との間で通信が行われる場合にはプロセス間通信５〜７
が介在している。

【００２５】各クライアントプロセス１〜３は、共有デ
ータのコピーであるデータ８〜１０と、データ８〜１０
に関するタイムスタンプ１１〜１３とを保持している。

【００２６】サーバプロセス４は、データを保持せず
に、データ８〜１０のコピー元である共有データに関す
るタイムスタンプ１４を保持している。

【００２７】初期状態では、全てのクライアントプロセ
ス１〜３が保持しているデータ８〜１０の内容は一致し
ており、全てのクライアントプロセス１〜３の持つタイ
ムスタンプ１１〜１３の全てとサーバプロセス４の持つ
タイムスタンプ１４とは一致している。

【００２８】あるクライアントプロセス（クライアント
プロセス１とする）でデータ８の変更に対する要求が発
生すると、クライアントプロセス１はその変更の内容を
示す変更要求とクライアントプロセス１内のタイムスタ
ンプ１１とを組にしてサーバプロセス４に送信し（ステ
ップ２１）、サーバプロセス４からの返事を待つ（ステ
ップ２２）。

【００２９】サーバプロセス４は、クライアントプロセ
ス１からの変更要求を受け付け（ステップ４１）、サー
バプロセス４内のタイムスタンプ１４とステップ４１で
受け付けた変更要求と組になっているタイムスタンプ
（クライアントプロセス１内のタイムスタンプ１１）と
を比較する（ステップ４２）。

【００３０】ステップ４２の比較で両者が一致すれば、
サーバプロセス４は、タイムスタンプ１４を１だけ増加
し（ステップ４３）、変更要求を送信してきたクライア
ントプロセス１に許可通知（「許可」を示すフラグ）と
タイムスタンプ１４とを組にして返送し（ステップ４
４）、ステップ４１で受け付けた変更要求とサーバプロ
セス４内のタイムスタンプ１４とを組にして他のクライ
アントプロセス２および３に通知する（ステップ４
５）。

【００３１】一方、ステップ４２の比較で両者が一致し
なければ、サーバプロセス４は、不許可通知（「不許
可」を示すフラグ）をクライアントプロセス１に返送す
る（ステップ４６）。

【００３２】クライアントプロセス２および３は、サー
バプロセス４からの変更通知を受け付け（ステップ３
１）、その変更通知と組になっているタイムスタンプ
（サーバプロセス４内のタイムスタンプ１４）をクライ
アントプロセス２および３内のタイムスタンプ１２およ
び１３としてセットし（ステップ３２）、クライアント
プロセス２および３が保持しているデータ９および１０
をその変更通知を反映して更新する（ステップ３３）。

【００３３】変更要求を送信したクライアントプロセス
１は、サーバプロセス４からの返事を受け付けると、そ
の返事が許可通知であるか否かを判定する（ステップ２
３）。

【００３４】ステップ２３の判定で返事が許可通知であ
る場合には、クライアントプロセス１は、その許可通知
と組になっているタイムスタンプ（サーバプロセス４内
のタイムスタンプ１４）をクライアントプロセス１内の
タイムスタンプ１１としてセットし（ステップ２４）、
ステップ２１で送信した変更要求を反映して自己のデー
タ８の更新を行う（データ８の変更は成功する）（ステ
ップ２５）。

【００３５】一方、ステップ２３の判定で返事が許可通
知でない場合（不許可通知である場合）には、クライア
ントプロセス１は、データ８の変更を行わない（データ
８の変更は失敗する）。

【００３６】次に、図５を参照して、２つのクライアン
トプロセス（クライアントプロセス１および３とする）
が同時にデータ８および１０の変更要求（後述する変更
要求５２および５３）を発行した場合の本実施例の共有
データ制御方式の動作について説明する。

【００３７】まず、サーバプロセス４が変更通知５１と
タイムスタンプ１４とを組にして各クライアントプロセ
ス１〜３に送信している状況を想定する（図５中ではサ
ーバプロセス４からクライアントプロセス１への変更通
知５１だけを示しているがクライアントプロセス２およ
び３に対しても同一の変更通知が送信されている）。

【００３８】変更通知５１に関する図３に示す処理をま
だ終了していないクライアントプロセス１は、変更要求
５２とクライアントプロセス１内のタイムスタンプ１１
（「０２」を示している）とを組にしてサーバプロセス
４に送信する。

【００３９】同時に、サーバプロセス４からの変更通知
（変更通知５１と同一の変更通知）に関する図３に示す
処理を終了したクライアントプロセス３も、別の変更要
求５３とクライアントプロセス３内のタイムスタンプ１
３（「０３」を示している）とを組にしてサーバプロセ
ス４に送信する。

【００４０】サーバプロセス４は、２つの変更要求５２
および５３を受け付け、両方の変更要求５２および５３
と組になっているタイムスタンプ（タイムスタンプ１１
および１３）とサーバプロセス４内のタイムスタンプ１
４（「０３」を示している）とを比較する。

【００４１】この比較の結果（タイムスタンプ１１とタ
イムスタンプ１４とは一致せずに、タイムスタンプ１３
とタイムスタンプ１４とは一致するとう結果）に基づい
て、サーバプロセス４は、変更要求５２に対しては不許
可通知をクライアントプロセス１に返送し、変更要求５
３に対しては許可通知をクライアントプロセス３に返送
する。したがって、クライアントプロセス１内のデータ
８の変更は失敗し、クライアントプロセス３内のデータ
１０の変更は成功する。

【００４２】次に、本実施例、ひいては本発明の共有デ
ータ制御方式と従来の技術である「操作権方式」とが併
用される場合の動作について説明する。

【００４３】この場合には、クライアントプロセス１〜
３およびサーバプロセス４は、以下のようにして動作す
ることになる。

【００４４】 操作権を取得したいクライアントプロ
セス１，２または３は、操作権の取得要求と自己が保持
するタイムスタンプ１１，１２または１３とを組にして
サーバプロセス４に送信する。

【００４５】 サーバプロセス４は、クライアントプ
ロセス１，２または３から送られてきたタイムスタンプ
１１，１２または１３と自己が保持するタイムスタンプ
１４とを比較する。

【００４６】 の比較で両者が一致する場合には、
サーバプロセス４は、サーバプロセス４内のタイムスタ
ンプ１４を１だけ増加し、増加後のタイムスタンプ１４
と許可通知とを操作権の取得要求を送信してきたクライ
アントプロセス１，２または３に返送する。また、サー
バプロセス４は、操作権の保持者としてそのクライアン
トプロセス１，２または３の識別情報を記録しておく。
この状態を、「操作権が設定された状態」と呼ぶ。

【００４７】 の比較で両者が一致しない場合に
は、サーバプロセス４は、不許可通知を操作権の取得要
求を送信してきたクライアントプロセス１，２または３
に返送する。

【００４８】 操作権が設定された状態では、操作権
を保持するクライアントプロセス１，２または３からの
変更要求以外に対しては、たとえその変更要求と組にな
っているタイムスタンプ１１，１２または１３がサーバ
プロセス４内のタイムスタンプ１４と一致したとして
も、サーバプロセス４は全て不許可通知を返送する。

【００４９】なお、本実施例では共有データが１つ（共
有データのコピーのデータ８〜１０が１組）である場合
について述べたが、共有データが複数である場合にも、
各共有データに対して別組のタイムスタンプを用意する
ことによって、本発明を適用することができることはい
うまでもない。

【００５０】

【発明の効果】以上説明したように本発明は、タイムス
タンプの考え方を導入することにより、操作権の明示的
な取得および解放を要することなく、複数のクライアン
トプロセス内のデータ（共有データのコピーのデータ）
に矛盾が生じないことを保証することができ、しかもそ
の非矛盾性の保証のために通信量を増大させることがな
いという効果がある。このような効果により、本発明の
共有データ制御方式は、電子会議システム等への応用に
おいて有効性を発揮する。

【００５１】以下に、上述の効果について詳細に説明す
る。

【００５２】 タイムスタンプの管理をサーバプロセ
スによって統一的に行うこと（タイムスタンプを増加す
ることができるのはサーバプロセスのみであり、同時に
複数のクライアントプロセスからサーバプロセスに変更
要求が送信されたときにはサーバプロセスによるタイム
スタンプのチェックにより排他制御が行われる）によ
り、共有データや共有データのコピーのデータに矛盾が
生じるような変更要求を確実に拒否することができる。

【００５３】 クライアントプロセスは変更要求をま
ずサーバプロセスに通知してその返事の判定に基づいて
実際のデータの変更を行うか否かを決定しているので、
クライアントプロセスとサーバプロセスとの間の通信量
は変更要求の通信とその返事の通信との２回（１往復）
でありタイムスタンプを使用しない場合の通信量と変わ
らない。すなわち、タイムスタンプの考え方の導入によ
る通信量の増大は生じない。

【００５４】 従来の共有データ制御方式（操作権方
式）におけるような操作権の明示的な取得および解放を
行う必要がなくなり、「あるクライアントプロセスにい
つまで操作権を保持させるべきか」という困難な決定を
行うことが不要になる。

【図面の簡単な説明】

【図１】本発明の一実施例の構成を示すブロック図であ
る。

【図２】図１中のクライアントプロセスがサーバプロセ
スに変更要求を発行する際の処理を示す流れ図である。

【図３】図１中のクライアントプロセスがサーバプロセ
スからの変更通知を受け付ける際の処理を示す流れ図で
ある。

【図４】図１中のサーバプロセスがクライアントプロセ
スからの変更要求を受け付ける際の処理を示す流れ図で
ある。

【図５】図１に示す共有データ制御方式の具体的な動作
を説明するためのブロック図である。

【符号の説明】

１〜３ クライアントプロセス ４ サーバプロセス ５〜７ プロセス間通信 ８〜１０ データ １１〜１４ タイムスタンプ ５１ 変更通知 ５２，５３ 変更要求

Claims (1)

【特許請求の範囲】
1. 【請求項１】 共有データのコピーのデータとそのデー
   タに関するタイムスタンプとを保持するクライアントプ
   ロセスと、 複数の前記クライアントプロセスとプロセス間通信によ
   って結合され、当該共有データに関するタイムスタンプ
   を保持し、複数の前記クライアントプロセスの中の１つ
   の前記クライアントプロセスからの変更要求に対して当
   該１つの前記クライアントプロセス内のタイムスタンプ
   と自己の保持するタイムスタンプとが同一の場合にのみ
   当該１つの前記クライアントプロセスに許可通知を発行
   し、複数の前記クライアントプロセスの中の１つの前記
   クライアントプロセス内のデータの変更を当該１つの前
   記クライアントプロセス以外の前記クライアントプロセ
   ス内のデータに反映させるサーバプロセスとを有するこ
   とを特徴とする共有データ制御方式。