JP2005100432A - 情報処理方法及び装置 - Google Patents
情報処理方法及び装置 Download PDFInfo
- Publication number
- JP2005100432A JP2005100432A JP2004308468A JP2004308468A JP2005100432A JP 2005100432 A JP2005100432 A JP 2005100432A JP 2004308468 A JP2004308468 A JP 2004308468A JP 2004308468 A JP2004308468 A JP 2004308468A JP 2005100432 A JP2005100432 A JP 2005100432A
- Authority
- JP
- Japan
- Prior art keywords
- clients
- cooperative
- groups
- work
- information processing
- 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.)
- Pending
Links
Images
Abstract
【課題】共有資源の競合に原因する協調作業のサービスレベルの低下を防止することが可能な情報処理方法及び装置を提供する。
【解決手段】複数のクライアントによる協調作業の実行において、セッションに参加している複数の複数のクライアント間で共有されている協調操作対象のデータへの操作頻度が検出される。次に、検出手段で検出された操作頻度が所定値を越えた場合に、複数のクライアントを複数のグループに分割し(S5001)、協調操作対象のレプリカを生成し、分割されたグループの夫々に協調操作対象として対応づける(S5002)。そして、複数のクライアントの各々が、所属するグループに対応づけられた協調操作対象に対して操作を行うように通知する(S5003)。
【選択図】 図7
【解決手段】複数のクライアントによる協調作業の実行において、セッションに参加している複数の複数のクライアント間で共有されている協調操作対象のデータへの操作頻度が検出される。次に、検出手段で検出された操作頻度が所定値を越えた場合に、複数のクライアントを複数のグループに分割し(S5001)、協調操作対象のレプリカを生成し、分割されたグループの夫々に協調操作対象として対応づける(S5002)。そして、複数のクライアントの各々が、所属するグループに対応づけられた協調操作対象に対して操作を行うように通知する(S5003)。
【選択図】 図7
Description
本発明は複数のユーザによる協調作業が可能な情報処理装置及びその方法に関する。
高速なネットワークで結合された高性能計算機の普及や、分散計算ソフトウェア技術の発達などにより、複数人から成るグループによる協調作業が行われるシステムが実用化されてきている。従来の協調作業システムでは、システム実現上における各種の制約によって、結果的に協調作業のサービスレベルの低下が防がれていた。
たとえば、発言権(以下、フロア)制御機能などを用いた場合には、フロアをクライアント間で手渡ししてゆくことにより、共有されているデータへの更新アクセスを、フロアを保持している参加者に限定し、他の参加者からの更新要求を認めなかった。そして、この排他制御機能の副作用により、更新要求の集中が防がれ、結果的に協調作業におけるサービス低下を避けることが出来た。
また、専用テレビ会議システムのような単機能型の専用協調作業システムでは、電話回線の許容量などのハードウェア構成上の制約から、システムの能力を越えた数の参加者は存在し得なかった。そのため、例えば、ある協調作業への参加に際して、参加者数が許容量以下であれば特別な参加制約をすることなく参加を許可するが、逆に、許容量を越えていれば、どんな種類の参加も許されない。
また、従来のデータベースサービスなどでは、アクセス権の有無やデータベースの一貫性保持などによるクライアントの制限は行なわれていたが、一方で、サービスレベルの維持を目的としたクライアントの制限は行なわれていないのが現状である。
近年、高速なネットワークで結合された高性能計算機の普及や、分散計算ソフトウェア技術の発達などによって、複数人からなるグループによる協調作業を計算機上で行うことが可能になってきている。このような状況下では、参加者数をハードウェア構成から制限することはなく、ネットワークあるいは計算機の能力の許す範囲で、参加を受け入れるようになってきている。そのため、システムの能力以上のクライアントが参加してしまうことにより、処理能力不足となり、各クライアントの得られるサービスのレベルが低下するという事態が発生する。
例えば、計算機ネットワークで、クライアント毎に異なった動画像を、決められた画質でリアルタイムに転送することを考えてみる。このとき、計算機ネットワークの容量は有限であることから、無制限にクライアントを受け入れて、複数の動画像データを無秩序に送り出そうとすると、動画像データの転送に衝突が発生し、動画像を待っている各々のクライアントに、適切な動画像データが配送されないという事態となってしまう。同様に、協調作業中におけるデータ共有に関しても、無制限のクライアントの受け入れは、各クライアントへのサービスの低下をもたらす。
特に、本発明が対象とする協調作業中に共有されるデータに関しては、このような状況下での更新要求の集中に原因して、各クライアントへの『レスポンスタイムの遅れ』や『トランザクションアボートの増大』などサービスの低下のみならず、その処理のために他の協調作業処理が阻害されるなどの問題が発生する。つまり、共有データへのアクセスを適切に制御して、協調作業のサービスのレベルを保障することが出来ないと、協調作業の進行に支障が出るという問題がある。協調作業におけるサービスレベルが正しく制御されないことによる具体的な問題点は、以下のようにまとめられる。
(1)データ共有機能自身における各クライアントへのサービスの低下。例えばレスポンスタイムの遅れやトランザクションアボートの増大などである.
(2)他の協調作業処理の阻害。例えば、セッション内の交渉機能の阻害などである。
(2)他の協調作業処理の阻害。例えば、セッション内の交渉機能の阻害などである。
本発明は、上記の問題に鑑みてなされたものであり、共有資源の競合に原因する協調作業のサービスレベルの低下を防止することが可能な情報処理方法及び装置を提供することを目的とする。
上記の目的を達成するための本発明の一態様による情報処理装置は以下の構成を備えている。即ち、
複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出手段と、
前記検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割手段と、
前記分割手段で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理手段とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行う。
複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出手段と、
前記検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割手段と、
前記分割手段で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理手段とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行う。
上記の構成によれば、複数のクライアントによる協調作業の実行において、検出手段は、セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する。分割手段は、検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する。更に処理手段は、前記分割手段で分割されたグループに協調操作対象として協調操作対象のレプリカを対応づける。そして、複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行う。操作対象のレプリカを生成し、一つの操作対象に対する操作を減少させることで、操作負荷が分散されるので、サービスレベルの維持が図られる。即ち、協調作業を管理するサーバ等の1つ当たりのクライアント数を分散することでサービスレベルの維持を図るものである。
また、好ましくは、前記分割手段は、前記協調作業への参加時刻に基づいて前記複数のクライアントを複数のグループに分割する。協調作業について、同レベルの熟練度のクライアントをそろえることで、より効果的な協調作業を行なえるからである。
また、好ましくは、前記分割手段は、協調作業対象へのアクセス分布に基づいて前記複数のクライアントを複数のグループに分割する。更新要求や参照要求の衝突が発生しにくいようにクライアントを分割することが可能となるからである。
また、好ましくは、前記分割手段は、前記複数のクライアントに対して分割の指示を行い、該複数のクライアントは各クライアント間の交渉によって複数のグループに分割される。協調作業を管理するサーバ等の処理負担が軽減されるからである。
以上説明したように本発明によれば、共有資源の競合に原因する協調作業のサービスレベルの低下を防止することが可能となる。
以下に添付の図面を参照して本発明の好適な一実施例を説明する。
<実施例1>
本実施例1では、複数人が参加する協調編集作業において、共有データへのアクセス履歴を利用して、協調作業におけるレスポンスタイムやトランザクション達成率(コミット成功率)など適切なサービスレベル(Quality of Service)を維持する場合について説明する。特に、協調編集作業中において利用されている共有データ(例えば、編集対象の文書)についての更新度合が所定の値を越えた場合に、協調作業に関与しているクライアントの一部に更新操作禁止の制約を課す例について述べる。
本実施例1では、複数人が参加する協調編集作業において、共有データへのアクセス履歴を利用して、協調作業におけるレスポンスタイムやトランザクション達成率(コミット成功率)など適切なサービスレベル(Quality of Service)を維持する場合について説明する。特に、協調編集作業中において利用されている共有データ(例えば、編集対象の文書)についての更新度合が所定の値を越えた場合に、協調作業に関与しているクライアントの一部に更新操作禁止の制約を課す例について述べる。
すなわち、本実施例1は、協調作業のサービスレベルを維持するために、
(1)共有データへの更新度合を観測している点と、
(2)協調作業のクライアントの一部を更新操作禁止に制約することで、残りのクライアントのサービスレベルを向上させる点と、
に特徴がある。
(1)共有データへの更新度合を観測している点と、
(2)協調作業のクライアントの一部を更新操作禁止に制約することで、残りのクライアントのサービスレベルを向上させる点と、
に特徴がある。
また、本実施例1では、データ共有機構内部において同様のサービス維持処理を実現した場合に比べて、個々のデータアクセス要求ではなく、協調作業のクライアントという、より大局的な単位で制約を課せることに特徴がある。
以下、まず本実施例を説明するための装置の構成について説明し、次に、その動作手順について述べる。
[1]構成の説明
図1は、本実施例1の情報処理システムを説明するブロック構成図である。同図において、101は入力装置であり、本実施例上で動作するプログラムの利用者が、コマンドやデータを入力する。入力装置101は、キーボード、マウス、パッド、あるいは、マイクロフォンなどで構成される。102はCPUであり、本実施例の協調編集作業ソフトウェアならびにサービス維持プログラム10を実行する。ここでは、一つのCPUを使っているが、それぞれに独立なCPUを利用するようなハードウェア形態であっても構わない。
図1は、本実施例1の情報処理システムを説明するブロック構成図である。同図において、101は入力装置であり、本実施例上で動作するプログラムの利用者が、コマンドやデータを入力する。入力装置101は、キーボード、マウス、パッド、あるいは、マイクロフォンなどで構成される。102はCPUであり、本実施例の協調編集作業ソフトウェアならびにサービス維持プログラム10を実行する。ここでは、一つのCPUを使っているが、それぞれに独立なCPUを利用するようなハードウェア形態であっても構わない。
103は、本実施例における協調編集作業システムの内容、および、サービス維持プログラム10の結果(データアクセスモードの変更のメッセージなど)をユーザに表示するための出力装置で、CRTディスプレイあるいはプロジェクターなどである。ここでは、説明を簡単にするため、単一の表示装置を使って複数の協調編集作業用の表示を行っているが、それぞれに独立な表示装置を使ってもかまわない。
104は記憶装置であり、本実施例で説明する協調編集作業、サービス維持プログラム10などを実現する制御プログラム、ならびに、それらのプログラムが利用するデータを保存する。ここでは、説明を簡単にするために、単一の記憶装置を使っているが、記憶対象毎に異なった記憶装置を用いてもよいし、ハードディスクなどの二次記憶装置を含む階層化された記憶装置であってもよい。
なお、ここにプログラムとして保存されている制御プログラムは、具体的には、サービス維持プログラム10、観測プログラム20、調整プログラム30(図3参照)である。また、この記憶装置104は、一時的に使われるデータを記憶する主記憶装置と大量のデータを永続的に保持しておく二次記憶装置とに分かれていても良い。また、装置の状態に関係なく永続的なデータを保存するROMなど読み出し専用記憶装置が含まれていても良い。
105は通信装置であり、計算機ネットワークに接続するFDDIコントローラなどである。106は計算機バスであり、以上に述べた各構成要素101〜105を結合する。
100は端末を示し、上記101〜106によって構成される協調編集作業を行うことが可能である。また、200及び300は、端末100と同様の構成の協調編集作業用の端末である。端末100、200、300は、それぞれの参加者に対して、協調作業を行なうための入出力ならびに処理を行なう。尚、本例では3つの端末を利用する構成について説明するが、端末の数は、2つあるいは4つ以上であってもよい。
5000は、本実施例で説明する協調編集作業を複数の計算機に渡って実現するための計算機ネットワークであり、例えば、Ethernet(登録商標)やFDDIなどである。本実施例では、汎用の計算機を利用した実現形態について説明しているため、その通信手段として計算機ネットワークを用いているが、これは、ISDNなどの広域回線であってもよい。
次に、本実施例1のソフトウェア構成について説明する。
まず、大きくプログラムの実行単位、例えば、UNIX(登録商標)におけるプロセスのレベルで見た場合のソフトウェア構成について説明する。この観点から見た場合、各端末では、協調編集用ソフトウェアが実行されており、協調編集作業への参加者は、それぞれ別々の端末に配置されている。図2に実施例1における協調編集作業の状態を示す。また、いずれかの端末(例えば端末100)では、セッションサーバーが実行されている。
図3に実施例1におけるセッションサーバのプログラム構成を示す。ここで、セッションサーバは、協調作業を行うに当たって必要となる各種の機能(たとえば、セッション内の交渉機能やデータ共有機構など)を提供するサーバである。以下に詳細を説明するサービス維持プログラム10や観測プログラム20などは、このセッションサーバ内で動作する。
[2]動作手順の概要
次に、本実施例における処理の動作手順についての概要を述べ、次に詳細な動作を説明する。
次に、本実施例における処理の動作手順についての概要を述べ、次に詳細な動作を説明する。
図4は実施例1のシステム上で動作する協調編集作業におけるサービス維持プログラム10の処理手順を表すフローチャートである。
本処理は、セッションサーバのデータ共有機構によってクライアント(ここでは、協調編集作業用ソフトウェア)間で共有されているデータに関する更新要求の度合いが、あるしきい値を越えた際に、ある条件で選択された一部のクライアントを更新操作禁止に制約すること、すなわち、一部のクライアントを犠牲にすることで、目的とする協調編集作業におけるサービス維持を実現する。
また、本処理は、セッションサーバ内の処理であるが、各クライアントからの要求に応じてセッションサーバ内で進行する協調作業(ここでは、協調編集作業)とは、非同期に実行される。この非同期の実行に関しては、たとえば、Machオペレーティングシステムに実装されているthreadパッケージなどを利用することで実現可能である。この際、協調作業中に共有されるデータに関しては、一貫性を保持したread操作が行なわれるものとする。
なお、本実施例1では、観測プログラム20において『該当セッション内の共有されているデータへの更新要求が、10秒間に200回以上であるか?』を観測し、調整プログラム30において『もっとも最近にセッションに参加したクライアント』を選択し、その『更新操作を禁止する』という制約を課すポリシーとする。
まず、 観測のための一定時間待つ(ステップS1001)。例えば、ここでは、観測条件に合わせて10秒間とする。次に、観測プログラム20により、共有されているデータへの更新要求度合とそのしきい値との関係を調べる(ステップS1002)。そして、しきい値を越えているなら、ステップS1003よりステップS1004へ進み、調整プログラム30を実行する。その後、ステップS1001にもどる。また、ステップS1003においてしきい値を越えていないなら、そのままステップ1001へもどる。
ここでは、説明を簡単にするために協調作業と非同期実行する場合について説明しているが、協調作業との間にデータの一貫性を保障するためには、適切な同期手段、たとえば、ロック機構などを用いてもよい。反対に、一貫性を必要としない場合には、dirty readの技法などを用いることで実行性能の向上を図ることも考えられる。
本実施例1で説明したサービス維持プログラム10の動作は、永久ループで構成されており、セッションサーバの実行が続く限り、サービス維持プログラム10も動作し続けるものとなっている。しかしながら、サービス維持プログラム10の動作形態はこれに限られるものではなく、例えば、セッションサーバへの協調作業の要求に同期して、サービス維持プログラム10を動作させるようにしてもよい。
[3]観測プログラム20
次に、本実施例1のサービス維持プログラム10のステップS1002において参照した更新要求度合としきい値との関係を測定するための観測プログラム20を説明する。図5は実施例1による観測プログラムの処理手順を説明するフローチャートである。ここでは、協調編集作業ソフトウェアの中で利用する共有データのアクセス統計情報を観測する例について説明する。
次に、本実施例1のサービス維持プログラム10のステップS1002において参照した更新要求度合としきい値との関係を測定するための観測プログラム20を説明する。図5は実施例1による観測プログラムの処理手順を説明するフローチャートである。ここでは、協調編集作業ソフトウェアの中で利用する共有データのアクセス統計情報を観測する例について説明する。
まず、本システムにおけるデータ共有機構に、アクセス統計情報のうち、『過去10秒間の更新情報』を問い合わせる(ステップS2001)。尚、本システムにおけるデータ共有機構は、協調編集作業において、各端末からの更新要求の回数を測定する機能を有する。
次に、得られた更新情報の更新要求回数をカウントして、予め設定してあったしきい値(本例では200)と比較する(ステップS2002)。本実施例では、カウントに際して、更新対象のオブジェクトには無関係に、更新要求回数をカウントするものとする。そして、比較結果を観測結果として返す(ステップS2003)。
ここでは、更新要求回数をカウントしているが、実際にコミットされた更新回数をカウントするように構成してもよい。
また、本例では、更新要求の対象となるオブジェクトと無関係に要求回数をカウントしているが、対象となるオブジェクトを限定して、例えば、協調作業の実行性能にクリティカルなオブジェクトへの要求回数をカウントするように構成してもよい。
更に、共有データに対して複数のセッションモードから更新要求等の操作要求がある場合は、複数のセッションモードからの操作要求を観測するように構成してもよい。
[4]調整プログラム30
次に、本実施例のサービス維持プログラム10のステップS1004で実行される調整プログラム30について説明する。図6は、実施例1による調整プログラムの処理手順を表すフローチャートである。本プログラムは、ある条件で選択された一部のクライアントを更新操作禁止に制約することにより、つまり、一部のクライアントに犠牲を強いることにより、協調作業における共有データの更新作業量を減らし、これにより、協調作業のサービスを提供するセッションサーバにかかる負荷の低減を図るものである。なお、本実施例1では、協調編集用ソフトウェアが、クライアントに相当する。
次に、本実施例のサービス維持プログラム10のステップS1004で実行される調整プログラム30について説明する。図6は、実施例1による調整プログラムの処理手順を表すフローチャートである。本プログラムは、ある条件で選択された一部のクライアントを更新操作禁止に制約することにより、つまり、一部のクライアントに犠牲を強いることにより、協調作業における共有データの更新作業量を減らし、これにより、協調作業のサービスを提供するセッションサーバにかかる負荷の低減を図るものである。なお、本実施例1では、協調編集用ソフトウェアが、クライアントに相当する。
まず、協調作業に参加しているクライアントの一部を選択する(ステップS3001)。ここでの選択条件は、『もっとも最近にセッションに参加したクライアント』である。次に、選択されたすべてのクライアントについて、更新操作禁止となるように制約を課す(ステップS3002)。これは、例えば、協調作業システムのデータ共有機構に制約の内容を保持し、該当するクライアントからの更新要求を無視あるいは拒否するように設定することで実現可能である。
ここでは、説明を簡単にするために、データ共有機構が該当するクライアントからの更新要求を無視あるいは拒否する例について説明したが、実行効率を向上させるために、クライアントに、その旨通知し、以降の更新要求の発行自体を抑制することで実現することも考えられれる。
ここでは、一部のクライアントを選び出し制約を課す例について説明したが、すべてのクライアントに関して、単位時間中にデータ共有機構に発行可能な更新要求の上限を設定するような制約も考えられる。
ここでは、説明を簡単にするため、『もっとも最近にセッションに参加したクライアント』を調整対象として選択したが、他の選択方法も容易に想像できる。たとえば、仮想記憶管理における LRU 手法と同様に、最後のアクセスがあったのが最も古いクライアントを選択することである。また、セッションサーバが各クライアント毎に、何らかの優先順位を保持し、それを利用することも可能である。
また、本実施例では、セッションサーバが、協調作業中に利用するデータ共有機構の統計情報を観測することで、本実施例のサービス維持の処理を実現する例について説明したが、協調作業システムの通信機構の統計情報を観測することで同様の処理を実現するように構成してもよい。
また、本実施例では、協調作業の負荷の軽減を図るために、更新操作禁止の制約を課しているが、これは、データ共有機構において、読み出し操作に比べて、更新操作の負荷が高いことを前提としているためである。共有データ機構がより柔軟なアクセスモードを支援している場合は、読み出し操作禁止等の更新操作禁止以外の制約を課してもよい。
また、ここでは、共有データ機構へのアクセス制限という制約を課すことによって調整を行っているが、選択条件によって選びだされたクライアントを協調作業から除去することで、残りのクライアントへのサービスレベルを維持するようなポリシーをとってもよい。
また、本実施例では、クライアントに対して更新操作禁止を指定する処理を示したが、更新要求の低減時に、再び更新操作可能に戻す構成を設けてもよい。また、通信システムにおけるトークンリング方式と同様に、更新操作禁止状態にあるクライアントを、協調作業に関っているクライアント群の中で周期的に切り替えるようにしてもよい。
以上説明したように、本実施例によれば、協調作業における一つのセッションサーバの負荷が適切なレベルに維持され、結果として、セッションサーバの提供するサービスのレベルが維持される。すなわち、観測プログラムが『該当セッション内の共有されているデータへの更新要求が、10秒間に200回以上であるか?』を観測し、その観測結果に応じて、調整プログラムが『もっとも最近にセッションに参加したクライアント』を選択し、『更新操作を禁止する』という制約を課すことで、制約を受けない残りのクライアントには、制約操作以前よりも多くのサービスをセッションサーバから受けることが可能となる。この結果として、レスポンスタイムの増大やトランザクション失敗率(アボート率)の増大などのようなサービスレベルの低下を回避することができる。
<実施例2>
次に実施例2を説明する。
次に実施例2を説明する。
本実施例2では、実施例1と同様、複数人が参加する協調編集作業においてサービスレベルを維持する。特に、実施例1の調整プログラムによる調整処理において、調整対象として特定のクライアントを選択することをせずに、クライアント群を分割することでデータ共有機構における負荷分散を行うことで、十分なサービスレベルの維持を可能とすることを特徴とする。
[1]実施例2の動作手順の概要
本実施例2では、実施例1と同様の構成の元で、同様のサービスレベルの維持を行なう。ただし、調整プログラム30の代りに拡張調整プログラムを用いて調整を行い、サービスレベルの維持を図る。
本実施例2では、実施例1と同様の構成の元で、同様のサービスレベルの維持を行なう。ただし、調整プログラム30の代りに拡張調整プログラムを用いて調整を行い、サービスレベルの維持を図る。
[2]拡張調整プログラム
拡張調整プログラムは、図3に示したセッションサーバ中のサービス維持機能における調整プログラム30に置き換えられたものである。図7は、実施例2による拡張調整プログラムによる制御を表すフローチャートである。本プログラムは、ある協調作業中のクライアント群を2つのグループに分割することで、協調作業における共有データ機構の更新負荷を減らし、これによって、協調作業の負荷低減を図るものである。
拡張調整プログラムは、図3に示したセッションサーバ中のサービス維持機能における調整プログラム30に置き換えられたものである。図7は、実施例2による拡張調整プログラムによる制御を表すフローチャートである。本プログラムは、ある協調作業中のクライアント群を2つのグループに分割することで、協調作業における共有データ機構の更新負荷を減らし、これによって、協調作業の負荷低減を図るものである。
まず、協調作業に参加しているクライアント群を参加時刻順に整列し、前後2つに分割する(ステップS5001)。説明を明確にするために、それぞれをグループA、グループBと呼ぶ。
次に、セッションサーバのデータ共有機構が保持しているオリジナルの共有データのレプリカを生成し、グループBに関しては、このレプリカを利用するように設定しなおす(ステップS5002)。これは、例えば、オブジェクト指向データベースシステムなどに実装されているバージョニング機能によって実現できる。
次に、2つのグループのクライアントについて、「グループを分割し共有データのレプリカを生成したので、定期的にマージ操作を行う必要がある」旨をメッセージする(ステップS5003)。マージ操作に関しては、バージョニング機能の一部として実装されている。例えば、オブジェクト指向データベースシステムにObjectStoreを利用した場合、関数os_configuration::merge()を利用することでマージ操作を達することができる。
本実施例2では、説明を単純にするために、レプリカ生成後のオリジナルデータとのデータの一貫性については、クライアントがマージ操作を非同期に実行することに委ねている。この他に、データ共有機構を拡張して、オリジナルデータの更新に同期して、レプリカデータの一貫性を保証するようなプロトコルを追加することも考えられる。
例えば、分散データベースシステムにおけるデータコヒーレンシーアルゴリズムが利用できる。ここでは、データ共有機構の負荷の低減を図る目的から、weakconsistencyモデルの実現手法について述べる。つまり、オリジナルデータの更新が発生した際には、そのトランザクションのコミット時点で、レプリカの不活性化(invalidate)を行なって、以降のレプリカデータへのアクセス時にオリジナル側から複写する手法である。このような手法を利用することで、トランザクションがコミットされるまでは、レプリカデータの利用が可能になるので、それだけオリジナルデータ側のデータ共有機構の負荷が低減される。
また、本実施例2では、参加時間順に並べてクライアント群の分割を行ったが、共有データ機構内のデータへのアクセス分布を参照して、参照要求あるいは更新要求の衝突が発生しにくいようなクライアント群の分割を行うことも考えられる。
また、本実施例2では、クライアント群を2つのグループに分割しているが、3つ以上のグループに分割することも上記実施例の記載から実現できることは明らかである。
さらに、本実施例2では、グループの分割をセッションサーバ側の決定に基づいて行っているが、セッションサーバは、アドバイスのメッセージを出すのみで、実際のグループ分割は、クライアント間の交渉に委ねるようにしてもよい。
以上のように、本実施例2によれば、協調作業において、1つのセッションサーバの負荷が適切なレベルに維持され、結果として、実施例1と同様に、セッションサーバの提供するサービスのレベルが維持される。
以上説明したように、上記各実施例によれば、協調作業におけるデータ共有機構へのアクセスを調整することにより、データ共有機構依存の更新負荷の低減を図り、これによって、共有作業のサービスレベルを維持することが可能になる。これらの結果、具体的には、次のような効果が達成される。即ち、(1)レスポンスタイムの向上やトランザクションアボートの減少など、データ共有機能における各クライアントへのサービスの向上、(2)ならびに、他の協調作業処理の阻害の減少である。
尚、上記実施例1では、クライアントに対して機能制限を課すが、操作頻度が所定の閾値を越えた場合は新規のクライアントの参入を禁止するようにしても良い。たとえば、リアルタイムに変更が求められるようなデータを共有するデータベースサービスを想定した場合に適用できる。具体的な例としては、動画を提供するデータベースサーバの能力が4クライアントへのサービス能力しかないにもかかわらず、5クライアント以上の要求が来てしまったなどの状況に適用することができる。
尚、本発明は、複数の機器から構成されるシステムに適用しても1つの機器からなる装置に適用しても良い。また、本発明はシステム或いは装置に本発明により規定される処理を実行させるプログラムを供給することによって達成される場合にも適用できることはいうまでもない。
100、200、300 端末
101 入力装置
102 CPU
103 出力装置
104 記憶装置
105 通信装置
101 入力装置
102 CPU
103 出力装置
104 記憶装置
105 通信装置
Claims (5)
- 複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出手段と、
前記検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割手段と、
前記分割手段で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理手段とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行うことを特徴とする情報処理装置。 - 前記分割手段は、前記協調作業への参加時刻に基づいて前記複数のクライアントを複数のグループに分割することを特徴とする請求項1に記載の情報処理装置。
- 前記分割手段は、協調作業対象へのアクセス分布に基づいて前記複数のクライアントを複数のグループに分割することを特徴とする請求項1に記載の情報処理装置。
- 前記分割手段は、前記複数のクライアントに対して分割の指示を行い、該複数のクライアントは各クライアント間の交渉によって複数のグループに分割されることを特徴とする請求項1に記載の情報処理装置。
- 複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置の情報処理方法であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出工程と、
前記検出工程で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割工程と、
前記分割工程で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理工程とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行うことを特徴とする情報処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004308468A JP2005100432A (ja) | 2004-10-22 | 2004-10-22 | 情報処理方法及び装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004308468A JP2005100432A (ja) | 2004-10-22 | 2004-10-22 | 情報処理方法及び装置 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP7073187A Division JPH08272723A (ja) | 1995-03-30 | 1995-03-30 | 情報処理方法及び装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005100432A true JP2005100432A (ja) | 2005-04-14 |
Family
ID=34464210
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004308468A Pending JP2005100432A (ja) | 2004-10-22 | 2004-10-22 | 情報処理方法及び装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005100432A (ja) |
-
2004
- 2004-10-22 JP JP2004308468A patent/JP2005100432A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11900098B2 (en) | Micro-service management system and deployment method, and related device | |
US5452299A (en) | Optimized transfer of large object data blocks in a teleconferencing system | |
US8549172B2 (en) | Distribution of software based on scheduled time to deploy software dynamic resource state of systems involved in deployment of software and based upon environmental conditions | |
CN100549964C (zh) | 信息处理设备、中断处理控制方法 | |
US9703610B2 (en) | Extensible centralized dynamic resource distribution in a clustered data grid | |
WO2018176998A1 (zh) | 数据存储方法及装置 | |
CN107087019A (zh) | 一种端云协同计算架构及任务调度装置及方法 | |
CN112463366B (zh) | 面向云原生的微服务自动扩缩容和自动熔断方法及系统 | |
JP2015537307A (ja) | コンポーネント指向ハイブリッドクラウドオペレーティングシステムのアーキテクチャ及びその通信方法 | |
CN103297412B (zh) | 瘦客户端系统、连接管理服务器、连接管理方法和计算机可读介质 | |
CN101493785A (zh) | 根据客户软件的特许级支持向虚拟机监视器转移 | |
CN114443263A (zh) | 显存管理方法、装置、设备及系统 | |
CN115562877B (zh) | 分布式算力资源的编排方法、装置、设备及存储介质 | |
CN107451853A (zh) | 一种红包实时派发的方法、装置、系统及存储介质 | |
WO2011060567A1 (en) | License redistributing method, moderator and license controlling system thereof | |
CN111158878A (zh) | 资源转移请求线程控制方法、装置及存储介质 | |
US20240248665A1 (en) | Resource rendering method and apparatus, device, computer readable storage medium, and computer program product | |
CN113486042B (zh) | 数据处理方法、装置、计算机可读介质及电子设备 | |
US5802322A (en) | Method and apparatus for the serialization of updates in a data conferencing network | |
Sadok et al. | Stateful DRF: considering the past in a multi-resource allocation | |
JP2000242614A (ja) | 分散処理システムおよびその方法、分散処理を行うための端末装置および記録媒体 | |
CN110472757A (zh) | 用于银行网点兑换外币的数据处理方法和装置 | |
USRE38457E1 (en) | Deferred sychronization of distributed objects | |
JP2005100432A (ja) | 情報処理方法及び装置 | |
CN116455830A (zh) | 实现存储网关高可用分布式qos的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060111 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060313 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060428 |