JP5395532B2 - クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム - Google Patents
クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム Download PDFInfo
- Publication number
- JP5395532B2 JP5395532B2 JP2009147852A JP2009147852A JP5395532B2 JP 5395532 B2 JP5395532 B2 JP 5395532B2 JP 2009147852 A JP2009147852 A JP 2009147852A JP 2009147852 A JP2009147852 A JP 2009147852A JP 5395532 B2 JP5395532 B2 JP 5395532B2
- Authority
- JP
- Japan
- Prior art keywords
- handle
- file
- parent
- event
- child
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、クライアント／サーバ型のファイルシステムへのアクセス技術に関する。
従来、ファイル共有システムとして、例えば、ＮＦＳ（Network File System）やＣＩＦＳ（Common Internet File System）が知られている。
例えば、非特許文献１に記載のクライアント／サーバ型の分散ファイルシステムにおいて、各クライアントは、サーバからファイルの内容を一度でも読み込むと、そのファイルの内容をキャッシュする。一般的に、キャッシュは、キャッシュコヒーレンシ（Cache Coherency）が課題となる。つまり、サーバ側でファイルの内容の更新が要求された際に、そのファイルの内容をキャッシュしている各クライアントがそれぞれ保持している情報の均一性を保つことが課題となる。
例えば、非特許文献１に記載のクライアント／サーバ型の分散ファイルシステムにおいて、各クライアントは、サーバからファイルの内容を一度でも読み込むと、そのファイルの内容をキャッシュする。一般的に、キャッシュは、キャッシュコヒーレンシ（Cache Coherency）が課題となる。つまり、サーバ側でファイルの内容の更新が要求された際に、そのファイルの内容をキャッシュしている各クライアントがそれぞれ保持している情報の均一性を保つことが課題となる。
非特許文献１に記載の方法では、サーバ側でファイルの内容の更新が要求された際に、ファイルの内容をキャッシュしている全てのクライアントのキャッシュを削除した時点で初めてファイルの内容を更新する。言い換えると、この方法では、サーバは、全てのクライアントに対して、キャッシュ無効化を行い、クライアントでのキャッシュクリアを確認するか、または、クライアントとのセッションが途絶するか、のいずれかの条件が、全てのクライアントに対して満たされない限り、ファイルの内容の更新を完了できない。非特許文献１に記載の方法では、このような方式により、キャッシュコヒーレンシの課題を解決している。
Mike Burrows,"The Chubby lock service for loosely-coupled distributed systems", OSDI'06, Seattle, WA, November, 2006.
しかしながら、従来技術では、例えば、ＮＦＳやＣＩＦＳでは、クライアントが、サーバとの通信において、サーバ上の所定のファイルおよびディレクトリにアクセスする回数が多数に及んだ場合には、そのアクセスに対応して、ファイルのオープンを行った回数と同数の重複した多数のハンドル（ファイルハンドル）が提供される。つまり、ネットワークの通信回数および通信量が多くなり、クライアント内部では多数のハンドルを格納するために多くのメモリ領域が消費される。
また、クライアントが、サーバとの通信において、サーバ上の所定のファイルおよびディレクトリに対して、各種オペレーション（オープン、クローズ、読込み、書込み等）を実行した際にも、そのオペレーションを実行した回数だけネットワーク上の通信が行われる。したがって、ネットワークの通信回数および通信量が多くなり、ネットワークに負荷をかけることとなる。
また、優先度の高い他の通信アプリケーション（クライアントアプリケーション）によりネットワークの通信の大部分が占有されている中で、この優先度の高い他の通信アプリケーションとの通信帯域の奪い合いを避けるために、対象とする通信アプリケーションを含むシステム内で通信量を低減できる技術が要望されている。
また、キャッシュコヒーレンシの課題に関しては、非特許文献１に記載の方法では、クライアント内で複数開かれているハンドルに対して、キャッシュされたファイルの内容の一次記憶領域（メモリ）がファイルのオープンを行った回数と同数必要である。さらに、この場合、ファイルの内容の転送に係る通信も同様に重複するため、本来は不要な通信が発生していることになる。
そこで、本発明では、前記した問題を解決し、ファイルシステムへのアクセスにおいて、クライアントとサーバとの間で発生する通信の回数や量を低減することのできる技術を提供することを目的とする。
前記目的を達成するために、本願発明者らは、クライアント／サーバ型のファイルシステムにおいて種々検討を行った。その結果、同一のクライアントがサーバ上の同じファイルおよびディレクトリに対して複数回のアクセスを行う際に用いる複数回分のハンドルを、親ハンドルおよび子ハンドルのデータ構造に分け、かつ、クライアント内で親ハンドルの処理と子ハンドルの処理とを分けることで、ファイルシステムに対する複数回のアクセスをクライアント内で集約可能であることを見出した。
そこで、本発明に係るクライアント装置は、ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、ハンドルを用いて操作するクライアント装置とを備えるコンピュータシステムにおける前記クライアント装置であって、前記ファイルシステムに対する所定操作の実行を要求するアプリケーション部と、前記アプリケーション部による要求を中継して前記ファイルシステムにアクセスするライブラリ部と、を有し、前記アプリケーション部が、前記ライブラリ部に対して、前記ファイルシステム上のファイルまたはディレクトリの操作に対応するハンドルの作成を要求するハンドル作成依頼を作成し、前記ライブラリ部が、前記アプリケーション部から１回目の前記ハンドル作成依頼を受領したときに、前記サーバ装置とのセッションを通じて、前記ハンドルとして前記ファイルシステム上のファイルまたはディレクトリを特定し操作できる親ハンドルを前記サーバ装置から取得し、前記親ハンドルに従属して前記セッションにおいて有効な子ハンドルを生成し、生成した前記子ハンドルを前記アプリケーション部に返却し、前記セッション中に前記アプリケーション部から前記ファイルと同一のファイルに対して、２回目以降のハンドル作成依頼を受領したときに、前記同一のファイルに対応して前記親ハンドルに関連付けて新たに生成した子ハンドルを返却し、前記親ハンドルの識別情報と生成した前記子ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納しておく親子ハンドル管理手段を備えることを特徴とする。
かかる構成によれば、クライアント装置は、サーバ側から付与された親ハンドルに対して従属する子ハンドルをライブラリ部にて生成し、アプリケーション部に返却する。アプリケーション部は、所定操作として、オープンまたはクローズ（ハンドルの作成または削除）や、ファイルの作成または削除を要求する。また、ライブラリ部で生成されるそれぞれの子ハンドルは、アプリケーション部においては、別々のハンドルとして利用できる。つまり、クライアント装置は、対象とするオープンによって得られた子ハンドルと、別のオープンによって得られた子ハンドルとを区別しつつ、他のオペレーションを集約することができる。したがって、同一クライアント装置から同じファイルおよびディレクトリに対する別ハンドルのアクセスを集約することができる。
また、本発明に係るクライアント装置は、前記アプリケーション部が、前記ライブラリ部に対して、前記サーバ装置の前記ファイルシステムで管理されたファイルの内容を取得することを要求するファイル内容取得依頼を作成し、前記ライブラリ部が、前記アプリケーション部から前記子ハンドルを用いた１回目の前記ファイル内容取得依頼を受領したときに、前記親ハンドルと共に前記ファイル取得依頼を前記サーバ装置に送信することで、前記サーバ装置から前記ファイルの内容を取得し、取得した前記ファイルの内容を前記親ハンドルに関連付けて記憶手段にキャッシュ情報として登録し、前記セッション中に前記アプリケーション部から、前記１回目のファイル取得依頼と同一のファイルに対して、取得した前記ファイルの内容に関連付けた前記親ハンドルに従属する子ハンドルを用いた２回目以降のファイル内容取得依頼を受領したときに、登録されている前記キャッシュ情報を返却するキャッシュ情報登録手段をさらに備えることが好ましい。
かかる構成によれば、クライアント装置は、親子ハンドルのデータ構造による集約として、オープンまたはクローズ（ハンドルの作成または削除）の集約や、ファイルの作成または削除の集約の他に、ファイルの書込または読込の集約（ファイルの内容のキャッシュ）も行うことができる。
また、本発明に係るクライアント装置は、前記アプリケーション部が、前記サーバ装置で管理するファイルおよびディレクトリの少なくとも１つの状態の変化を示すイベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼を子ハンドル毎に作成する際に、監視するイベント種別とイベント発生通知時の処理を示すコールバック処理の情報を前記ライブラリ部に登録し、前記ライブラリ部の前記親子ハンドル管理手段が、前記ハンドルリストにおいて、前記イベント監視登録依頼で用いられる子ハンドル毎に前記コールバック処理の情報を記憶し、前記ライブラリ部が、前記アプリケーション部から、前記イベント監視登録依頼を前記子ハンドルと共に受領したときに、前記子ハンドル毎に記憶されている前記コールバック処理の情報を集約して前記親ハンドルの識別情報および当該イベント監視登録依頼と共に前記サーバ装置に送信し、前記サーバ装置から、前記集約したコールバック処理の情報を前記イベント発生通知として受信したときに、受信した前記コールバック処理の情報における集約を解除することで、当該イベント発生通知に該当する子ハンドルを探索し、前記探索された子ハンドルに付与されているイベント発生通知時の処理を実行するイベント通知制御手段をさらに備えることが好ましい。
かかる構成によれば、クライアント装置は、親子ハンドルのデータ構造による集約として、サーバ上でイベントが発生したときに、同一のクライアント装置にて当該イベントを複数の子ハンドルを用いて監視しているときに、イベント通知を集約することができる。
また、本発明に係るクライアント装置は、前記ライブラリ部が前記イベント通知制御手段を備える態様において、前記アプリケーション部が、前記コールバック処理の情報として、監視するイベント種別とイベント発生通知時の処理の有無を管理するマスク値を前記ライブラリ部に登録し、前記ライブラリ部の前記親子ハンドル管理手段が、前記子ハンドルに対して、前記コールバック処理の情報であるイベント毎の前記マスク値の集合をイベントマスクとして付与して記憶し、前記ライブラリ部のイベント通知制御手段が、前記イベント監視登録依頼と共に受領した前記子ハンドルのイベントマスク値と、前記親ハンドルのイベントマスク値との論理和を計算することで前記コールバック処理の情報を集約し、この計算結果で前記親ハンドルのイベントマスク値を更新し、前記更新により生成された新イベントマスクの登録依頼を、前記イベント監視登録依頼と共に前記サーバ装置に送信し、前記サーバ装置から、前記イベント発生通知として前記新イベントマスクを受信したときに、前記ハンドルリストに記載された前記子ハンドルのイベントマスク値と前記受信した新イベントマスクのマスク値との論理積を計算することで、受信した前記新イベントマスクにおける前記子ハンドルのイベントマスク値の集約を解除することが好ましい。
かかる構成によれば、クライアント装置は、コールバック処理の情報としてイベントマスクを、親ハンドルと、その親ハンドルに従属した子ハンドルとに付与して管理する。イベントマスクは、イベント種別毎に、例えば、イベント発生通知処理の「有」および「無」を、それぞれ論理値の「１」および「０」としたビット列で表現できる。そして、クライアント装置は、サーバ側からイベント発生通知を受信したときに親ハンドルと子ハンドルとの論理積を計算することでイベント発生を通知すべき子ハンドルを容易に探索できる。これは、クライアント装置が、イベント監視登録依頼をサーバ側に送信する前に、親ハンドルと子ハンドルの論理値の論理和を計算して更新した新イベントマスクの所定のイベントについてのマスク値が「１」かつ、子ハンドルの当該イベントについてのマスク値が「１」であるときにだけイベント発生通知処理をすればよいことが決定できるからである。
また、本発明に係るクライアント装置は、前記アプリケーション部が、前記ライブラリ部に対して、前記セッションにおいて前記サーバ装置に記憶された前記ファイルシステムで管理されたファイルまたはディレクトリに対するロックを前記子ハンドルが取得することを要求するロック取得依頼を作成し、前記ライブラリ部の前記親子ハンドル管理手段が、前記ハンドルリストにて前記子ハンドルのロック取得状況の情報を前記子ハンドルに関連付けて記憶し、前記ライブラリ部が、前記アプリケーション部から、前記ファイルシステムで管理された所定のファイルまたはディレクトリに対する前記ロック取得依頼を前記子ハンドルと共に受領したときに、前記受領した子ハンドルのロック取得状況の情報が前記ハンドルリストに記憶されている場合に当該ロック取得状況の情報を返却し、一方、記憶されていない場合に、当該子ハンドルの前記ロック取得依頼を前記親ハンドルの識別情報と共に前記サーバ装置に送信し、前記サーバ装置から、サーバ側にて当該子ハンドルのロック取得状況の情報が登録されたことを示す応答を受信したときに、受信した前記応答で示されるロック取得状況の情報を、当該子ハンドルのロック取得状況の情報として前記ハンドルリストに登録するロック制御管理手段をさらに備えることが好ましい。
かかる構成によれば、クライアント装置は、ロック機能を有しているので、ファイルシステムで管理されたファイルまたはディレクトリに対する他のクライアント装置によるアクセスを排他することができる。したがって、対象のクライアント装置とは別のクライアント装置から、同じファイルおよびディレクトリに対する別ハンドルのアクセスが生じる場合にも、当該対象のクライアント装置から、当該同じファイルおよびディレクトリに対する別ハンドルのアクセスを集約することができる。
また、前記目的を達成するために、本発明に係るサーバ装置は、ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、親ハンドルに従属する子ハンドルを用いて操作するアプリケーション部を備えるクライアント装置とを備えるコンピュータシステムにおける前記サーバ装置であって、前記クライアント装置とのセッションにより、前記アプリケーション部から、前記ファイルシステム上のファイルまたはディレクトリの操作に対応する前記親ハンドルの作成を要求するハンドル作成依頼を受信し、前記親ハンドルを生成し、生成した前記親ハンドルを当該クライアント装置に返却し、当該クライアント装置のアプリケーション部と生成した前記親ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納しておくハンドル管理手段を備えることを特徴とする。
かかる構成によれば、サーバ装置は、クライアント側からのハンドル作成依頼に応答して親ハンドルを生成してクライアント装置のアプリケーション部に付与し、ハンドルリストを生成する。したがって、ハンドルリストを用いることでクライアントのアプリケーション部毎に親ハンドルを管理することができる。
また、本発明に係るサーバ装置は、前記セッションにより、前記アプリケーション部から、前記ファイルシステムで管理されたファイルの内容を取得することを要求するファイル取得依頼を、当該アプリケーション部と前記ファイルに対応した前記親ハンドルと共に受信し、当該ファイルの内容を当該クライアント装置に返却し、前記ハンドルリストにて、返却した前記ファイルの内容が当該クライアント装置にキャッシュされていることを示すキャッシュ状態情報を、前記受信した親ハンドルの識別情報と関連付けて登録するキャッシュ管理手段をさらに備えることが好ましい。
かかる構成によれば、サーバ装置は、クライアント側からのファイル取得依頼に応答したときに、ハンドルリストにて、キャッシュ状態を親ハンドルに関連付けて登録する。ここで、同一クライアント装置から同じファイルに対する別ハンドルのアクセスは、クライアント装置内で集約されているため、一度キャッシュされた後には、ファイル取得依頼に係るファイルシステムへのアクセスを防止できる。また、サーバ側でファイルの内容の更新が要求された際に、サーバは、ハンドルリストを用いることで、ファイルの内容をキャッシュしている全てのクライアントのアプリケーション部に対して、キャッシュ無効化を行い、クライアントのアプリケーション部でのキャッシュクリアを容易に確認することができる。
また、本発明に係るサーバ装置は、前記セッションにより、前記アプリケーション部から、当該サーバ装置で管理するファイルおよびディレクトリの少なくとも１つの状態の変化を示すイベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼および前記親ハンドルの識別情報を、監視するイベント種別とイベント発生通知時の処理を示すコールバック処理の情報と共に受信したときに、前記ハンドルリストにて、受信した前記コールバック処理の情報を前記親ハンドルの識別情報と関連付けて登録し、前記イベントが発生したことを検知したときに、当該発生したイベントを通知するために登録されている前記親ハンドルを前記ハンドルリストからすべて抽出し、抽出された前記親ハンドルに基づいて、該当するクライアント装置のアプリケーション部に対してセッションを通じて、当該親ハンドルに関連付けて登録されている前記コールバック処理の情報を送信するイベント管理手段をさらに備えることが好ましい。
かかる構成によれば、サーバ装置は、クライアント側から、イベント監視登録依頼として取得したコールバック処理の情報を、ハンドルリストにて親ハンドルに関連付けて登録しておく。つまり、サーバ装置は、ハンドルリストにてコールバック処理の情報をクライアントのアプリケーション部毎に登録しておく。そして、イベント発生時には、サーバは、ハンドルリストに登録されたコールバック処理の情報を用いることでクライアントのアプリケーション部毎のセッションを通じてイベント発生を通知することができる。
また、本発明に係るサーバ装置は、前記イベント管理手段が、前記コールバック処理の情報として、イベント発生通知時の処理の有無を管理するイベント毎のマスク値の集合であるイベントマスクを前記親ハンドルの識別情報と共に受信したときに、前記ハンドルリストにて、前記受信したイベントマスクを前記親ハンドルの識別情報と関連付けて登録し、前記イベントが発生したことを検知したときに、前記コールバック処理の情報として、前記親ハンドルの識別情報に関連付けて登録されているイベントマスクを送信することが好ましい。
かかる構成によれば、サーバ装置は、コールバック処理の情報としてイベントマスクを、親ハンドルの識別情報と共に管理する。イベントマスクは、イベント種別毎に、例えば、イベント発生通知処理の「有」および「無」を、それぞれ論理値の「１」および「０」としたビット列で表現できる。このため、サーバ装置は、イベントマスクのマスク値を参照することで、イベントが発生したときの通知先を容易に識別することができる。例えば、所定のイベントが発生したことを検知したときに、当該イベントについてのマスク値が「１」である親ハンドルに対応したクライアント装置にはセッションを通じてイベント通知を送信し、当該イベントについてのマスク値が「０」である親ハンドルに対応したクライアント装置には、通知しない。そのため、イベント通知の必要のないクライアントへのネットワーク通信を確実に防止できる。
また、本発明に係るサーバ装置は、前記記憶手段が、前記親ハンドルに従属して前記クライアント装置で生成され前記セッションにおいて有効な子ハンドルの識別情報と、前記セッションにおいて当該サーバ装置に記憶された前記ファイルシステムで管理されたファイルまたはディレクトリに対するロックを前記子ハンドルが取得していることを表す情報との対応関係を示すロック取得リストをさらに記憶し、前記セッションにより、前記アプリケーション部から、当該アプリケーション部に対応した前記親ハンドルと前記子ハンドルと共に、当該子ハンドルが前記ファイルシステムで管理された所定のファイルまたはディレクトリに対する前記ロックを取得することを要求するロック取得依頼を受信したときに、受信した前記ロック取得依頼にて対象とするファイルまたはディレクトリが別のクライアント装置によってロック取得済みであることを表す情報が前記ロック取得リストに記憶されているか否かを判別し、当該情報が前記ロック取得リストに記憶されている場合には、前記別のクライアント装置によるロックが解除されるまで、受信した前記子ハンドルをロック待ち行列の記憶手段に登録して管理し、一方、当該情報が前記ロック取得リストに記憶されていない場合には、受信した前記子ハンドルを前記ロック取得リストに登録し、前記判別の結果に応じて、受信した前記子ハンドルのロック取得状況の情報を前記クライアント装置のアプリケーション部に返却するロック管理手段をさらに備えることが好ましい。
かかる構成によれば、サーバ装置は、ロック取得リストにて親ハンドル毎すなわちクライアントのアプリケーション部毎にロック取得済みの子ハンドルを登録しておき、クライアント側から、当該クライアントの子ハンドルのロック取得依頼を受信し、ロック取得リストまたはロック待ち行列の記憶手段に登録する。ロック取得リストでは、子ハンドル毎にロック取得済みの子ハンドルを登録し、ロック待ち行列でもロック取得状況を子ハンドル毎に管理できるので、クライアント装置の同一アプリケーション部から、同じファイルに対するロック取得依頼が生じる場合にも、当該アプリケーション部への応答を集約することができる。
また、前記目的を達成するために、本発明に係るコンピュータシステムは、前記したクライアント装置と、前記したサーバ装置とを備えることを特徴とする。
また、前記目的を達成するために、本発明に係るファイルシステムアクセス方法は、ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、ハンドルを用いて操作するクライアント装置とを備え、前記クライアント装置が、前記ファイルシステムに対する所定操作の実行を要求するアプリケーション部と、前記アプリケーション部による要求を中継して前記ファイルシステムにアクセスするライブラリ部とを有しているコンピュータシステムにおいて前記ファイルシステムにアクセスするファイルシステムアクセス方法であって、前記クライアント装置の前記ライブラリ部が、前記アプリケーション部による前記ファイルシステム上のファイルまたはディレクトリの操作に対応する子ハンドルを生成する際に、当該ファイルに対する１以上の前記子ハンドルを集約した親ハンドルがクライアント側ハンドルリストに登録されているか否かを判別する親ハンドル登録判別ステップと、前記親ハンドルが登録されていない場合に、前記親ハンドルの作成を要求するハンドル作成依頼を前記サーバ装置に送信するハンドル作成依頼送信ステップとを実行し、前記サーバ装置が、前記ハンドル作成依頼に基づいて、前記親ハンドルを生成し、生成した前記親ハンドルを当該クライアント装置に返却すると共に、当該クライアント装置の前記アプリケーション部と生成した前記親ハンドルの識別情報とを関連付けたサーバ側ハンドルリストを生成し、記憶手段に格納する親ハンドル生成ステップを実行し、前記クライアント装置の前記ライブラリ部が、前記サーバ装置から受信した親ハンドルの識別情報を前記クライアント側ハンドルリストに記憶する親ハンドル情報格納ステップと、前記親ハンドル登録判別ステップにて前記親ハンドルが登録されている場合、または、前記親ハンドル情報格納ステップにて前記親ハンドルの識別情報を記憶した場合に、当該親ハンドルに従属する子ハンドルを生成し、生成した前記子ハンドルの識別情報と当該親ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納する子ハンドル生成ステップとを実行することを特徴とする。
本発明に係るコンピュータシステム、または、本発明に係るファイルシステムアクセス方法によれば、親子ハンドルのデータ構造による集約として、ファイルのオープンまたはクローズの集約や、ファイルの作成または削除の集約を行うことができる。
また、本発明に係るクライアントプログラムは、前記したクライアント装置を構成する各手段としてコンピュータを機能させるためのプログラムである。このように構成されることにより、このプログラムをインストールされたコンピュータは、このプログラムに基づいた各機能を実現することができる。
また、本発明に係るサーバプログラムは、前記したサーバ装置を構成する各手段としてコンピュータを機能させるためのプログラムである。このように構成されることにより、このプログラムをインストールされたコンピュータは、このプログラムに基づいた各機能を実現することができる。
本発明によれば、クライアント／サーバ型のファイルシステムへのアクセスに用いるハンドルを親ハンドルおよび子ハンドルとしてクライアント内で親ハンドルおよび子ハンドルの処理を分けたので、同一クライアント装置から同じファイルおよびディレクトリに対する別ハンドルのアクセスを集約することができる。その結果、クライアントとサーバとの間で発生する通信の回数や量を低減することができる。
図面を参照して本発明のコンピュータシステムおよび装置を実施するための形態（以下「実施形態」という）について詳細に説明する。以下では、説明の都合上、発明の概要として、１．コンピュータシステムのハードウェア構成、２．コンピュータシステムにおける前提条件、３．親子ハンドルの構成、４．親子ハンドルの管理方式、５．親子ハンドルのキャッシュ方式、６．親子ハンドルのイベント通知方式の各章の説明をした後に、７．具体的な構成および動作の章について順次説明することとする。
［１．コンピュータシステムのハードウェア構成］
本発明の実施形態に係るコンピュータシステム１のハードウェア構成を図１に示す。
本実施形態では、クライアント／サーバ型（以下、Ｃ／Ｓ型という）のコンピュータシステム１は、オペレーティングシステム（ＯＳ：Operating System）等により構築された、ＬＡＮ（Local Area Network）上での分散コンピュータシステムとして構成した。図１に示すように、コンピュータシステム１は、ネットワークＮを介して通信可能に接続された、サーバコンピュータ（サーバ装置）２と、クライアントコンピュータ（クライアント装置）３とを備えている。ここで、サーバコンピュータ２と、クライアントコンピュータ３の台数は任意である。
本発明の実施形態に係るコンピュータシステム１のハードウェア構成を図１に示す。
本実施形態では、クライアント／サーバ型（以下、Ｃ／Ｓ型という）のコンピュータシステム１は、オペレーティングシステム（ＯＳ：Operating System）等により構築された、ＬＡＮ（Local Area Network）上での分散コンピュータシステムとして構成した。図１に示すように、コンピュータシステム１は、ネットワークＮを介して通信可能に接続された、サーバコンピュータ（サーバ装置）２と、クライアントコンピュータ（クライアント装置）３とを備えている。ここで、サーバコンピュータ２と、クライアントコンピュータ３の台数は任意である。
サーバコンピュータ２およびクライアントコンピュータ３（３ａ，３ｂ）は、ＣＰＵ（Central Processing Unit）４およびメモリ５等の演算装置と、外部との各種情報の送受信を行うネットワークI/F（ネットワークインタフェース）６と、ハードディスク等の永続性記憶装置７とを備えたコンピュータと、このコンピュータにインストールされたプログラムとから構成される。
サーバコンピュータ２の永続性記憶装置７は、ファイルデータ８と、サーバ側データ９と、ハンドル管理プログラム１１と、ロック管理プログラム１２と、キャッシュ管理プログラム１３と、イベント管理プログラム１４とを記憶している。
クライアントコンピュータ３の永続性記憶装置７は、クライアント側データ１０と、親子ハンドル管理プログラム１５と、ロック制御管理プログラム１６と、イベント通知制御プログラム１７と、キャッシュ情報登録プログラム１８とを記憶している。
なお、各データおよびプログラムの詳細については後記する。
クライアントコンピュータ３の永続性記憶装置７は、クライアント側データ１０と、親子ハンドル管理プログラム１５と、ロック制御管理プログラム１６と、イベント通知制御プログラム１７と、キャッシュ情報登録プログラム１８とを記憶している。
なお、各データおよびプログラムの詳細については後記する。
［２．コンピュータシステムにおける前提条件］
コンピュータシステム１において、クライアントコンピュータ３が、中央のサーバコンピュータ２で管理するファイルやディレクトリを示す資源を操作するためのキーとしてのハンドルを管理することを前提としている。前記のハードウェア構成と図２に示す論理構成を前提として、コンピュータシステムにおける前提条件と、ハンドルを含む用語の定義を以下に記述する。
コンピュータシステム１において、クライアントコンピュータ３が、中央のサーバコンピュータ２で管理するファイルやディレクトリを示す資源を操作するためのキーとしてのハンドルを管理することを前提としている。前記のハードウェア構成と図２に示す論理構成を前提として、コンピュータシステムにおける前提条件と、ハンドルを含む用語の定義を以下に記述する。
＜２−１＞ハンドルの概要
ハンドルとは、ある管理された領域の外側から、内側のオブジェクトを操作するためのキーとなるデータ、ポインタ、インスタンスである。例えば、Ｗｉｎｄｏｗｓ（登録商標）システムでは、ＯＳによって管理された領域中の資源を、ＯＳ上で実行されているプログラムから操作する際に、ハンドルを用いる。例えば、ハンドルを用いてファイル、プロセス、スレッド、デバイスなどを操作することができる。Ｗｉｎｄｏｗｓシステムでは、ハンドルは３２ビットの整数により表現される。本実施形態では、それのメタファーとして、ハンドルという用語を用いる。ここでは、親ハンドルや子ハンドルと区別せずに総称してハンドルと呼ぶこととする。ハンドルを用いる、前記したある管理された領域とは、サーバによって管理されたファイルシステムの領域であり、ファイルシステムを管理するのはサーバである。また、クライアントアプリケーション３１（図２参照）は、ハンドルを通じてサーバ上のファイルを操作する。本実施形態のコンピュータシステム１では、ハンドルは、クライアントコンピュータ３中のメモリ上に構築された構造体を指すポインタであり、メモリ領域上にはハンドルやファイルに関連する情報（サーバ情報、ファイル名）が格納されている。
ハンドルとは、ある管理された領域の外側から、内側のオブジェクトを操作するためのキーとなるデータ、ポインタ、インスタンスである。例えば、Ｗｉｎｄｏｗｓ（登録商標）システムでは、ＯＳによって管理された領域中の資源を、ＯＳ上で実行されているプログラムから操作する際に、ハンドルを用いる。例えば、ハンドルを用いてファイル、プロセス、スレッド、デバイスなどを操作することができる。Ｗｉｎｄｏｗｓシステムでは、ハンドルは３２ビットの整数により表現される。本実施形態では、それのメタファーとして、ハンドルという用語を用いる。ここでは、親ハンドルや子ハンドルと区別せずに総称してハンドルと呼ぶこととする。ハンドルを用いる、前記したある管理された領域とは、サーバによって管理されたファイルシステムの領域であり、ファイルシステムを管理するのはサーバである。また、クライアントアプリケーション３１（図２参照）は、ハンドルを通じてサーバ上のファイルを操作する。本実施形態のコンピュータシステム１では、ハンドルは、クライアントコンピュータ３中のメモリ上に構築された構造体を指すポインタであり、メモリ領域上にはハンドルやファイルに関連する情報（サーバ情報、ファイル名）が格納されている。
＜２−２＞ファイルおよびディレクトリの定義
ファイルおよびディレクトリに関しては、一般的なＯＳにおけるファイルシステムと同様の概念である。このうち、ファイルに対しては、作成、削除、読込、書込（更新）、ロック取得、ロック解除（ロック解放）のオペレーションが可能である。同様に、ディレクトリに対しては、作成、削除、一覧表示のオペレーションが可能である。以下、ファイルとディレクトリを総称する場合にノードと呼ぶことにする。
ファイルおよびディレクトリに関しては、一般的なＯＳにおけるファイルシステムと同様の概念である。このうち、ファイルに対しては、作成、削除、読込、書込（更新）、ロック取得、ロック解除（ロック解放）のオペレーションが可能である。同様に、ディレクトリに対しては、作成、削除、一覧表示のオペレーションが可能である。以下、ファイルとディレクトリを総称する場合にノードと呼ぶことにする。
＜２−３＞サーバの定義
コンピュータシステム１の論理構成を図２に示す。
Ｃ／Ｓ型ファイルシステムにおけるサーバとは、複数のファイルおよびディレクトリを特定する名前空間を持ち、バイト配列を記録するファイルと、より下位のファイルおよびディレクトリを管理するディレクトリとに対して、オペレーションおよびサービスを、ハンドルを用いてネットワークを通じて提供するプログラムによって動作しているプロセスを示す。ここで、サービスとは、イベント監視やイベント通知を指す。なお、同様に、オペレーションおよびサービスを、ネットワークを通じて提供するコンピュータがサーバコンピュータ２である。図２に示すサーバ（サーバプログラム）２１は、プログラムによって動作しているプロセスに当たる。なお、サーバ２１は、バックエンドデータベース２２に、ファイルシステムとして複数のファイルおよびディレクトリを特定する名前空間２５を持っている。
コンピュータシステム１の論理構成を図２に示す。
Ｃ／Ｓ型ファイルシステムにおけるサーバとは、複数のファイルおよびディレクトリを特定する名前空間を持ち、バイト配列を記録するファイルと、より下位のファイルおよびディレクトリを管理するディレクトリとに対して、オペレーションおよびサービスを、ハンドルを用いてネットワークを通じて提供するプログラムによって動作しているプロセスを示す。ここで、サービスとは、イベント監視やイベント通知を指す。なお、同様に、オペレーションおよびサービスを、ネットワークを通じて提供するコンピュータがサーバコンピュータ２である。図２に示すサーバ（サーバプログラム）２１は、プログラムによって動作しているプロセスに当たる。なお、サーバ２１は、バックエンドデータベース２２に、ファイルシステムとして複数のファイルおよびディレクトリを特定する名前空間２５を持っている。
＜２−４＞クライアントの定義
Ｃ／Ｓ型ファイルシステムにおけるクライアントとは、ネットワークを隔てたサーバ内のファイルシステムについてサーバにより提供される各種サービスを利用して、サーバ内にあるファイルおよびディレクトリを示す資源にアクセスするプログラムにより動作しているプロセスを指す。同様に、サーバ内にあるファイルおよびディレクトリを示す資源にアクセスするコンピュータがクライアントコンピュータ３である。図２に示すクライアントコンピュータ３は、プログラムによって動作しているプロセスとして、クライアントアプリケーション（アプリケーション部）３１と、クライアントライブラリ（ライブラリ部）３２とを備えている。クライアントアプリケーション３１はサーバ２１上の各種サービスを利用する。クライアントライブラリ３２は、クライアントアプリケーション３１からの操作を受け付け、サーバ２１との通信を媒介する。
Ｃ／Ｓ型ファイルシステムにおけるクライアントとは、ネットワークを隔てたサーバ内のファイルシステムについてサーバにより提供される各種サービスを利用して、サーバ内にあるファイルおよびディレクトリを示す資源にアクセスするプログラムにより動作しているプロセスを指す。同様に、サーバ内にあるファイルおよびディレクトリを示す資源にアクセスするコンピュータがクライアントコンピュータ３である。図２に示すクライアントコンピュータ３は、プログラムによって動作しているプロセスとして、クライアントアプリケーション（アプリケーション部）３１と、クライアントライブラリ（ライブラリ部）３２とを備えている。クライアントアプリケーション３１はサーバ２１上の各種サービスを利用する。クライアントライブラリ３２は、クライアントアプリケーション３１からの操作を受け付け、サーバ２１との通信を媒介する。
＜２−５＞セッションの定義
セッションとは、クライアントライブラリ３２とサーバ２１との通信の単位であり、クライアントコンピュータ３上に１つまたは複数起動されているプロセスと、サーバ２１との通信を区切る単位である。
サーバ２１が冗長化されており、故障によりフェイルオーバした場合、セッションおよび永続化されていたファイルシステムの内容は、フェイルオーバ後のサーバにも引き継がれる。このような場合、セッションが切れるのは、次の３つのケースのみである。
（１）クライアントがセッションを切った場合
（２）サーバとクライアント間のネットワークが一定時間以上不通となった場合
（３）サーバが多重故障した場合
１つのクライアントは、論理的に異なる複数のサーバのそれぞれに対して、最大で１つのセッションを生成することができる。
ここで、クライアントアプリケーション３１とクライアントライブラリ３２は、１対１のセットの構成をとって、このセットがクライアントコンピュータ２内に複数あってもよく、複数のクライアントアプリケーション３１と１つのクライアントライブラリ３２とが対応付けられている構成（Ｎ対１）であってもよい。
なお、以下では、簡便のため、１対１のセットの構成をとって、クライアント（クライアント装置）として説明する。単にクライアント（クライアント装置）あるいはクライアント毎（クライアント装置毎）と表現するときには、クライアントアプリケーション３１あるいはクライアントアプリケーション３１毎であることを表すこととする。
セッションとは、クライアントライブラリ３２とサーバ２１との通信の単位であり、クライアントコンピュータ３上に１つまたは複数起動されているプロセスと、サーバ２１との通信を区切る単位である。
サーバ２１が冗長化されており、故障によりフェイルオーバした場合、セッションおよび永続化されていたファイルシステムの内容は、フェイルオーバ後のサーバにも引き継がれる。このような場合、セッションが切れるのは、次の３つのケースのみである。
（１）クライアントがセッションを切った場合
（２）サーバとクライアント間のネットワークが一定時間以上不通となった場合
（３）サーバが多重故障した場合
１つのクライアントは、論理的に異なる複数のサーバのそれぞれに対して、最大で１つのセッションを生成することができる。
ここで、クライアントアプリケーション３１とクライアントライブラリ３２は、１対１のセットの構成をとって、このセットがクライアントコンピュータ２内に複数あってもよく、複数のクライアントアプリケーション３１と１つのクライアントライブラリ３２とが対応付けられている構成（Ｎ対１）であってもよい。
なお、以下では、簡便のため、１対１のセットの構成をとって、クライアント（クライアント装置）として説明する。単にクライアント（クライアント装置）あるいはクライアント毎（クライアント装置毎）と表現するときには、クライアントアプリケーション３１あるいはクライアントアプリケーション３１毎であることを表すこととする。
なお、図２に示すセッション４１は、クライアントコンピュータ３ａとサーバコンピュータ２との間の通信の通信量および通信回数をサーバ側およびクライアント側でそれぞれ利用されるセッショ用メモリにより概念的に示したものである。同様に、セッション４２は、クライアントコンピュータ３ｂとサーバコンピュータ２との間の通信を示すものである。
＜２−６＞ハンドルの定義
クライアントとサーバの間でセッションが張られている場合に限り、クライアントは、
サーバ上の“ファイルおよびディレクトリ”をオープンし、サーバによって管理されている領域にあるファイルを操作することができる。すなわち、ハンドルとは、サーバによって管理されている領域（ファイルシステム）上にある資源（ファイルおよびディレクトリ）に対する操作を行うために、サーバがクライアントに提供するキーである。また、ハンドルとは、クライアントが操作する資源をサーバに指示するために、サーバがクライアントに提供するキーでもある。親子ハンドルについては後記する。
クライアントとサーバの間でセッションが張られている場合に限り、クライアントは、
サーバ上の“ファイルおよびディレクトリ”をオープンし、サーバによって管理されている領域にあるファイルを操作することができる。すなわち、ハンドルとは、サーバによって管理されている領域（ファイルシステム）上にある資源（ファイルおよびディレクトリ）に対する操作を行うために、サーバがクライアントに提供するキーである。また、ハンドルとは、クライアントが操作する資源をサーバに指示するために、サーバがクライアントに提供するキーでもある。親子ハンドルについては後記する。
＜２−７＞ハンドルを通じて提供されるオペレーション
図２に示すクライアントアプリケーション３１は、ハンドルを通じて、“ファイルおよびディレクトリ”に対して、作成、削除、イベント監視要求およびその応答の受付、の各オペレーションを実行できる。
また、クライアントアプリケーション３１は、ファイルに対してのみ、書込、読込、ロック取得、ロック解除、の各オペレーションを実行できる。
さらに、クライアントアプリケーション３１は、ディレクトリに対してのみ、下位ファイルおよびディレクトリの一覧表示のオペレーションを実行できる。
図２に示すクライアントアプリケーション３１は、ハンドルを通じて、“ファイルおよびディレクトリ”に対して、作成、削除、イベント監視要求およびその応答の受付、の各オペレーションを実行できる。
また、クライアントアプリケーション３１は、ファイルに対してのみ、書込、読込、ロック取得、ロック解除、の各オペレーションを実行できる。
さらに、クライアントアプリケーション３１は、ディレクトリに対してのみ、下位ファイルおよびディレクトリの一覧表示のオペレーションを実行できる。
＜２−８＞ロックの定義
図２に示すクライアントアプリケーション３１は、ハンドルを用いて、“ファイルおよびディレクトリ”に対するロックを取得することができる。ロックとは、ファイルに対するアクセスを排他する手段である。ここでは、ハンドルを用いて、例えばあるファイルへアクセスする際に、同じファイルに別ハンドルを用いアクセスすることを排他するような場合を、“ハンドルがロックを取得している”と表現する。ロックを取得している子ハンドルは、ロックを取得していない子ハンドルと明確に区別される。
クライアントアプリケーション３１は、クライアントライブラリ３２に対して、ロック取得依頼（ロック取得依頼メッセージ）を作成する。ロック取得依頼は、セッションにおいてサーバ側に記憶されたファイルシステム６２で管理されたファイルまたはディレクトリに対するロックを子ハンドルが取得することを要求するものである。
なお、アクセスを排他する手段とは、物理的な構成ではなく情報であり、例えば、排他する権利や権限を有していることを示す識別情報や証明書を含むことができる。
図２に示すクライアントアプリケーション３１は、ハンドルを用いて、“ファイルおよびディレクトリ”に対するロックを取得することができる。ロックとは、ファイルに対するアクセスを排他する手段である。ここでは、ハンドルを用いて、例えばあるファイルへアクセスする際に、同じファイルに別ハンドルを用いアクセスすることを排他するような場合を、“ハンドルがロックを取得している”と表現する。ロックを取得している子ハンドルは、ロックを取得していない子ハンドルと明確に区別される。
クライアントアプリケーション３１は、クライアントライブラリ３２に対して、ロック取得依頼（ロック取得依頼メッセージ）を作成する。ロック取得依頼は、セッションにおいてサーバ側に記憶されたファイルシステム６２で管理されたファイルまたはディレクトリに対するロックを子ハンドルが取得することを要求するものである。
なお、アクセスを排他する手段とは、物理的な構成ではなく情報であり、例えば、排他する権利や権限を有していることを示す識別情報や証明書を含むことができる。
ロックには、属性として、アドバイザリロック（advisory lock）と、マンダトリロック(mandatory lock)とがある。
アドバイザリロックは、ファイルに対するロックの取得だけを排他する。アドバイザリロックを用いてファイルへアクセスする場合は、ファイルに対する処理をアプリケーション同士の紳士協定によって排他する。
マンダトリロックは、ファイルに対する特定のオペレーションを禁止し、ロックを取得しているハンドルだけが特定のオペレーションを実行することができる。
アドバイザリロックとマンダトリロックとを比較した場合、一般的にはアドバイザリロックの方が軽量で計算コストが少ないという性質がある。一方、マンダトリロックは、安全性が高いが、計算コストも高いという性質がある。
アドバイザリロックは、ファイルに対するロックの取得だけを排他する。アドバイザリロックを用いてファイルへアクセスする場合は、ファイルに対する処理をアプリケーション同士の紳士協定によって排他する。
マンダトリロックは、ファイルに対する特定のオペレーションを禁止し、ロックを取得しているハンドルだけが特定のオペレーションを実行することができる。
アドバイザリロックとマンダトリロックとを比較した場合、一般的にはアドバイザリロックの方が軽量で計算コストが少ないという性質がある。一方、マンダトリロックは、安全性が高いが、計算コストも高いという性質がある。
ロックにおける第二の属性として、共有ロックと排他ロックとがある。
排他ロックとは、１つのハンドルに対してのみ取得できるものである。すなわち、ある“ファイルおよびディレクトリ”に対する排他ロックを取得しているハンドルは、常に1個または０個である。
共有ロックとは、複数のハンドルにより共有することができるロックである。すなわち、共有ロックが既に取得されている“ファイルおよびディレクトリ”に対しては、排他ロックを取得することができない。
排他ロックとは、１つのハンドルに対してのみ取得できるものである。すなわち、ある“ファイルおよびディレクトリ”に対する排他ロックを取得しているハンドルは、常に1個または０個である。
共有ロックとは、複数のハンドルにより共有することができるロックである。すなわち、共有ロックが既に取得されている“ファイルおよびディレクトリ”に対しては、排他ロックを取得することができない。
＜２−９＞イベントの定義
イベントとは、サーバの状態に変化が起きた際に、その変化それ自体を指す。イベントには、変化の種別が識別されるコード、内容およびタイミングの情報を含む。
サーバは、“ファイルおよびディレクトリ”の状態に変化が起きた際に、イベントをクライアントに対して通知することができる。なお、イベントは、ファイルおよびディレクトリの少なくとも１つの状態の変化を示す。
また、図２に示すクライアントライブラリ３２は、サーバ上のファイルの変化を検知してクライアントアプリケーション３１に対してイベントを通知することができる。
ここでは、“ファイルおよびディレクトリ”に関するイベントのことをノードイベントと呼ぶ。本実施形態では、例えば合計８種類のノードイベントを想定している。
イベントとは、サーバの状態に変化が起きた際に、その変化それ自体を指す。イベントには、変化の種別が識別されるコード、内容およびタイミングの情報を含む。
サーバは、“ファイルおよびディレクトリ”の状態に変化が起きた際に、イベントをクライアントに対して通知することができる。なお、イベントは、ファイルおよびディレクトリの少なくとも１つの状態の変化を示す。
また、図２に示すクライアントライブラリ３２は、サーバ上のファイルの変化を検知してクライアントアプリケーション３１に対してイベントを通知することができる。
ここでは、“ファイルおよびディレクトリ”に関するイベントのことをノードイベントと呼ぶ。本実施形態では、例えば合計８種類のノードイベントを想定している。
まず、ファイルおよびディレクトリに共通のノードイベントには、例えば次の２種類がある。
（１）ハンドル無効化（ノード削除等によりノードにアクセスできなくなった）
（２）マスタのフェイルオーバ（マスタ（サーバ）がフェイルオーバし、一部のイベント通知が欠送した可能性がある）
なお、フェイルオーバ（Fail-over）は、例えば、優先順位の高い回線に異常が発生したときに、メッセージトラフィックが次に優先順位の高い回線に途切れることなく送信されることを示す。
（１）ハンドル無効化（ノード削除等によりノードにアクセスできなくなった）
（２）マスタのフェイルオーバ（マスタ（サーバ）がフェイルオーバし、一部のイベント通知が欠送した可能性がある）
なお、フェイルオーバ（Fail-over）は、例えば、優先順位の高い回線に異常が発生したときに、メッセージトラフィックが次に優先順位の高い回線に途切れることなく送信されることを示す。
次に、本実施形態で定義するノードイベントのうち、ファイルのハンドルに対して登録可能なイベントのことをファイルイベントと呼ぶ。
ファイルイベントには、例えば次の４種類がある。
（３）コンテンツ更新（ファイルの内容の更新が行われた）
（４）メタ情報更新（ファイル属性の更新が行われた）
（５）ロック取得（ロックの取得に成功した）
（６）ロック解除（ファイルがロックされていない状態になった）
ファイルイベントには、例えば次の４種類がある。
（３）コンテンツ更新（ファイルの内容の更新が行われた）
（４）メタ情報更新（ファイル属性の更新が行われた）
（５）ロック取得（ロックの取得に成功した）
（６）ロック解除（ファイルがロックされていない状態になった）
さらに、本実施形態で定義するノードイベントのうち、ディレクトリに対して登録可能なイベントのことをディレクトリイベントと呼ぶ。
ディレクトリイベントには、例えば次の２種類がある。
（７）ノード作成（ディレクトリ下にノードが作成された）
（８）ノード削除（ディレクトリ下のノードが削除された）
ディレクトリイベントには、例えば次の２種類がある。
（７）ノード作成（ディレクトリ下にノードが作成された）
（８）ノード削除（ディレクトリ下のノードが削除された）
＜２−１０＞イベントの管理方式
図２に示すサーバ２１およびクライアントライブラリ３２では、イベントをマスク値によって管理する。
本実施形態では、上記の通り、例えば（１）〜（８）の８種類のイベントがある。それぞれのイベントについては、「要通知」、「通知不要」の２通りの登録状態がある。これに対して、本実施形態では８ビットのそれぞれの桁にイベントを割り付け、あるイベントに対して、それに対応するビットが「０」であれば「通知不要」、「１」であれば「要通知」として管理することとした。なお、ビットの０，１の集合をリスナと呼び、ビットの０，１を適宜入れ替えることで、リスナのオンオフを切り替える。なお、図４には、６種類のイベントに対応した例を示した。
図２に示すサーバ２１およびクライアントライブラリ３２では、イベントをマスク値によって管理する。
本実施形態では、上記の通り、例えば（１）〜（８）の８種類のイベントがある。それぞれのイベントについては、「要通知」、「通知不要」の２通りの登録状態がある。これに対して、本実施形態では８ビットのそれぞれの桁にイベントを割り付け、あるイベントに対して、それに対応するビットが「０」であれば「通知不要」、「１」であれば「要通知」として管理することとした。なお、ビットの０，１の集合をリスナと呼び、ビットの０，１を適宜入れ替えることで、リスナのオンオフを切り替える。なお、図４には、６種類のイベントに対応した例を示した。
［３．親子ハンドルの構成］
＜３−１＞個数および管理の関係
ハンドルは、親ハンドルと子ハンドルから構成される。同一セッション内においては、オープンされているファイルにつき、親ハンドルは必ず１つ確保される。
子ハンドルは、図２に示すクライアントアプリケーション３１がオープン操作を実行した回数だけ、クライアント側で確保される。クライアントから、“ロック要求”が発生するまで、サーバ側では、子ハンドルは管理しない。
＜３−１＞個数および管理の関係
ハンドルは、親ハンドルと子ハンドルから構成される。同一セッション内においては、オープンされているファイルにつき、親ハンドルは必ず１つ確保される。
子ハンドルは、図２に示すクライアントアプリケーション３１がオープン操作を実行した回数だけ、クライアント側で確保される。クライアントから、“ロック要求”が発生するまで、サーバ側では、子ハンドルは管理しない。
＜３−２＞親ハンドルの定義
親ハンドルとは、図２に示すクライアントライブラリ３２が、サーバ２１に対する処理を要求する際に用いるハンドルである。
サーバ２１は、親ハンドルを用いて、クライアントを識別すると共に、要求されているものがファイルなのかディレクトリなのかを識別する。
図２に示すクライアントライブラリ３２は、子ハンドルを用いたクライアントアプリケーション３１からの要求に応じて、サーバ２１に対する処理を要求する。なお、親ハンドルは、クライアントアプリケーション３１毎に作成される。
親ハンドルとは、図２に示すクライアントライブラリ３２が、サーバ２１に対する処理を要求する際に用いるハンドルである。
サーバ２１は、親ハンドルを用いて、クライアントを識別すると共に、要求されているものがファイルなのかディレクトリなのかを識別する。
図２に示すクライアントライブラリ３２は、子ハンドルを用いたクライアントアプリケーション３１からの要求に応じて、サーバ２１に対する処理を要求する。なお、親ハンドルは、クライアントアプリケーション３１毎に作成される。
＜３−３＞子ハンドルの定義
子ハンドルとは、図２に示すクライアントアプリケーション３１が、サーバ２１に対する処理をクライアントライブラリ３２に要求する際に用いるハンドルである。
従って、クライアントアプリケーション３１は、子ハンドルの単位で、ファイルシステムに対する処理を要求する。
本実施形態で定義する子ハンドルは、従来技術で定義されるところの“ハンドル”やファイルディスクリプタに相当する。すなわち、図２に示すクライアントアプリケーション３１は、“ファイルおよびディレクトリ”のオープンに対して、必ず別々のハンドルが提供される。
子ハンドルとは、図２に示すクライアントアプリケーション３１が、サーバ２１に対する処理をクライアントライブラリ３２に要求する際に用いるハンドルである。
従って、クライアントアプリケーション３１は、子ハンドルの単位で、ファイルシステムに対する処理を要求する。
本実施形態で定義する子ハンドルは、従来技術で定義されるところの“ハンドル”やファイルディスクリプタに相当する。すなわち、図２に示すクライアントアプリケーション３１は、“ファイルおよびディレクトリ”のオープンに対して、必ず別々のハンドルが提供される。
次に、唯一、サーバ側で子ハンドルを厳密に区別しなければならないケースについて記述する。すなわち、ロックの取得可否および保持確認については、図２に示すクライアントアプリケーション３１が認識している単位あるいは管理している単位で、サーバ側でも同様に管理する必要がある。
［４．親子ハンドルの管理方式］
＜４−１＞ハンドル作成およびハンドル削除
本節では、ハンドルのライフサイクルおよび具体的なデータ構造について説明する。
ここでは、場合分けとして、親ハンドルと子ハンドルそれぞれについて（２通り）、クライアント側のハンドルかサーバ側のハンドルか（２通り）、ハンドルの生成のタイミングおよび破壊のタイミング（２通り）の組み合わせに関して、８通りのケースについて説明する。
＜４−１＞ハンドル作成およびハンドル削除
本節では、ハンドルのライフサイクルおよび具体的なデータ構造について説明する。
ここでは、場合分けとして、親ハンドルと子ハンドルそれぞれについて（２通り）、クライアント側のハンドルかサーバ側のハンドルか（２通り）、ハンドルの生成のタイミングおよび破壊のタイミング（２通り）の組み合わせに関して、８通りのケースについて説明する。
≪親ハンドルについて≫
クライアント側で親ハンドルが生成されるタイミングは、図２に示すクライアントアプリケーション３１が、クライアントライブラリ３２にパス指定で、ノードオープンを最初に要求した際のみである。
サーバ側で親ハンドルが生成されるタイミングは、図２に示すクライアントライブラリ３２が、ネットワーク通信を経て、オープンを要求したときのみである。
クライアント側で親ハンドルが生成されるタイミングは、図２に示すクライアントアプリケーション３１が、クライアントライブラリ３２にパス指定で、ノードオープンを最初に要求した際のみである。
サーバ側で親ハンドルが生成されるタイミングは、図２に示すクライアントライブラリ３２が、ネットワーク通信を経て、オープンを要求したときのみである。
クライアント側で親ハンドルが削除されるタイミングは、以下の３通りである。
（１）セッションが切断した場合
（２）該当するノードが削除された場合
（３）親ハンドル用のメモリ領域が不足しており、かつ、クローズ済みのハンドルが存在する場合
（１）セッションが切断した場合
（２）該当するノードが削除された場合
（３）親ハンドル用のメモリ領域が不足しており、かつ、クローズ済みのハンドルが存在する場合
このうち、（３）のケースでは、新たな親ハンドルを作成しようとするときにメモリ領域が不足していた場合に、以前に作成してクローズ済みである別の親ハンドルを削除することを意味する。つまり、クライアントによってクローズが明示的に行われた場合であっても、メモリ領域が不足しなければ、クローズ済みの親ハンドルは削除されない。ただし、クライアントアプリケーション３１がオープンしているハンドルが全て、クライアントによって明示的にクローズされている場合であって、明示的にオープンされているハンドルが１つもクライアントアプリケーション３１に存在していない場合には、セッションは切断される。そのため、この場合には、（１）のケースに該当することになり、その結果、クローズ済みである（親）ハンドルは削除されることになる。
サーバ側で親ハンドルが削除されるタイミングは、以下の３通りである。
（１）ハンドルを持っているセッションが切断した場合
（２）該当するノードが削除された場合
（３）クライアントから明示的にクローズを要求された場合
（１）ハンドルを持っているセッションが切断した場合
（２）該当するノードが削除された場合
（３）クライアントから明示的にクローズを要求された場合
≪子ハンドルについて≫
クライアント側で子ハンドルが生成されるタイミングは、図２に示すクライアントアプリケーション３１が、クライアントライブラリ３２にパス指定で、ノードオープンを要求した際である。
サーバ側で子ハンドルが生成されるタイミングは、図２に示すクライアントアプリケーション３１が、明示的にロック取得を要求した場合のみである。
クライアント側で子ハンドルが生成されるタイミングは、図２に示すクライアントアプリケーション３１が、クライアントライブラリ３２にパス指定で、ノードオープンを要求した際である。
サーバ側で子ハンドルが生成されるタイミングは、図２に示すクライアントアプリケーション３１が、明示的にロック取得を要求した場合のみである。
クライアント側で子ハンドルが削除されるタイミングは、図２に示すクライアントアプリケーション３１が、クライアントライブラリ３２にハンドルのクローズを明示的に要求した場合、および、セッションが切断した場合である。
サーバ側で子ハンドルが削除されるタイミングは、図２に示すクライアントアプリケーション３１がロックの解除およびロック待ちの解除を要求し、成功した場合、および、セッションが切断した場合である。ただし、上記の解除のオペレーションは失敗しない前提であり、セッションがなくなれば、サーバ側では自動的に解除する。
サーバ側で子ハンドルが削除されるタイミングは、図２に示すクライアントアプリケーション３１がロックの解除およびロック待ちの解除を要求し、成功した場合、および、セッションが切断した場合である。ただし、上記の解除のオペレーションは失敗しない前提であり、セッションがなくなれば、サーバ側では自動的に解除する。
＜４−２＞ハンドル内で管理される情報
クライアント側の親ハンドルで管理される情報は、サーバと共通のハンドルＩＤ、ノードパスおよび子ハンドルのリスト、後記するイベントマスクの値であり、ファイルの場合には、さらに、ファイルの内容のキャッシュが管理される。
クライアント側の子ハンドルで管理される情報は、同じ親ハンドルを持つ子ハンドルを区別できる子ハンドルＩＤ、ロック取得状態、イベントマスクの値である。
親ハンドルについては、サーバ側では、キャッシュを除きクライアントと同様の情報を管理する。
クライアント側の親ハンドルで管理される情報は、サーバと共通のハンドルＩＤ、ノードパスおよび子ハンドルのリスト、後記するイベントマスクの値であり、ファイルの場合には、さらに、ファイルの内容のキャッシュが管理される。
クライアント側の子ハンドルで管理される情報は、同じ親ハンドルを持つ子ハンドルを区別できる子ハンドルＩＤ、ロック取得状態、イベントマスクの値である。
親ハンドルについては、サーバ側では、キャッシュを除きクライアントと同様の情報を管理する。
＜４−３＞サーバ側でファイルに付属する情報
サーバ側では、あるファイルに対して、次の５つの情報を保持する。
（１）ファイルをオープンしているハンドル全て
（２）ファイルに対するイベントを監視しているハンドル全て
（３）ファイルの内容をキャッシュしているハンドル全て
（４）ファイルに対するロック取得済みハンドル
（５）ファイルに対するロック待ち行列のリスト
サーバ側では、あるファイルに対して、次の５つの情報を保持する。
（１）ファイルをオープンしているハンドル全て
（２）ファイルに対するイベントを監視しているハンドル全て
（３）ファイルの内容をキャッシュしているハンドル全て
（４）ファイルに対するロック取得済みハンドル
（５）ファイルに対するロック待ち行列のリスト
このうち、ここでは、（４）ロック取得済みハンドル、および、（５）ファイルに対するロック待ち行列のリストについて言及する。これら（４）、（５）のハンドルに関しては、ハンドルＩＤと子ハンドルＩＤによって全ての子ハンドルを識別している。すなわち、図２に示すクライアントライブラリ３２は、ロックの取得を要求する際に初めて、子ハンドルの存在をサーバに登録する。これにより、子ハンドルによる、不要なネットワーク上の通信を省略している（図８、図９参照）
［５．親子ハンドルのキャッシュ方式］
≪書込みの集約および読込みの集約≫
本実施形態では、非特許文献１の方法と同様に、ファイルの内容を一度でも読み込んだクライアントは、図２に示すクライアントライブラリ３２内にてファイルの内容をキャッシュする。ただし、本実施形態では、１つのクライアントプロセス内での同じファイルに対するキャッシュは、親ハンドルに対応づけて管理する。これにより、重複している一次記憶領域（メモリ）を低減し、ファイルの内容を転送する通信量および通信回数を節約することができる。すなわち、例えば図２に示す片方の子ハンドル３４により、一度読み込まれたファイルの内容は、同じクライアントが保持している別の子ハンドル３４による読み込みの際でも、キャッシュを保持することができる（図１０参照）。
≪書込みの集約および読込みの集約≫
本実施形態では、非特許文献１の方法と同様に、ファイルの内容を一度でも読み込んだクライアントは、図２に示すクライアントライブラリ３２内にてファイルの内容をキャッシュする。ただし、本実施形態では、１つのクライアントプロセス内での同じファイルに対するキャッシュは、親ハンドルに対応づけて管理する。これにより、重複している一次記憶領域（メモリ）を低減し、ファイルの内容を転送する通信量および通信回数を節約することができる。すなわち、例えば図２に示す片方の子ハンドル３４により、一度読み込まれたファイルの内容は、同じクライアントが保持している別の子ハンドル３４による読み込みの際でも、キャッシュを保持することができる（図１０参照）。
［６．親子ハンドルのイベント通知方式］
＜６−１＞イベント監視の登録および集約
図２に示すクライアントアプリケーション３１は、クライアントライブラリ３２にイベント監視要求を行う際、イベント種別およびイベント通知時の処理（コールバック処理）を登録する。ここで、クライアントアプリケーション３１は、イベント監視要求を行うときに、クライアントライブラリ３２に対して、イベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼（イベント監視登録依頼メッセージ）を作成する。クライアントアプリケーション３１は、イベント監視登録依頼を作成する際に、監視するイベント種別とイベント発生通知時の処理の有無を管理するマスク値とを示すコールバック処理の情報をクライアントライブラリ３２に登録する。
クライアントライブラリ３２は、イベント種別に対応する子ハンドルの真偽値記憶領域を更新し、一時記憶領域（メモリ）にコールバック処理を記憶する。ここで、クライアントライブラリ３２の親子ハンドル管理手段１３１は、ハンドルリスト５２において、イベント監視登録依頼で用いられる子ハンドルに対して、コールバック処理の情報であるイベント毎のマスク値の集合をイベントマスクとして付与して記憶する。
次に、クライアントライブラリ３２は、親ハンドルとサーバとに登録するイベントマスク値を計算する。
＜６−１＞イベント監視の登録および集約
図２に示すクライアントアプリケーション３１は、クライアントライブラリ３２にイベント監視要求を行う際、イベント種別およびイベント通知時の処理（コールバック処理）を登録する。ここで、クライアントアプリケーション３１は、イベント監視要求を行うときに、クライアントライブラリ３２に対して、イベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼（イベント監視登録依頼メッセージ）を作成する。クライアントアプリケーション３１は、イベント監視登録依頼を作成する際に、監視するイベント種別とイベント発生通知時の処理の有無を管理するマスク値とを示すコールバック処理の情報をクライアントライブラリ３２に登録する。
クライアントライブラリ３２は、イベント種別に対応する子ハンドルの真偽値記憶領域を更新し、一時記憶領域（メモリ）にコールバック処理を記憶する。ここで、クライアントライブラリ３２の親子ハンドル管理手段１３１は、ハンドルリスト５２において、イベント監視登録依頼で用いられる子ハンドルに対して、コールバック処理の情報であるイベント毎のマスク値の集合をイベントマスクとして付与して記憶する。
次に、クライアントライブラリ３２は、親ハンドルとサーバとに登録するイベントマスク値を計算する。
＜６−２＞サーバ側に登録されるイベントマスク（真偽値集合）
あるハンドルの親ハンドルをＰ、子ハンドル集合を
とする。このハンドルが登録している、あるイベント種別ｅiについて、サーバに登録されるリスナの真偽値Ｌp（ｅi）は、論理和を用いて、式（１）によって定義される。
あるハンドルの親ハンドルをＰ、子ハンドル集合を
親ハンドルは、イベント種別に対応する真偽値記憶領域を、真偽値Ｌp（ｅi）の値によって更新し、同様の値（更新した値）をサーバに送信する。
これを受信したサーバは、
の値を登録する（図５、図１１参照）。なお、ｉの最大値「８」は一例であって、イベント種別ｅiは、８種類に限定されるものではない。
これを受信したサーバは、
＜６−３＞子ハンドルに対するイベントの通知
あるハンドルがイベント監視を登録している“ファイルおよびディレクトリ”において、イベントが発生した場合に、イベント通知が、クライアント側の子ハンドルに届くまでを説明する。
サーバ内で、イベントが発生した場合、サーバプログラム２１は、該当するイベントを監視している親ハンドル（クライアントアプリケーション３１に相当する）を列挙し、それらのハンドルを所有しているクライアント（クライアントアプリケーション３１に相当する）に対して、ネットワークを通してイベント通知を行う。クライアントライブラリ３２は、イベント通知をサーバより受信した後、イベント種別ｅiを判定し、
が真である子ハンドルＣjにのみ、イベントを通知し、指定する領域に保存されているコールバック処理を実行する（図６、図１２参照）。これによって、１つのクライアント（クライアントアプリケーション３１に相当する）における、子ハンドルに対するイベント関連の処理を集約することができ、本来は子ハンドルの個数分だけ必要であった通信を、ただ一度だけの通信で完了することができる。
あるハンドルがイベント監視を登録している“ファイルおよびディレクトリ”において、イベントが発生した場合に、イベント通知が、クライアント側の子ハンドルに届くまでを説明する。
サーバ内で、イベントが発生した場合、サーバプログラム２１は、該当するイベントを監視している親ハンドル（クライアントアプリケーション３１に相当する）を列挙し、それらのハンドルを所有しているクライアント（クライアントアプリケーション３１に相当する）に対して、ネットワークを通してイベント通知を行う。クライアントライブラリ３２は、イベント通知をサーバより受信した後、イベント種別ｅiを判定し、
［７．具体的な構成および動作］
（第１実施形態）
＜７−１＞具体的な構成
図１〜図４を参照して、第１実施形態のコンピュータシステム１におけるサーバコンピュータ２およびクライアントコンピュータ３の詳細な構成を説明する。
≪サーバ側≫
図１を参照して、サーバコンピュータ２の永続性記憶装置７に格納された情報について説明する。
ファイルデータ８は、読込み／書込み対象のファイルの内容を示すデータである。
サーバ側データ９は、図３（ｂ）に示すように、ハンドルリスト６１と、ファイルシステム６２と、セッションリスト６３と、ロック取得リスト６４とを備えている。
ハンドルリスト６１には、親ハンドルと、監視対象のイベントの情報が記述される。その詳細は後記する。
ファイルシステム６２には、ファイルデータ８の名前空間におけるファイルおよびディレクトリが記述されている。
セッションリスト６３には、サーバに接続されているクライアントの管理情報（イベント通知先等）が記述されている。
ロック取得リスト６４には、ロック取得状態の情報や子ハンドルの情報が記述されている。
（第１実施形態）
＜７−１＞具体的な構成
図１〜図４を参照して、第１実施形態のコンピュータシステム１におけるサーバコンピュータ２およびクライアントコンピュータ３の詳細な構成を説明する。
≪サーバ側≫
図１を参照して、サーバコンピュータ２の永続性記憶装置７に格納された情報について説明する。
ファイルデータ８は、読込み／書込み対象のファイルの内容を示すデータである。
サーバ側データ９は、図３（ｂ）に示すように、ハンドルリスト６１と、ファイルシステム６２と、セッションリスト６３と、ロック取得リスト６４とを備えている。
ハンドルリスト６１には、親ハンドルと、監視対象のイベントの情報が記述される。その詳細は後記する。
ファイルシステム６２には、ファイルデータ８の名前空間におけるファイルおよびディレクトリが記述されている。
セッションリスト６３には、サーバに接続されているクライアントの管理情報（イベント通知先等）が記述されている。
ロック取得リスト６４には、ロック取得状態の情報や子ハンドルの情報が記述されている。
図１に戻って説明を続ける。
サーバコンピュータ２において、永続性記憶装置７に格納されたハンドル管理プログラム１１、ロック管理プログラム１２、キャッシュ管理プログラム１３、イベント管理プログラム１４を、ＣＰＵ４が読み込んで、メモリ５に展開する。これにより、ハードウェア装置とソフトウェアとが協働することによって、前記したハードウェア資源がプログラムによって制御されることにより実現され、図４（ｂ）に示すサーバ２１内のハンドル管理部１２１、ロック管理部１２２、キャッシュ管理部１２３、イベント管理部１２４として動作する。これらハンドル管理部１２１、ロック管理部１２２、キャッシュ管理部１２３、イベント管理部１２４の動作については後記する。
サーバコンピュータ２において、永続性記憶装置７に格納されたハンドル管理プログラム１１、ロック管理プログラム１２、キャッシュ管理プログラム１３、イベント管理プログラム１４を、ＣＰＵ４が読み込んで、メモリ５に展開する。これにより、ハードウェア装置とソフトウェアとが協働することによって、前記したハードウェア資源がプログラムによって制御されることにより実現され、図４（ｂ）に示すサーバ２１内のハンドル管理部１２１、ロック管理部１２２、キャッシュ管理部１２３、イベント管理部１２４として動作する。これらハンドル管理部１２１、ロック管理部１２２、キャッシュ管理部１２３、イベント管理部１２４の動作については後記する。
ここで、図４（ｂ）に示すサーバ２１内のファイルシステム管理部１２５は、ファイルシステムを管理し、オープン、読み込み、クローズ等の処理を行う。
また、同様に、セッション管理部１２６は、サーバとクライアントとのセッションを管理するものである。
また、同様に、セッション管理部１２６は、サーバとクライアントとのセッションを管理するものである。
≪クライアント側≫
図１を参照してクライアントコンピュータ３の永続性記憶装置７に格納された情報について説明する。
クライアント側データ１０は、図３（ａ）に示すように、キャッシュリスト５１と、ハンドルリスト５２とを備えている。
キャッシュリスト５１には、キャッシュ情報が記述されている。
ハンドルリスト５２には、親ハンドルの識別情報と子ハンドルのの識別情報とが関連付けられて記述される。その詳細は後記する。
図１を参照してクライアントコンピュータ３の永続性記憶装置７に格納された情報について説明する。
クライアント側データ１０は、図３（ａ）に示すように、キャッシュリスト５１と、ハンドルリスト５２とを備えている。
キャッシュリスト５１には、キャッシュ情報が記述されている。
ハンドルリスト５２には、親ハンドルの識別情報と子ハンドルのの識別情報とが関連付けられて記述される。その詳細は後記する。
図１に戻って説明を続ける。
クライアントコンピュータ３において、永続性記憶装置７に格納された親子ハンドル管理プログラム１５、ロック制御管理プログラム１６、イベント通知制御プログラム１７、キャッシュ情報登録プログラム１８をＣＰＵ４が読み込んで、メモリ５に展開する。これにより、ハードウェア装置とソフトウェアとが協働することによって、前記したハードウェア資源がプログラムによって制御されることにより実現され、図４（ａ）に示すクライアントライブラリ３２内の親子ハンドル管理部１３１、ロック制御部１３２、イベント通知制御部１３３、キャッシュ情報登録部１３４として動作する。これら親子ハンドル管理部１３１、ロック制御部１３２、イベント通知制御部１３３、キャッシュ情報登録部１３４の動作については後記する。
クライアントコンピュータ３において、永続性記憶装置７に格納された親子ハンドル管理プログラム１５、ロック制御管理プログラム１６、イベント通知制御プログラム１７、キャッシュ情報登録プログラム１８をＣＰＵ４が読み込んで、メモリ５に展開する。これにより、ハードウェア装置とソフトウェアとが協働することによって、前記したハードウェア資源がプログラムによって制御されることにより実現され、図４（ａ）に示すクライアントライブラリ３２内の親子ハンドル管理部１３１、ロック制御部１３２、イベント通知制御部１３３、キャッシュ情報登録部１３４として動作する。これら親子ハンドル管理部１３１、ロック制御部１３２、イベント通知制御部１３３、キャッシュ情報登録部１３４の動作については後記する。
≪ハンドルリストのデータ構造≫
コンピュータシステム１で利用されるハンドルリストのデータ構造の一例を図４に示す。図４（ａ）にはクライアント側のハンドルリスト５２、図４（ｂ）にはサーバ側のハンドルリスト６１を対比してそれぞれ示している。
コンピュータシステム１で利用されるハンドルリストのデータ構造の一例を図４に示す。図４（ａ）にはクライアント側のハンドルリスト５２、図４（ｂ）にはサーバ側のハンドルリスト６１を対比してそれぞれ示している。
図４（ａ）に示すハンドルリスト５２は、子ハンドル領域７０と、親ハンドル領域８０とを備えている。子ハンドル領域７０は、細分化された領域（細分化領域）として、子ハンドルＩＤ領域７１と、ロック取得状態領域７２と、イベントマスク領域７３と、子ハンドルＩＤ領域７４と、ロック取得状態領域７５と、イベントマスク領域７６と、子ハンドルＩＤ領域７７と、ロック取得状態領域７８と、イベントマスク領域７９とを備えている。なお、各細分化領域には、値を例示しているが、例えば、符号７８は、値が未決定の細分化領域を示している。また、各値が格納されるタイミングについては後記する。
図４（ａ）に示す親ハンドル領域８０は、同様な細分化領域として、親ハンドルＩＤ領域８１と、イベントマスク領域８２とを備えている。なお、各細分化領域には、値を例示しているが、例えば、キャッシュ情報登録部１３４がキャッシュリスト５１にキャッシュ情報を格納したときに、図４（ｂ）に符号９３で示すキャッシュ状態情報領域を、細分化領域として新たに設け、「キャッシュ取得」を示す値を記述することもできる。
図４（ｂ）に示すハンドルリスト６１は、親ハンドル領域９０を備えている。図４（ｂ）に示す親ハンドル領域９０は、図４（ａ）に示す親ハンドル領域８０と同様なものであり、符号９３で示すキャッシュ状態情報領域を備えている。
≪イベントマスクの具体例≫
図５（ａ）に示すイベントマスク５０１は、前記した式（１）において、サーバに登録されるリスナの真偽値Ｌp（ｅi）の集合を模式的に示したものである。ここでは、一例として、８種類のイベント種別として、ハンドル無効化ｅ1と、マスタフェイルオーバｅ2と、コンテンツ更新ｅ3と、メタ情報更新ｅ4と、ロック取得ｅ5と、ロック解除ｅ6と、ノード作成ｅ7と、ノード削除ｅ8とを想定した。なお、ノード種別の数は、任意である。
図５（ａ）に示すイベントマスク５０１は、前記した式（１）において、サーバに登録されるリスナの真偽値Ｌp（ｅi）の集合を模式的に示したものである。ここでは、一例として、８種類のイベント種別として、ハンドル無効化ｅ1と、マスタフェイルオーバｅ2と、コンテンツ更新ｅ3と、メタ情報更新ｅ4と、ロック取得ｅ5と、ロック解除ｅ6と、ノード作成ｅ7と、ノード削除ｅ8とを想定した。なお、ノード種別の数は、任意である。
図５（ｂ）に示すように、一例として、子ハンドル１に、イベントマスク５０２が付与され、子ハンドル２に、イベントマスク５０３が付与されているものとすると、図４（ａ）に示すクライアントライブラリ３２内の親子ハンドル管理部１３１は、イベントマスク５０２のマスク値と、イベントマスク５０３のマスク値との論理和を計算することで、親ハンドルのマスク値を計算する。これをイベントマスク５０４として示した。
≪イベント通知の振り分けの具体例≫
図６（ａ）に、図５（ｂ）に示した親ハンドルのマスク値（イベントマスク５０４）を示す。また、図６（ｂ）に、図５（ｂ）に示した子ハンドル１および子ハンドル２のマスク値（イベントマスク５０２，５０３）を示す。
図６（ａ）および図６（ｂ）に示す例において、図４（ｂ）に示すサーバ２１内のイベント管理部１２４による動作と、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３による動作とを、次の４つのケースについて説明する。
図６（ａ）に、図５（ｂ）に示した親ハンドルのマスク値（イベントマスク５０４）を示す。また、図６（ｂ）に、図５（ｂ）に示した子ハンドル１および子ハンドル２のマスク値（イベントマスク５０２，５０３）を示す。
図６（ａ）および図６（ｂ）に示す例において、図４（ｂ）に示すサーバ２１内のイベント管理部１２４による動作と、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３による動作とを、次の４つのケースについて説明する。
第１ケース：サーバ側でハンドル無効化イベントが発生した場合
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、ハンドル無効化ｅ1の値は、「０」、つまり、フラグが偽であるため、イベント管理部１２４は、イベントの発生を親ハンドル（クライアントアプリケーション３１に相当する：以下同様）に通知しない。したがって、サーバからクライアントへのイベント通知はない。
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、ハンドル無効化ｅ1の値は、「０」、つまり、フラグが偽であるため、イベント管理部１２４は、イベントの発生を親ハンドル（クライアントアプリケーション３１に相当する：以下同様）に通知しない。したがって、サーバからクライアントへのイベント通知はない。
第２ケース：サーバ側でハンドルマスタフェイルオーバイベントが発生した場合
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、マスタフェイルオーバｅ2の値は、「１」、つまり、フラグが真であるため、イベント管理部１２４は、イベントの発生を親ハンドルに通知する。したがって、サーバからクライアントへのイベント通知がある。
この場合、クライアント側のイベント通知制御部１３３は、図６（ｂ）に示した子ハンドル１のマスク値（イベントマスク５０２）において、マスタフェイルオーバｅ2の値が、「１」、つまり、フラグが真であると判定し、子ハンドル１（クライアントアプリケーション３１の集約した処理のうちの１つに相当する：以下同様）のみに通知する。
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、マスタフェイルオーバｅ2の値は、「１」、つまり、フラグが真であるため、イベント管理部１２４は、イベントの発生を親ハンドルに通知する。したがって、サーバからクライアントへのイベント通知がある。
この場合、クライアント側のイベント通知制御部１３３は、図６（ｂ）に示した子ハンドル１のマスク値（イベントマスク５０２）において、マスタフェイルオーバｅ2の値が、「１」、つまり、フラグが真であると判定し、子ハンドル１（クライアントアプリケーション３１の集約した処理のうちの１つに相当する：以下同様）のみに通知する。
第３ケース：サーバ側でコンテンツ更新イベントが発生した場合
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、コンテンツ更新ｅ3の値は、符号６０１で示すように「１」であるため、イベント管理部１２４は、イベントの発生を親ハンドルに通知する。したがって、サーバからクライアントへのイベント通知がある。この場合、クライアント側のイベント通知制御部１３３は、図６（ｂ）に示した子ハンドル１のマスク値（イベントマスク５０２）において、コンテンツ更新ｅ3の値が、符号６０２で示すように「０」であると判定し、一方、子ハンドル２のマスク値（イベントマスク５０３）において、コンテンツ更新ｅ3の値が、符号６０３で示すように「１」であると判定するので、子ハンドル２のみに通知する。つまり、イベント通知制御部１３３は、親ハンドルと、子ハンドルの該当するマスク値の論理積が真である場合に、その子ハンドルにイベント通知を行う。
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、コンテンツ更新ｅ3の値は、符号６０１で示すように「１」であるため、イベント管理部１２４は、イベントの発生を親ハンドルに通知する。したがって、サーバからクライアントへのイベント通知がある。この場合、クライアント側のイベント通知制御部１３３は、図６（ｂ）に示した子ハンドル１のマスク値（イベントマスク５０２）において、コンテンツ更新ｅ3の値が、符号６０２で示すように「０」であると判定し、一方、子ハンドル２のマスク値（イベントマスク５０３）において、コンテンツ更新ｅ3の値が、符号６０３で示すように「１」であると判定するので、子ハンドル２のみに通知する。つまり、イベント通知制御部１３３は、親ハンドルと、子ハンドルの該当するマスク値の論理積が真である場合に、その子ハンドルにイベント通知を行う。
第４ケース：サーバ側でロック取得イベントが発生した場合
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、ロック取得ｅ5の値は「１」であるため、イベント管理部１２４は、イベントの発生を親ハンドルに通知する。この場合、クライアント側のイベント通知制御部１３３は、図６（ｂ）に示した子ハンドル１，２のマスク値（イベントマスク５０２，５０３）の双方において、ロック取得ｅ5の値が「１」であるので、子ハンドル１，２の双方に通知する。以下、同様に振り分けることができる。
この場合には、図６（ａ）に示した親ハンドルのマスク値（イベントマスク５０４）において、ロック取得ｅ5の値は「１」であるため、イベント管理部１２４は、イベントの発生を親ハンドルに通知する。この場合、クライアント側のイベント通知制御部１３３は、図６（ｂ）に示した子ハンドル１，２のマスク値（イベントマスク５０２，５０３）の双方において、ロック取得ｅ5の値が「１」であるので、子ハンドル１，２の双方に通知する。以下、同様に振り分けることができる。
＜７−２＞具体的な動作
次に、コンピュータシステム１の動作について、図７乃至図１２を参照（適宜図１乃至図６参照）して説明する。
＜７−２−１＞ハンドル作成処理
図７に示すハンドル作成処理は、図４（ａ）に示すクライアントライブラリ３２内の親子ハンドル管理部１３１の動作と、図４（ｂ）に示すサーバ２１内のハンドル管理部１２１の動作により行われる。
次に、コンピュータシステム１の動作について、図７乃至図１２を参照（適宜図１乃至図６参照）して説明する。
＜７−２−１＞ハンドル作成処理
図７に示すハンドル作成処理は、図４（ａ）に示すクライアントライブラリ３２内の親子ハンドル管理部１３１の動作と、図４（ｂ）に示すサーバ２１内のハンドル管理部１２１の動作により行われる。
図７に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ハンドル作成依頼を受領する（ステップＳ１）。そして、クライアントライブラリ３２は、同じファイルに対する親ハンドルが既に存在するか否かを判別する（ステップＳ２）。親ハンドルが未作成である場合（ステップＳ２：Ｎｏ）、クライアントライブラリ３２は、ハンドルリスト５２（図４参照）に親ハンドル領域８０（メモリ領域）を確保する（ステップＳ３）。なお、新規作成した時点では、ハンドルリスト５２（図４参照）において、親ハンドルＩＤ領域８１、イベントマスク領域８２の各値は未決定である。そして、クライアントライブラリ３２は、ファイル名とイベントリスナとをサーバ側へ送信する（ステップＳ４）。このハンドルをオープンするオペレーションにおいては、ファイル作成オプションフラグが存在している。このフラグとファイルオープン結果との関係は、次の通りである。
（ａ）フラグにおいて、ファイル作成オプションがＯＮの場合
（ａ１）ファイルがあっても成功
（ａ２）ファイルがなければ作成し、オープンは成功
（ｂ）フラグにおいて、ファイル作成オプションがＯＦＦの場合
（ｂ１）ファイルがあれば成功
（ｂ２）ファイルがなければ失敗
（ａ）フラグにおいて、ファイル作成オプションがＯＮの場合
（ａ１）ファイルがあっても成功
（ａ２）ファイルがなければ作成し、オープンは成功
（ｂ）フラグにおいて、ファイル作成オプションがＯＦＦの場合
（ｂ１）ファイルがあれば成功
（ｂ２）ファイルがなければ失敗
サーバ２１は、受信データのファイル作成オプションフラグにより、ファイルの作成処理の要求を含んでいるか否かを判別する（ステップＳ５）。ファイルの作成処理を含んでいない場合（ステップＳ５：Ｎｏ）、サーバ２１は、ハンドルリスト６１（図４参照）に親ハンドル領域９０（メモリ領域）を確保し（親ハンドルを登録し）、親ハンドルＩＤを発行する（ステップＳ６）。なお、この時点では、親ハンドルＩＤ領域９１の値は決定しているが、イベントマスク領域９２の値と、キャッシュ状態領域９３の値とは未決定である。
続いて、クライアントライブラリ３２は、ファイルオープン結果と親ハンドルＩＤとをサーバ側から受信する（ステップＳ７）。そして、クライアントライブラリ３２は、親ハンドルＩＤを記憶する（ステップＳ８）。つまり、この時点で、ハンドルリスト５２（図４参照）の親ハンドルＩＤ領域８１の値が決定する。そして、クライアントライブラリ３２は、ハンドルリスト５２（図４参照）に子ハンドル領域７０（メモリ領域）を確保し、親ハンドルに登録する（ステップＳ９）。つまり、ハンドルリスト５２（図４参照）において、子ハンドル領域７０と親ハンドル領域８０とが関連付けられる。なお、この時点では、クライアントライブラリ３２は、子ハンドル領域７０（図４参照）において、例えば、子ハンドルＩＤ領域７１を決定しているが、ロック取得状態領域７２については未決定である。イベントマスク領域７３についてはデフォルト値（イベントリスナは０だけの集合）が入力される。
また、前記したステップＳ２において、親ハンドルが既に作成されている場合（ステップＳ２：Ｙｅｓ）、クライアントライブラリ３２は、直ちにステップＳ９に進む。ステップＳ９に続いて、クライアントライブラリ３２は、クライアントアプリケーション３１に、子ハンドルを返却する（ステップＳ１０）。これにより、クライアントアプリケーション３１は、子ハンドルＩＤを取得する。
また、前記したステップＳ５において、ファイルの作成処理を含んでいる場合（ステップＳ５：Ｙｅｓ）、サーバ２１は、ファイルを作成し（ステップＳ１１）、ステップＳ６に進む。また、ファイルを作成した場合、サーバ２１は、作成したファイルの親ディレクトリを監視しているハンドル（子ハンドル）があるか否かを判別する（ステップＳ１２）。親ディレクトリを監視するハンドルがない場合（ステップＳ１２：Ｎｏ）、特になにもせずに処理を終了するが、親ディレクトリを監視するハンドルがある場合（ステップＳ１２：Ｙｅｓ）、当該ハンドル（監視ハンドル）に対してはイベントが発生したことになるので、後記するイベント通知処理を実行する。
＜７−２−２＞ロック取得処理および子ハンドル登録処理
図８に示すロック取得処理および子ハンドル登録処理は、図４（ａ）に示すクライアントライブラリ３２内のロック制御部１３２の動作と、図４（ｂ）に示すサーバ２１内のロック管理部１２２の動作により行われる。
図８に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ロック取得依頼を受領する（ステップＳ２１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ２２）。なお、受領した子ハンドルの子ハンドルＩＤが登録されている場合に当該子ハンドルを有効であると判定することができる。
図８に示すロック取得処理および子ハンドル登録処理は、図４（ａ）に示すクライアントライブラリ３２内のロック制御部１３２の動作と、図４（ｂ）に示すサーバ２１内のロック管理部１２２の動作により行われる。
図８に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ロック取得依頼を受領する（ステップＳ２１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ２２）。なお、受領した子ハンドルの子ハンドルＩＤが登録されている場合に当該子ハンドルを有効であると判定することができる。
受領した子ハンドルが有効である場合（ステップＳ２２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、ハンドルリスト５２を参照して、子ハンドルが、既にロック取得しているハンドル、または、現在ロック待ちのハンドルであるか否かを判別する（ステップＳ２３）。子ハンドルが、ロック取得済みのハンドルでもなく、また、ロック待ちのハンドルでもない場合（ステップＳ２３：Ｎｏ）、クライアントライブラリ３２は、親ハンドルＩＤと当該子ハンドルＩＤとを、ロック取得依頼と共にサーバ側に送信する（ステップＳ２４）。
サーバ２１は、ロック取得依頼を受信すると、ロック取得依頼の対象のファイルが別のクライアントによってロック取得済みのファイルであるか否かを判別する（ステップＳ２５）。ロック取得依頼の対象のファイルが、別のクライアントによってロック取得済みのファイルである場合（ステップＳ２５：Ｙｅｓ）、サーバ２１は、受信した子ハンドルを、ロック待ち行列２７（図２参照）のロック待ち領域に登録する（ステップＳ２６）。そして、サーバ２１は、ロック取得依頼の対象のファイルについて、別のクライアントによるロックが解除され、受信した子ハンドルがロック取得するまで待機する（ステップＳ２７）。続いて、サーバ２１は、受信した子ハンドルを、ロック取得リスト６４（図３参照）に登録し（ステップＳ２８）、ロック取得依頼応答をクライアント側に返信する。
前記したステップＳ２５において、ロック取得依頼の対象のファイルが、別のクライアントによってロック取得済みのファイルではない場合（ステップＳ２５：Ｎｏ）、サーバ２１は、ステップＳ２６，Ｓ２７の処理をスキップしてステップＳ２８に進む。
クライアント側において、クライアントライブラリ３２は、ロック取得依頼応答をサーバ側から受信する（ステップＳ２９）。クライアントライブラリ３２は、子ハンドルのロック情報を記憶する（ステップＳ３０）。つまり、この時点で、クライアントライブラリ３２は、子ハンドル領域７０（図４参照）において、ロック取得状態領域７２の値を決定する。そして、クライアントライブラリ３２は、クライアントアプリケーション３１に、ロック取得の成功を通知する（ステップＳ３１）。なお、現在ロック待ちのハンドルである場合には、待機中であることも合わせて通知する。
前記したステップＳ２３において、子ハンドルが、既にロック取得しているハンドル、または、現在ロック待ちのハンドルである場合（ステップＳ２３：Ｙｅｓ）、クライアントライブラリ３２は、直ちにステップＳ３１に進む。
また、前記したステップＳ２２において、クライアントアプリケーション３１から受領した子ハンドルが無効である場合（ステップＳ２２：Ｎｏ）、クライアントライブラリ３２は、クライアントアプリケーション３１に、ロック取得の失敗を通知する（ステップＳ３２）。
また、前記したステップＳ２２において、クライアントアプリケーション３１から受領した子ハンドルが無効である場合（ステップＳ２２：Ｎｏ）、クライアントライブラリ３２は、クライアントアプリケーション３１に、ロック取得の失敗を通知する（ステップＳ３２）。
＜７−２−３＞ロック解除処理および子ハンドル登録削除処理
図９に示すロック解除処理および子ハンドル登録削除処理は、図４（ａ）に示すクライアントライブラリ３２内のロック制御部１３２の動作と、図４（ｂ）に示すサーバ２１内のロック管理部１２２の動作により行われる。
図９に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ロック解除依頼を受領する（ステップＳ４１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ４２）。受領した子ハンドルが有効である場合（ステップＳ４２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、子ハンドルが、既にロック取得しているハンドル、または、現在ロック待ちのハンドルであるか否かを判別する（ステップＳ４３）。子ハンドルが既にロック取得しているハンドル、または、現在ロック待ちのハンドルである場合（ステップＳ４３：Ｙｅｓ）、クライアントライブラリ３２は、親ハンドルＩＤと当該子ハンドルＩＤとを、ロック解除依頼と共にサーバ側に送信する（ステップＳ４４）。
図９に示すロック解除処理および子ハンドル登録削除処理は、図４（ａ）に示すクライアントライブラリ３２内のロック制御部１３２の動作と、図４（ｂ）に示すサーバ２１内のロック管理部１２２の動作により行われる。
図９に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ロック解除依頼を受領する（ステップＳ４１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ４２）。受領した子ハンドルが有効である場合（ステップＳ４２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、子ハンドルが、既にロック取得しているハンドル、または、現在ロック待ちのハンドルであるか否かを判別する（ステップＳ４３）。子ハンドルが既にロック取得しているハンドル、または、現在ロック待ちのハンドルである場合（ステップＳ４３：Ｙｅｓ）、クライアントライブラリ３２は、親ハンドルＩＤと当該子ハンドルＩＤとを、ロック解除依頼と共にサーバ側に送信する（ステップＳ４４）。
サーバ２１は、ロック解除依頼と共に受信した当該子ハンドルが、当該クライアントによってロック取得済みのファイルのものであるか否かを判別する（ステップＳ４５）。当該クライアントによってロック取得済みのファイルのハンドルである場合（ステップＳ４５：Ｙｅｓ）、サーバ２１は、受信した子ハンドルを、ロック取得リスト６４（図３参照）から削除し（ステップＳ４６）、ロック解除依頼応答をクライアント側に返信する。
一方、ステップＳ４５において、ロック解除依頼と共に受信した当該子ハンドルが、当当該クライアントによってロック待ちのファイルのものである場合（ステップＳ４５：Ｎｏ）、サーバ２１は、受信した子ハンドルを、ロック待ち行列２７（図２参照）のロック待ち領域から削除し（ステップＳ４７）、ロック解除依頼応答をクライアント側に返信する。
一方、ステップＳ４５において、ロック解除依頼と共に受信した当該子ハンドルが、当当該クライアントによってロック待ちのファイルのものである場合（ステップＳ４５：Ｎｏ）、サーバ２１は、受信した子ハンドルを、ロック待ち行列２７（図２参照）のロック待ち領域から削除し（ステップＳ４７）、ロック解除依頼応答をクライアント側に返信する。
クライアント側において、クライアントライブラリ３２は、ロック取得解除応答をサーバ側から受信する（ステップＳ４８）。そして、クライアントライブラリ３２は、ハンドルリスト５２（図４参照）の子ハンドル領域７０において、子ハンドルのロック情報を更新して記憶する（ステップＳ４９）。クライアントライブラリ３２は、クライアントアプリケーション３１に、ロック解除の成功を通知する（ステップＳ５０）。
前記したステップＳ４３において、子ハンドルが、ロック取得済みのハンドルでもなく、また、ロック待ちのハンドルでもない場合（ステップＳ４３：Ｎｏ）、クライアントライブラリ３２は、直ちにステップＳ５０に進む。また、前記したステップＳ４２において、クライアントアプリケーション３１から受領した子ハンドルが無効である場合（ステップＳ４２：Ｎｏ）、クライアントライブラリ３２は、クライアントアプリケーション３１に、ロック解除の失敗を通知する（ステップ５１）。
＜７−２−４＞ファイル読込処理およびキャッシュ作成処理
図１０に示すファイル読込処理およびキャッシュ作成処理は、図４（ａ）に示すクライアントライブラリ３２内のキャッシュ情報登録部１３４の動作と、図４（ｂ）に示すサーバ２１内のキャッシュ管理部１２３の動作により行われる。
図１０に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ファイル内容取得依頼を受領する（ステップＳ６１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ６２）。受領した子ハンドルが有効である場合（ステップＳ６２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、ハンドルリスト５２（図４参照）の親ハンドル領域８０にキャッシュが存在するか否かを判別する（ステップＳ６３）。親ハンドル領域８０（図４参照）に、“キャッシュ保持”を示すキャッシュ状態が記録されていない場合（ステップＳ６３：Ｎｏ）、クライアントライブラリ３２は、親ハンドルＩＤを、ファイル内容取得依頼と共にサーバ側に送信する（ステップＳ６４）。
図１０に示すファイル読込処理およびキャッシュ作成処理は、図４（ａ）に示すクライアントライブラリ３２内のキャッシュ情報登録部１３４の動作と、図４（ｂ）に示すサーバ２１内のキャッシュ管理部１２３の動作により行われる。
図１０に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、ファイル内容取得依頼を受領する（ステップＳ６１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ６２）。受領した子ハンドルが有効である場合（ステップＳ６２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、ハンドルリスト５２（図４参照）の親ハンドル領域８０にキャッシュが存在するか否かを判別する（ステップＳ６３）。親ハンドル領域８０（図４参照）に、“キャッシュ保持”を示すキャッシュ状態が記録されていない場合（ステップＳ６３：Ｎｏ）、クライアントライブラリ３２は、親ハンドルＩＤを、ファイル内容取得依頼と共にサーバ側に送信する（ステップＳ６４）。
サーバ２１は、ファイル内容取得依頼と共に受信した親ハンドルに対応するファイルが存在するか否かを判別する（ステップＳ６５）。親ハンドルに対応するファイルが存在する場合（ステップＳ６５：Ｙｅｓ）、サーバ２１は、バックエンドデータベース２２（図２参照）から該当するファイルの内容（以下、ファイル内容という）を取得して読み込み（ステップＳ６６）、ファイル内容をクライアント側に返信する。なお、この時点で、ハンドルリスト６１（図４参照）の親ハンドル領域９０のキャッシュ状態領域９３が“キャッシュ保持”に書き換えられる。一方、ステップＳ６５において、親ハンドルに対応するファイルが存在しない場合（ステップＳ６５：Ｎｏ）、サーバ２１は、ファイルの読み込みが失敗したことを示す応答をクライアント側に返信する。
クライアント側において、前記したステップＳ６６に続いて、クライアントライブラリ３２は、ファイル内容をサーバ側から受信する（ステップＳ６７）。そして、クライアントライブラリ３２は、親ハンドルのキャッシュ情報にファイル内容を登録する（ステップＳ６８）。なお、この時点で、ハンドルリスト５２（図４参照）の親ハンドル領域８０に、“キャッシュ保持”を示すキャッシュ状態情報が記録される。そして、クライアントライブラリ３２は、クライアントアプリケーション３１に、ファイル内容取得の成功を通知し、ファイル内容を返却する（ステップＳ６９）。これにより、クライアントコンピュータ３（図１参照）のメモリ５または永続性記憶装置７に、ファイル内容が記憶される。
また、クライアント側において、前記したステップＳ６５でＮｏの場合に続いて、クライアントライブラリ３２は、ファイルの読み込みが失敗したことを示す応答をサーバ側から受信する場合（ステップＳ７０）、クライアントアプリケーション３１に、ファイル内容取得の失敗を通知する（ステップＳ７２）。なお、前記したステップＳ６２において、クライアントアプリケーション３１から受領した子ハンドルが無効である場合も（ステップＳ６２：Ｎｏ）、ファイル内容取得の失敗を通知する。
一方、前記したステップＳ６３において、ハンドルリスト５２（図４参照）の親ハンドル領域８０に“キャッシュ保持”を示すキャッシュ状態が記録されている場合（ステップＳ６３：Ｙｅｓ）、クライアントライブラリ３２は、直ちに、保持しているキャッシュ情報を読み込み（ステップＳ７１）、ステップＳ６９に進む。
＜７−２−５＞ノードイベント監視登録処理
図１１に示すノードイベント監視登録処理は、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３の動作と、図４（ｂ）に示すサーバ２１内のイベント管理部１２４の動作により行われる。
図１１に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、イベント監視登録依頼を受領する（ステップＳ８１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ８２）。受領した子ハンドルが有効である場合（ステップＳ８２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、当該子ハンドルのイベントマスク値と、現在の親ハンドルのイベントマスク値との論理和を計算する（ステップＳ８３）。
図１１に示すノードイベント監視登録処理は、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３の動作と、図４（ｂ）に示すサーバ２１内のイベント管理部１２４の動作により行われる。
図１１に示すように、クライアント側において、クライアントライブラリ３２は、クライアントアプリケーション３１から、イベント監視登録依頼を受領する（ステップＳ８１）。このとき、クライアントアプリケーション３１から、子ハンドルを受領する。クライアントライブラリ３２は、受領した子ハンドルが有効か否かを判別する（ステップＳ８２）。受領した子ハンドルが有効である場合（ステップＳ８２：Ｙｅｓ）、続けて、クライアントライブラリ３２は、当該子ハンドルのイベントマスク値と、現在の親ハンドルのイベントマスク値との論理和を計算する（ステップＳ８３）。
なお、初めて論理和をとる段階において、現在の親ハンドルのイベントマスク値とは、親ハンドルのイベントマスクの初期値のことである。この親ハンドルのイベントマスクの初期値は、ハンドルリスト５２（図４参照）の子ハンドル領域７０のリスト一番目の子ハンドルのイベントマスク値と同一となる。具体的には、図４（ａ）の子ハンドルＩＤ領域７１が「子ハンドルid0」である子ハンドルは、図４（ａ）に示す例において、３つの中で最初に作成された子ハンドルである。そして、「子ハンドルid0」である子ハンドルのイベントマスクは、一例としてイベント種別ｅiを６種類としたときに、イベントマスク領域７３に示すように、「000000」である。したがって、親ハンドルのイベントマスクの初期値は、「000000」となる。
クライアントライブラリ３２は、ステップＳ８３の計算結果により、親ハンドル領域８０（図４参照）のイベントマスク領域８２に登録されているイベントマスク値を更新する（ステップＳ８４）。そして、クライアントライブラリ３２は、親ハンドルＩＤおよび新イベントマスク値を、イベント監視登録依頼と共にサーバ側に送信する（ステップＳ８５）。
サーバ２１は、イベント監視対象のファイルが存在するか否かを判別する（ステップＳ８６）。イベント監視対象のファイルが存在する場合（ステップＳ８６：Ｙｅｓ）、サーバ２１は、受信した新イベントマスク値を登録し（ステップＳ８７）、イベントマスク登録結果をクライアント側に返信する。なお、この時点で、ハンドルリスト６１（図４参照）における親ハンドル領域９０のイベントマスク領域９２の値が決定する。
一方、イベント監視対象のファイルが存在しない場合（ステップＳ８６：Ｎｏ）、サーバ２１は、イベント監視登録が失敗したことを示す応答をクライアント側に返信する。
一方、イベント監視対象のファイルが存在しない場合（ステップＳ８６：Ｎｏ）、サーバ２１は、イベント監視登録が失敗したことを示す応答をクライアント側に返信する。
クライアント側において、前記したステップＳ８７に続いて、クライアントライブラリ３２は、イベントマスク登録結果をサーバ側から受信する（ステップＳ８８）。そして、クライアントライブラリ３２は、クライアントアプリケーション３１から受領した当該子ハンドルのイベント情報を登録する（ステップＳ８９）。そして、クライアントライブラリ３２は、クライアントアプリケーション３１に、子ハンドルによるイベント監視登録の成功を通知する（ステップＳ９０）。
なお、ステップＳ８９よりも前において、クライアント側で論理和の計算に用いられるイベントマスクは、クライアント側のみの“仮登録”である。一方、ステップＳ８９における子ハンドルのイベント情報の登録処理は、イベント監視登録が成功してサーバ側で実際にイベント監視が実行可能になっているので、コンピュータシステム１における“本登録”である。つまり、イベント通知処理では、新イベントマスク値を有したイベントマスク（新イベントマスク）だけが利用されることとなる。
また、クライアント側において、前記したステップＳ８６でＮｏの場合に続いて、クライアントライブラリ３２は、イベント監視登録が失敗したことを示す応答をサーバ側から受信する場合、クライアントアプリケーション３１に、イベント監視登録の失敗を通知する（ステップＳ９１）。なお、前記したステップＳ８２において、クライアントアプリケーション３１から受領した子ハンドルが無効である場合も（ステップＳ８２：Ｎｏ）、イベント監視登録の失敗を通知する。
＜７−２−６＞イベント通知処理
図１２に示すイベント通知処理は、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３の動作と、図４（ｂ）に示すサーバ２１内のイベント管理部１２４の動作により行われる。
図１２に示すように、サーバコンピュータ２において、ファイルシステム６２で管理しているファイルやディレクトリの状態が変化すると、サーバ２１は、当該ハンドル（監視ハンドル）に対してイベント発生を検知する（ステップＳ１０１）。例えば、図７に示したように、サーバ側において、ハンドル作成時に、サーバ２１がファイルを作成し、作成したファイルの親ディレクトリを監視しているハンドル（子ハンドル）がある場合（ステップＳ１２：Ｙｅｓ）、図７および図１２の符号「Ａ」で示すように、ステップＳ１０１に進む。そして、サーバ２１は、ハンドルリスト６１（図４参照）から、発生したイベントの通知を受けるように（監視するように）登録されているリスナの情報を抽出し、抽出したリスナ一覧をメモリ５に複製して親ハンドルリストを取得する（ステップＳ１０２）。
図１２に示すイベント通知処理は、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３の動作と、図４（ｂ）に示すサーバ２１内のイベント管理部１２４の動作により行われる。
図１２に示すように、サーバコンピュータ２において、ファイルシステム６２で管理しているファイルやディレクトリの状態が変化すると、サーバ２１は、当該ハンドル（監視ハンドル）に対してイベント発生を検知する（ステップＳ１０１）。例えば、図７に示したように、サーバ側において、ハンドル作成時に、サーバ２１がファイルを作成し、作成したファイルの親ディレクトリを監視しているハンドル（子ハンドル）がある場合（ステップＳ１２：Ｙｅｓ）、図７および図１２の符号「Ａ」で示すように、ステップＳ１０１に進む。そして、サーバ２１は、ハンドルリスト６１（図４参照）から、発生したイベントの通知を受けるように（監視するように）登録されているリスナの情報を抽出し、抽出したリスナ一覧をメモリ５に複製して親ハンドルリストを取得する（ステップＳ１０２）。
そして、サーバ２１は、この親ハンドルリストからすべての親ハンドルを削除するまで該当するリスナに対してイベント通知を実行する。すなわち、サーバ２１は、更新した親ハンドルリストが空になったと判別した場合（ステップＳ１０３：Ｙｅｓ）、イベント通知処理を終了する。さもなければ（ステップＳ１０３：Ｎｏ）、サーバ２１は、親ハンドルリスト中の親ハンドルの情報から、イベント通知先（クライアントとのセッション）の情報を取得する（ステップＳ１０４）。そして、サーバ２１は、取得した情報に基づいて、セッションを経由して、該当する親ハンドルＩＤと新イベントマスクとをクライアントへ送信する（ステップＳ１０５）。そして、サーバ２１は、親ハンドルリストから、該当するクライアントの親ハンドルを削除し（ステップＳ１０６）、ステップＳ１０３に戻る。
前記したステップＳ１０５に続いて、クライアント側において、クライアントライブラリ３２は、イベント通知により新イベントマスクを受信する（ステップＳ１０７）。そして、クライアントライブラリ３２は、ハンドルリスト５２（図４参照）から、イベント通知により受信した親ハンドルに所属する全ての子ハンドルの情報を抽出し、抽出した子ハンドル一覧をメモリ５に複製した子ハンドルリスト（以下、複製リストという）を取得する（ステップＳ１０８）。
そして、クライアントライブラリ３２は、この複製リストからすべての子ハンドルを削除するまで、コールバックを必要とする子ハンドルを探索する処理を実行する。すなわち、クライアントライブラリ３２は、更新した複製リストが空になったと判別した場合（ステップＳ１０９：Ｙｅｓ）、探索処理を終了する。さもなければ（ステップＳ１０９：Ｎｏ）、クライアントライブラリ３２は、現在の複製リストの先頭の子ハンドルの情報を取得する（ステップＳ１１０）。
そして、クライアントライブラリ３２は、当該子ハンドルのイベントマスク値と、イベント通知により受信した新イベントマスク値との論理積を計算する（ステップＳ１１１）。具体的には、一例として、図６に、子ハンドルのイベントマスクおよび新イベントマスクのイベント種別が「コンテンツ更新ｅ3」である値の論理積を求める場合の計算方法を符号６０１〜６０３で示した。計算の結果、論理積が真であれば、当該子ハンドルは、コールバックを必要とする子ハンドルであるので、クライアントライブラリ３２は、コールバック呼び出しを実行する（ステップＳ１１２）。すなわち、クライアントライブラリ３２は、コールバック処理を行う。そして、クライアントライブラリ３２は、複製リストから、該当子ハンドルを削除し（ステップＳ１１３）、ステップＳ１０９に戻る。一方、ステップＳ１１１の計算の結果、論理積が偽であれば、クライアントライブラリ３２は、ステップＳ１１２をスキップして、ステップＳ１１３に進む。
第１実施形態のコンピュータシステム１によれば、クライアントライブラリ３２が、サーバ側で付与された親ハンドルに従属する子ハンドルを生成し、クライアントアプリケーション３１に返却し、クライアントアプリケーション３１が、子ハンドルを用いたサーバ側のファイルシステムへのオペレーションを要求したときに、クライアントライブラリ３２がこの要求を中継する。このとき、それぞれの子ハンドルは、クライアントアプリケーション３１においては、別々のハンドルとして利用できるので、ネットワーク通信においては、同一のクライアントから同じファイルおよびディレクトリに対する別ハンドルのアクセスを親ハンドルに集約することができる。その結果、ファイルシステムへのアクセスにおいて、クライアントとサーバとの間で発生する通信の回数や量を低減することができる。
（第２実施形態）
第１実施形態のコンピュータシステム１は、ベストモードの構成で説明したが、本発明はこれに限定されず、ロック機能を備えずに構成することも可能である。この場合には、図４（ａ）に示すクライアントライブラリ３２内のロック制御部１３２や、図４（ｂ）に示すサーバ２１内のロック管理部１２２を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
第１実施形態のコンピュータシステム１は、ベストモードの構成で説明したが、本発明はこれに限定されず、ロック機能を備えずに構成することも可能である。この場合には、図４（ａ）に示すクライアントライブラリ３２内のロック制御部１３２や、図４（ｂ）に示すサーバ２１内のロック管理部１２２を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
（第３実施形態）
本発明は、イベント監視およびイベント通知機能を備えずに構成することも可能である。この場合には、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３と、図４（ｂ）に示すサーバ２１内のイベント管理部１２４を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
本発明は、イベント監視およびイベント通知機能を備えずに構成することも可能である。この場合には、図４（ａ）に示すクライアントライブラリ３２内のイベント通知制御部１３３と、図４（ｂ）に示すサーバ２１内のイベント管理部１２４を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
（第４実施形態）
本発明は、キャッシュ機能を備えずに構成することも可能である。この場合には、図４（ａ）に示すクライアントライブラリ３２内のキャッシュ情報登録部１３４と、図４（ｂ）に示すサーバ２１内のキャッシュ管理部１２３を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
なお、上記ロック機能、イベント監視およびイベント通知機能、キャッシュ機能のうちの任意の２つ以上を備えずに、さらに簡易なコンピュータシステムを構成することも可能である。
本発明は、キャッシュ機能を備えずに構成することも可能である。この場合には、図４（ａ）に示すクライアントライブラリ３２内のキャッシュ情報登録部１３４と、図４（ｂ）に示すサーバ２１内のキャッシュ管理部１２３を除去する点が異なるだけで、同様に、簡易なコンピュータシステムを構成することができる。
なお、上記ロック機能、イベント監視およびイベント通知機能、キャッシュ機能のうちの任意の２つ以上を備えずに、さらに簡易なコンピュータシステムを構成することも可能である。
以上、本発明の各実施形態について説明したが、本発明はこれらに限定されるものではなく、その趣旨を変えない範囲で実施することができる。例えば、各実施形態では、Ｃ／Ｓ型のコンピュータシステムは、ＯＳ等により構築されたＬＡＮ上での分散コンピュータシステムとして構成したが、ＯＳおよびコンピュータの種別を問わず、ネットワーク上に分散したコンピュータシステムに対して本発明を適用することができる。
１ コンピュータシステム
２ サーバコンピュータ（サーバ装置）
３（３ａ，３ｂ） クライアントコンピュータ（クライアント装置）
４ ＣＰＵ
５ メモリ
６ ネットワークI/F（ネットワークインタフェース）
７ 永続性記憶装置
８ ファイルデータ
９ サーバ側データ
１０ クライアント側データ
１１ ハンドル管理プログラム
１２ ロック管理プログラム
１３ キャッシュ管理プログラム
１４ イベント管理プログラム
１５ 親子ハンドル管理プログラム
１６ ロック制御管理プログラム
１７ イベント通知制御プログラム
１８ キャッシュ情報登録プログラム
２１ サーバ（サーバプログラム）
２２ バックエンドデータベース（データベース）
３１ クライアントアプリケーション（アプリケーション部）
３２ クライアントライブラリ（ライブラリ部）
５１ キャッシュリスト
５２ ハンドルリスト（クライアント側ハンドルリスト）
６１ ハンドルリスト（サーバ側ハンドルリスト）
６２ ファイルシステム
６３ セッションリスト
６４ ロック取得リスト
１２１ ハンドル管理部（ハンドル管理手段）
１２２ ロック管理部（ロック管理手段）
１２３ キャッシュ管理部（キャッシュ管理手段）
１２４ イベント管理部（イベント管理手段）
１２５ ファイルシステム管理部
１２６ セッション管理部
１３１ 親子ハンドル管理部（親子ハンドル管理手段）
１３２ ロック制御部（ロック制御管理手段）
１３３ イベント通知制御部（イベント通知制御手段）
１３４ キャッシュ情報登録部（キャッシュ情報登録手段）
Ｎ ネットワーク
２ サーバコンピュータ（サーバ装置）
３（３ａ，３ｂ） クライアントコンピュータ（クライアント装置）
４ ＣＰＵ
５ メモリ
６ ネットワークI/F（ネットワークインタフェース）
７ 永続性記憶装置
８ ファイルデータ
９ サーバ側データ
１０ クライアント側データ
１１ ハンドル管理プログラム
１２ ロック管理プログラム
１３ キャッシュ管理プログラム
１４ イベント管理プログラム
１５ 親子ハンドル管理プログラム
１６ ロック制御管理プログラム
１７ イベント通知制御プログラム
１８ キャッシュ情報登録プログラム
２１ サーバ（サーバプログラム）
２２ バックエンドデータベース（データベース）
３１ クライアントアプリケーション（アプリケーション部）
３２ クライアントライブラリ（ライブラリ部）
５１ キャッシュリスト
５２ ハンドルリスト（クライアント側ハンドルリスト）
６１ ハンドルリスト（サーバ側ハンドルリスト）
６２ ファイルシステム
６３ セッションリスト
６４ ロック取得リスト
１２１ ハンドル管理部（ハンドル管理手段）
１２２ ロック管理部（ロック管理手段）
１２３ キャッシュ管理部（キャッシュ管理手段）
１２４ イベント管理部（イベント管理手段）
１２５ ファイルシステム管理部
１２６ セッション管理部
１３１ 親子ハンドル管理部（親子ハンドル管理手段）
１３２ ロック制御部（ロック制御管理手段）
１３３ イベント通知制御部（イベント通知制御手段）
１３４ キャッシュ情報登録部（キャッシュ情報登録手段）
Ｎ ネットワーク
Claims (14)
- ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、ハンドルを用いて操作するクライアント装置とを備えるコンピュータシステムにおける前記クライアント装置であって、
前記ファイルシステムに対する所定操作の実行を要求するアプリケーション部と、
前記アプリケーション部による要求を中継して前記ファイルシステムにアクセスするライブラリ部と、を有し、
前記アプリケーション部は、前記ライブラリ部に対して、前記ファイルシステム上のファイルまたはディレクトリの操作に対応するハンドルの作成を要求するハンドル作成依頼を作成し、
前記ライブラリ部は、
前記アプリケーション部から１回目の前記ハンドル作成依頼を受領したときに、前記サーバ装置とのセッションを通じて、前記ハンドルとして前記ファイルシステム上のファイルまたはディレクトリを特定し操作できる親ハンドルを前記サーバ装置から取得し、前記親ハンドルに従属して前記セッションにおいて有効な子ハンドルを生成し、生成した前記子ハンドルを前記アプリケーション部に返却し、前記セッション中に前記アプリケーション部から前記ファイルと同一のファイルに対して、２回目以降のハンドル作成依頼を受領したときに、前記同一のファイルに対応して前記親ハンドルに関連付けて新たに生成した子ハンドルを返却し、前記親ハンドルの識別情報と生成した前記子ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納しておく親子ハンドル管理手段を備えることを特徴とするクライアント装置。 - 前記アプリケーション部は、前記ライブラリ部に対して、前記サーバ装置の前記ファイルシステムで管理されたファイルの内容を取得することを要求するファイル内容取得依頼を作成し、
前記ライブラリ部は、
前記アプリケーション部から前記子ハンドルを用いた１回目の前記ファイル内容取得依頼を受領したときに、前記親ハンドルと共に前記ファイル取得依頼を前記サーバ装置に送信することで、前記サーバ装置から前記ファイルの内容を取得し、取得した前記ファイルの内容を前記親ハンドルに関連付けて記憶手段にキャッシュ情報として登録し、前記セッション中に前記アプリケーション部から、前記１回目のファイル取得依頼と同一のファイルに対して、取得した前記ファイルの内容に関連付けた前記親ハンドルに従属する子ハンドルを用いた２回目以降のファイル内容取得依頼を受領したときに、登録されている前記キャッシュ情報を返却するキャッシュ情報登録手段をさらに備えることを特徴とする請求項１に記載のクライアント装置。 - 前記アプリケーション部は、前記サーバ装置で管理するファイルおよびディレクトリの少なくとも１つの状態の変化を示すイベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼を子ハンドル毎に作成する際に、監視するイベント種別とイベント発生通知時の処理を示すコールバック処理の情報を前記ライブラリ部に登録し、
前記ライブラリ部の前記親子ハンドル管理手段は、前記ハンドルリストにおいて、前記イベント監視登録依頼で用いられる子ハンドル毎に前記コールバック処理の情報を記憶し、
前記ライブラリ部は、
前記アプリケーション部から、前記イベント監視登録依頼を前記子ハンドルと共に受領したときに、前記子ハンドル毎に記憶されている前記コールバック処理の情報を集約して前記親ハンドルの識別情報および当該イベント監視登録依頼と共に前記サーバ装置に送信し、前記サーバ装置から、前記集約したコールバック処理の情報を前記イベント発生通知として受信したときに、受信した前記コールバック処理の情報における集約を解除することで、当該イベント発生通知に該当する子ハンドルを探索し、前記探索された子ハンドルに付与されているイベント発生通知時の処理を実行するイベント通知制御手段をさらに備える、
ことを特徴とする請求項１または請求項２に記載のクライアント装置。 - 前記アプリケーション部は、前記コールバック処理の情報として、監視するイベント種別とイベント発生通知時の処理の有無を管理するマスク値を前記ライブラリ部に登録し、
前記ライブラリ部の前記親子ハンドル管理手段は、前記子ハンドルに対して、前記コールバック処理の情報であるイベント毎の前記マスク値の集合をイベントマスクとして付与して記憶し、
前記ライブラリ部のイベント通知制御手段は、
前記イベント監視登録依頼と共に受領した前記子ハンドルのイベントマスク値と、前記親ハンドルのイベントマスク値との論理和を計算することで前記コールバック処理の情報を集約し、この計算結果で前記親ハンドルのイベントマスク値を更新し、前記更新により生成された新イベントマスクの登録依頼を、前記イベント監視登録依頼と共に前記サーバ装置に送信し、前記サーバ装置から、前記イベント発生通知として前記新イベントマスクを受信したときに、前記ハンドルリストに記載された前記子ハンドルのイベントマスク値と前記受信した新イベントマスクのマスク値との論理積を計算することで、受信した前記新イベントマスクにおける前記子ハンドルのイベントマスク値の集約を解除することを特徴とする請求項３に記載のクライアント装置。 - 前記アプリケーション部は、前記ライブラリ部に対して、前記セッションにおいて前記サーバ装置に記憶された前記ファイルシステムで管理されたファイルまたはディレクトリに対するロックを前記子ハンドルが取得することを要求するロック取得依頼を作成し、
前記ライブラリ部の前記親子ハンドル管理手段は、前記ハンドルリストにて前記子ハンドルのロック取得状況の情報を前記子ハンドルに関連付けて記憶し、
前記ライブラリ部は、
前記アプリケーション部から、前記ファイルシステムで管理された所定のファイルまたはディレクトリに対する前記ロック取得依頼を前記子ハンドルと共に受領したときに、前記受領した子ハンドルのロック取得状況の情報が前記ハンドルリストに記憶されている場合に当該ロック取得状況の情報を返却し、一方、記憶されていない場合に、当該子ハンドルの前記ロック取得依頼を前記親ハンドルの識別情報と共に前記サーバ装置に送信し、前記サーバ装置から、サーバ側にて当該子ハンドルのロック取得状況の情報が登録されたことを示す応答を受信したときに、受信した前記応答で示されるロック取得状況の情報を、当該子ハンドルのロック取得状況の情報として前記ハンドルリストに登録するロック制御管理手段をさらに備える、
ことを特徴とする請求項１乃至請求項４のいずれか一項に記載のクライアント装置。 - ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、親ハンドルに従属する子ハンドルを用いて操作するアプリケーション部を備えるクライアント装置とを備えるコンピュータシステムにおける前記サーバ装置であって、
前記クライアント装置とのセッションにより、前記アプリケーション部から、前記ファイルシステム上のファイルまたはディレクトリの操作に対応する前記親ハンドルの作成を要求するハンドル作成依頼を受信し、前記親ハンドルを生成し、生成した前記親ハンドルを当該クライアント装置に返却し、当該クライアント装置のアプリケーション部と生成した前記親ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納しておくハンドル管理手段を備えることを特徴とするサーバ装置。 - 前記セッションにより、前記アプリケーション部から、前記ファイルシステムで管理されたファイルの内容を取得することを要求するファイル取得依頼を、当該アプリケーション部と前記ファイルに対応した前記親ハンドルと共に受信し、当該ファイルの内容を当該クライアント装置に返却し、前記ハンドルリストにて、返却した前記ファイルの内容が当該クライアント装置にキャッシュされていることを示すキャッシュ状態情報を、前記受信した親ハンドルの識別情報と関連付けて登録するキャッシュ管理手段をさらに備えることを特徴とする請求項６に記載のサーバ装置。
- 前記セッションにより、前記アプリケーション部から、当該サーバ装置で管理するファイルおよびディレクトリの少なくとも１つの状態の変化を示すイベントが発生した場合にイベント発生通知を受け取るためのイベント監視登録依頼および前記親ハンドルの識別情報を、監視するイベント種別とイベント発生通知時の処理を示すコールバック処理の情報と共に受信したときに、前記ハンドルリストにて、受信した前記コールバック処理の情報を前記親ハンドルの識別情報と関連付けて登録し、
前記イベントが発生したことを検知したときに、当該発生したイベントを通知するために登録されている前記親ハンドルを前記ハンドルリストからすべて抽出し、抽出された前記親ハンドルに基づいて、該当するクライアント装置のアプリケーション部に対してセッションを通じて、当該親ハンドルに関連付けて登録されている前記コールバック処理の情報を送信するイベント管理手段をさらに備える、
ことを特徴とする請求項６または請求項７に記載のサーバ装置。 - 前記イベント管理手段は、
前記コールバック処理の情報として、イベント発生通知時の処理の有無を管理するイベント毎のマスク値の集合であるイベントマスクを前記親ハンドルの識別情報と共に受信したときに、前記ハンドルリストにて、前記受信したイベントマスクを前記親ハンドルの識別情報と関連付けて登録し、
前記イベントが発生したことを検知したときに、前記コールバック処理の情報として、前記親ハンドルの識別情報に関連付けて登録されているイベントマスクを送信することを特徴とする請求項８に記載のサーバ装置。 - 前記記憶手段は、前記親ハンドルに従属して前記クライアント装置で生成され前記セッションにおいて有効な子ハンドルの識別情報と、前記セッションにおいて当該サーバ装置に記憶された前記ファイルシステムで管理されたファイルまたはディレクトリに対するロックを前記子ハンドルが取得していることを表す情報との対応関係を示すロック取得リストをさらに記憶し、
前記セッションにより、前記アプリケーション部から、当該アプリケーション部に対応した前記親ハンドルと前記子ハンドルと共に、当該子ハンドルが前記ファイルシステムで管理された所定のファイルまたはディレクトリに対する前記ロックを取得することを要求するロック取得依頼を受信したときに、受信した前記ロック取得依頼にて対象とするファイルまたはディレクトリが別のクライアント装置によってロック取得済みであることを表す情報が前記ロック取得リストに記憶されているか否かを判別し、
当該情報が前記ロック取得リストに記憶されている場合には、前記別のクライアント装置によるロックが解除されるまで、受信した前記子ハンドルをロック待ち行列の記憶手段に登録して管理し、一方、当該情報が前記ロック取得リストに記憶されていない場合には、受信した前記子ハンドルを前記ロック取得リストに登録し、前記判別の結果に応じて、受信した前記子ハンドルのロック取得状況の情報を前記クライアント装置のアプリケーション部に返却するロック管理手段をさらに備える、
ことを特徴とする請求項６乃至請求項９のいずれか一項に記載のサーバ装置。 - 請求項１に記載のクライアント装置と、請求項６に記載のサーバ装置とを備えることを特徴とするコンピュータシステム。
- ファイルおよびディレクトリを管理するファイルシステムを備えるサーバ装置と、前記ファイルシステムが管理するファイルまたはディレクトリを、ハンドルを用いて操作するクライアント装置とを備え、前記クライアント装置が、前記ファイルシステムに対する所定操作の実行を要求するアプリケーション部と、前記アプリケーション部による要求を中継して前記ファイルシステムにアクセスするライブラリ部とを有しているコンピュータシステムにおいて前記ファイルシステムにアクセスするファイルシステムアクセス方法であって、
前記クライアント装置の前記ライブラリ部は、
前記アプリケーション部による前記ファイルシステム上のファイルまたはディレクトリの操作に対応する子ハンドルを生成する際に、当該ファイルに対する１以上の前記子ハンドルを集約した親ハンドルがクライアント側ハンドルリストに登録されているか否かを判別する親ハンドル登録判別ステップと、
前記親ハンドルが登録されていない場合に、前記親ハンドルの作成を要求するハンドル作成依頼を前記サーバ装置に送信するハンドル作成依頼送信ステップとを実行し、
前記サーバ装置は、
前記ハンドル作成依頼に基づいて、前記親ハンドルを生成し、生成した前記親ハンドルを当該クライアント装置に返却すると共に、当該クライアント装置の前記アプリケーション部と生成した前記親ハンドルの識別情報とを関連付けたサーバ側ハンドルリストを生成し、記憶手段に格納する親ハンドル生成ステップを実行し、
前記クライアント装置の前記ライブラリ部は、
前記サーバ装置から受信した親ハンドルの識別情報を前記クライアント側ハンドルリストに記憶する親ハンドル情報格納ステップと、
前記親ハンドル登録判別ステップにて前記親ハンドルが登録されている場合、または、前記親ハンドル情報格納ステップにて前記親ハンドルの識別情報を記憶した場合に、当該親ハンドルに従属する子ハンドルを生成し、生成した前記子ハンドルの識別情報と当該親ハンドルの識別情報とを関連付けたハンドルリストを生成し、記憶手段に格納する子ハンドル生成ステップとを実行する、
ことを特徴とするファイルシステムアクセス方法。 - 請求項１乃至請求項５のいずれか一項に記載のクライアント装置を構成する各手段としてコンピュータを機能させるためのクライアントプログラム。
- 請求項６乃至請求項１０のいずれか一項に記載のサーバ装置を構成する各手段としてコンピュータを機能させるためのサーバプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009147852A JP5395532B2 (ja) | 2009-06-22 | 2009-06-22 | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009147852A JP5395532B2 (ja) | 2009-06-22 | 2009-06-22 | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2011003147A JP2011003147A (ja) | 2011-01-06 |
| JP5395532B2 true JP5395532B2 (ja) | 2014-01-22 |
Family
ID=43561030
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009147852A Expired - Fee Related JP5395532B2 (ja) | 2009-06-22 | 2009-06-22 | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5395532B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210015387A (ko) * | 2019-08-02 | 2021-02-10 | 한국전자통신연구원 | Opc ua를 이용한 분산형 스마트 팩토리 운영 방법 및 장치 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2507235B2 (ja) * | 1994-06-24 | 1996-06-12 | インターナショナル・ビジネス・マシーンズ・コーポレイション | クライアント・サ―バ・コンピュ―タ・システム、及びそのクライアント・コンピュ―タ、サ―バ・コンピュ―タ、並びにオブジェクト更新方法 |
| JP2000137689A (ja) * | 1998-11-04 | 2000-05-16 | Hitachi Ltd | 共用データキャッシュ処理方法及びその実施装置並びにその処理プログラムを記録した媒体 |
| JP2003233520A (ja) * | 2002-02-07 | 2003-08-22 | Fujitsu Ltd | ネットワーク上のファイル資源のためのファイル制御装置 |
| US7624126B2 (en) * | 2003-06-25 | 2009-11-24 | Microsoft Corporation | Registering for and retrieving database table change information that can be used to invalidate cache entries |
| JP4175379B2 (ja) * | 2006-04-25 | 2008-11-05 | 日本電気株式会社 | ファイル共有方法およびファイル共有システム |
-
2009
- 2009-06-22 JP JP2009147852A patent/JP5395532B2/ja not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210015387A (ko) * | 2019-08-02 | 2021-02-10 | 한국전자통신연구원 | Opc ua를 이용한 분산형 스마트 팩토리 운영 방법 및 장치 |
| KR102593008B1 (ko) * | 2019-08-02 | 2023-10-23 | 한국전자통신연구원 | Opc ua를 이용한 분산형 스마트 팩토리 운영 방법 및 장치 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2011003147A (ja) | 2011-01-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11641397B2 (en) | File service using a shared file access-rest interface | |
| US10534681B2 (en) | Clustered filesystems for mix of trusted and untrusted nodes | |
| CN107787490B (zh) | 分布式数据库网格中的直接连接功能 | |
| US9965364B2 (en) | Fault tolerant listener registration in the presence of node crashes in a data grid | |
| US9558194B1 (en) | Scalable object store | |
| JP5695324B2 (ja) | スプリットブレイン状況におけるメジャーグループを決定するための方法、システム、及びコンピュータ読み取り可能な記録媒体 | |
| US9275058B2 (en) | Relocation of metadata server with outstanding DMAPI requests | |
| US9367346B2 (en) | Accelerating distributed transactions on key-value stores through dynamic lock localization | |
| JP3197789B2 (ja) | 分散ファイル・システム内にあるディレクトリの操作を要求する方法およびシステム | |
| US9171019B1 (en) | Distributed lock service with external lock information database | |
| WO2018059032A1 (zh) | 一种虚拟节点的数据迁移方法和虚拟节点 | |
| US20030028514A1 (en) | Extended attribute caching in clustered filesystem | |
| US7366742B1 (en) | System and method for distributed discovery and management of frozen images in a storage environment | |
| CN104715001A (zh) | 用于对数据处理系统的集群中的共享资源执行写入操作的方法和系统 | |
| JP5541149B2 (ja) | スナップショット採取プログラム、サーバおよびスナップショット採取方法 | |
| US20100162035A1 (en) | Multipurpose Storage System Based Upon a Distributed Hashing Mechanism with Transactional Support and Failover Capability | |
| CN107710164B (zh) | 作为一种服务的灾难恢复 | |
| JP7389793B2 (ja) | 分散型異種ストレージシステムにおけるデータ一貫性のリアルタイムチェックのための方法、デバイス、およびシステム | |
| US20150213011A1 (en) | Method and system for handling lock state information at storage system nodes | |
| US8788474B2 (en) | Inode event notification for cluster file systems | |
| US10558373B1 (en) | Scalable index store | |
| JP2006503347A (ja) | ストレージ・エリア・ネットワーク上の非同期メッセージング | |
| JP5395532B2 (ja) | クライアント装置、サーバ装置、コンピュータシステム、および、ファイルシステムアクセス方法、並びに、クライアントプログラムおよびサーバプログラム | |
| JP6697101B2 (ja) | 情報処理システム | |
| JP6044363B2 (ja) | コンピュータ、ｎａｓアクセス方法およびｎａｓアクセスプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20110819 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110920 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20130201 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20131002 |
|
| 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: 20131015 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131018 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5395532 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |