JP2002505468A - 故障検知用のリース - Google Patents

Abstract

(57)【要約】 【目的】故障検知及びその故障リカハ゛リを実行するシステムを提供すること。 【解決手段】このシステムの使用において、クライアントは、所定時間サーハ゛により管理されるリソースを利用するために、サーハ゛からのリースをリクエストする。これに応答して、サーハ゛は、リースを許可し、クライアントは継続的にリースの更新をリクエストする。クライアントがリース更新に失敗した場合には、サーハ゛は、クライアントにエラーが発生したことを検知する。同様にサーハ゛が更新リクエストの応答に失敗した場合には、クライアントがサーハ゛にエラーが発生したことを検知する。リース確立の一部として、クライアント及びサーハ゛は、故障リカハ゛リルーチン交換し、各々の故障リカハ゛リルーチンは、他方に故障が発生したときに呼び出す。

Description

【発明の詳細な説明】

【０００１】 関連出願 参考のために示すが、本出願は、1996年10月11日出願の米国特許出願No.08/72
9,421の一部継続出願である。 1998年2月26日出願の米国特許仮出願No.60/076,048、発明の名称「分散コンピ
ュータシステム」。 同日出願の米国特許出願No.09/044,923、発明の名称「記憶領域をリースする ための方法及び装置」（代理人整理番号No.06502.0011-01000）。 同日出願の米国特許出願No.09/044,838、発明の名称「分散システムにおける 委譲認証のリースに用いられる方法、装置及びプロダクト」（代理人整理番号No
.06502.0011-02000）。 同日出願の米国特許出願No.09/044,934、発明の名称「分散システムにおける グループメンバーシップのリース用の方法、装置及びプロダクト」（代理人整理
番号No.06502.0011-03000）。 同日出願の米国特許出願No.09/044,933、発明の名称「イベントに基づくシス テムにおける振るまい転送方法」（代理人整理番号no.06502.0054-00000）。 同日出願の米国特許出願No.09/044,919、発明の名称「オブジェクトの据え置 き型再構築と分散システムにおけるイベント通知用の遠隔ロード」（代理人整理
番号No.06502.0062-01000）。 同日出願の米国特許出願No.09/044,938、発明の名称「遠隔メソッド呼出用の 方法及び装置」（代理人整理番号No.06502.0102-00000）。 同日出願の米国特許出願No.09/045,652、発明の名称「遠隔メソッドを識別す るための決定論的ハッシュのための方法及びシステム」（代理人整理番号No.065
02.0103-00000）。 同日出願の米国特許出願No.09/044,790、発明の名称「分散システムにおける 遠隔オブジェクトのステータスを判断するための方法及び装置」（代理人整理番
号No.06502.0104-00000）。 同日出願の米国特許出願No.09/044,930、発明の名称「分散システムにおいて 遠隔手続コールに関連付けられた処理を実行するためのダウンロード可能なスマ
ートプロキシ」（代理人整理番号No.06502.0105-00000）。 同日出願の米国特許出願No.09/044,917、発明の名称「遠隔メソッドの停止及 び継続」（代理人整理番号No.06502.0106-00000）。 同日出願の米国特許出願No.09/044,835、発明の名称「データベースにおける マルチエントリ及びマルチテンプレートのマッチングのための方法及びシステム
」（代理人整理番号No.06502.0107-00000）。 同日出願の米国特許出願No.09/044,839、発明の名称「データベースにおける インプレイス・モディフィケーションのための方法及びシステム」（代理人整理
番号No.06502.0108）。 同日出願の米国特許出願No.09/044,945、発明の名称「データベースにおける タイプセイフ属性マッチングのための方法及びシステム」（代理人整理番号No.0
6502.0109-00000）。 同日出願の米国特許出願No.09/044,931、発明の名称「分散システムにおける ダイナミック検索サービス」（代理人整理番号No.06502.0110-00000）。 同日出願の米国特許出願No.09/044,939、発明の名称「分散型システムにおけ るデバイスとの情報通信用のダウンロード可能なコードを配信するための装置及
び方法」（代理人整理番号No.06502.0112-00000）。 同日出願の米国特許出願No.09/044,826、発明の名称「検索サービスへのアク セスを容易にするための方法及びシステム」（代理人整理番号No.06502.0109-00
000）。 同日出願の米国特許出願No.09/044,932、発明の名称「分散システムにおいて ダイナミックに情報をベリファイするための装置及び方法」（代理人整理番号No
.06502.0114-00000）。 1998年2月26日出願の米国特許出願No.09/030,840、発明の名称「ネットワーク
上におけるダイナミックな分散コンピューティングをするための方法及び装置」
。 同日出願の米国特許出願No.09/044,936、発明の名称「永続的な共有メモリ空 間のための対話型設計ツール」（代理人整理番号No.06502.0116-00000）。 同日出願の米国特許出願No.09/044,934、発明の名称「多様型トークンに基づ く制御」（代理人整理番号No.06502.0117-00000）。 同日出願の米国特許出願No.09/044,915、発明の名称「スタックに基づくアク セス制御」（代理人整理番号No.06502.0118-00000）。 同日出願の米国特許出願No.09/044,944、発明の名称「スタックに基づく安全 性要求」（代理人整理番号No.06502.0119-00000）。 同日出願の米国特許出願No.09/044,837、発明の名称「安全性要求のメソッド の指定」（代理人整理番号No.06502.0120-00000）。

【０００２】 （背景技術） Ａ．発明の属する技術分野 本発明は、データ処理システムに関し、更に詳しくは、データ処理システムに
おける故障検知及びそのリカバリに関する。

【０００３】 Ｂ．関連技術の説明 完全なリソース管理は、コンピュータを効率的且つ効果的に利用するためには
重要な要素である。一般的には、リソース管理は、リクエストに応じたリソース
（例えば、メモリ）の割当と、リクエスタがもはやリソースを要求しない場合等
における適当なタイミングでのリソースの割当解除とを含む。一般的には、リソ
ースは、コンピュータ内で実行されるコンピュータ演算可能なエンティティ（例
えば、アプリケーション、プログラム、アプレット等）により参照されるデータ
を保持する。

【０００４】 実際には、コンピュータ上で実行するアプリケーションがリソースを参照する
ためにシークする時に、アプリケーションが完全にそれらを参照することができ
るようにするために、コンピュータは、まず最初にリソースを割当又は指定しな
ければならない。アプリケーションがもはやリソースを参照しない時は、コンピ
ュータは、リソースを再使用するために割当解除又は再生することができる。コ
ンピュータの各リソースは、特定の"ハンドル"を有しており、これによって、リ
ソースは参照可能なのである。ハンドルは、種々の方法、例えば、アドレス、配
列インデックス、ユニーク値、ポインタ等により実装することができる。

【０００５】 リソース管理は、単一コンピュータでは比較的簡単である。その理由は、リソ
ースが再生されえる時、例えば、アプリケーションがもはやそれらを参照しなく
なった場合や電源に異常が発生した場合を示すイベントが判断しやすいからであ
る。複数コンピュータを連結した分散システム用のリソース管理は、より難しい
。その理由は、種々の異なるコンピュータのアプリケーションが同一のリソース
を使用するからである。

【０００６】 分散システムにおけるディスコネクトにより、不完全且つ時期尚早なリソース
の再生か、又は、リソース再生の故障が起こることがある。例えば、分散型シス
テムの異なるコンピュータ上で動作する複数アプリケーションは、他のマシン上
に配置されたリソースを参照することもできる。リソースが配置されているコン
ピュータと、それらのリソースを参照するアプリケーションとの間のコネクショ
ンが絶たれると、コンピュータは時期尚早にリソースを再生することになる。或
いは、コンピュータは、アプリケーションがリソースへのアクセスを失敗すると
、延長ピリオドになっても永久にリソースを維持することになる。

【０００７】 これらの問題を解決するために、ネットワークリソースを管理するためのシス
テムが開発され、その一つが"分散型ガベージコレクション"として周知である。
分散型ガベージコレクションは、分散型システム用の言語又はランタイムシステ
ムにより提供される機能を記述し、種々のネットワークコンピュータにおいて動
作する単一又はグループのアプリケーションにより使用されるリソースを自動的
に管理する。

【０００８】 一般的には、ガベージコレクションは、リソースがもはやアプリケーションの
どの部分からも参照されなくなったときに、リソースを後の使用のために解放さ
せるという概念を用いている。分散型ガベージコレクションは、分散型コンピュ
ーティングの領域にこの概念を拡張して、あらゆるコンピュータ上のアプリケー
ションが一つもリソースを参照しなくなったときにリソースを再生する。

【０００９】 分散型ガベージコレクションは、割当リソースとそれらのリソースへのリファ
レンスとの間の保全性を維持しなければならない。換言すれば、ネットワークの
コンピュータ上で走行するアプリケーションがそのリソースを参照し続ける限り
、システムはリソースの解放又は割当解除を行うことを許可されていない。この
リファレンス−リソースのバインドは、"リファレンスの保全性"と称されるが、
リファレンスが参照するリソースに当該リファレンスが常にアクセスすることを
許可することを保証するものではない。例えば、ネットワーク障害によりアクセ
スが不可能となる。しかしながら、保全性は、リファレンスを使用してあらゆる
リソースへアクセスすることができるならば、リファレンスが最初に付与された
リソースと同一リソースとなることを保障する。

【００１０】 ガベージコレクションを使用する分散型システムは、更に、リソースが制限時
間内に参照されない場合には、リソースを再生しなければならない。換言すれば
、システムは、"メモリリーク"に対し保障しなければならない。メモリリークは
、全てのアプリケーションがリソースに対するリファレンスを怠ったときに発生
するものであるが、例えば、いくつかのアプリケーションがそのリソースを参照
中であるという誤った判断が原因になって、システムは再使用を目的とするリソ
ースの再生に失敗する。

【００１１】 リファレンスの保全性の故障及びメモリリークは、リソースを参照するアプリ
ケーションと、それらのリソースの割当・割当解除を管理するガベージコレクシ
ョンシステムとの間のディスコネクトに起因することが多い。例えば、リソース
を参照するアプリケーションと、上述のリソースを管理するガベージコレクショ
ンシステムとの間のネットワークコネクション内のディスコネクトは、ガベージ
コレクションシステムがそのリソースを再生すべきか否か・いつ再生すべきかと
いうことを判断するのを妨害する。あるいは、ガベージコレクションシステムは
、アプリケーションが所定時間内にリソースにアクセスしなかったということを
理由として、誤ってそのリソースを収集してしまうという判断をすることもある
。分散型ガベージコレクションのメカニズムを改良するために、多くの技術が利
用されており、例えば、メモリリークを発生させずにリファレンスの保全性を維
持するメカニズムを確保しようとの試みがなされている。従来のアプローチの一
つとして、参照回数を数えるという形態を利用したものがあるが、そのカウント
は、互いのリソースを参照しているアプリケーションの数を数えることによって
なされるものである。リソースのカウント数がゼロになった時にガベージコレク
ションシステムはそのリソースを再生することができる。しかしながら、このよ
うなリファレンスカウント概念による機能は、リソースが対応するリファレンス
カウンタにより生成された場合にのみ有効である。この場合におけるガベージコ
レクションシステムは、リソースのリファレンスカウントをそのリソースを参照
するアプリケーションの数が追加されるに従って増加させ、アプリケーションが
そのリソースを参照しなくなったときに減少させるというものである。

【００１２】 しかしながら、リファレンスカウント概念は、とりわけ、分散型システム内で
起こり得る故障に直面しやすいという問題を引き起こす。このような故障は、リ
ソースが参照されなくなったガベージコレクションシステムを通知するメッセー
ジの配信を妨害するというコンピュータ・アプリケーションの故障又はネットワ
ークの故障という形態をとることができる。メッセージがネットワークのディス
コネクトにより配信されなかった場合には、ガベージコレクションシステムは、
いつそのリソースを再生すべきかが判断できなくなる。

【００１３】 このような故障を防止するため、従来のリファレンスカウント概念は、"キー プアライブ"のメッセージを含み、それは、"ピングバック"とも称される。この 概念によれば、ネットワーク内のアプリケーションは、リソースを監視するガベ
ージコレクションシステムにメッセージを送信し、アプリケーションがまだ通信
可能であることを示す。これらのメッセージは、ガベージコレクションシステム
がリソースへの参照を抜かしてしまうのを防止する。このような"キープアライ ブ"のメッセージの受信の故障により、ガベージコレクションシステムは、リソ ースへのリファレンスカウントを減少させることができ、そのカウントがゼロに
なると、ガベージコレクションシステムはリソースを再生する。しかしながら、
このことは、ネットワークの故障に端を発した後、"キープアライブ"のメッセー
ジの受信の失敗に起因してリファレンスカウントがゼロになり、結局、時期尚早
のリソース再生という結果を招く。従って、リファレンスの保全性は確保されな
い。

【００１４】 ガベージコレクションシステムにおけるリファレンスの保全性に関する問題を
解決するために、リファレンス回数を保持するだけでなく、更に、リソースを参
照するコンピュータ演算可能な各エンティティに対応する識別子を保持するとい
う他の手法が提案されている。例えば、エイ・ビレル等による"ネットワークオ ブジェクト用の分散型ガベージコレクション"（No.116デジタルシステムリサー チセンター、1993年12月15日）を参照されたい。この方法は、上述のリファレン
スカウント概念と同様の問題を有するものである。更に、この方法によれば、各
リソースを参照するコンピュータ演算可能な各エンティティ用のユニーク識別子
の追加が必要となり、これにより、分散型システム内の通信を不必要に増加させ
るオーバーヘッドを追加することになり、記憶領域の追加が必要となる（すなわ
ち、各リソースを参照するアプリケーションに対応する識別子リスト）。

【００１５】 （発明の開示） 本発明によれば、リファレンスの保全性は、所定ピリオドの間、リソースをリ
ースすることにより、コスト高を招くメモリリークを起こすことなく保障される
。その間、分散型システム内の集合、例えば、リソースへのリファレンスを管理
するアプリケーション、そのリソースを管理するガベージコレクションシステム
等がそのリソースを承認すると、そのリソースへのリファレンスが保障される。
リースピリオドの終わりには、リソースへのリファレンスを継続する保障がなく
なり、ガベージコレクションシステムはリソースを再生することが可能になる。
リソースへのリファレンスを保持するアプリケーションとリソースを管理するガ
ベージコレクションシステムとが保障且つ制限されたリースピリオドを承認する
ため、両者は、リース及び保障がいつ終了するかを認識することができる。これ
により、リファレンスのリース期間内においては、リファレンスの保全性が保障
され、ネットワークエラーによるリソース解放の失敗の原因となることが回避さ
れる。

【００１６】 本発明に係る他の実施の形態においては、リーステクニックは、故障検知及び
そのリカバリに用いられる。故障検知用としてリースを使用する場合には、クラ
イアントは、サーバからのリースを要求し、そのリースが許可された後に、クラ
イアントは、サーバにより管理されるリソースに関する種々の処理を実行する。
リースが終了しかけると、クライアントはリースを更新する。何らかの原因で、
この更新が失敗するとすれば、その原因は、サーバにエラーが起こったか又はク
ライアントサーバ間でデータを転送する通信メカニズムにエラーが起こったかの
いずれかによるものである。更に、クライアントがリースを更新することなく又
はクライアントが明示的にリースのキャンセルをリクエストすることなく、リー
スが終了した場合には、サーバは、クライアント又は通信メカニズムのいずれか
にエラーが起こったと認識する。この場合には、サーバがエラーを検知している
。

【００１７】 故障検知に加えて、他の実施形態は、更に故障リカバリをも提供する。リース
の確立の間、クライアントはサーバに故障リカバリルーチンを提供し、同様に、
サーバはクライアントに故障リカバリルーチンを提供する。従って、故障検知に
際しては、クライアント及びサーバの両者は、それぞれ、他方の故障リカバリル
ーチンを呼び出して、互いに故障リカバリを実行する。故障リカバリを実行した
後、クライアントとサーバとの両者は、その障害発生前の状態になる。すなわち
、クライアントとサーバは、エラーが発生するとリソースに対してなされた全て
の変更を元に戻す等して移行すべき状態を決定し、予め状況を切り抜ける。

【００１８】 （発明を実施するための最良の形態） 以下に、本発明の一実施の形態の詳細について添付図面を参照して説明する。
図面及び以下の説明において同一又は略同一の部材を参照する場合には、全体を
通してできる限り同一の符号を用いる。 本発明は、従来の分散型プロセッシングシステムのアーキテクチャに基づいて
構成されたコンピュータに実装することができる。しかしながら、本発明の実装
するためのアーキテクチャ及び手順は、従来のものとは異なる。その理由は、そ
のアーキテクチャ及び手順がリファレンスの保全性を保障するとともに、メモリ
リークを排除するからである。

【００１９】Ａ．概要 分散型プロセッシングシステム内の各コンピュータに配置されたメソッド呼出
（MI）コンポーネントは、本発明に係る分散型ガベージコレクション概念を実装
するものである。MIコンポーネントは、数多くのソフトウエアモジュールからな
り、これらのモジュールは、できればJAVA^TMプログラミング言語によって記述さ
れたものがよい。

【００２０】 一般的に、分散型プロセッシングシステム内のアプリケーションが、他のコー
ルに対する返り値としての名前の検索により、或いは、他の方法によって、分散
型リソースへのリファレンスを取得し、当該リソースへアクセスするためにシー
クするたびに、そのアプリケーションは、リソース又はそのリソースを管理する
MIコンポーネントに対してコールする。そのMIコンポーネントは、管理用MIコン
ポーネントと称され、そのリソースへの処理中のリファレンスの数を見失わない
ように監視する。リソースへのリファレンスの数がゼロになると、管理用MIコン
ポーネントは、リソースを再生することができる。リソースへのリファレンス数
は、一般的に、"リファレンスカウント"と称され、リファレンスカウントを増加
させるコールは、"ダーティーコール"と称される。

【００２１】 アプリケーションが分散型リソースをもはや要求しない場合には、リソース又
は管理用MIコンポーネントに異なったコールを送信する。このコールを受信する
と、管理用MIコンポーネントは、そのリソース用のリファレンスカウントを減少
させる。リファレンスをドロップさせるこのコールは、"クリーンコール"と称さ
れる。

【００２２】 本発明の一実施形態によれば、ダーティーコールは、リソースへのリファレン
スのために、リクエストされたタイムインターバル及びコールされたリースピリ
オドを含むことができる。ダーティーコールを受信すると、管理用MIコンポーネ
ントは、リースが許可されるピリオドを示すリターンコールを送信する。従って
、管理用MIコンポーネントは、処理中のリファレンスの数と同様に、それらのリ
ファレンスのためのリースピリオドを監視する。その結果、リソースへのリファ
レンスカウントがゼロになったとき、又は、リソースへのリースピリオドが終了
したときに、管理用MIコンポーネントは、そのリソースを再生することができる
。

【００２３】Ｂ．手順 MIコンポーネント内のアプリケーションコールプロセッサは、図１に示したア
プリケーションコール手順１００を実行する。管理用MIコンポーネント内のサー
バコールプロセッサは、図２から図４に示した手順２００、３００、４００の各
工程を実行する。管理用MIコンポーネントのガベージコレクタは、従来の手順を
実行してサーバコールプロセッサからの命令に基づいて既にリファレンスにバイ
ンドされたリソースを再生する。ガベージコレクタの従来の手順については説明
を省略する。

【００２４】 １．アプリケーションコールプロセッサ 図１は、分散型プロセッシングシステム内に配置された同一又は他のMIコンポ
ーネントにより管理されるリソースへのリファレンス用のアプリケーションリク
エストを処理するために、MIコンポーネントのアプリケーションコールプロセッ
サが用いる手順１００のフローチャートを示したものである。

【００２５】 アプリケーションがリソースへのリファレンスを取得した後、アプリケーショ
ンコールプロセッサは、ダーティーコールを送信するが、このダーティーコール
は、そのリソース用の管理用MIコンポーネントに対するリソースへのリファレン
ス、リクエストされたリースピリオドを含む（ステップ１１０）。ダーティーコ
ールは、リソース又は管理用MIコンポーネントに対するものであればよい。

【００２６】 アプリケーションコールプロセッサは、次に、管理用MIコンポーネントコンポ
ーネントからのリターンコールを待ち、これを受信する（ステップ１２０）。リ
ターンコールは、許可されたリースピリオドを含み、この間、管理用MIコンポー
ネントは、ダーティーコールのリファレンスが、そのリソースへバインドされる
のを保障する。換言すれば、管理用MIコンポーネントは、許可ピリオドにおいて
は、ダーティーコールのリファレンスに対応するリソースを収集しないことに応
じる。管理用MIコンポーネントが許可ピリオドを配信しない場合又はリース用の
リクエストを拒否した場合には、アプリケーションコールプロセッサは、許可ピ
リオドを受信するまで他のダーティーコールを送信しなければならない。

【００２７】 アプリケーションコールプロセッサは、アプリケーションによるリファレンス
の使用を監視し、リファレンスがもはや必要ではなくなったことをアプリケーシ
ョンがアプリケーションコールプロセッサに明示的に通知する場合又はアプリケ
ーションコールプロセッサがこの決定をそれ自身で行う場合に（ステップ１３０
）、アプリケーションコールプロセッサは、クリーンコールを管理用MIコンポー
ネントへ送信する（ステップ１４０）。ダーティーコールに用いられる方法と同
様の方法で、クリーンコールは、リファレンスされたリソースに対して行うこと
ができ、管理用MIコンポーネントがクリーンコールを処理することになる。その
後に、アプリケーションコールプロセッサは、リファレンスのリストからアプリ
ケーションにより用いられているリファレンスを削除する（ステップ１５０）。

【００２８】 アプリケーションがリファレンスを終えていない場合には（ステップ１３０）
、アプリケーションコールプロセッサは、リファレンスに対する許可ピリオドが
終了しかけているか否かを判断し（ステップ１６０）、アプリケーションコール
プロセッサは、ステップ１１０から１２０までを繰り返し実行して、アプリケー
ションのかわりに管理用MIコンポーネントにより、リソースへのリファレンスが
管理されることを確保する。

【００２９】２．サーバコールプロセッサ MIコンポーネントのサーバコールプロセッサは、３つの主要手順、すなわち、
（１）ダーティーコールの処理、（２）到来するクリーンコールの処理、（３）
適当な時期にリソースを再生するためにガベージコレクションサイクルの初期化
を実行する。

【００３０】 （i）ダーティーコール 図２は、リソースをリファレンスするリクエスト、例えば、MIソフトウエアコ
ンポーネントが管理するダーティーコールを処理するために、MIコンポーネント
のサーバコールプロセッサが使用する手順２００のフローチャートである。これ
らのリクエストは、分散型プロセッシングシステムのMIコンポーネントのアプリ
ケーションコールプロセッサから到来し、その分散型プロセッシングシステムは
、リクエストを処理するサーバコールプロセッサと同一のMIコンポーネントのア
プリケーションコールプロセッサを含む。

【００３１】 まず、サーバコールプロセッサは、ダーティーコールを受信する（ステップ２
１０）。サーバコールプロセッサは、次に、受け入れ可能な許可ピリオドを決定
する（ステップ２２０）。許可ピリオドは、リクエストされたリースピリオド又
は他のタイムピリオドと同一でもよい。サーバコールプロセッサは、要求された
リソースの量と、同一のリソース用に前に許可された他の許可ピリオドの数とに
基づいて、適当な許可ピリオドを決定する。

【００３２】 サーバコールプロセッサは、リソースが未だダーティーコールのリファレンス
に割り当てられていないと判断する場合には（ステップ２３０）、サーバコール
プロセッサは、要求されたリソースを割り当てる（ステップ２４０）。

【００３３】 サーバコールプロセッサは、次に、ダーティーコールのリファレンスに対応す
るリファレンスカウントを増加し（ステップ２５０）、受入可能な許可ピリオド
をリファレンス−リソースのバインドに設定し（ステップ２６０）、許可ピリオ
ドと一緒にリターンコールをアプリケーションコールプロセッサに送信する（ス
テップ２７０）。このようにして、サーバコールプロセッサは、その制御下でリ
ソースへのリファレンスについて到来するダーティーコールを制御する。

【００３４】 アプリケーションは、現在のリースが終了する前にダーティーコールを延長リ
クエストと一緒に送信することによってリースを延長することができる。手順２
００に示したように、リースを延長するためのリクエストは、リース用の初期化
リクエストと同様に取り扱われる。延長は、リソースがリファレンスカウントが
ゼロにならない限り、ただ単にタイムインターバルの追加によっては再生されな
いことを意味する。

【００３５】 （ii）クリーンコール MIコンポーネントのサーバコールプロセッサは、アプリケーションコールプロ
セッサから到来するクリーンコールをも処理する。分散型プロセッシングシステ
ム内のアプリケーションがもはやリソースへのリファレンスを要求しなくなった
場合には、アプリケーションは、そのリファレンス用にリソースを管理するMIコ
ンポーネントに、そのリソースが再生して再使用できることを通知する。

【００３６】 サーバコールプロセッサは、MIコンポーネントが管理するリソースへのリファ
レンスとクリーンコールとを受信して（ステップ３１０）、対応するリファレン
スカウントを減少させる（ステップ３２０）。クリーンコールは、リソースに送
信されるが、その際、サーバコールプロセッサはリソースを監視し、コール処理
のための手順３００が実行される。その後、サーバコールプロセッサは、クリー
ンコールを送信したMIコンポーネントに、受信承認としてリターンコールを送信
する。本発明の実装形態によれば、リファレンスをドロップさせるクリーンコー
ルを拒否できないが、承認しなければならない。

【００３７】 （iii）ガベージコレクション サーバコールプロセッサは、リソースを再生するためにガベージコレクション
サイクルの初期化をも行う。このため、より多くのリファレンスがリソースに対
してなされていないか又はリソースへの合意済みリースピリオドが終了したかを
判断する。図４に示した手順４００は、サーバコールプロセッサがガベージコレ
クションサイクルを初期化するために用いるステップのフローチャートである。

【００３８】 サーバコールプロセッサは、リファレンスカウントと許可されたリースピリオ
ドとを監視し、MIコンポーネントによって管理されるリソースへのリファレンス
カウントがゼロなのか又はリファレンス用の許可ピリオドが終了したのかを判断
する（ステップ４１０）。どちらかの状態が存在する場合には、サーバコールプ
ロセッサは、そのリソースのガベージコレクションを初期化する（ステップ４２
０）。そうでない場合には、リファレンスカウントと許可されたリースピリオド
とを監視し続ける。

【００３９】Ｃ．コールフロー 図５は、分散型プロセッシングシステムのMIコンポーネントにおけるコールフ
ローを説明するための図である。管理用MIコンポーネント５２５は、リソース５
３０へのリファレンスを監視することによりリソース５３０を管理する（ガベー
ジコレクト５０５参照）。管理用MIコンポーネント５２５がリソースを管理する
ため、管理用MIコンポーネント５２５のサーバコールプロセッサは、このコール
フロープログラムのオペレーションを実行する。

【００４０】 図５は、アプリケーション５１０，５４０がそれぞれ対応するMIコンポーネン
トコンポーネント５１５，５４５を有することをも示す。各アプリケーション５
１０，５４０は、リソース５３０のうちいずれかへのリファレンスを取得し、シ
ークしてリソース５３０のうちいずれかとのアクセスを取得し、これにより、リ
ファレンスは対応するリソースへバインドされることになる。アクセスを取得す
るために、アプリケーション５１０，５４０は、それぞれ対応するMIコンポーネ
ント５１５，５４５を呼び出し、それぞれダーティーコール５５１，５７１をMI
コンポーネント５２５へ送信する。MIコンポーネント５１５，５２５は、管理用
MIコンポーネント５２５等の他のMIコンポーネントにより管理されるリソース５
３０へのアクセスを行うためにアプリケーションリクエストを処理するため、MI
コンポーネント５１５，５４５のアプリケーションコールプロセッサは、このコ
ールフロープログラムのオペレーションを実行する。

【００４１】 ダーティーコール５５１，５７１に応答して、管理用MIコンポーネント５２５
は、それぞれリターンコール５５２，５７２を、それぞれMIコンポーネント５１
５，５４５に送信する。ダーティーコールは、ダーティーコール５５１，５７１
のリファレンス用に許可されたリースピリオドを含む。

【００４２】 同様に、図５は、更に、クリーンコール５６１，５８１をそれぞれ管理用MIコ
ンポーネント５２５に送信するMIコンポーネント５１５，５４５を示す。クリー
ンコール５６１，５８１は、アプリケーション５１０，５４０がそれぞれクリー
ンコール５６１，５８１内で指定されたリソースへのアクセスをもはや要求しな
いということを、管理用MIコンポーネント５２５に対して通知する。管理用MIコ
ンポーネント５２５は、クリーンコール５６１，５８１に対してそれぞれリター
ンコール５６２，５８２を用いて応答する。リターンコール５６２，５８２は、
リターンコール５５２，５７２とは異なり、MIコンポーネント５２５が受信した
クリーンコール５６１，５８１の単なる受信承認に過ぎない。

【００４３】 アプリケーション５１０，５４０は、両者とも、同一リソースへのアクセスを
要求することができる。例えば、アプリケーション５１０は、"リソース(1)"へ のアクセスをリクエストすることができるが、一方でアプリケーション５４０が
、以前にそのリソースへのアクセスが許可されていたということがある。MIコン
ポーネント５２５は、一致したリースピリオドの間、アプリケーション５１０，
５４０の両者に対して有効なリソースを作ることにより、この状況を処理する。
従って、MIコンポーネント５２５は、アプリケーション５１０，５４０の両者が
リソースへのリファレンスをドロップさせるか、最新の一致したピリオドが終了
するかのいずれかが発生するまでは、"リソース(1)"を再生するためにガベージ コレクションサイクルを初期化しないことになる。

【００４４】 同一のリソースへ同時にアクセスするために複数のアプリケーションを許可す
ることによって、本発明は、リソースへのリファレンスをドロップさせる管理用
MIコンポーネントへクリーンコールを送信した後に、アプリケーションがリソー
スへアクセスすることをも許可する。これが発生するのは、リソースが依然とし
て他のアプリケーションによって参照されているか、又は、リファレンスのリー
スがまだ終了していないために管理用MIコンポーネント５２５がまだリソースを
再生していないからである。しかしながら、リソースは、より多くのアプリケー
ションがどれもリースを保持しない場合又は最後のリースが終了した場合に、制
限ピリオドの後、再生されることになる。

【００４５】Ｄ．MIコンポーネント 図６は、本発明の一実施形態に係るMIコンポーネント６００を構成するモジュ
ールのブロック図である。MIコンポーネント６００は、監視されるリファレンス
用のリファレンスコンポーネント６０５、アプリケーションコールプロセッサ６
４０、サーバコールプロセッサ６５０及びガベージコレクタ６６０を含むことが
できる。

【００４６】 リファレンスコンポーネント６０５は、リファレンスデータポーション６１０
、リファレンス６２０、許可ピリオドレジスタ６３０を備えたテーブル又はこれ
と同様の構造体から構成される。MIコンポーネント６００は、対応するリファレ
ンスデータポーション６１０内で指定された各リファレンス用にリファレンスカ
ウント６２０と許可ピリオド６３０とを使用して、対応するリソースを再生する
には、いつガベージコレクタ６６０を初期化すればよいかを判断する。

【００４７】 アプリケーションコールプロセッサ６４０は、ソフトウエアモジュールであり
、図１に示した手順１００の各ステップを実行する。サーバコールプロセッサ６
５０は、ソフトウエアモジュールであり、図２から図４に示した手順２００，３
００，４００の各ステップを実行する。ガベージコレクタ６６０は、ソフトウエ
アモジュールであり、上述したようにサーバコールプロセッサ６５０からの命令
に応じてリソースを再生する。

【００４８】Ｅ．分散型プロセッシングシステム 図７は、本発明を実装するのに使用可能な分散型プロセッシングシステム５０
を示したものである。図７においては、分散型プロセッシングシステム５０は、
３つの独立した異種のプラットフォーム１００，２００，３００を含み、これら
は、ネットワーク雲５５によって表されるネットワークコンフィギュレーション
内で連結されている。図７の雲５５により表されるネットワークコンフィギュレ
ーションの構成及びプロトコルは、プラットフォーム７００，８００，９００の
間での情報通信が可能である限り余り重要ではない。加えて、これらの３つのプ
ラットフォームは、説明のために例示したものであるため、本発明におけるプラ
ットフォームの使用を特定数に限定するものではない。更に、本発明については
、専用のネットワークアーキテクチャは重要ではない。例えば、本発明に従って
使用可能な他のネットワークアーキテクチャとしては、あらゆるプラットフォー
ムが連結可能なネットワークコントローラのような単一のプラットフォームを使
用するものでもよい。

【００４９】 分散型プロセッシングシステム５０の実装においては、プラットフォーム７０
０，８００，９００は、各々、プロセッサ７１０，８１０，９１０をそれぞれ備
えるほか、メモリ７５０，８５０，９５０をそれぞれ備える。各プロセッサ７１
０，８１０，９１０の各々には、アプリケーション７２０，８２０，９２０、オ
ペレーティングシステム７４０，８４０，９４０、MIコンポーネント７３０，８
３０，９３０がそれぞれ含まれる。

【００５０】 アプリケーション７２０，８２０，９２０は、プログラムにより構成でき、こ
のプログラムは、予め作成されたものを本発明に従って作動するように修正され
たものか又は本発明によって得られるサービスの効果を得るべく専用として作成
されたものであればよい。

【００５１】 MIコンポーネント７３０，８３０，９３０は、図６を参照して説明したように
MIコンポーネント６００に対応している。

【００５２】 オペレーティングシステム７０，８４０，９４０は、それぞれ対応するプロセ
ッサ７１０，８１０，９１０に連結された標準オペレーティングシステムである
。プラットフォーム７００，８００，９００は、異種でもよい。例えば、プラッ
トフォーム７００は、プロセッサ７１０としてサンマイクロシステムズ インコ
ーポレーテッド製のUltraSparc（登録商標）マイクロプロセッサを備え、Solari
s（登録商標）オペレーティングシステム７４０を使用している。プラットフォ ーム８００は、プロセッサ８１０としてシリコングラフィックス インコーポレ
ーテッド製のMIPSマイクロプロセッサを備え、Unixオペレーティングシステム８
４０を使用している。そして、プラットフォーム９００は、プロセッサ９１０と
してインテル コーポレーテッド製のペンティアムマイクロプロセッサを備え、
マイクロソフトウインドウズ９５オペレーティングシステム９４０を使用してい
る。本発明は、これに限定されるものではなく、異種のプラットフォームを適用
することも可能である。

【００５３】 Sun、Sun Microsystems、Solaris、Java、the SunLogoは、米国又はその他の 国におけるサンマイクロシステムズ インコーポレーテッドの商標又は登録商標
である。UltraSparc及び他の全てのSPARC商標は、米国又はその他の国において ライセンス契約の下で使用されており、スパークインターナショナル インコー
ポレーテッドの商標である。SPARC商標を付した製品は、サンマイクロシステム ズ インコーポレーテッドにより開発されたアーキテクチャに基づいたものであ
る。

【００５４】 メモリ７５０，８５０，９５０は種々の機能、例えば、関連付けられたプラッ
トフォーム用の全体の記憶領域を提供する。他の機能は、各プロセッサ７１０，
８１０，９１０による実行前に、アプリケーション７２０，８２０，９２０、MI
コンポーネント７３０，８３０，９３０及びオペレーティングシステム７２０，
８４０，９４０を記憶することである。加えて、メモリ７５０，８５０，９５０
の各部分は、ネットワーク５０の全プラットフォーム７００，８００，９００に
有効な共有メモリからなる。

【００５５】Ｅ．メソッド呼出サービス 本発明はクライアント／サーバモデルを使用して実装することができる。クラ
イアントは、ダーティーコール、クリーンコール等のリクエストを生成し、サー
バはリクエストに対して応答を返す。

【００５６】 図７に示したMIコンポーネント７３０，８３０，９３０の各々は、クライアン
トコンポーネントとサーバコンポーネントの両者を含む。図８は、クライアント
プラットフォーム１０００及びサーバプラットフォーム１１００のブロック図で
あり、図７に示したプラットフォーム７００，８００，９００のうちいずれか２
つに適用される。

【００５７】 プラットフォーム１０００，１１００は、それぞれメモリ１０５０，１１５０
、プロセッサ１０１０，１１１０を保持する。プラットフォーム１０００，１１
００に含まれる要素は、図７を参照して説明した要素と同様の手法で機能する。
この例においては、プロセッサ１０１０は、クライアントアプリケーション１０
２０を実行し、プロセッサ１１１０は、サーバアプリケーション１１２０を実行
する。プロセッサ１０１０，１１１０は、更に、それぞれオペレーティングシス
テム１０４０，１１４０及びMIコンポーネント１０３０，１１３０を実行する。

【００５８】 MIコンポーネント１０３０，１１３０は、各々、サーバコールプロセッサ１０
３１，１１３１、アプリケーションコールプロセッサ１０３２，１１３２、ガベ
ージコレクタ１０３３，１１３３を含む。MIコンポーネント１０３０，１１３０
は、その各々が監視する各リファレンスとして、リファレンスデータポーション
１０３４，１１３４、リファレンスカウント１０３５，１１３５、許可ピリオド
レジスタ１０３６，１１３６を含むリファレンスコンポーネントをも含む。

【００５９】 アプリケーションコールプロセッサ１０３２，１１３２は、それぞれクライア
ントサービスを象徴し、これらの各々は、サーバサービスを象徴するサーバコー
ルプロセッサ１０３１，１１３１の各々と情報通信を行う。プラットフォーム１
０００，１１００は、サーバコールプロセッサ、アプリケーションコールプロセ
ッサ、ガベージコレクタ、リファレンスコンポーネントを保持しているため、プ
ラットフォームは、クライアント又はサーバのいずれかとして動作可能である。

【００６０】 しかしながら、問題を解決するためには、プラットフォーム１０００はクライ
アントプラットフォームと呼ばれ、プラットフォーム１１００はサーバプラット
フォームと呼ばれる。この例においては、クライアントアプリケーション１０２
０は、分散型リソースへのリファレンスを取得するとともにMIコンポーネント１
０３０を使用してサーバプラットフォーム１１００のMIコンポーネントにより管
理されるリソースへダーティーコールを送信する。

【００６１】 更に、サーバプラットフォーム１１００は、サーバアプリケーション１１２０
を実行することができる。サーバアプリケーション１１２０は、MIコンポーネン
ト１１３０を使用してダーティーコールを送信することもでき、このダーティー
コールは、ダーティーコールのリソースがMIコンポーネント１１３０により管理
される場合に、MIコンポーネント１１３０によって処理される。

【００６２】 従って、クライアントプラットフォーム１０００のMIコンポーネント１０３０
用のサーバコールプロセッサ１０３１、ガベージコレクタ１０３３及びリファレ
ンスカウンタ１０３５は、アクティブではなく、図８においては陰を付けて表示
されている。同様に、サーバプラットフォーム１１００のMIコンポーネント１１
３０のアプリケーションコールプロセッサ１１３２も休止中であるため陰を付し
て表示されている。

【００６３】 クライアントアプリケーション１０２０がリソースに対応するリファレンスを
取得する場合には、アプリケーションコールプロセッサ１０３２は、ダーティー
コールを送信し、サーバコールプロセッサ１１３１がこれを受信する。ダーティ
ーコールは、リクエストされたリースピリオドを含む。サーバコールプロセッサ
１１３１は、ダーティーコール内のリファレンス用にリファレンスカウント１１
３５を増加し、許可ピリオドを決定する。これに応答して、サーバコールプロセ
ッサ１１３１は、リターンコールを許可ピリオドとともに、アプリケーションコ
ールプロセッサ１０３０へ送信する。アプリケーションコールプロセッサ１０３
２は、許可ピリオドを使用して記録された許可ピリオド１０３５を更新し、いつ
ダーティーコールのリファレンスに対応するリソースを再生するかを決定する。

【００６４】 サーバコールプロセッサ１１３１は、更に、それが管理するリソースへのリフ
ァレンスに対応するリファレンスカウントと許可ピリオドとを監視する。リファ
レンスカウント１１３５のうちの一つがゼロになるか、又は、リファレンス用の
許可ピリオド１１３５が終了するかのいずれか最初のイベントが起こった時に、
サーバコールプロセッサ１１３１は、ガベージコレクタ１１３３を初期化して、
ゼロのリファレンスカウント又は終了した許可ピリオドを保持するリファレンス
に対応するリソースを再生することができる。

【００６５】 本発明の一実施形態によるリースされたリファレンスの概念は、プラットフォ
ーム１０００，１１００のプロトコル上でクロックの同期を必要としない。その
概念は、それらが同等の増加周期であることを要求するに過ぎない。リースは、
特定のタイミングでは終了しないが、特定のタイムインターバルで終了するもの
である。そのインターバルがほぼ正確に一致している限り、プラットフォーム１
０００，１１００は、許可されたリースピリオドについてほぼ正確に一致する。
更に、コンピュータ周期におけるリースタイミングは比較的長いため、クロック
速度のモニタ差異は殆どないか又は影響がない。

【００６６】 ダーティーコールの転送時間は、プロトコルに影響を及ぼす。MIコンポーネン
ト１０３０がリファレンス用のリースを保持し、リースが終了して更新リクエス
トをする直前までウエイトするとすれば、リースは、MIコンポーネント１１３０
がリクエストを受信する前に終了する。そうだとすれば、MIコンポーネント１１
３０は、更新リクエストを受信する前にリソースを再生することができる。従っ
て、ダーティーコールを送信する場合には、リソースへのリースピリオドが終了
する前に、更新されたダーティーコールが作成されるようにするために、送信元
では、ダーティーコールのリソースを処理するプラットフォームへの転送時間を
考慮に入れて、リクエストされたリースピリオドにタイムファクターを追加すべ
きである。

【００６７】Ｆ．結論 本発明による分散型ガベージコレクションの概念によれば、分散型プロセッシ
ングシステムのリソースへのリファレンスに対応する許可されたリースピリオド
を配信することにより、リファレンスの保全性が保障され、メモリリークが排除
される。具体的には、許可されたリースピリオドが終了したときに、リソースへ
のリファレンスを付すことによってなされる。その後、リソースは収集される。
リソースは、分散型プロセッシングシステムのプロセスによってリファレンスさ
れなくなった場合に、リソース用にリファレンスに割り当てられたカウンタへの
リファレンスとともに収集することもできる。

【００６８】本発明の変形例 上述したリーステクニックは、ガベージコレクションに関するものである。し
かしながら、リースを用いた本発明の他の実施形態によっても故障検知及びエラ
ーリカバリを行うことができる。

【００６９】 例えば、ハートビートやタイムアウト等の多くのシステムがクライアントサー
バ環境内の故障検知に使用されている。ハートビートを使用することにより、ク
ライアントは、クライアントが生きていることを示すメッセージを定期的なイン
ターバルでサーバへ送信する。インターバルのうち、サーバがメッセージを受信
しない場合には、サーバは、クライアントか又はクライアントサーバ間でデータ
転送を行う情報通信メカニズムか（すなわち、ネットワーク）のいずれかに故障
が発生したこと認識する。タイムアウトを使用することにより、所定の時間長さ
が設定され、サーバがそのタイムピリオドの間にクライアントから何の情報も受
信しない場合には、サーバは、クライアントか又は情報通信メカニズムかに故障
が発生したことを認識する。

【００７０】 これらの従来のシステムは、故障発生を適切に示すが、クライアント及びサー
バの両者は、故障後のシステムの状態を認識していない状態のままにされる。例
えば、クライアントがプログラムでサーバがファイルシステムマネージャである
場合に、クライアントは、書込オペレーションがサーバにより管理される特定の
ファイル上で実行されるよう要求することができる。従来の故障検知システムは
、それが発生したときに故障を検知するものではあるが、クライアントは、故障
が発生したのがファイル上で書込オペレーションが実行される前なのか後なのか
を認識しない。これではクライアントはシステムの状態を認識することができな
い。

【００７１】 本発明に係る他の実施形態は、この問題を故障検知及びそのリカバリ用のリー
ステクニックを用いることにより解決するものである。故障検知用にリースを使
用する場合には、クライアントは、サーバからのリースをリクエストすると共に
、許可されたリースピリオドの間、サーバによって管理されるリソースに関する
種々の処理を実行する。リースが終了しかけると、クライアントはリースを更新
する。何らかの理由で更新故障が起こるとすれば、それは、サーバに故障が発生
したか又は情報通信メカニズムに故障が発生したかによる。何れの場合もクライ
アントは故障を検知している。サーバ側では、クライアントがリースを更新する
ことなく又は明示的なキャンセルを実行することなくリースが終了する場合には
、サーバは、クライアント又は情報通信メカニズムのいずれかに故障があったこ
とを認識し、サーバが故障を検知することになる。

【００７２】 故障検知の際には、クライアント及びサーバは、故障を切り抜けた状態に準ず
る状態へ進行することによりリカバリを実行する。すなわち、クライアントとサ
ーバは、故障の発生又は検知の際に進もうとする状態を飛び越える。例えば、上
述したファイルシステムの例によれば、クライアント及びサーバは、故障が検知
されると、その障害を飛び越えてロールバックしようとする。"ロールバック"と
は、クライアント、サーバ及びファイル等の関連するエンティティを故障発生前
の状態に戻すことをいう。従って、この例では、サーバが既に書込オペレーショ
ンを実行した後だとすると、サーバは書込オペレーションが行われる直前の状態
にファイルをリストアし、クライアントは、故障検知の後、書込オペレーション
が実行されなかったと認識することになる。そのため、クライアントはその処理
を継続することができる。

【００７３】 あるいは、クライアント及びサーバは、もっと前にロールバックすることもで
きる。例えば、クライアント及びサーバは、ファイル操作の間にエラーが発生す
る場合には常にこれを切り抜けることができ、そのロールバックにより、クライ
アント及びサーバは、クライアントがリースを保持する前（すなわち、ファイル
が生成される前）の状態へ戻される。あるいは、ロールバックにより、ファイル
操作中の所定のチェックポイントへ戻されるようにしてもよい。故障後システム
状態を決定するためのクライアントとサーバとの間のこの事前切り抜けは、種々
の方法で実行できるが、その方法には、ハンドシェーク、予め指定されたファイ
ルの読出が含まれる。あるいは、この事前切り抜けは、クライアント及びサーバ
がディベロプメントタイム中における単なる命令により所定の故障後システム状
態へ移行することにより行うようにしてもよい。

【００７４】 加えて、リースの確立の間、クライアントはサーバに故障リカバリルーチンを
提供し、同様に、サーバはクライアントに故障リカバリルーチンを提供する。従
って、故障検知に際しては、クライアント及びサーバの両者は、それぞれ、他方
の故障リカバリルーチンを呼び出して、互いに故障リカバリを実行する。この状
況で、サーバに故障が起こると、クライアントが故障を検知し、クライアントが
サーバのリカバリルーチンを呼び出し、そのリカバリルーチンがサーバ上でリカ
バリを実行する。例えば、リカバリルーチンがサーバをリスタートさせて、シス
テム管理者にメッセージを送信することができる。同様に、クライアントに故障
が起こると、サーバは、クライアントのリカバリルーチンを呼び出し、クライア
ント上で故障リカバリを実行する。

【００７５】 クライアント及びサーバが互いにリカバリしあうため、システム管理は、分散
型システムで行われる。すなわち、従来のシステムで採用していたような、シス
テム管理を実行する中央管理者のかわりに、故障検知及びそのリカバリのために
リーステクニックを使用することにより、当該他の実施形態は、システム管理処
理を分散させる。そのため、クライアントはサーバ上でリカバリを実行すること
ができ、サーバはそのクライアント上でリカバリを実行することができる。

【００７６】 他の実施形態は、あらゆるクライアントサーバ関係、例えば、ネットワークを
介して情報通信する独立のマシン上にクライアント及びサーバが配置される分散
型システムにおけるオペレーションに用いることができる。このような他の実施
形態による使用に好適な分散型システムとしては、審査に係属中の米国特許出願
No. 、発明の名称「分散型システムにおけるダイナミック検索サービス 」において開示された分散型システムが典型的である。しかしながら、より明確
にする目的で、以下に、補助記憶装置上の記憶ロケーションをリースするファイ
ルシステムマネージャであるサーバに関して、他の実施形態を説明する。

【００７７】 ［記憶ロケーションのリースの概要］ 記憶デバイスは、種々の論理的にグループ化されたデータを保持する多くの記
憶ロケーションを備え、それらの論理的にグループ化されたデータは、複数プロ
グラムによって利用可能である。これらの論理的グループ化は、ファイル形態、
データベース形態又はドキュメント形態をとることができる。記憶ロケーション
のリースにより、所定の予め取り決めた時間長さだけ、記憶ロケーションにアク
セス（例えば、読出及び書込アクセス）することができる。どの種類のデータが
記憶ロケーションに保持されているか又は記憶ロケーションが全くデータを保持
していないのかということは、記憶ロケーションのリースに関しては足りないこ
とである。

【００７８】 コンピュータシステム又は分散型システムにおいては、多くのプログラムが記
憶ロケーションの種々のグループ内で記憶されたファイルに競合アクセスするこ
とができる。従って、記憶ロケーションのグループは、アクセスが競合する多く
のプログラムを保持することができる。リーステクニックは、このような環境で
の記憶ロケーションの使用を調整するのに使用することができる。

【００７９】 ファイル用のデータを保持する記憶ロケーションのグループに対してリースを
使用する場合には、プログラム（"クライアント"）は、ファイルシステムマネー
ジャ（"サーバ"）からのリースをリクエストし、所定時間（"リースピリオド"）
の間、記憶ロケーションのグループへアクセスする。有効性、優先順位及び他の
要因により、サーバは、リクエストを拒むか又はリースピリオドを許可する。許
可されたリースピリオドは、リクエストされた完全なリースピリオドでもよいし
、その一部分でもよい。一旦、クライアントがリースを受信すると、クライアン
トは、リースピリオドの間、記憶ロケーションのグループにアクセスすることが
できる。

【００８０】 リースピリオドをリクエストする場合には、クライアントは、正確なリースピ
リオドをリクエストすることができる。この状況では、サーバは、リースピリオ
ドが、リクエストされた完全なリースピリオドである場合にのみ、リースを許可
することができ、その一部分のときとは対照的である。

【００８１】 リースがアクティブである間、クライアントは、記憶ロケーションのグループ
へのアクセスが保障され、それらに対して読出／書込のオペレーションを実行す
る。同様にして、サーバは、アクティブリースの間には、記憶ロケーションの保
全性を維持する。例えば、リースピリオドの間、サーバは、リースしたファイル
の消去・上書きをさせないほか、エンティティもリースを保持するにもかかわら
ず、リースしたファイルに対してクライアント以外のエンティティによる影響を
与えない。しかしながら、リースが終了すると、サーバは、もはや、クライアン
トへのファイルの保全性を保障することができないため、サーバは、そのファイ
ルを消去するか又はそれを変更し、あるいは、同様の処理を行う他のクライアン
トにリースを許可する。サーバにより再生されるのは、処理中のリースがない記
憶ロケーションである。

【００８２】 各記憶ロケーションは、関連の限定パラメータ、例えば、アクセスパラメータ
又は特権パラメータを保持可能である。アクセスパラメータは、その記憶ロケー
ション用にサーバがサポートするアクセスのタイプを決定する。例えば、記憶ロ
ケーションは、読出アクセスオンリーと定義することができる。この場合、サー
バは、特定の記憶ロケーションに対して許可されたリース用の読出アクセスのみ
を許可する。逆に言えば、その記憶ロケーションへクライアントが書込しようと
しても、サーバにより許可されない。他の記憶ロケーションのアクセスパラメー
タとしては、書込アクセス、割当アクセス、再割当アクセス及びサブブロックア
クセス（すなわち、大きな記憶ブロック用）を含むことができる。

【００８３】 関連する特権パラメータは、クライアントがリースを許可される前に保持すべ
き特権レベルを指定する。サーバは、特権パラメータを使用して競合するリース
のリクエストの優先順位を付ける。換言すれば、サーバが同一の記憶ロケーショ
ンに対して複数の処理中のリースリクエストを保持する場合には、サーバは、リ
クエストを行うクライアントの特権レベルに基づいてリクエストに優先順位を付
ける。

【００８４】 当該他の実施形態はまた、同一の記憶ロケーションに対する複数の競合リース
を許可することにより、記憶ロケーションのグループへの競合アクセスをサポー
トする。例えば、特定の記憶ロケーションのパラメータが"読出"アクセスを指定
するとすれば、サーバは、その記憶ロケーションへ当該記憶ロケーションの保全
性を破壊することなく、複数の競合するリースを許可することができる。競合す
るリースは、例えば、大きいサイズのファイルへも適用されることになる。サー
バは、そのより大きいサイズのファイルの保全性に悪影響を及ぼすことなく、よ
り小さいサイズのファイルのサブブロックへリースを許可するにすぎない。

【００８５】 クライアントが一旦リースをリクエストすると、サーバは、クライアントにオ
ブジェクトを返すが、そのオブジェクトは、リース時間の決定メソッド、リース
更新メソッド、リースのキャンセルメソッド及び故障リカバリ実行用メソッドを
含む。オブジェクトは、クラスのインスタンスであり、より多くのファンクショ
ンを提供するために多くの手法で拡張することができるが、ベーシッククラスは
Javaプログラミング言語により以下の表１のように定義される。

【表１】

【００８６】 このクラスは、多くのメソッドを保持し、このメソッドは、期間取得メソッド
、更新メソッド及びリカバリメソッドを含む。"期間取得"メソッドは、許可され
たリースピリオドの長さをクライアントに配信する。このピリオドは、サーバに
より許可された最新のリースを表している。しかしながら、リース上で残存する
時間量の決定は、クライアントの応答性によるところとなる。

【００８７】 "更新"メソッドは、クライアントがリースを更新するのを許可するものであり
、オリジナルリースリクエストを再初期化することなく、より多くの時間を要求
することができる。クライアントがリースの更新を所望する場合としては、オリ
ジナルリースが不十分になった場合（すなわち、クライアントがより多くの記憶
ロケーションの使用を要求する場合）や、一部のリースのみが許可された場合（
すなわち、要求されたリースより少ない場合）がある。

【００８８】 クライアントは、更新メソッドを使用して、追加的なリースピリオドを要求す
るか又は多くの追加のリースピリオドが許可されるまで、継続的に更新メソッド
を何度も呼び出す。更新メソッドには戻り値がない。更新が許可されると、新た
なリースピリオドは、コールがなされたリースオブジェクトに反映される。サー
バがリースを更新することができない場合又は更新しようとしない場合には、そ
の原因がそのコールがなされたリースオブジェクトに示される。

【００８９】 クライアントは、当該クライアントがリースをキャンセルしたいとする場合に
"キャンセル"メソッドを呼び出させる。従って、キャンセルメソッドの呼出によ
り、サーバは、記憶ロケーションを再生することができ、他のプログラムがそれ
らにアクセスすることができるようになる。リースがクライアントによる明示的
なキャンセルをすることなく終了する場合には、サーバはエラーが発生したもの
と仮定する。

【００９０】 "リカバリ"メソッドは、サーバにより配信され、これにより、クライアントは
サーバ上で故障リカバリを実行することができる。例えば、このようなエラーリ
カバリは、サーバのリスタートを含む。

【００９１】 参考のために示すが、記憶ロケーションのリースについては、審査に係属中の
米国特許出願No. 、発明の名称「記憶領域をリースするためのメソッド 及びシステム」に説明されている。

【００９２】 ［詳細な実装形態］ 図９は、本発明の他の実施形態に用いて好適なデータプロセッシングシステム
９０００を示したものである。データプロセッシングシステム９０００は、イン
ターネット９００２に連結されたコンピュータシステム９００１を含む。コンピ
ュータシステム９００１は、メモリ９００３、補助記憶デバイス９００４、中央
処理ユニット（CPU）９００６、入力デバイス９００８及びビデオディスプレイ ９０１０を含む。メモリ９００３は、更に、オペレーティングシステム９０１２
及びクライアントとなるプログラム９０１４を含む。オペレーティングシステム
９０１２は、サーバとなるファイルシステムマネージャ９０１６を保持し、サー
バが補助記憶デバイス９００４のファイル９０１８を管理する。補助記憶デバイ
ス９００４は、Java^TMスペース９０１９も含む。クライアント９０１４は、サー
バ９０１６からのリースをリクエストすることによって一又は複数のファイル９
０１８へのアクセスをリクエストする。これに応えて、サーバ９０１６は、後述
するように、リースの許可又は拒否のいずれかを選択することができる。

【００９３】 Javaスペース９０１９は、オブジェクトをストアするためにデータプロセッシ
ングシステム９０００のプログラムにより使用されるオブジェクトの貯蔵箇所で
ある。プログラムは、Javaスペース９０１９を使用して、オブジェクトをネット
ワーク上の他のデバイスとアクセス可能とするとともに、永続的にこれらのオブ
ジェクトをストアする。参考のために示すが、Javaスペースについては、1997年
11月17日に本件出願人により出願された審査に係属中の米国特許出願番号No.08/
971,529、発明の名称「多様型エントリ及びエントリマッチングを使用したデー タベースシステム」に説明されている。当業者にとって周知であるように、コン
ピュータ９０００は、追加の又は異なるコンポーネントを保持するものでもよい
。

【００９４】 上述した変形例の要旨は、メモリ９００３に記憶させたものとして説明したが
、いわゆる当業者にとっては、これらの要旨を他のコンピュータ読取可能な媒体
、例えば、補助記憶装置（ハードディスク、フロッピーディスク、コンパクトデ
ィスク・読出オンリメモリ）；インターネット９００２からの伝送波；又はラン
ダムアクセスメモリや読出オンリメモリ等の他の媒体、に記憶させても、又は、
これらから読み出してもよいことは周知である。更に、いわゆる当業者にとって
は、他のデータ形態、例えば、データベース、スプレッドシート、ドキュメント
等の形態を補助記憶デバイスにおけるリース用に使用可能であることは周知であ
る。

【００９５】 図１０は、クライアントがサーバからのリースをリクエストする場合に当該ク
ライアントによって実行されるステップのフローチャートを示したものである。
クライアントにより実行される第一のステップは、サーバに対してリースのリク
エストを送信することである（ステップ１０００２）。クライアントによって実
行される最初のステップは、リースのリクエストをサーバに送信することである
（ステップ１００２）。このリクエストは、多くのパラメータを伴うファンクシ
ョンコールであり、(1)クライアントがリースしようとしているリクエストされ た記憶ロケーション、(2)所望のリースピリオド、(3)正確なリースインジケータ
、(4)クライアントが所望するアクセスタイプ、(5)クライアントの特権、及び、
(6)リカバリメソッドを保持するオブジェクトを含む。このメソッドは、クライ アント用にエラーリカバリを実行するためのコードを保持する。

【００９６】 リクエストされた記憶ロケーションは、リースされるべき記憶ロケーションの
表示を保持する。所望のリースピリオドは、クライアントが記憶ロケーションを
利用しようと欲する時間長さを保持する。正確なリースリクエストは、正確なリ
ースリクエストがなされているか又はリクエストされた時間よりも短いリースで
十分であるかの表示を保持する。リクエストされたアクセスタイプは、クライア
ントがリクエストした記憶ロケーションアクセスのタイプを表示する。アクセス
タイプは、読出アクセス、ライトアクセス、割当アクセス、再割当アクセス、サ
ブブロックアクセス（すなわち、大きなサイズの記憶ブロック用）を含む。特権
フィールドは、ユーザ又はクライアントの特権レベルを表示する。有効なリクエ
ストを形成するためには、クライアントリクエストは、リクエストされた記憶ロ
ケーション及び所望のリースピリオドの両者を保持しなければならない。

【００９７】 記憶ロケーションへのリースリクエストを生成するには、一般的に２つのシナ
リオがある。第一のシナリオは、ファイルが生成されたときに起こる。"生成"コ
マンドは、ファイルを生成するのに使用され、サーバに対するリースリクエスト
を生成して、ファイルへアクセスする。第二のシナリオは、クライアントが既存
の記憶ロケーション又は既存リースを保持するファイル（すなわち、競合するリ
ース）へアクセスしようとする場合に起こる。

【００９８】 リクエストを送信した後、クライアントは、サーバからリースオブジェクトを
受信する（ステップ１０００４）。リースオブジェクトは、上述したように、フ
ァイルハンドル、期間取得メソッド、更新メソッド、キャンセルメソッドを含む
種々の情報を保持する。

【００９９】 クライアントはリースオブジェクトを受信したあと、ファイルを利用する（ス
テップ１０００５）。次に、クライアントは、ファイルの使用を完了したか否か
を判断する（ステップ１０００６）。完了した場合には、クライアントはキャン
セルメソッドをリースオブジェクト上で呼び出してそのリースを明示的にキャン
セルする（ステップ１０００７）。このメソッドを呼び出すことにより、サーバ
が故障発生を認識することなく、当該サーバによりリースがキャンセルされるこ
とになる。

【０１００】 クライアントがファイルの使用を完了しなかった場合には、クライアントはリ
ースが終了しかけであるか否かを判断する（ステップ１０００８）。クライアン
トは、このステップを期間取得メソッドを呼び出すことにより実行し、残存時間
が所定のスレショルドレベル以内であるか否かを判断する。リースが終了しかけ
でない場合には、処理はステップ１０００５へ戻る。しかしながら、リースが終
了しかけである場合には、クライアントは、更新リクエストをサーバへ送信する
（ステップ１０００９）。このステップにおいては、クライアントは更新メソッ
ドをリースオブジェクト上で呼び出す。更新メソッドを呼び出した後、クライア
ントは更新リクエストが成功したか否かを判断する（ステップ１００１０）。こ
のステップにおいては、クライアントは、更新リクエストが成功したかどうかを
更新メソッドがうまくリターンを返したかによって判断する。成功した場合には
、処理はステップ１０００５へ戻る。しかしながら、更新メソッドがうまくいか
なかった場合には、クライアントはリカバリメソッドをリースオブジェクト上で
呼び出す（ステップ１００１２）。更新リクエストがうまくいかなかったため、
クライアントは、故障発生を認識するため、リカバリメソッドを呼び出すことに
よりエラーリカバリを実行する必要があるからである。リカバリメソッドにより
、サーバ上でリカバリが実行される。

【０１０１】 図１１は、本発明に係る他の実施形態におけるサーバにより実行されるステッ
プのフローチャートを示す。サーバにより実行される第一のステップは、Javaス
ペース９０１９へアクセスすることである（ステップ１１００２）。サーバは、
リースリクエストの間に受信された全オブジェクトを保存するJavaスペースを保
持する。これらのオブジェクトは、Javaスペースに保存されるが、その理由は、
サーバが故障を検知した場合に、サーバが、Javaスペースにアクセスして、オブ
ジェクト上でリカバリメソッドを呼び出してリカバリを実行するためである。更
に、オブジェクトは永続的に保存されるが、その理由は、サーバに故障及びクラ
ッシュが起こった場合において、当該サーバがリスタートされたときに、リカバ
リメソッドをJavaスペースの各オブジェクト上で呼び出し、それが当該サーバの
故障時における全ての処理中のリースに反映される。ステップ１１００２におい
て、サーバは、全オブジェクト、といっても、リースオブジェクトの一部として
クライアントから受信した全オブジェクトにアクセスにアクセスする。Javaスペ
ース内にオブジェクトが存在する場合には、故障はサーバが処理する間に発生す
る。

【０１０２】 次に、サーバは、リカバリメソッドをJavaスペース内の各オブジェクト上で呼
び出す（ステップ１０００４）。このステップにおいて、Javaスペースにオブジ
ェクトが存在する場合には、サーバが故障により処理を中断しているため、リカ
バリを実行しなければならない。サーバは、このリカバリを、リースを保持して
いた各クライアント用にリカバリメソッドを呼び出すことにより実行する。これ
らのリカバリメソッドは、例えば、クライアントをリスタートして、それらを故
障発生前の状態に戻すものであればよい。全リカバリメソッドを呼び出した後、
サーバは、Javaスペースから全オブジェクトを削除する（ステップ１１００６）
。リカバリが実行された後、オブジェクトはもはや必要ではない。

【０１０３】 オブジェクトを削除した後、サーバは、リースリクエストをクライアントの一
つから受信する（ステップ１１００８）。リースリクエストを受信した後、サー
バは、Javaスペース内にこのリクエストで受信したオブジェクトを保存する（ス
テップ１１０１０）。Javaスペースにオブジェクトを保存することにより、Java
スペースはオブジェクトを永続的に保存し、故障発生時でも、サーバは、Javaス
ペースにアクセスすることができ、且つ、オブジェクト上でリカバリメソッドを
呼び出してクライアント用にエラーリカバリを実行することができる。

【０１０４】 Javaスペースにオブジェクトを保存した後、サーバは、上述したメソッドを用
いてオブジェクトを返すことにより、リースリクエストを許可する。そのオブジ
ェクトは、サーバ用のリカバリメソッドが含まれる（ステップ１１０１２）。暫
くのサーバ処理の後、サーバは、クライアントから更新リクエストを受信したか
否かを判断する（ステップ１１０１４）。更新リクエストが受信された場合には
、サーバはリースを更新する（ステップ１１０１７）。しかしながら、更新が受
信されなかった場合には、サーバは、キャンセルメソッドを呼び出すクライアン
トによってキャンセルリクエストが受信されたか否かを判断する（ステップ１１
０１５）。クライアントがキャンセルメソッドを呼び出した場合には、サーバは
、ステップ１１０１０で保存されたオブジェクトをJavaスペースから削除するこ
とによってリースをキャンセルし、これがファイル上で最新の処理中のリースで
ある場合には、サーバはファイルを削除する（ステップ１１０１６）。

【０１０５】 キャンセルリクエストが受信されなかった場合には、サーバは、リースが終了
したか否かを判断する（ステップ１１０１８）。リースが終了していない場合に
は、処理がステップ１１０１４へ戻る。しかしながら、リースが終了した場合に
は、サーバは、故障発生を認識するため、中断したリースを保持するクライアン
ト用のJavaスペースのオブジェクト上でリカバリメソッドを呼び出す（ステップ
１１０２０）。リカバリメソッドを呼び出した後、サーバは、このオブジェクト
が不要となるため、削除する（ステップ１１０２２）。

【０１０６】 以上、本発明に係る方法及びシステムについて好適な実施形態を参照して説明
したが、特許請求の範囲で定義される保護が要求される発明の範囲を逸脱するこ
となく、種々の変形例が可能であることは、いわゆる当業者にとっては周知であ
る。

【図面の簡単な説明】

【図１】 図１は、本発明の一実施の形態に係るアプリケーションコールプロセッサによ
って実行される工程のフローチャートである。

【図２】 図２は、本発明の一実施の形態に係るダーティーコールを処理するサーバコー
ルプロセッサによって実行される工程のフローチャートである。

【図３】 図３は、本発明の一実施の形態に係るクリーンコールを処理するサーバコール
プロセッサによって実行される工程のフローチャートである。

【図４】 図４は、本発明の一実施の形態に係るガベージコレクション処理を初期化する
サーバコールプロセッサによって実行される工程のフローチャートである。

【図５】 図５は、分散型プロセッシングシステムにおけるコールの好適なフローを示し
た図である。

【図６】 図６は、本発明に係るメソッド呼出サービスに実装されるコンポーネントを示
したブロック図である。

【図７】 図７は、本発明の一実施形態において使用される分散型プロセッシングシステ
ムの構成を示した図である。

【図８】 図８は、本発明の一実施形態に係る分散型プロセッシングシステムのプラット
フォームに含まれる個々のソフトウエアコンポーネントを示した図である。

【図９】 図９は、本発明の他の実施形態において使用されるデータプロセッシングシス
テムを示した図である。

【図１０】 図１０は、本発明の他の実施形態に係り、サーバからのリースをリクエストす
る場合にクライアントによって実行される工程を示したフローチャートである。

【図１１】 図１１は、本発明の他の実施形態に係り、クライアントがリースをリクエスト
したする場合にサーバによって実行される工程を示したフローチャートである。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年４月１８日（２０００．４．１８）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】変更

【補正内容】

【０００１】 参考のために示すが、本出願は、1998年11月3日に発行された米国特許No.5,83
2,529号、発明の名称「分散型ガーベジコレクションのための方法、装置及びプ ロダクト」の関連出願である。また、本出願は、2000年1月18日に発行された米 国特許No.6,016,500号、発明の名称「故障検知のためのリース」の関連出願であ
る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 ウォールラス アン エム アメリカ合衆国、01450 マサチューセッ ツ州、グロトン、ノースウッズ ロード ９ (72)発明者 シェフラー ロバート アメリカ合衆国、02144 マサチューセッ ツ州、サマビレ、ノース ストリート 96 (72)発明者 アーノルド ケネス シー アール シー アメリカ合衆国、02173 マサチューセッ ツ州、レキシントン、ムーン ヒル ロー ド ７ Ｆターム(参考） 5B045 JJ07 JJ42 5B060 AA10 AC11 5B098 AA03 AA10 GA05 GD03 GD12 GD14 GD22

Claims (3)

【特許請求の範囲】
1. 【請求項１】 クライアントが、サーバにより管理されるリソースを使用す
   るために、当該サーバからの第一リカバリルーチンを保持するリースをリクエス
   トする工程と、 前記クライアントが所定時間内にリソースを利用することができるように前記
   サーバによるリースを許可し、第二リカバリルーチンを前記クライアントに送信
   する工程と、 前記クライアントが前記リソースを利用する工程と、 前記所定時間が終了に近づいた場合を前記クライアントが判断する工程と、 前記クライアントがリースが終了に近づいた場合に前記リースを更新するリク
   エストを前記サーバに送信する工程と、 前記更新リクエストが成功したか否かを判断する工程と、 前記クライアントにより前記更新リクエストが不成功であったと判断された場
   合に、前記クライアントが前記サーバ用に故障リカバリを実行するために、前記
   クライアントが前記第二リカバリルーチンを呼び出す工程と、 前記リースが終了した場合をサーバが判断する工程と、 前記リースが終了した場合に前記クライアント用に故障リカバリを実行するた
   めに、前記サーバが前記第一リカバリルーチンを呼び出す工程と、からなること
   を特徴とするクライアントサーバを有するデータ処理システムにおけるデータ処
   理方法。
2. 【請求項２】 分散型システムのマシンにアクセスするためのリースを配信
   する工程と、 前記リースが延長を要求するか否かを判断する工程と、 前記リースを延長するために更新リクエストを送信する工程と、 前記マシンにアクセスするのを妨害するイベントを故障に基づいて検知して、
   前記更新リクエストに応じて新たなリースを受信する工程と、 からなることを特徴とするプロセッサによって実行される分散型システムの故
   障検知方法。
3. 【請求項３】 更に、前記マシンへのアクセスを妨害するイベントの検知に
   基づいてリカバリルーチンを実行することを特徴とする請求項２に記載のプロセ
   ッサによって実行される分散型システムの故障検知方法。