(57)【要約】  データベースサーバにおいてファイルシステム操作ロックを実行するための方法および装置が提供される。データベースサーバによって管理されるファイルの一部に対してファイル操作を実行するようにとの要求が、データベースサーバにおいて受信される。要求の受信に応答して、データベースサーバは、ファイル操作に関与するファイルの一部のみをカバーするロックを付与する。たとえば、データベースサーバは、ファイル上のある範囲のバイトをカバーするロックを付与してもよく、この場合、バイトの範囲はファイル全体よりも小さい。その後、データベースサーバは、ファイルに対してファイル操作を実行する。ファイル操作はＮＦＳ操作であってもよい。
2008524694.tif 000002
【特許請求の範囲】
【請求項１】
マシンにより実現される方法であって、
データベースサーバにおいて、前記データベースサーバによって管理されるファイルの一部に対してファイル操作を実行するようにとの要求を受信するステップと、
前記要求を受信する前記ステップに応答して、前記ファイル操作に関与する前記ファイルの前記一部のみをカバーするロックを付与するステップと、
前記ファイルの前記一部に対して前記ファイル操作を実行するステップとを備える、方法。
【請求項２】
前記操作は前記ファイルのある範囲のバイト内に該当する情報に関与し、付与される前記ロックは前記範囲のバイトに対応している、請求項１に記載の方法。
【請求項３】
前記ロックは要求元に付与され、前記ロックは、前記要求元以外のあらゆるエンティティに対し、前記ファイルへの読出アクセスを拒否する、請求項１に記載の方法。
【請求項４】
前記ロックは要求元に付与され、前記ロックは、前記要求元以外のあらゆるエンティティに対し、前記ファイルへの書込アクセスを拒否する、請求項１に記載の方法。
【請求項５】
前記一部は前記ファイルよりも小さい、請求項１に記載の方法。
【請求項６】
前記ロックは、前記ファイル上のある範囲のバイトへの読出および書込アクセスを付与する、請求項５に記載の方法。
【請求項７】
前記ロックは第１のロックであり、前記一部は第１の部分であり、前記方法はさらに、
要求元から、前記ファイルの第２の部分に対する第２のロックを必要とする第２の要求を受信するステップと、
前記データベースサーバが前記ファイルに対して前記第１のロックを付与したために前記第２の要求が実行されないことを、前記要求元に知らせるステップとを備える、請求項１に記載の方法。
【請求項８】
マシンにより実現される方法であって、
データベースサーバにおいて、ある特定のロックの付与を必要とする操作を実行するようにとの要求をエンティティから受信するステップと、
データベースサーバがエンティティに、ある特定された期間の間、特定のロックを付与するステップと、
予め定められた期間の間、前記エンティティから通信が受信されなかった場合、特定のロックを解除するようにとの要求をエンティティから受信することなく、特定のロックを自動的に解除するステップとを備える、方法。
【請求項９】
前記特定のロックは、前記エンティティ以外のあらゆる要求元に対し、リソースへの読出アクセスを拒否する、請求項８に記載の方法。
【請求項１０】
前記特定のロックは、前記エンティティ以外のあらゆる要求元に対し、リソースへの書込アクセスを拒否する、請求項８に記載の方法。
【請求項１１】
前記特定のロックは、前記エンティティに、リソース上のある範囲のバイトへの読出および書込アクセスを付与する、請求項１に記載の方法。
【請求項１２】
前記特定のロックは、前記エンティティに、リソース上のある範囲のバイトへの書込ア
クセスを付与する、請求項１に記載の方法。
【請求項１３】
前記ロックを付与する前記ステップは、Ｂツリーにエントリを追加するステップを備え、前記エントリは、前記ファイル操作に関与する前記ファイルの前記一部を識別する情報を記憶する、請求項１に記載の方法。
【請求項１４】
前記ロックを付与する前記ステップは、Ｂツリーにエントリを追加するステップを備え、前記エントリは、前記ファイル操作を要求した要求元を識別する情報を記憶する、請求項１に記載の方法。
【請求項１５】
前記ロックを付与する前記ステップは、前記ファイル操作の実行を防ぐ第２のロックが前記ファイルの前記一部に対して付与されていたかどうかを判断するために、Ｂツリーにアクセスするステップを備える、請求項１に記載の方法。
【請求項１６】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１７】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項２に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１８】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項３に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１９】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項４に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２０】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項５に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２１】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項６に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２２】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項７に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２３】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項８に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２４】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項９に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２５】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１０に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２６】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１１に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２７】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１２に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２８】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１３に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２９】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１４に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項３０】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１５に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
この発明は、データベース管理システムにおけるファイル操作の実行に関する。
【背景技術】
【０００２】
背景
データは、データベースおよびファイルサーバといったさまざまなタイプの記憶機構に記憶される。各記憶機構は通常、それ自体のアクセス手段を有している。たとえば、ＳＱＬプロトコルは通常、データベース上で操作を実行するために使用され、ＮＦＳプロトコルは通常、ファイルシステム上で操作を実行するために使用される。ＳＱＬプロトコルは、データベースに記憶されたデータにアクセスしてそれを処理するためのＡＮＳＩ規格である。ＮＦＳプロトコルは、ネットワーク中のファイルに対するファイル操作の実行をサポートする分散ファイルシステムプロトコルである。ＮＦＳは、ＵＮＩＸ（登録商標）ホスト間でファイルを共有するための周知の規格である。ＮＦＳプロトコルでは、ファイルシステム操作は、ある特定のファイルを識別する識別子であるファイルハンドルを用いて、ファイルに対して実行される。ＮＦＳの現在のバージョンであるバージョン４は、ＲＦＣ３０１０で規定されているが、機密保護の強化、およびステートフルな操作の実行の強化といった、バージョン３を上回る付加的な機能性をサポートしている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
現在、データベース管理システムは、ＮＦＳプロトコルを用いたデータベースへのアクセスをサポートしていない。このため、ユーザがデータにアクセスしたい場合、ユーザは、データにアクセスする適切な態様を判断するために、どのタイプの記憶機構がデータを記憶しているかを確かめなければならない。たとえば、ユーザは、データがリレーショナルにデータベースに記憶されているか、またはファイルシステムに記憶されているかを判断しなければならない。多くの状況では、データが実際にどの記憶機構に記憶されているかを判断することは、ユーザにとって厄介な場合がある。
【０００４】
さらに、さまざまな理由により、単一の記憶機構にできるだけ多種類のデータを記憶させることが望ましい。維持される異なるタイプの記憶機構の数を最小限に抑えることは、記憶機構を維持するために必要なリソースの量を減少させる。また、データベースといった中心場所に多種類のデータを記憶させることは、使いやすさおよび機密保護を促進する。なぜなら、データは複数の分散した場所に記憶されていないためである。
【０００５】
したがって、データベース管理システム内でファイルシステム操作を実行するためのアプローチが望ましい。この章で述べるアプローチは、追求可能なアプローチであるが、必ずしも以前に構想または追及されたアプローチであるとは限らない。したがって、特に示唆されていない限り、この章で述べるどのアプローチも、単にこの章に含まれているというだけで先行技術としての資格を得ると仮定すべきではない。
【０００６】
この発明の実施例を、添付図面の図において、限定のためではなく一例として例示する。図中、同じ参照番号は同様の要素を指す。
【発明を実施するための最良の形態】
【０００７】
詳細な説明
以下の説明では、解説のため、多数の特定の詳細がこの発明の実施例の完全な理解を提供するために述べられる。しかしながら、この発明の実施例がこれらの特定の詳細なしで実践され得ることは明らかである。他の点では、ここに述べるこの発明の実施例を不必要に不明瞭にしないよう、周知の構造および装置をブロック図の形で示す。
【０００８】
機能的概要
この発明の実施例は、データベースに記憶されたファイルに対して、ＮＦＳファイル操作といったどんなステートフルな要求も実行し得る。ステートフルな操作を実行する際、データベースサーバは、リソースに対するさまざまなファイルベースのロックを採用し得る。ファイルベースのロックがデータベースロックと異なる点は、ファイルベースのロックは、データベーストランザクションがコミットされたときには解除されず、むしろ、リソースが順調に実行されたＮＦＳファイルシステム操作「閉じる」（クローズ）の対象である場合に解除されるということである。また、ファイルベースのロックは、リソースのほんの一部、たとえばファイルのある範囲のバイトに対して付与され得る。
【０００９】
一実施例では、データベースサーバによって管理されるファイル操作を実行するようにとの要求が、データベースサーバにおいて受信される。この要求は、データベースに記憶されたファイルの一部に対してそのファイル操作を実行することであるかもしれない。この要求の受信に応答して、データベースサーバは、そのファイル操作に関与するファイルの一部のみをカバーするファイルベースのロックを付与する。たとえば、データベースサーバは、ファイル上のある範囲のバイトをカバーするファイルベースのロックを付与してもよいが、この場合、バイトの範囲はファイル全体よりも小さい。その後、データベースサーバは、ファイルに対してファイル操作を実行してもよい。ファイルが一旦ＮＦＳファイルシステム操作「閉じる」の対象となると、そのファイルに対し、ファイルベースのロックが解除される。
【００１０】
アーキテクチャ上の概要
図１は、この発明の一実施例に従った、ファイルシステム操作を実行するようにとの要求を処理可能なシステム１００のブロック図である。システム１００は、クライアント１１０と、データベース管理システム（ＤＢＭＳ）１２０と、通信リンク１３０とを含む。クライアント１１０のユーザは、１つ以上のファイルシステム操作の実行を特定する要求をＤＢＭＳ１２０に発行してもよい。解説のため、要求がＮＦＳの或るバージョン、たとえばバージョン４に準拠する例を挙げる。
【００１１】
クライアント１１０は、ＤＢＭＳ１２０に要求を発行可能な任意の媒体または機構によって実現されてもよい。クライアント１１０は、ＤＢＭＳ１２０にステートフルな要求を発行してもよい。ここで使用されるように、「ステートフルな要求」とは、ステートフルな操作の実行を求める要求のことである。通常、ステートフルな要求は、ＮＦＳなどのステートフルなプロトコルを用いて発行される。クライアント１１０の非限定で例示的な例は、通信リンク１３０にアクセス可能な装置上で実行中のアプリケーションを含む。説明を簡単にするために図１にはクライアントが１つしか図示されていないが、システム１００は、通信リンク１３０上でＤＢＭＳ１２０と各々通信する任意の数のクライアント１１０を含んでいてもよい。
【００１２】
クライアント１１０は、多数の要求を並行して発行可能な媒体または機構によって実現されてもよい。たとえば、クライアント１１０は装置上で実行中のアプリケーションに対応していてもよく、そのアプリケーションは、ＤＢＭＳ１２０に要求を各々送信し得る多数のプロセスで構成されていてもよい。したがって、混乱を避けるため、ＤＢＭＳ１２０に要求を発行する任意のエンティティを指すために、「要求元」という用語をここで使用する。このため、要求元は、クライアント１１０、クライアント１１０上で実行中のプロ
セス、またはクライアント１１０によって生成されたプロセスに対応していてもよい。
【００１３】
ＤＢＭＳ１２０は、電子データの記憶および検索を容易にするソフトウェアシステムである。ＤＢＭＳ１２０は、データベースサーバ１２２とデータベース１２４とを備える。データベースサーバ１２２は、データベース１２４に保持されたファイルに対する任意のステートフルな要求、たとえばファイル操作を実行するようにとの要求をデータベースサーバ１２２が処理できるようにするフレームワークを用いて実現される。
【００１４】
データベースサーバ１２２は、マルチプロセス・シングルスレッド環境において、マルチスレッドサーバとしてエミュレートされて実現されてもよい。各々作業を実行可能なプロセス群のプールが、データベースサーバ１２２に存在する。データベースサーバ１２２が要求を受信すると、データベースサーバ１２２は、プロセス群のプール内の任意のプロセスに、受信された要求を処理するよう割当ててもよい。マルチプロセス・シングルスレッド環境においてデータベースサーバ１２２を実現することにより、データベースサーバ１２２は、多数のクライアント１１０をサポートするよう拡大可能になる。
【００１５】
通信リンク１３０は、クライアント１１０とＤＢＭＳ１２０との間のデータの交換を提供する任意の媒体または機構によって実現されてもよい。通信リンク１３０の例は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、イーサネット（登録商標）またはインターネットといったネットワーク、もしくは１つ以上の地上リンク、衛星リンク、または無線リンクを制限なく含む。
【００１６】
フレームワーク
図２は、この発明の一実施例に従ったデータベースサーバ１２２の機能的構成要素のブロック図である。上述のように、データベースサーバ１２２は、データベース１２４に保持されたファイルに対するステートフルな要求をデータベースサーバ１２２が処理できるようにするフレームワーク２００を用いて実現される。加えて、同じフレームワーク２００が、データベース１２４に保持されたデータに対するステートレスな要求、たとえばＨＴＴＰまたはＦＴＰプロトコルで実現された要求をデータベースサーバ１２２が処理できるようにしてもよい。さらに、以下に説明するように、フレームワーク２００は、ステートレスまたはステートフルな新しいプロトコルをサポートするために、またはフレームワーク２００によってサポートされる既存のプロトコルに新しい機能性を追加するために、付加的な構成要素を含むよう構成されてもよい。
【００１７】
データベースサーバ１２２のフレームワーク２００における各構成要素を以下に説明し、その後、「フレームワークを用いたファイル操作処理」と題された章で、例示的なステートフルな要求をフレームワーク２００を用いて処理する説明を提示する。
【００１８】
フレームワーク２００は、ステートフルまたはステートレスな要求によって必要とされる付加的な機能性を提供する、図２に図示されていない付加的な構成要素を用いて実現されてもよい。たとえば、拡張２３４とは、フレームワーク２００にプラグ接続され、フレームワーク２００がステートレスまたはステートフルな新しいプロトコルをサポートすること、またはフレームワーク２００によってサポートされる既存のプロトコルに新しい機能性を追加することを可能にする構成要素を指す。拡張構成要素２３４をフレームワーク２００にプラグ接続するために、プロトコルインタープリタ２１０が、適切な情報を用いて適切な時点で拡張構成要素２３４を呼出すよう構成されている。
【００１９】
プロトコルインタープリタ
プロトコルインタープリタ２１０は、通信リンク１３０を通してＤＢＭＳ１２０に送信されたパケットを受信する。プロトコルインタープリタ２１０は、通信リンク１３０を通
してクライアント１１０からパケットを受信し、そのパケットを以下に説明するように処理することが可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。プロトコルインタープリタ２１０は、パケットを受信すると、そのパケットに関連付けられたパケットタイプを識別し、そのパケットを、そのパケットタイプのパケットを読出すよう構成された構成要素に送信する。たとえば、プロトコルインタープリタ２１０が、パケットのヘッダを検査することにより、そのパケットがＮＦＳ要求を含むと判断した場合、プロトコルインタープリタ２１０は、そのパケットをＮＦＳパケットリーダ２２４に送信する。ＮＦＳ要求を含むパケットがＮＦＳパケットリーダ２２４によって読出された後で、ＮＦＳパケットリーダ２２４は、そのパケット内で特定された個々のファイルシステム操作についての情報を、さらなる処理のためにプロトコルインタープリタ２１０に送り返す。
【００２０】
プロトコルインタープリタ２１０は、ルックアップ機構２１２を含む。ルックアップ機構２１２は、ＤＢＭＳ１２０の要求元についてのステート情報を記憶可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。ルックアップ機構は、ステート情報を揮発性ストレージに記憶してもよく、ステート情報の検索を容易にする任意の機構、たとえばＢツリーおよびハッシュテーブルを用いて実現されてもよい。以下に、「ステート情報の保持」と題された章で、ルックアップ機構２１２の例示的な一実施例をより詳細に提示する。
【００２１】
プロトコルインタープリタ２１０は、プロトコルインタープリタ２１０によって受信されたパケットによって要求される操作を処理するよう構成されている。プロトコルインタープリタ２１０は、受信されたパケットによって要求される操作を実行するよう構成されてもよく、または、以下により詳細に説明するように、プロトコルインタープリタ２１０は、プロトコルインタープリタ２１０によって受信されたパケットによって要求される操作を実行するために、フレームワーク２００の１つ以上の構成要素と通信してもよい。
【００２２】
エクスポータ
エクスポータ２２０は、エクスポート操作を実行可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。エクスポートにより、要求元は、ディレクトリツリー（directory tree）がサーバに存在するというよりもむしろ、ディレクトリツリーが要求元に存在するかのように、ディレクトリツリーの一部を閲覧できるようになる。
【００２３】
一実施例では、フレームワーク２００がエクスポート操作を順調に実行した後で、フレームワーク２００はそのエクスポート操作の要求元に（ａ）どのディレクトリフォルダが要求元にエクスポートされるかを識別する情報と、（ｂ）エクスポートされたディレクトリフォルダへの読出および／または書込アクセスを要求元が有するかどうかを識別する情報とを送信する。要求元がエクスポート操作を通してディレクトリフォルダへのアクセスを受信した場合、要求元は、要求元がアクセスを有するディレクトリフォルダの、任意の子ディレクトリフォルダを含むすべての内容を閲覧してもよい。
【００２４】
一実施例では、エクスポータ２２０は、（ａ）どの要求元がディレクトリフォルダをエクスポートしたかについての情報と、（ｂ）任意のエクスポートされたディレクトリフォルダに関連付けられたアクセス許可についての情報とを保持してもよい。ディレクトリフォルダは、特定のクライアント１１０にエクスポートされてもよく（たとえばある特定のＩＰアドレスまたはドメイン名にディレクトリフォルダをエクスポートする）、または１つ以上のクライアントにエクスポートされてもよく、たとえば、ディレクトリフォルダは、あるＩＰマスクにディレクトリフォルダをエクスポートすることによって、関連したマシン群にエクスポートされてもよい。
【００２５】
リソースロッカ
リソースロッカ２２０は、リソースをロック可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。一実施例では、リソースロッカ２２２は、データベース１２４に記憶されたファイルに対してバイト範囲ロッキングを実行するよう構成されている。
【００２６】
リソースに対するロックの実行が要求されると、リソースロッカ２２２がロックを実行する。ファイルベースのロックを付与するようにとの要求の実行において、リソースロッカ２２２は、ルックアップ機構２１２によって保持された情報を更新してもよい。ファイルベースのロックについては、以下により詳細に説明する。
【００２７】
たとえば、一実施例では、プロトコルインタープリタ２１０がリソースロッカ２２２に、あるファイルに対してファイルベースのロックの付与を要求するファイルシステム操作を実行するよう命令してもよい。リソースロッカ２２２はＢツリーにアクセスして、まず、ファイルベースのロックが付与されてもよいか、および要求されたファイルベースのロックが付与されてもよいかを判断してもよく、次に、リソースロッカ２２２は、ファイルベースのロックがファイルに対して付与されたことを反映するよう、１つ以上のＢツリーを更新してもよい。リソースロッカ２２２がアクセスまたは更新し得る特定のＢツリーについては、以下により詳細に説明する。
【００２８】
パケットリーダ
フレームワーク２００はいくつかのパケットリーダを含む。各パケットリーダは、ある特定のプロトコルに準拠するパケットから情報を読出すよう設計されている。たとえば、フレームワーク２００は、ＮＦＳパケットリーダ２２４と、ＦＴＰパケットリーダ２２６と、ＨＴＴＰパケットリーダ２２８とを含む。
【００２９】
ＮＦＳパケットリーダ２２４は、ＮＦＳプロトコルに準拠するパケットを読出して構文解析することが可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。そのようなパケットは、１つの操作を要求してもよく、または多くの操作を要求してもよい。２つ以上のファイルシステム操作を要求するパケットは「複合要求」と呼ばれる。ＮＦＳパケットリーダ２２４は、パケットにおいて特定された第１の操作を読出し、その操作を識別するデータをプロトコルインタープリタ２１０に戻すよう構成されている。前の操作が一旦処理されると、プロトコルインタープリタ２１０はその後、ＮＦＳパケットリーダ２２４に、パケットから別の操作を読出させてもよい。
【００３０】
ＦＴＰパケットリーダ２２６は、ＦＴＰ要求を含むパケットを読出して構文解析することが可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。ＦＴＰパケットリーダ２２６は、ＦＴＰパケット内に含まれるＦＴＰ操作情報を読出して構文解析し、その後、処理のためにＦＴＰ操作情報をプロトコルインタープリタ２１０に通信するよう構成されている。
【００３１】
ＨＴＴＰパケットリーダ２２８は、ＨＴＴＰ要求を含むパケットを読出して構文解析することが可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。ＨＴＴＰパケットリーダ２２６は、ＨＴＴＰパケット内に含まれるＨＴＴＰ操作情報を読出して構文解析し、その後、処理のためにＨＴＴＰ操作情報をプロトコルインタープリタ２１０に通信するよう構成されている。
【００３２】
図２は、３つの異なるタイプのパケットタイプ、すなわちＮＦＳ、ＦＴＰ、およびＨＴＴＰパケット用のパケットリーダを例示しているが、他の実施例は、付加的なタイプのパ
ケット用の付加的なパケットリーダを備えていてもよい。このように、フレームワークは、ステートレスまたはステートフルな任意のプロトコルを読出可能な構成要素を含んでいてもよい。
【００３３】
権限検証子
権限検証子２３０は、ある特定のファイルシステム操作を実行するのに十分な許可レベルをある特定の要求元が有しているかどうかを検証可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。プロトコルインタープリタ２１０がファイルシステム操作を実行するたびに、プロトコルインタープリタ２１０は権限検証子２３０に、ある特定のファイルシステム操作を実行するのに十分な許可レベルをある特定の要求元が有しているかどうかを判断するよう命令してもよい。ある特定のファイルシステム操作を実行するのに十分な許可レベルをある特定のユーザが有しているかどうかの判断については、図３のステップ３１８を参照して以下により詳細に説明する。
【００３４】
オーソライザ
オーソライザ２３２は、プロトコルインタープリタ２１０によって受信されたある特定の要求を発行した要求元が実際に、その特定の要求において識別されたのと同じ要求元であるかどうかを判断可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。このように、要求において特定された任意の操作を実行する前に、要求元の識別情報がオーソライザ２３２によって検証されてもよい。プロトコルインタープリタ２１０が要求を受信するたびに、プロトコルインタープリタ２１０はオーソライザ２３２に、プロトコルインタープリタ２１０によって受信されたある特定の要求を発行した要求元が実際に、その特定の要求において識別されたのと同じ要求元であるかどうかを判断するよう命令してもよい。ある特定の要求がある特定のクライアント１１０によって発行されたかどうかの判断については、ステップ３１６を参照して以下により詳細に説明する。
【００３５】
ステート情報の保持
ＮＦＳプロトコルでは、ファイルシステム操作は、「開いて」いるがまだ「閉じて」はいないファイルに対して実行される。要求元は、ファイルを開くためにファイルシステム操作「開く」（オープン）の実行を要求し、それから、要求元はそのファイルに対して他のファイルシステム操作を実行してもよい。要求元は、そのファイルに対して望まれるファイルシステム操作をすべて実行した後で、ファイルを閉じるためにファイルシステム操作「閉じる」の実行を要求する。
【００３６】
データベースサーバによって実行されるファイルシステム操作は、１つ以上のデータベーストランザクションにまたがっていてもよい。したがって、あるファイルに対し、そのファイルの状態を各々変更する１つ以上のデータベーストランザクションが、そのファイルが開いた時点と閉じた時点との間で実行されてもよい。
【００３７】
ＮＦＳはステートフルなプロトコルであるため、ステートフルな要求を処理する際にステート情報を保持することがフレームワーク２００にとって必要である。ステート情報とは、任意のセッションにおいて、リソースに対し、要求元によって以前に実行された任意の動作を記述する情報である。一実施例によれば、ステート情報は、要求元が開いた各ファイルについて保持される。たとえば、ある要求元がファイルＡとファイルＢとを開いた場合、その要求元は、ファイルＡについての第１の組のステート情報とファイルＢについての第２の組のステート情報とに関連付けられるであろう。
【００３８】
ステート情報は、要求元が（ａ）ファイルを開くかまたは閉じる場合、もしくは（ｂ）開いたファイルに対する新しいロックを取得する場合にはいつでも、割当てられるかまたは更新される。このため、要求元が（ａ）ファイルを開くかまたは閉じる場合、もしくは
（ｂ）開いたファイルに対する新しいロックを取得する場合にはいつでも、ステート情報は、ファイルに対して実行されるステートフルな操作を反映するよう更新される。
【００３９】
要求元に関連付けられたステート情報は、ファイルが開いてから要求元によってファイルに対して実行されたステートフルな操作のすべてを反映している。たとえば、ある要求元が最初にあるファイルを開いた場合、ステート情報Ａが割当てられてもよい。その後、同じ要求元がそのファイルに対するロックを取得すると、ステート情報Ａは無効になり、新しいステート情報Ｂが割当てられる。なお、ステート情報Ｂは、そのロックと、そのファイルがその要求元によって開かれたという事実との双方を反映している。その後、同じ要求元がそのファイルに対する第２のロックを取得すると、ステート情報Ｂは無効になり、新しいステート情報Ｃが割当てられる。なお、ステート情報Ｃは、２つのロックと、そのファイルがその要求元によって開かれたという事実との双方を反映している。要求元がファイルを閉じると、そのファイルについての、その要求元に関するステート情報は、もはや保持される必要がない。
【００４０】
要求元とファイルとの関係の状態の追跡
状態識別データは、クライアント１１０とデータベースサーバ１２２との間で交換される通信に添付されて、通信において参照されたファイルの現在の状態に言及してもよい。要求元がファイルを開くと、フレームワーク２００によって状態識別データが作成される。状態識別データは、要求元が開いた特定のファイルについて、その特定の要求元に関連付けられたステート情報を識別する。
【００４１】
開いたファイルの状態を追跡するために、新しく作成された状態識別データが要求元に戻される。たとえば、ファイルＡＢＣを開くようにとの要求を要求元ＸＹＺが発行したと仮定されたい。フレームワーク２００は、新しく開かれたファイルＡＢＣに関連付けられたステート情報を記述する状態識別データを生成し、この状態識別データを要求元ＸＹＺに戻す。
【００４２】
開かれたファイルに対してファイルシステム操作を実行するようにとの要求を要求元がデータベースサーバ１２２に送信すると、その要求は、要求元に以前に送信された任意の状態識別データを含んでおり、たとえば、状態識別データは、そのファイルが開かれるのに応答して要求元に以前に送信されたものであるかもしれない。このように、その要求は、そのファイルに関連付けられたステート情報を識別する。たとえば、ファイルＡＢＣに対するロックを求める要求を要求元ＸＹＺが送信した場合、その要求は、データベースサーバ１２２がファイルＡＢＣに対してファイルシステム操作「開く」を実行するのに応答して要求元ＸＹＺに以前に送信された状態識別情報を含むであろう。フレームワーク２００は、その要求に含まれる状態識別を使用して、対応するステート情報をルックアップ機構２１２を用いて検索してもよい。
【００４３】
このため、上述のように、フレームワーク２００はあるステートフルなファイルシステム操作の実行に応答して状態識別データを生成し、生成された状態識別データはファイルシステム操作の要求元に送信される。その後、要求元は、フレームワーク２００が状態識別データを用いてファイルについてのステート情報を検索できるように、状態識別データを要求に含めることによって、同じファイルに対して付加的なステートフルなファイルシステム操作を実行してもよい。
【００４４】
開かれたファイルに対してファイルシステム操作が実行される場合、そのファイルに関連付けられたステート情報は、そのファイルの新しい操作状態を反映するよう更新される。新しい状態識別データは、更新されたステート情報を参照するよう作成される。その後、フレームワーク２００は新しい状態識別データを要求元に送信する。このように、１組
のみの状態識別データが、要求元とフレームワーク２００との間で交換される。フレームワークがステートフルなファイルシステム操作を順調に実行した後にフレームワーク２００から送信される状態識別データは、ステートフルなファイルシステム操作の対象であったリソースに関連付けられた最新のステート情報を識別する。
【００４５】
次の章で説明されるように、フレームワーク２００は、ルックアップ機構２１２にステート情報を記憶させてもよく、ルックアップ機構２１２に記憶されたステート情報を状態識別データを用いて検索してもよい。
【００４６】
ステート情報の保持
一実施例によれば、ステート情報はルックアップ機構２１２を用いて保持される。一実施例では、ルックアップ機構２１２は複数のＢツリーを用いて実現される。複数のＢツリーは、ステートフルなファイルシステム操作の要求を処理する際に使用されるステート情報を記憶する。たとえば、複数のＢツリーは、要求元データ、ファイルデータ、およびロックデータを記憶してもよい。要求元データとは、ファイルシステム操作を発行するために登録された要求元を識別するデータである。ファイルデータとは、どの要求元によってどのファイルが開かれたかを識別するデータである。ロックデータとは、どのファイルに対するどのロックがどの要求元に付与されたかを識別するデータである。
【００４７】
一実施例では、複数のＢツリーは、「クライアントＢツリー」、「クライアント存在Ｂツリー」（client_exists B-tree）、「要求元Ｂツリー」、「オープンファイルＢツリー」（open_files B-tree）、「オープンＢツリー」（opens B-tree）、「ロック要求元Ｂツリー」（locks_requestor B-tree）、および「付与ロックＢツリー」（granted_locks B-tree）を含む。これらのＢツリーの各々はステート情報を記憶してもよく、以下により詳細に説明される。
【００４８】
この発明の他の実施例は、異なる１組のＢツリーを用いてルックアップ機構２１２を実現してもよい。たとえば、上述のいくつかのＢツリー、たとえばクライアント存在Ｂツリーが、他のＢツリーにも記憶された情報を記憶し、そのため、ルックアップ機構２１２の実現化例によっては、上述のＢツリーのすべてが必要とはならないかもしれない。しかしながら、同じまたは同様の情報を２つ以上のＢツリーに記憶することは有利であり得る。なぜなら、その情報は、第１の状況では第１の鍵を用いてより効率的にアクセスされるかもしれず、第２の状況では第２の鍵を用いてより効率的にアクセスされるかもしれないためである。
【００４９】
この発明の他の実施例では、ルックアップ機構２１２は、複数のＢツリーの代わりに複数のハッシュテーブルを用いて実現されてもよい。ルックアップ機構２１２を実現する複数のハッシュテーブルは、以下に述べるものと同様の情報を記憶する。ルックアップ機構２１２を実現するために、この発明の他の実施例によって他の機構が同様に採用されてもよい。
【００５０】
クライアントＢツリー
クライアントＢツリーとは、クライアントについての情報を保持するＢツリーである。フレームワーク２００に登録した各クライアント１１０は、クライアントＢツリー内のインデックスエントリに反映される。クライアント１１０は、以下により詳細に説明されるように、クライアント識別子を確立するようにとの要求を発行することによってフレームワーク２００に登録する。クライアントＢツリーの鍵は、データベースサーバによって以前にクライアントに割当てられたクライアント識別子である。クライアント識別子は、フレームワーク２００に登録されたある特定のクライアント１１０を一意的に識別する。クライアントＢツリーの各ノードは、クライアント識別子およびクライアント提供識別子、
たとえばクライアントのネットワークアドレスを含む、ある特定のクライアントについての情報を記憶する。
【００５１】
クライアント存在Ｂツリー
クライアントＢツリーと同様、クライアント存在Ｂツリーは、クライアントについての情報を保持する。クライアントＢツリーおよびクライアント存在Ｂツリーはともにクライアントについての情報を保持するが、クライアント存在Ｂツリーの鍵はクライアント提供識別子である。クライアント提供識別子は、たとえば、クライアントのネットワークアドレスであってもよい。
【００５２】
クライアント存在Ｂツリーは、ある特定のクライアント１１０がフレームワーク２００に登録したかどうかを、クライアント提供識別子に基づいて判断するために使用されてもよい。クライアント存在Ｂツリーの各インデックスエントリはまた、クライアント識別子およびクライアント提供識別子を含む、ある特定のクライアントについての情報を記憶する。
【００５３】
要求元Ｂツリー
要求元Ｂツリーとは、要求元についての情報を保持するＢツリーである。要求元Ｂツリーの鍵は、ある要求元に関連付けられたクライアント識別子と、その要求元を一意的に識別する要求元識別子との双方を反映している。要求元Ｂツリーは、ある特定のクライアント１１０に関連付けられたすべての要求元を判断するために使用されてもよく、それは、ファイルシステム操作「開く」の処理中に、または操作不能となったクライアントを回復させる際に必要とされてもよい。
【００５４】
要求元Ｂツリーの各インデックスエントリは、要求元についての情報を記憶する。たとえば、ある特定の要求元に対応している要求元Ｂツリーのインデックスエントリは、どのクライアントがその要求元に関連付けられているか、その要求元からの最後の通信はいつ受信されたか、その要求元はどのファイルを開いたか、およびどのステート情報がその要求元に関連付けられているかについての情報を記憶してもよい。
【００５５】
オープンファイルＢツリー
オープンファイルＢツリーとは、開かれたファイルについての情報を保持するＢツリーである。オープンファイルＢツリーの鍵は、ファイルのファイルハンドルである。オープンファイルＢツリーは、ある特定のファイルに対してファイルシステム操作を実行することが可能かどうかを判断するために使用されてもよい。オープンファイルＢツリーの各インデックスエントリは、開いたファイルについての情報を記憶してもよい。そのような情報は、たとえば、その開いたファイルに対するファイルベースのロックの数、その開いたファイルに対するファイルベースのロックのタイプ、その開いたファイルに関連付けられたステート情報をどの状態識別データが識別しているか、その開いたファイルのためのオブジェクト識別子を含んでいてもよい。
【００５６】
オープンＢツリー
オープンＢツリーとは、開かれたファイルについての情報を保持するＢツリーである。オープンＢツリーの鍵は状態識別データである。オープンＢツリーを横断することにより、オープンＢツリーの鍵として使用される状態識別データによって識別されるステート情報に関連付けられた開いたファイルについての情報を特定できる。
【００５７】
たとえば、あるクライアントがある特定のファイルを開いたと仮定されたい。そのクライアントのために保持されたステート情報は、そのクライアントがその特定のファイルを開いたことを示すであろう。そのステート情報は１組の状態識別データに割当てられる。
その状態識別データは、オープンＢツリーを横断してその特定のファイルが開いていることを示すインデックスエントリを見つけるために使用されてもよい。
【００５８】
オープンＢツリーの各インデックスエントリは、ある開いたファイルについての情報、たとえばその開いたファイルに関連付けられたステート情報を識別する状態識別データ、その開いたファイルを開いた要求元、そのファイルが読出用に開かれたかまたは書込用に開かれたか、その開いたファイルは修正されたか、およびその開いたファイルを開いた要求元以外の要求元に対して読出または書込が拒否されたか、といった情報を記憶する。
【００５９】
ファイルを開くために、状態識別データが、開いたファイルを識別するよう生成される。状態識別データは（ａ）ファイルを開くよう要求した要求元に送信され、（ｂ）そのファイルが開かれたことを反映するよう、オープンＢツリーにエントリを追加するために使用される。
【００６０】
ロック要求元Ｂツリー
ロック要求元Ｂツリーとは、ロック要求元についての情報を保持するＢツリーである。ロック要求元Ｂツリーの鍵は状態識別データである。ロックＢツリーの各インデックスエントリは、ロックの要求元についての情報、たとえばクライアント識別子、要求元識別子、およびロック所有者識別子を含む。ロック所有者識別子は、ロックを付与されたある特定の要求元を一意的に識別する。クライアント識別子および要求元識別子はフレームワーク２００によって割当てられ、ロック所有者識別子は要求元によって供給される。
【００６１】
付与ロックＢツリー
付与ロックＢツリーとは、付与されたロックについての情報を保持するＢツリーである。付与ロックＢツリーの鍵はファイルハンドルである。付与ロックＢツリーは、ある特定のファイルに対して付与されたファイルベースのロックがもしあれば、どのファイルベースのロックが付与されたかを迅速に判断するために使用されてもよい。
【００６２】
プロトコルインタプリタ２１０がリソースロッカ２２２に、ある特定のロックの付与を要求するファイルシステム操作を実行するよう命令する場合、リソースロッカ２２２は、ルックアップ機構２１２の１つ以上のＢツリーにアクセスしてもよい。例示のため、プロトコルインタプリタ２１０が、あるファイルに対するある特定のロックの付与を求める要求を受信し、その後、プロトコルインタプリタ２１０がリソースロッカ２２２にファイルシステム操作の処理を命令すると仮定されたい。リソースロッカ２２２は最初に、付与ロックＢツリーにアクセスすることにより、相反するロックが既にそのファイルに対して付与されたかどうかを判断してもよい。リソースロッカ２２２は、ファイルシステム操作によって識別されたファイルのファイルハンドルを用いて、付与ロックＢツリーを横断してもよい。付与ロックＢツリーにおけるあるエントリがそのファイルハンドルのために存在している場合、そのエントリの審査は、相反するロックが既にそのファイルに対して付与されたかどうかをリソースロッカ２２２に知らせる。
【００６３】
相反するロックがそのファイルに対してまだ付与されていないとリソースロッカ２２２が判断した場合、リソースロッカ２２２は（ａ）リソースの新しい状態を識別するために新しい状態識別データを生成し、（ｂ）要求されたロックの付与を反映するよう、付与ロックＢツリーにエントリを追加してもよい。リソースロッカ２２２は、リソースについて新たに生成された新しい状態識別データを用いて、付与ロックＢツリーに新しいエントリを追加し、その後、前の状態識別データによって参照されたロックＢツリーにおける前のエントリを削除してもよい。ロックＢツリーにおける新しいエントリは、リソースに対して実行されたすべての以前のステートフルな操作への参照を含んでおり、そのため、前の状態識別データによって参照されるエントリを記憶する必要はない。
【００６４】
フレームワークを用いたファイル操作処理
図３は、この発明の一実施例に従った、ファイルシステム操作を処理するためのステップを示すフローチャートである。図３のステップを実行することにより、ステートフルな操作、たとえばステートフルなＮＦＳ操作がＤＢＭＳ１２０によって実行されてもよい。
【００６５】
一般に、フレームワークは、フレームワークが実行する操作についてのステート情報を保持している。ステートフルな操作を実行する際、フレームワークは、操作の状態に対応している状態識別データを要求元に戻す。ステートフルな操作を求める次の要求において、要求元はその状態識別データをフレームワークに送り返す。そしてフレームワークは、次の要求における操作に当てはまるステート情報を識別する鍵として、その状態識別データを使用する。
【００６６】
フレームワークにより生成されたクライアント識別子の取得
図２を参照すると、まずステップ３１０で、要求元のためにクライアント識別子を確立するようにとの第１の要求が、データベースサーバにおいて受信される。ステップ３１０は、プロトコルインタプリタ２１０が、クライアント１１０により通信リンク１３０を通して送信された、第１の要求を含むパケットを受信することによって、実行されてもよい。
【００６７】
プロトコルインタプリタ２１０は、さまざまなパケットタイプのパケットを受信してもよい。プロトコルインタプリタ２１０は、受信されたパケットのパケットタイプを識別するよう構成されているが、各パケットタイプを読出すよう構成される必要はない。プロトコルインタプリタ２１０は、たとえばパケットのヘッダ内に含まれる情報を検査することによって、受信されたパケットのパケットタイプを判断してもよい。プロトコルインタプリタ２１０は、受信されたパケットのパケットタイプを一旦判断すると、そのパケットを、そのパケットタイプのパケットの読出を担当する構成要素に送信する。
【００６８】
説明のため、ステップ３１０で受信されたパケットは、要求元のためにクライアント識別子を確立するようにとの要求を含むＮＦＳパケットであると仮定されたい。クライアント識別子を確立することは、ＮＦＳ操作である。これらの状況下で、プロトコルインタプリタは、そのパケットを読出すためにそのパケットをＮＦＳパケットリーダ２２４に送信する。ＮＦＳパケットリーダ２２４は、そのパケットを読出して構文解析し、要求されたファイルシステム操作（すなわち、クライアント識別子の確立）を識別するデータをプロトコルインタプリタ２１０に送り返す。
【００６９】
ファイルシステム操作を識別するデータを受信した後で、プロトコルインタプリタ２１０はファイルシステム操作を処理する。この例では、プロトコルインタプリタ２１０は、クライアント識別子を確立するようにとの要求を処理する。要求を処理する一環として、プロトコルインタプリタ２１０は、（ａ）クライアント識別子が要求元のためにもう確立されたかどうか、および（ｂ）要求元のためにクライアント識別子がまだ確立されていない場合、どのクライアント識別子を要求元に関連付けるべきかを判断するために、たとえばルックアップ機構２１２に相談してもよい。
【００７０】
一実施例では、データベースサーバは、特定の要求元のためにクライアント識別子が確立されたかどうかを判断するために、クライアント提供識別子（たとえばクライアントのネットワークアドレス）に基づいてクライアント存在Ｂツリーを横断してもよい。要求元のためにクライアント識別子がまだ確立されていない場合、データベースサーバは、クライアントのためのクライアント識別子を生成してもよい。クライアントのためのクライアント識別子を生成した後で、データベースサーバは、要求元に割当てられた新しいクライ
アント識別子についての情報を記憶するために、クライアントＢツリーおよびクライアント存在Ｂツリーにインデックスエントリを追加してもよい。
【００７１】
ステップ３１０の実行後、処理はステップ３１２に進む。ステップ３１２で、上述のステップ３１０で確立されたクライアント識別子が要求元に送信される。ステップ３１２は、プロトコルインタプリタ２１０が、クライアント識別子を含む通信を通信リンク１３０を通して要求元に送信することにより、実行されてもよい。一実施例では、要求元は、クライアント識別子を検証するためにデータベースサーバ１２２と付加的な通信を交換することにより、受信されたクライアント識別子をデータベースサーバ１２２を用いて検証してもよい。ステップ３１２の実行後、処理はステップ３１４に進む。
【００７２】
複合要求の受信
ステップ３１４で、ファイルシステム操作を実行するようにとの第２の要求が受信される。ステップ３１４は、プロトコルインタプリタ２１０が、クライアント１１０により通信リンク１３０を通して送信された、第２の要求を含むパケットを受信することによって、実行されてもよい。第２の要求はクライアント識別子を含む。
【００７３】
複合要求の処理を例示するため、ステップ３１４で受信される第２の要求が、２つ以上のファイルシステム操作を含む複合要求であると仮定されたい。複合要求において特定されたファイルシステム操作は、フレームワーク２００によって順次処理される。
【００７４】
ステートフルなファイルシステム操作の要求の処理を例示するため、第２の要求において特定された第１のファイルシステム操作が、要求元によって以前に開かれたファイルに対するファイルベースのロックを求める要求であると仮定されたい。フレームワーク２００がファイルを開いた後で、フレームワーク２００は（ａ）その開かれたファイルに関連付けられたステート情報を識別する状態識別データを生成し、（ｂ）その状態識別データを要求元に送信する。このため、ステップ３１４で受信された要求が、開いたファイルに対してファイルシステム操作を実行するようにとの要求である場合、ステップ３１４で受信された要求は、以前に要求元に送信された状態識別データを含む。この例では、状態識別データにより、フレームワーク２００は、ファイルベースのロックを求める要求の対象であるファイルに関連付けられたステート情報を参照できるようになる。
【００７５】
ステップ３１４の要求がファイルシステム操作の要求を含むとプロトコルインタプリタ２１０が判断した後で、プロトコルインタプリタ２１２は、ステップ３１４の要求を含むパケットを、そのパケットを読出すためにＮＦＳパケットリーダ２２４に送信してもよい。その後、ＮＦＳパケットリーダ２２４は、第１の未処理のファイルシステム操作（以下、「現在の」ファイルシステム操作と呼ぶ）についての情報をプロトコルインタプリタ２１０に送信する。以下により詳細に説明されるように、現在のファイルシステム操作が処理された後で、フレームワーク２００は、そのパケットにおいて特定されたさらなる未処理のファイルシステム操作を処理する。
【００７６】
セッションへの要求の割当
複合要求において特定された現在のファイルシステム操作についての情報を、プロトコルインタプリタ２１０がＮＦＳパケットリーダ２２４から一旦受信すると、プロトコルインタプリタ２１０は、現在のファイルシステム操作をあるデータベースセッションに割当てる。割当てられたデータベースセッションは、データベースセッション群のプールから選択され得るものであり、複合要求内に含まれたファイルシステム操作をデータベースサーバが処理するセッションである。ステート情報はセッションとは別に保持されるため（上述のように、ステート情報はルックアップ機構２１２に保持される）、現在のファイルシステム操作をサービスするために、データベースセッション群のプールからどのセッシ
ョンが選択されてもよい。ステップ３１４の実行後、処理はステップ３１６に進む。
【００７７】
クライアントの認証
ステップ３１６で、ステップ３１４で受信された要求が、要求内に含まれるクライアント識別子によって識別されるクライアントによって発行されたかどうかについて、判断が下される。一実施例では、要求が受信されるたび、その要求は要求元の識別情報を確認するために認証される。ステップ３１６は、プロトコルインタプリタ２１０がオーソライザ２３２と通信して、オーソライザ２３２に要求を認証させることにより、実行されてもよい。オーソライザ２３２は、認証プロセスにおいて、要求内に含まれるクライアント識別子を使用してもよい。ステップ３１４で受信された要求をオーソライザ２３２が認証した後で、オーソライザ２３２は、認証プロセスの結果をプロトコルインタプリタ２１０に通信する。オーソライザ２３２は、ケルベロス、ＬＩＰＫＥＹ、およびＳＰＫＭ−３を含む標準認証ライブラリおよびプロトコルを用いて、要求元を認証してもよい。
【００７８】
ステップ３１４で受信された要求がオーソライザ２３２によって認証されない場合、プロトコルインタプリタ２１０は、（ステップ３１４で受信された）第２の要求を送信した要求元に通信を送信して、第２の要求が認証されなかったことを要求元に知らせる。第２の要求が一旦認証されると、処理はステップ３１８に進む。
【００７９】
要求された操作が許可されるかどうかの判断
ステップ３１８で、現在のファイルシステム操作を実行するのに十分な許可レベルを要求元が有しているかどうかについて、判断が下される。ステップ３１８は、プロトコルインタプリタ２１０が権限検証子２３０と通信して、現在のファイルシステム操作を実行するのに十分な許可レベルを要求元が有しているかどうかを権限検証子２３０に検証させることにより、実行されてもよい。
【００８０】
一実施例では、権限検証子２３０は、各要求元についてのアクセス制御リストを用いて、特定されたファイルシステム操作を実行するのに十分な許可レベルを要求元が有しているかどうかを判断する。権限検証子２３０は、各要求元についてのアクセス制御リストを保持している。各アクセス制御リストは、アクセス制御エントリ（ＡＣＥ）のリストを含む。各ＡＣＥは、要求元がある特定の権限を付与されているか、または拒否されているかを識別する。
【００８１】
例示のため、要求元１２３４が、権限Ａおよび権限Ｂを必要とするファイルシステム操作を実行するようにとの要求を発行したと仮定されたい。権限検証子２３０は、要求元１２３４についてのＡＣＥのリストを保持している。権限検証子２３０は、アクセス制御リストにおいて特定されたＡＣＥを処理する。要求元１２３４についてのアクセス制御リストが、要求元１２３４が許可Ａを付与されたことを示す第１のＡＣＥと、要求元１２３４が許可Ｂを付与されたことを示す第２のＡＣＥと、要求元１２３４が許可Ａを拒否されたことを示す第３のＡＣＥとを含む場合、権限検証子２３０は、要求されたファイルシステム操作を実行するのに十分な許可レベルを要求元１２３４が有していると判断する。なぜなら、権限検証子２３０は、判断を下すことができるようになるまで、アクセス制御リストのＡＣＥを順次処理するためである。このため、要求元１２３４についてのアクセス制御リストにおける第２のＡＣＥを権限検証子２３０が一旦読出すと、権限検証子２３０は、要求されたファイルシステム操作を行なうのに十分な許可レベルを要求元１２３４が有しているかどうかについての判断を下すことができ、権限検証子２３０はアクセス制御リストの残りを読出さない。ステップ３１８の実行後、処理はステップ３２０に進む。
【００８２】
適切なステート情報の場所特定
ステップ３２０で、現在のファイルシステム操作の実行がステート情報を必要とする場
合、第２の情報内に含まれる状態識別データに基づいて、適切なステート情報が検索される。状態識別データは、以前に要求元に割当てられ通信されたかもしれず、たとえば、要求元は以前にファイルを開いたかもしれず、またはファイルに対するロックを以前に付与されたかもしれない。要求が複合要求である場合、ステップ３２０で検索されるステート情報は、現在のファイルシステム操作に関連付けられてもよい。ステップ３２０は、プロトコルインタプリタ２１０がルックアップ機構２１２を用いてステート情報を検索することにより、実行されてもよい。ステップ３２０で検索されるステート情報は、現在のファイルシステム操作を実行するために必要な任意のステート情報を含む。ステップ３２０の処理後、処理はステップ３２２に進む。
【００８３】
要求されたファイルシステム操作の実行
ステップ３２２で、選択されたデータベースセッション内で、現在のファイルシステム操作が、適切なステート情報に基づいて処理される。一実施例では、ステップ３２２は、プロトコルインタプリタ２１０自体によって実行されてもよい。別の実施例では、プロトコルインタプリタ２１０はフレームワーク２００の他の構成要素と通信して、その他の構成要素に現在のファイルシステム操作を実行させてもよい。現在のファイルシステム操作が処理された後で、処理はステップ３２４に進む。
【００８４】
ステート情報の更新
ステップ３２２では、あるセッションにおいてファイルシステム操作が実行される。そのセッションによって使用される状態は、ファイルシステム操作の実行によって変わる。この例では、そのセッションの状態を表わすステート情報を、「更新されたステート情報」と呼ぶことにする。更新されたステート情報は、現在のファイルシステム操作の処理から生じた状態変更を反映している。たとえば、更新されたステート情報は、ファイルシステム操作の対象であるファイルが開かれたかどうか、およびファイルに対してロックが付与されたかどうかを反映している。このため、更新されたステート情報は、現在のファイルシステム操作がファイルに対して実行された後のファイルの現在の状態を反映している。
【００８５】
ステップ３２４で、ルックアップ機構２１２内に記憶された情報が、現在のファイルシステム操作に関連付けられた更新されたステート情報を反映するよう更新される。一実施例では、ルックアップ機構２１２を構成する１つ以上のＢツリーが、セッションの新しい状態を示すよう更新される。ルックアップ機構２１２を構成するＢツリーは、（ａ）更新されたステート情報を識別するために新しい状態識別データを生成し、（ｂ）更新されたステート情報を反映するよう、ルックアップ機構２１２の適切なＢツリーを更新するかまたは適切なＢツリーにエントリを追加することによって、更新されてもよい。
【００８６】
たとえば、ステップ３２２で、ステップ３２２で処理された現在のファイルシステム操作が、ある特定のファイルの最初の１００バイトに対してファイルベースのロックを実行する操作であったと仮定されたい。リソースロッカ２２２は最初に、付与ロックＢツリーにアクセスすることにより、相反するロックが既にそのファイルに対して付与されたかどうかを判断してもよい。リソースロッカ２２２は、現在のファイルシステム操作において識別されたファイルのファイルハンドルを用いて、付与ロックＢツリーを横断してもよい。付与ロックＢツリーにおけるあるエントリがそのファイルハンドルのために存在する場合、そのエントリの審査は、相反するロックが既にそのファイルに対して付与されたかどうかをリソースロッカ２２２に知らせる。
【００８７】
相反するロックがそのファイルに対してまだ付与されていないとリソースロッカ２２２が判断した場合、リソースロッカ２２２は（ａ）リソースの新しい状態を識別するために新しい状態識別データを生成し、（ｂ）要求されたロックの付与を反映するよう、付与ロ
ックＢツリーにエントリを追加する。すなわち、リソースロッカ２２２は、リソースについて新たに生成された新しい状態識別データを用いて、付与ロックＢツリーに新しいエントリを追加し、その後、前の状態識別データによって参照されたロックＢツリーにおける前のエントリを削除してもよい。付与ロックＢツリーにおける新しいエントリは、リソースに対して付与された任意の前のロックに加え、そのファイルの最初の１００バイトに付与されたファイルベースのロックへの参照を含んでおり、そのため、前の状態識別データによって参照されるエントリを記憶する必要はない。
【００８８】
ステップ３２４の実行後、処理はステップ３２６に進む。
複合要求において特定された操作の反復
各要求は、実行されるべき１つ以上のファイルシステム操作を特定する複合要求であるかもしれない。ステップ３２６で、ステップ３１４で受信された要求が複合要求であり、その複合要求において特定されたさらなる未処理のファイルシステム操作が存在する場合、処理はステップ３１８に進み、そこで、ステップ３１４の第２の要求において特定された次の未処理のファイルシステム操作が「現在のファイルシステム操作」になる。このように、複合要求において特定された各ファイルシステム操作は、フレームワーク２００によって順次処理される。
【００８９】
ステップ３１４の第２の要求において特定されたファイルシステム操作がすべて処理された後で、処理はステップ３２８に進む。
要求元への結果および改定された状態識別子の提供
ステップ３２８で、ステップ３１４の要求において特定されたファイルシステム操作をすべて実行した結果が、通信で要求元に送信される。この通信は、順調に実行されたファイルシステム操作の対象であったある特定のリソースに割当てられたステート情報を識別する任意の状態識別データを含んでいてもよい。ステップ３２８の実行は、プロトコルインタプリタ２１０が、複合要求の各ファイルシステム操作の処理結果を、ステートフルなファイルシステム操作の実行に応答して生成された任意の状態識別データとともに要求元に送信することにより、実行されてもよい。たとえば、要求元が以前に開いたファイル上のある特定の範囲のバイトに対して読出−書込ロックが付与されることを要求元が要求した場合、プロトコルインタプリタ２１０は、リソースの新しい状態を識別する新しい状態識別データを含む通信、すなわち、ある特定のファイル上のある特定の範囲のバイトに対して読出−書込ロックが付与されたという通信を要求元に送信することにより、ステップ３２８を実行してもよい。なお、新しい状態識別情報は、ステートレスなファイルシステム操作の順調な処理に応答してではなく、ステートフルなファイルシステム操作の順調な処理に応答して、要求元に送信される。
【００９０】
ＮＦＳプロトコルでは、複合要求において特定された多数のファイルシステム操作の処理結果が、単一の通信で要求元に送信されてもよい。このため、ステップ３２８で要求元に送信される状態識別データは、複合要求において特定された順調に実行されたステートフルな各ファイルシステム操作についての状態識別情報を含む通信により、単一の通信で送信されてもよい。
【００９１】
フレームワーク２００が複合要求におけるある特定のファイルシステム操作を処理できない場合、単一の通信が要求元に送信される。この通信は、（ａ）処理されたその複合要求において特定されたファイルシステム操作の処理の、任意の新しい状態識別情報を含む結果と、（ｂ）どのファイルシステム操作が実行できなかったかを示す情報とを記述する情報を含んでいる。
【００９２】
フレームワークを用いたステートレスなトランザクションの処理
フレームワーク２００はまた、ステートレスな要求、たとえばステートレスなファイル
システム操作、またはステートレスなプロトコルに準拠する要求も処理してもよい。プロトコルインタプリタ２１０がステートレスな要求を含むパケットを受信すると、プロトコルインタプリタ２１０は、そのパケットを読出して構文解析するために、そのパケットをある構成要素に送信してもよい。たとえば、プロトコルインタプリタ２１０は、ＦＴＰ要求を含むパケットをＦＴＰパケットリーダ２２６に送信し、プロトコルインタプリタ２１０は、ＨＴＴＰ要求を含むパケットをＨＴＴＰパケットリーダ２２８に送信する。
【００９３】
ステートレスな要求を読出して構文解析した後で、ＦＴＰパケットリーダ２２６およびＨＴＴＰパケットリーダ２２８は、そのステートレスな要求を識別する情報をプロトコルインタプリタ２１０に送信する。プロトコルインタプリタ２１０は次に、そのステートレスな要求を実行してもよく、または、そのステートレスな要求を実行するためにフレームワーク２１０の別の構成要素と通信してもよく、たとえば、リソースをロックするためにリソースロッカ２２２が必要とされてもよい。その要求はステートレスなものであるため、その要求が一旦順調に実行されれば、ステート情報をその要求に割当てる必要はない。
【００９４】
ファイルシステム操作とデータベーストランザクションとの関係
クライアントがファイルへの書込を希望する場合、クライアントはファイルシステム操作「開く」、次に多数の書込ファイルシステム操作、そして次にファイルシステム操作「閉じる」の実行を要求してもよい。この章の目的のため、単一のファイルシステム操作とは、ファイルシステム操作「開く」に始まり、対応するファイルシステム操作「閉じる」に至る多数のＮＦＳ操作を指す。単一のファイルシステム操作を実行するために、データベースサーバ１２２は、１つ以上のデータベーストランザクションが実行されるようにすることを要求され得る。これら１つ以上のデータベーストランザクションの各々がコミットされてから、そのファイルシステム操作が実行される。このため、ある特定のデータベーストランザクションによってデータベース１２４に加えられた変更がコミットされてから、ファイルシステム操作の実行がうまくいくかどうかが分かるようになる。
【００９５】
このため、次の数章において以下により詳細に説明するように、リソースの閲覧を希望する要求元は、（ａ）任意のコミット済みのデータベーストランザクションを現在反映しているリソースのバージョンか、または（ｂ）完了したファイルシステム操作のみを反映し、まだ完了していないファイルシステム操作に対応しているコミット済みのデータベーストランザクションを全く反映していないリソースのバージョンのいずれかの閲覧を期待してもよい。
【００９６】
コミット済みの開いた変更
要求元は、同じリソースに対して「開く」および「閉じる」コマンドを個々に発行してもよい。このため、「閉じる」コマンドが１つの要求元に関してファイルを閉じたとしても、そのファイルがすべての要求元に関してまだ閉じられていない場合がある。「最終クローズ」という用語は、ファイルがすべての要求元に関して閉じられることをもたらすファイルシステム操作「閉じる」を指す。このため、１つ以上の要求元によって現在開かれているどのリソースも、そのリソースに対して実行された最終クローズをまだ有していない。
【００９７】
ファイルの状態を各々変更する多数のデータベーストランザクションが、ファイルが開かれた時点と最終クローズの時点との間で実行されてもよい。ファイルに対して実行された変更は、そのファイルに対する最終クローズが実行される前にコミットされてもよい。（１）データベースにおいてコミットされたものの、（２）最終クローズをまだ有していないファイルに関与する変更を、ここに「コミット済みの開いた変更」（open-committed
changes）と呼ぶ。
【００９８】
一貫性のないクライアント
リソースに対して最終クローズが実行されておらず、要求元がそのリソースを取得するようにとの要求を送信した場合、要求元が受信すべきリソースの状態は、要求元に関連付けられたクライアントのタイプに依存する。「一貫性のない（inconsistent）クライアント」とは、リソースの「現在の状態」の閲覧を期待するクライアントである。この文脈では、リソースの現在の状態は、リソースに加えられた任意のコミット済みの開いた変更を含むが、リソースに加えられたコミットされていない変更は全く含まない。
【００９９】
たとえば、あるリソースが最初に開かれた後、データベースによりコミットされた２つのトランザクションがそのリソースの状態を変更し、そのリソースに対して最終クローズがまだ実行されていない場合、そのリソースに対する要求を発行する一貫性のないクライアントは、その２つのデータベーストランザクションによって加えられた変更を反映しているリソースの状態の閲覧を期待する。ＮＦＳ、ＦＴＰまたはＨＴＴＰプロトコルを用いてＤＢＭＳ１２０にアクセスするクライアントは、一貫性のないクライアントの一例である。一貫性のないクライアントに関連付けられた要求元は、一貫性のない要求元、すなわち、リソースの現在の状態の閲覧を期待する要求元である。
【０１００】
一貫性のあるクライアント
一貫性のある（consistent）クライアントとは、コミット済みの開いた変更を見ることを全く許可されていないクライアントである。むしろ、一貫性のあるクライアントは、あるリソースに加えられたコミット済みの変更のみを、（ａ）そのリソースが開かれたもののまだ閉じられていない場合には、そのリソースが開かれる前に、または（ｂ）そのリソースに対して最終クローズが実行された後のいずれかにおいて見る。たとえば、あるリソースが開かれたものの、最終クローズがそのリソースに対してまだ実行されていないと仮定されたい。そのリソースへのアクセスを要求する一貫性のあるクライアントは、「開く」操作の実行直前のリソースの状態の閲覧を期待する。
【０１０１】
このため、あるリソースが開かれた後、コミット済みの２つのデータベーストランザクションがそのリソースの状態を変更し、最終クローズがまだ実行されていない場合、そのリソースに対する要求を発行する一貫性のあるクライアントは、その２つのトランザクションによって加えられた変更を反映していないリソースの状態の閲覧を期待する。説明を簡単にするために、一貫性のあるクライアントによって見られるはずのリソースの状態を、リソースの「コミット済みの閉じた」（closed-committed）バージョンと呼ぶことにする。
【０１０２】
ＳＱＬプロトコルを用いてＤＢＭＳ１２０にアクセスするクライアントは、一貫性のあるクライアントの一例である。一貫性のあるクライアントに関連付けられたどの要求元も、一貫性のある要求元であり、すなわち、この要求元は、コミット済みの閉じられた状態におけるリソースの状態の閲覧を期待する。
【０１０３】
さらなる例示のため、以下のファイルシステム操作および時点は以下の順序で起こる。
（１）  時点ｔ１
（２）  要求元１がファイルｆ１を開く
（３）  要求元１がファイルｆ１への変更をコミットする
（４）  時点ｔ２
（５）  要求元２がファイルｆ１を開く
（６）  要求元２がファイルｆ１への変更をコミットする
（７）  時点ｔ３
（８）  要求元１がファイルｆ１を閉じる
（９）  時点ｔ４
（１０）  要求元２がファイルｆ１を閉じる
（１１）  時点ｔ５
時点ｔ３では、ファイルｆ１の一貫性のあるバージョンは時点ｔ１でのファイルであり、そのファイルの一貫性のないバージョンは時点ｔ３でのファイルである。時点ｔ４では、ファイルｆ１の一貫性のあるバージョンは時点ｔ１でのファイルであり、そのファイルの一貫性のないバージョンは時点ｔ４でのファイルである。時点ｔ５では、ファイルｆ１の一貫性のあるバージョンは時点ｔ５でのファイルであり、そのファイルの一貫性のないバージョンは時点ｔ５でのファイルである。一貫性のあるクライアントはリソースの前の状態の閲覧を期待するので、その状態は、リソースに対して最終クローズが実行されるまで保存されなければならない。
【０１０４】
コミット済みの閉じたバージョンの再構築
フレームワーク２００が一貫性のある要求元および一貫性のない要求元をサポートするために、フレームワーク２００は、異なるタイプのロック、すなわちデータベースロックとファイルベースのロックとを採用している。データベースロックとは、データベース操作の実行に応答して取得されるロックであり、そのデータベース操作が順調に完了する（コミットされる）と解除される。ファイルベースのロックとは、ファイルシステム操作「開く」の実行に応答して取得されるロックであり、ファイルベースのロックは、ファイルシステム操作「閉じる」が実行されると解除される。
【０１０５】
図４は、この発明の一実施例に従った、データベースロックおよびファイルベースのロックを用いる機能的ステップを示すフローチャートである。ステップ４１０で、要求元は、ある特定のリソースに関与する操作を要求する。ステップ４１０は、クライアント１１０が通信リンク１３０を通してデータベースサーバ１２２に要求を送信することにより、実行されてもよい。ステップ４１０の実行後、処理はステップ４１２に進む。
【０１０６】
ステップ４１２で、要求元の要求元タイプについての判断が下される。ステップ４１２はデータベースサーバ１２２によって実行されてもよい。要求元タイプに基づき、データベースサーバ１２２は、その特定のリソースのどのバージョンを要求元に送信すべきかを判断する。要求元が一貫性のない要求元である場合、データベースサーバ１２２は、その特定のリソースの現在のバージョンを送信する。しかしながら、要求元が一貫性のある要求元である場合、データベースサーバ１２２は、その特定のリソースの古めのバージョン、すなわち、そのリソースのコミット済みの閉じたバージョンを送信する。
【０１０７】
要求元タイプの判断は、要求が準拠するプロトコルのタイプに基づいて実行されてもよい。要求がＳＱＬプロトコルに準拠する場合、要求元は一貫性のある要求元である。しかしながら、要求がＮＦＳ、ＦＴＰまたはＨＴＴＰプロトコルに準拠する場合、要求元は一貫性のない要求元である。ステップ４１２の実行後、処理はステップ４１４に進む。
【０１０８】
ステップ４１４で、要求された操作を実行するために、その特定のリソースに対する第１のロックが取得される。第１のロックは、第１のタイプのロック、たとえばファイルベースのロックである。ステップ４１４の実行後、処理はステップ４１６に進む。
【０１０９】
ステップ４１６で、要求された操作によって必要とされる各データベース操作を実行するために、第２のロックが取得される。第２のロックは、第２のタイプのロック、たとえばデータベースロックである。
【０１１０】
一実施例では、ある特定のリソースの状態を変更する任意のデータベース操作を実行する前に、そのリソースの一時コピーがデータベース１２４に記憶される。その特定のリソースに対してファイルベースのロックが付与された場合、その特定のリソースへの変更は
、実際のリソース自体というよりもむしろリソースの一時コピーにおいて反映される。リソースのオリジナルバージョンは修正されないままであるため、オリジナルバージョンは、一貫性のある要求元にサービスを提供する際にデータベースサーバ１２２によって使用されてもよい。データベースサーバ１２２は、一貫性のない要求元にサービスを提供する際にリソースの一時コピーを使用してもよい。なぜなら、一時コピーは、コミット済みのデータベース操作によってリソースに加えられた変更すべてを反映しているためである。ステップ４１６の実行後、処理はステップ４１８に進む。
【０１１１】
ステップ４１８で、データベースロックが、対応するデータベース操作の順調な完了に応答して解除される。あるデータベースシステムによって操作が実行される場合、そのデータベースシステムは、操作を実行するために使用されるトランザクションをコミットし、操作中に修正されたすべてのリソースに対して保たれるデータベースロックを解除する。要求された操作によって必要とされたすべてのデータベース操作の実行後、処理はステップ４２０に進む。
【０１１２】
ステップ４２０で、ファイルベースのロックが、ファイルシステム操作の順調な完了に応答して解除される。すなわち、リソースに対して最終クローズが実行されると、そのリソースに対するファイルベースのロックが解除され、そのリソースの一時コピーがそのリソースの現在のバージョンとして確立されてもよい。一時コピーは、たとえば、オリジナルコピーの上に一時コピーをコピーし、次に一時コピーを削除することによって、現在のバージョンとして確立されてもよい。
【０１１３】
ファイルシステム操作が実行された後では、リソースの一貫性のないバージョンと、リソースのコミット済みの閉じたバージョンとは同じである。したがって、一貫性のある要求元および一貫性のない要求元はともに、リソースが再度開かれるまで、リソースのオリジナルバージョンを用いてサービスを提供されてもよい。
【０１１４】
図４のステップを実行することにより、ファイルベースのロックおよびデータベースロックは、データベースサーバ１２２が一貫性のある要求元および一貫性のない要求元の双方にサービスを提供できるようにするよう、使用されてもよい。あるリソースに対してファイルベースのロックが保持されている場合、ファイルシステム操作「開く」の実行前のリソースの状態が保持されており、このため、データベースサーバ１２２が一貫性のある要求元にサービスを提供できるようになる。
【０１１５】
並行アクセスの管理
ファイルベースのロックの使用は、多数の要求元が同じリソースに関与する操作を実行している場合に、同等に有利である。たとえば、多数の要求元が各々、同じファイルに対してファイルシステム操作を実行するようにとの要求を発行するかもしれない。２つ以上の要求元がファイルを開くかもしれず、２つ以上の要求元がリソースの状態に変更を加えるかもしれない。
【０１１６】
例示のため、第１の要求元があるファイルを開き、そのファイルに変更を加えたと仮定されたい。第２の要求元が、同じファイルのあるバージョンについての要求をデータベースサーバ１２２に送信すると、データベースサーバ１２２は、第２の要求元の要求元タイプを判断する。第２の要求元が一貫性のある要求元である場合、データベースサーバ１２２は、そのファイルが開かれた後で第１の要求元によりそのファイルに加えられた変更を全く反映していないそのファイルのバージョンを提供する。第２の要求元が一貫性のない要求元である場合、データベースサーバ１２２は、そのファイルが開かれた後で第１の要求元によりそのファイルに加えられた変更を反映しているそのファイルのバージョンを提供する。
【０１１７】
リソースがファイルベースのロックの対象である場合にデータベースサーバがどのようにしてそのリソースの状態を維持するかについてのさらなる情報を、以下に「トランザクション意味論の実行」と題された章で説明する。
【０１１８】
トランザクション意味論の実行
リソースが一旦、ファイルシステム操作「開く」の対象となると、リソースの前のバージョンについての情報を保持することが有利である理由は多数ある。まず、上述のように、リソースが一旦、ファイルシステム操作「開く」の対象となったものの、最終クローズの対象にはなっていない場合に、リソースの前のバージョンを保持することは、データベースサーバ１２２が、一貫性のある要求元からのリソースについての要求に応えることを可能にする。第２に、リソースの前のバージョンを保持することは、データベースサーバがリソースを前のバージョンに復帰させることを可能にする。リソースを前のバージョンに復帰させることは、さまざまな状況において、たとえば（ａ）要求元がリソースの正しくないバージョンを作成した場合、（ｂ）要求元がスキーマとは互換性がないスキーマベースのリソースのバージョンを作成した場合、または（ｃ）多数の要求元によってリソースに対して実行された変更が互いに互換性がない場合などに、必要かもしれない。
【０１１９】
重大なことに、リソースを前の状態に復帰させるためにリソースから除去される必要がある変更は、コミット済みの変更を含み得る。したがって、コミットされていないトランザクションによって加えられた変更を除去するためにデータベースシステムによって使用される従来のアンドゥ機構は、必要な復帰を実行するのに十分ではない。
【０１２０】
この発明の実施例は、リソースの状態を前の状態から変更したコミット済みのデータベーストランザクションが実行された場合でも、そのリソースが前の状態に復帰されることを有利に可能にする。この発明の一実施例によれば、コミット済みのデータベーストランザクションにより、１つ以上の変更がリソースに加えられる。コミット済みのデータベーストランザクションがリソースの状態を変更した後で、コミット済みのデータベーストランザクションによって加えられた変更の前の状態にリソースを復帰させるようにとの要求が受信される。たとえば、クライアント１１０は、ある特定のファイルを、ある特定の時点より前の状態、たとえばそのファイルのコミット済みの閉じたバージョンに復帰させるようにとの要求を、データベースサーバ１２２に発行してもよい。
【０１２１】
その要求の受信に応答して、リソースは、特定の時点、たとえばファイルが開かれた時点より前の状態に復帰される。リソースを復帰させる際、リソースの現在の状態は、コミット済みのデータベーストランザクションによってファイルに加えられた変更を反映するのをやめる。次の章において、リソースを前の状態に復帰させるための手法をより詳細に説明する。
【０１２２】
リソース復帰手法
リソースをある特定の時点より前の状態に復帰させるために、さまざまな手法が使用されてもよい。使用される特定の手法は、たとえば、リソースがスキーマベースのリソースであるか、または非スキーマベースのリソースであるかに依存し得る。スキーマベースのリソースとは、ある定義されたスキーマに準拠するリソースである。たとえば、所与のスキーマに準拠している発注書類は、スキーマベースのリソースの一例である。非スキーマベースのリソースとは、スキーマベースのリソースではないリソースである。
【０１２３】
分解された形でのリソースの記憶
スキーマベースのリソースは、リソース全体をまとめて記憶することにより、たとえばＸＭＬ文書をデータベーステーブルのロブ列に記憶することにより、構築された形で記憶
されてもよい。また、これに代えて、スキーマベースのリソースを構成する要素を別個に記憶することにより、スキーマベースのリソースを分解された形で記憶することが有利であり得る。たとえば、ＸＭＬ文書の個々のＸＭＬタグおよびそれらの関連付けられたデータを記述するデータが、データベーステーブルのある列に記憶されてもよい。スキーマベースのリソースの要素は別個に記憶されるため、スキーマベースのリソースが読出される前に、スキーマベースのリソースの要素を再構築する必要があり得る。
【０１２４】
図５は、スキーマベースのリソースを分解された形で記憶するための機構を示すリソーステーブルを示している。図５のテーブルは参照列５０４を含む。スキーマベースのリソースを記述するデータは、リソーステーブルに記憶されてもよく、またはリソーステーブルによって参照されてもよい。たとえば、リソーステーブルの参照列５０４は、スキーマベースのリソースに関するデータが記憶されている別のテーブル、すなわちＸＭＬタイプテーブル５１０を識別するポインタ５０６を含む。ＸＭＬタイプテーブル５１０はそれ自体が、スキーマベースのリソースの他のデータ要素を記憶する１つ以上の他のテーブルを参照してもよい。たとえば、ＸＭＬタイプテーブル５１０は、入れ子状テーブル５２０への参照５１２を有して図示されている。
【０１２５】
ＸＭＬタイプテーブル５１０および任意の入れ子状テーブル５０２は、スキーマベースのリソースの要素についてのデータを記憶する。要求元がスキーマベースのリソースの最初の１００バイトを読出を希望する場合、そのリソースは、その要求に応えるよう再構築されなければならない。なぜなら、ＸＭＬタイプテーブル５１０は、スキーマベースのリソースの各データ要素がどのバイトに現れるかを記述する情報を記憶していないためである。したがって、スキーマベースのリソースからデータが読出される場合、そのスキーマベースのリソースは再構築されてＸＭＬロブ列５０２に記憶されなければならない。要求元がスキーマベースのリソースの最初の１００バイトの読出を希望する場合、そのような要求は、データベースサーバ１２２によって、ＸＭＬロブ列５０２に記憶された再構築されたリソースの最初の１００バイトを読出すことにより、容易に実行され得る。
【０１２６】
以下により詳細に説明されるように、ＸＭＬタイプテーブル５１０および任意の入れ子状テーブル５２０に記憶されたリソースの分解された要素をそのまま残した状態で、ＸＭＬロブ列５０２に記憶されたリソースの再構築されたコピーに対して次の操作が実行されてもよい。
【０１２７】
スキーマベースのリソースの復帰
一実施例によれば、スキーマベースのリソースは「前のバージョン情報」に基づいて復帰される。図５は、この発明の一実施例に従った、スキーマベースのリソースのために前のバージョン情報を記憶するシステムのブロック図である。前のバージョン情報は、ＸＭＬタイプテーブル５１０および任意の入れ子状テーブル５２０に保持されてもよく、一方、スキーマベースのリソースに対して最終クローズが実行されるまで、スキーマベースのリソースに加えられた変更が、ＸＭＬロブ列５０２に記憶されたリソースの再構築されたコピーに対して実行されてもよい。
【０１２８】
この発明の一実施例では、リソースの状態を変更し得るデータベース操作の実行直前にファイルベースのロックがリソースに対して付与されると、スキーマベースのリソースの構築されたコピーが作成される。たとえば、スキーマベースのリソースの構築されたコピーは作成されてＸＭＬロブ列５０２に記憶されてもよい。
【０１２９】
その後、リソースの構築されたコピー（ＸＭＬロブ列５０２に記憶されたリソースのコピー）は、リソースの現在のバージョンとして扱われ、データベース操作によって必要とされる変更が、リソースの構築されたコピー（ＸＭＬロブ列５０２に記憶されたリソース
のコピー）に加えられる。実際には、ＸＭＬロブ列５０２におけるリソースのコピーは、リソースのダーティ・バージョン（dirty version）のキャッシュとなる。なお、スキーマベースのリソースの分解されたバージョンは、依然としてＸＭＬタイプテーブル５１０に保持されている。
【０１３０】
スキーマベースのリソースを、そのリソースの分解されたコピーに復帰させるために、ＸＭＬロブ列５０２に記憶されたリソースのコピーが削除される。その後、ＸＭＬタイプテーブル５１０に記憶された構築されたコピーの代わりに、ＸＭＬタイプテーブル５１０および任意の入れ子状テーブル５２０に記憶されたリソースの分解されたバージョンが、リソースの現在のバージョンとして扱われる。
【０１３１】
ファイルシステム操作「閉じる」がリソースに対して実行されると、ＸＭＬロブ列５０２に記憶されたリソースの構築されたコピーを反映するよう、ＸＭＬタイプテーブル５１０および任意の入れ子状テーブル５２０に記憶されたリソースの分解されたバージョンを変更することにより、ＸＭＬタイプテーブル５１０に記憶されたリソースの分解されたコピーに加えられた変更が永続的になり得る。
【０１３２】
非スキーマベースのリソースの復帰のためのスナップショットタイムの使用
図６Ａおよび図６Ｂは、この発明の実施例に従った、非スキーマベースのリソースのために前のバージョン情報を記憶するブロック図である。図６Ａおよび図６Ｂは、非スキーマベースのリソースのために前のバージョン情報を記憶するための３つの異なるアプローチを説明するために使用される。
【０１３３】
第１のアプローチによれば、図６Ａに示すように、リソーステーブル６００がＬＯＢ列６０２に非スキーマベースのリソースを記憶する。このアプローチでは、そのリソースに対してファイルシステム操作「開く」が実行されると、リソーステーブル６００の列６０４にスナップショットタイムが記憶される。このスナップショットタイムは、リソースに対してファイルシステム操作「開く」が実行される直前の論理的時点を示す。
【０１３４】
１つ以上のデータベーストランザクションがリソースへの変更をコミットした後で、それらのデータベーストランザクションは「アンドゥ」されていないかもしれないが、リソースは、スナップショットタイム以降にリソースに関連付けられたアンドゥ情報を用いて、スナップショットタイムでの状態に復帰されるかもしれない。アンドゥ情報とは、実行されたもののまだコミットされてないデータベーストランザクションを「ロールバック」するかまたはアンドゥするために使用され得る、ＤＢＭＳ１２０によって保持される情報を指す。
【０１３５】
スナップショットタイムおよびアンドゥ情報は、１組の変更をリソースに加えて、スナップショットタイムでのリソースの状態を反映するようリソースの状態を変更するために使用される。リソースが一旦、スナップショットタイムでのリソースの状態を反映するように復帰されると、スナップショットタイムは、リソーステーブル６００の列６０４から除去される。
【０１３６】
一実施例では、１組の変更をリソースに加えて、スナップショットタイムでのリソースの状態を反映するようリソースの状態を変更するために、「フラッシュバッククエリー」が使用されてもよい。フラッシュバッククエリーを実行するための手法は、その全体がここに十分に述べられているかのように引用により援用されている、２００３年４月３０日出願の米国特許出願第１０／４２７，５１１号「フラッシュバックデータベース」（Flashback Database）に記載されている。
【０１３７】
非スキーマベースのリソースの復帰のためのキャッシュ列の使用
第２のアプローチによれば、図６Ｂに示すように、リソーステーブル６５０がＬＯＢ列６５２に非スキーマベースのリソースを記憶する。このアプローチでは、そのリソースに対してファイルシステム操作「開く」が実行されると、そのリソースのコピーがリソーステーブル６５０の列６５４に記憶される。列６５４は「キャッシュ列」として使用される。すなわち、列６５４に記憶されたリソースのコピーは、リソースの現在のバージョンとして扱われる。データベーストランザクションがリソースへの変更を行なうと、その変更は、列６５２に記憶されたオリジナルリソースにではなく、列６５４に記憶されたリソースのコピーに加えられる。
【０１３８】
リソースに対してファイルシステム操作「閉じる」が実行される場合、６５４に記憶されたリソースのコピーは列６５２に記憶されてもよく、そのため、オリジナルリソースは、コミット済みのデータベース操作によってリソースに加えられたあらゆる変更を反映する。ファイルシステム操作「閉じる」が実行されるまで、列６５２に記憶されたリソースの現在の値は、ファイルシステム操作「開く」の実行直前のリソースの状態を反映している。したがって、ファイルシステム操作「閉じる」の実行直前のリソースの状態にリソースを復帰させることが必要である場合、加える必要があるリソーステーブル６５０への唯一の変更は、列６５４に記憶されたリソースのコピーを除去することである。最終クローズがリソースに対して実行される前に、一貫性のない要求元は、列６５４におけるリソースのコピーを閲覧してもよく、一貫性のある要求元は、列６５２に記憶されたリソースを閲覧してもよい。
【０１３９】
ハイブリッドアプローチ
ストレージ空間制約により、ある時点よりも古いアンドゥ情報は通常、より新しいアンドゥ情報によって上書きされる。したがって、復帰を実行するためにスナップショットタイムを使用すること（すなわち第１のアプローチ）は、必ずしも実行可能ではない。しかしながら、アンドゥ情報が利用可能である場合、スナップショットタイムに基づいた復帰が、キャッシュ列復帰（すなわち第２の復帰）よりも好ましい場合がある。
【０１４０】
したがって、第３の（ハイブリッド）アプローチでは、リソースの復帰が必要とされ得る時点においてリソースについてのアンドゥ情報が利用可能ではないかもしれないとデータベースサーバ１２２が判断しない限り、上述のスナップショットベースのアプローチが実行される。リソースの復帰が必要とされ得る時点においてリソースについてのアンドゥ情報が利用可能ではないかもしれないとデータベースサーバ１２２が判断した場合、上述のキャッシュ列アプローチが実行される。
【０１４１】
データベースサーバ１２２は、データベースサーバ１２２によってアンドゥ情報が保持される時間量が設定可能な時間量よりも少ない場合に、リソースの復帰が必要とされ得る時点においてリソースについてのアンドゥ情報が利用可能ではないかもしれないと判断してもよい。
【０１４２】
一貫性チェック
一実施例によれば、修正されたファイル閉じられた時点で、そのファイルの一貫性がチェックされ、保留中のファイルシステム操作「開く」はもう残っていない。たとえば、スキーマベースのリソースは、それがスキーマの規則に準拠していることを確認するためにチェックされてもよい。スキーマベースのリソースが対応するスキーマに準拠していない場合、リソースは、それが開かれた時点でのリソースの状態に復帰されてもよい。
【０１４３】
上述のように、リソースが付与されたファイルベースのロックの対象であり、リソースを前の状態に復帰させるようにとの要求を要求元が発行している場合、またはリソースが
一貫性チェックに合格していない場合、リソースは上述のように前の状態に復帰されてもよい。ファイルベースのロックについてのさらなる詳細および利点を、以下に提示する。
【０１４４】
ファイルベースのロック
ファイルベースのロックは、データベースサーバ１２２が、データベース１２４に保持されたファイルに対してファイルシステム操作を実行することを可能にする。リソースロッカ２２２は、データベース１２４に記憶されたリソースに対するファイルシステムロックを管理してもよい。ファイルベースのロックの挙動は、ＨＴＴＰといったステートレスなプロトコルのために使用される他のロックと比べ、３つの重要な点において異なっている。
【０１４５】
第１に、ファイルベースのロックは、リソース全体に対してではなく、リソースの一部に対して付与され得る。特に、ファイルベースのロックは、リソース上のある範囲のバイトに対して付与され得る。このため、単一のファイルが多数のファイルベースのロックの対象となる場合があり、その場合、ファイルベースのロックは各々、そのファイルの異なるバイト範囲をカバーする。
【０１４６】
第２に、ファイルベースのロックはリースベースであり、すなわち、ある特定のファイルベースのロックが一旦、要求元に付与されると、その特定のロックは第１の期間の間付与され、その満了後、その特定のロックは失効する。しかしながら、要求元によって受信されたどの通信も、その特定のロックを第２の期間の間に更新する。このため、ファイルシステムロックが失効する前に要求元がデータベースサーバ１２２と通信する限り、要求元はファイルベースのロックを絶えず更新し得る。
【０１４７】
ある特定のファイルシステムロックが一旦失効すると、ルックアップ機構２１２は、その特定のロックがもはや付与されていないことを反映するよう更新される。要求元によって要求された各ロックが依然として有効であることを確認するために、ルックアップ機構２１２内に保持されたデータは定期的にチェックされてもよい。
【０１４８】
ある特定の要求元が、以前に付与された別のロックと相反するロックを要求している場合、以前に付与されたロックが依然として有効であることを確認するために、以前に付与されたロックがチェックされてもよい。以前に付与されたロックがもはや有効ではない場合、ルックアップ機構２１２に記憶された情報は、ロックが無効であることを反映するよう更新される（たとえば、ロックについての情報が消去されてもよい）。また、ある特定のクライアントが失効した場合、その特定のクライアントに付与されたロックはすべて解除される。一実施例では、クライアントが最後にフレームワーク２００と通信してから設定可能な時間量が経過した後で、クライアントは失効してもよい。このため、以前に付与されたロックが、付与を要求されているロックと相反する場合、以前に付与されたロックに関連付けられたクライアントは、そのクライアントが依然として有効であることを検証するためにチェックされてもよい。クライアントが有効ではない場合、以前に付与されたロックは解除され、付与を要求されているロックが実行されてもよい。一実施例では、ある特定のクライアントが失効したかどうかの判断は、クライアントＢツリーをチェックすることによって実行されてもよい。
【０１４９】
ステートレスなプロトコルのロックに対する、ファイルベースのロックの第３の相違点は、読出アクセスのみを提供するファイルベースのロックがないことである。代わりに、ファイルベースのロックが読出アクセスを付与する範囲で、ファイルベースのロックは読出−書込アクセスも付与する。
【０１５０】
この発明の一実施例では、ファイルベースのロックは、リソース全体をカバーする第１
の組と、リソースの一部、たとえばリソースのある範囲のバイトをカバーする第２の組とを含む。図７は、この発明の一実施例に従った、さまざまなタイプのファイルベースのロック、およびそれらの互換性を示す表である。図７に示すさまざまなファイルベースのロックの各々を、以下に簡単に説明する。
【０１５１】
ファイルベースのバイト読出−書込ロック（byte-read-write file-based lock）とは、リソースの一部に対するロックである。ファイルベースのバイト読出−書込ロックは、リソース上のある範囲のバイトへの読出および書込アクセスを付与するために使用されてもよい。
【０１５２】
ファイルベースのバイト書込ロック（byte-write file-based lock）とは、リソースの一部に対するロックである。ファイルベースのバイト書込ロックは、リソース上のある範囲のバイトへの書込アクセスを付与するために使用されてもよい。
【０１５３】
ファイルベースの読出拒否ロック（deny-read file-based lock）とは、リソース全体に対するロックである。ファイルベースの読出拒否ロックは、読出拒否ロックを付与されたもの以外のあらゆる要求元に対し、リソースへの読出アクセスを拒否するために使用されてもよい。
【０１５４】
ファイルベースの書込拒否ロック（deny-write file-based lock）とは、リソース全体に対するロックである。ファイルベースの書込拒否ロックは、書込拒否ロックを付与されたもの以外のあらゆる要求元に対し、リソースへの書込アクセスを拒否するために使用されてもよい。
【０１５５】
ファイルベースのロックは、ロック共有ロックまたはロック排他ロック、たとえばＷｅｂＤＡＶロックとは互換性がない。図７は、さまざまなファイルベースのロックの互換性を示している。ある特定のファイルベースのロックが以前に付与された別のロックと互換性がない場合、そのファイルベースのロックは付与されない。このため、バイト読出−書込ロックの範囲とバイト書込ロックの範囲とが相反しない場合、バイト書込ロックが既に付与されたリソースに対してバイト読出−書込ロックが付与されてもよい。しかしながら、バイト書込ロックが既に付与されたリソースに対して読出拒否ロックを付与することは不可能である。
【０１５６】
リアルアプリケーションクラスタにおけるファイルベースのロック
データベース１２２は、リアルアプリケーションクラスタ（ＲＡＣ）で、たとえばオラクル・コーポレイション（Oracle Corporation）のＲＡＣ１０ｇオプションを用いて実現されてもよい。ＲＡＣ環境では、あるリソースに対してファイルベースのロックが付与されると、どのデータベースサーバがそのリソースに対してそのファイルベースのロックを付与したかを記述するデータが、データベース１２４に記憶されなければならない。
【０１５７】
たとえば、データベースに記憶されたリソースは、（ａ）そのリソースにファイルベースのロックが付与されたことを示すフラグと、（ｂ）そのリソースにそのファイルベースのロックを付与したデータベースサーバを識別する情報とに関連付けられてもよい。ルックアップ機構２１２は、付与されたファイルベースのロックについてのデータをメモリ内に保持する。ＲＡＣインスタンスにおいて、付与されたファイルベースのロックに関する情報が他のノードに見えることになっている場合、メモリ内に記憶された情報は永続的に記憶されなければならず、または、データ一貫性を保つ態様でＲＡＣの他のノードに移送可能でなければならない。ルックアップ機構２１２に記憶された情報が、それが存在するデータベースサーバ以外のＲＡＣの他のデータベースサーバには見えない場合、第１のデータベースサーバによって付与されたどのファイルベースのロックも、第２のデータベー
スサーバのファイルベースのロックと相反し得る。
【０１５８】
データベースサーバ１２２によって採用された上述のファイルベースのロックは、データベースサーバ１２２が、データベース１２４によって保持されたファイルに対してステートフルな要求、たとえば要求されたＮＦＳ操作を処理することを可能にする。したがって、データベース１２２が上述のファイルシステム操作ロックを採用しているため、クライアント１１０は、データ一貫性を保存する態様で、ＮＦＳプロトコルを用いて、データベース１２４に記憶されたファイルにアクセスしてもよい。
【０１５９】
機構の実現
一実施例によれば、クライアント１１０、データベースサーバ１２２，およびデータゲース１２４は各々、コンピュータシステム上で実現されてもよい。図８は、この発明の一実施例が実施され得るコンピュータシステム８００を示すブロック図である。コンピュータシステム８００は、情報を通信するためのバス８０２または他の通信機構と、情報を処理するためにバス８０２と結合されたプロセッサ８０４とを含む。コンピュータシステム８００はまた、プロセッサ８０４により実行されるべき命令および情報を記憶するためにバス８０２に結合された、ランダムアクセスメモリ（ＲＡＭ）または他のダイナミック記憶装置といったメインメモリ８０６も含む。メインメモリ８０６は、プロセッサ８０４により実行されるべき命令の実行中に一時的な変数または他の中間情報を記憶するためにも使用されてもよい。コンピュータシステム８００はさらに、プロセッサ８０４用の命令およびスタティック情報を記憶するためにバス８０２に結合された読出専用メモリ（ＲＯＭ）８０８または他のスタティック記憶装置を含む。磁気ディスクまたは光ディスクといった記憶装置８１０が、情報および命令を記憶するために提供され、バス８０２に結合されている。
【０１６０】
コンピュータシステム８００は、情報をコンピュータユーザに表示するためのブラウン管（ＣＲＴ）などのディスプレイ８１２に、バス８０２を介して結合されていてもよい。英数字キーおよび他のキーを含む入力装置８１４が、情報およびコマンド選択をプロセッサ８０４に通信するためにバス８０２に結合されている。別のタイプのユーザ入力装置は、方向情報およびコマンド選択をプロセッサ８０４に通信するための、および、ディスプレイ８１２上のカーソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キーといったカーソル制御８１６である。この入力装置は通常、２つの軸、つまり第１の軸（たとえばｘ）および第２の軸（たとえばｙ）において２つの自由度を有しており、それによりこの装置は平面における場所を特定することができる。
【０１６１】
この発明は、ここに説明された手法を実施するためのコンピュータシステム８００の使用に関する。この発明の一実施例によれば、それらの手法は、メインメモリ８０６に含まれる１つ以上の命令の１つ以上のシーケンスをプロセッサ８０４が実行するのに応答して、コンピュータシステム８００により実行される。そのような命令は、記憶装置８１０などの別のマシン読取り可能な媒体からメインメモリ８０６に読込まれてもよい。メインメモリ８０６に含まれる命令のシーケンスの実行により、プロセッサ８０４は、ここに説明されたプロセスステップを行なうようになる。代替的な実施例では、この発明を実施するために、ソフトウェア命令の代わりに、またはソフトウェア命令と組合わせて、配線接続回路が使用されてもよい。このため、この発明の実施例は、ハードウェア回路とソフトウェアとのどの特定の組合せにも限定されない。
【０１６２】
ここで使用されているような用語「マシン読取り可能な媒体」とは、マシンを特定のやり方で動作させるデータを提供することに関与するあらゆる媒体を指す。コンピュータシステム８００を用いて実現される一実施例では、さまざまなマシン読取り可能な媒体が、たとえば、実行のためのプロセッサ８０４への命令の提供に関与する。そのような媒体は
、不揮発性媒体、揮発性媒体、および通信媒体を含むもののそれらに限定されない多くの形態を取り得る。不揮発性媒体はたとえば、記憶装置８１０といった光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ８０６といったダイナミックメモリを含む。通信媒体は、バス８０２を構成する配線を含む、同軸ケーブル、銅線および光ファイバを含む。通信媒体はまた、電波および赤外線データ通信中に発生するものといった音波または光波の形も取り得る。
【０１６３】
マシン読取り可能な媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または任意の他の磁気媒体、ＣＤ−ＲＯＭ、任意の他の光媒体、パンチカード、紙テープ、孔のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップまたはカートリッジ、以下に説明するような搬送波、または、コンピュータがそこから読取り可能な任意の他の媒体を含む。
【０１６４】
さまざまな形態のマシン読取り可能な媒体は、プロセッサ８０４への１つ以上の命令の１つ以上のシーケンスを実行のために保持することに関与していてもよい。たとえば、命令はまず、遠隔コンピュータの磁気ディスク上に保持されていてもよい。遠隔コンピュータは命令をそのダイナミックメモリにロードし、モデムを用いて電話回線を通して命令を送信することができる。コンピュータシステム８００にとってローカルなモデムは、電話回線上のデータを受信し、赤外線送信機を用いてデータを赤外線信号に変換することができる。赤外線検出器は、赤外線信号で搬送されたデータを受信でき、適切な回路が、データをバス８０２上に配置できる。バス８０２はデータをメインメモリ８０６に搬送し、そこからプロセッサ８０４が命令を検索して実行する。メインメモリ８０６によって受信された命令は、プロセッサ８０４による実行の前または後のいずれかで、記憶装置８１０上に随意に記憶されてもよい。
【０１６５】
コンピュータシステム８００はまた、バス８０２に結合された通信インターフェイス８１８も含む。通信インターフェイス８１８は、ローカルネットワーク８２２に接続されたネットワークリンク８２０に双方向データ通信結合を提供する。たとえば、通信インターフェイス８１８は、データ通信接続を対応する種類の電話回線に提供するデジタル相互サービス網（ＩＳＤＮ）カード、またはモデムであってもよい。別の例として、通信インターフェイス８１８は、データ通信接続を互換性があるＬＡＮに提供するローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクも実現され得る。そのようなどの実現化例でも、通信インターフェイス８１８は、さまざまな種類の情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送受信する。
【０１６６】
ネットワークリンク８２０は通常、１つ以上のネットワークを介して、他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク８２０は、ローカルネットワーク８２２を介して、ホストコンピュータ８２４に、またはインターネットサービスプロバイダ（ＩＳＰ）８２６により運営されるデータ装置に、接続を提供してもよい。ＩＳＰ８２６は次に、現在一般に「インターネット」８２８と呼ばれている全世界的パケットデータ通信ネットワークを介して、データ通信サービスを提供する。ローカルネットワーク８２２およびインターネット８２８は双方とも、デジタルデータストリームを搬送する電気信号、電磁信号または光信号を使用する。コンピュータシステム８００との間でデジタルデータを搬送する、さまざまなネットワークを通る信号、ネットワークリンク８２０上の信号、および通信インターフェイス８１８を通る信号は、情報を運ぶ搬送波の例示的な形態である。
【０１６７】
コンピュータシステム８００は、ネットワーク、ネットワークリンク８２０および通信インターフェイス８１８を介して、メッセージを送信し、プログラムコードを含むデータ
を受信する。インターネットの例では、サーバ８３０は、アプリケーションプログラム用の要求されたコードを、インターネット８２８、ＩＳＰ８２６、ローカルネットワーク８２２、および通信インターフェイス８１８を介して送信してもよい。
【０１６８】
受信されたコードは、それが受信された際にプロセッサ８０４により実行されてもよく、および／または、後の実行用に記憶装置８１０または他の不揮発性ストレージに記憶されてもよい。このように、コンピュータシステム８００は、搬送波の形をしたアプリケーションコードを取得し得る。
【０１６９】
前述の明細書において、この発明の実施例が、実現化例により異なり得る多数の特定の詳細を参照して説明されてきた。このため、発明が何であるか、および出願人らによって何が発明であると意図されているかを唯一排他的に示すものは、本願から生じる１組の請求項であり、それは、そのような請求項が生じる特定の形を取り、その後のあらゆる訂正を含む。そのような請求項に含まれた用語についてここに明示的に述べたいかなる定義も、請求項で用いられているようなそのような用語の意味を支配する。このため、請求項に明示的に述べられていない限定、要素、特性、特徴、利点、または属性は、そのような請求項の範囲を全く限定しない。したがって、明細書および図面は、限定的な意味というよりもむしろ例示的な意味において考慮されるべきである。
【図面の簡単な説明】
【０１７０】
【図１】この発明の一実施例に従った、ステートフルなプロトコルで実現される要求を処理可能なシステムの高レベル図のブロック図である。
【図２】この発明の一実施例に従ったデータベースサーバの機能的構成要素のブロック図である。
【図３】この発明の一実施例に従った、ファイル操作を処理する機能的ステップを示すフローチャートである。
【図４】この発明の一実施例に従った、データベースロックおよびファイルシステム操作ロックを用いる機能的ステップを示すフローチャートである。
【図５】この発明の一実施例に従った、スキーマベースのリソースのために前のバージョン情報を記憶するブロック図である。
【図６Ａ】この発明の一実施例に従った、非スキーマベースのリソースのために前のバージョン情報を記憶するブロック図である。
【図６Ｂ】この発明の一実施例に従った、非スキーマベースのリソースのために前のバージョン情報を記憶するブロック図である。
【図７】この発明の一実施例に従った、さまざまなタイプのファイルシステム操作ロック、およびそれらの互換性を示す表である。
【図８】この発明の一実施例が実現され得るコンピュータシステムを示すブロック図である。
【図１】
2008524694.tif 000003
【図２】
2008524694.tif 000004
【図３】
2008524694.tif 000005
【図４】
2008524694.tif 000006
【図５】
2008524694.tif 000007
【図６Ａ】
2008524694.tif 000008
【図６Ｂ】
2008524694.tif 000009
【図７】
2008524694.tif 000010
【図８】
2008524694.tif 000011
【手続補正書】
【提出日】平成18年10月13日(2006.10.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マシンにより実現される方法であって、
データベースサーバにおいて、前記データベースサーバによって管理されるファイルの一部に対してファイル操作を実行するようにとの要求を受信するステップを備え、前記一部は前記ファイル全体よりも小さく、前記方法はさらに、
前記要求を受信する前記ステップに応答して、データベースサーバが、前記ファイル操作に関与する前記ファイルの前記一部のみをカバーするロックを付与し、それにより、ファイルの別の部分に対して並行操作が実行されることを可能にするステップと、
データベースサーバが、前記ファイルの前記一部に対して前記ファイル操作を実行するステップとを備える、方法。
【請求項２】
前記操作は前記ファイルのある範囲のバイト内に該当する情報に関与し、付与される前記ロックは前記範囲のバイトに対応している、請求項１に記載の方法。
【請求項３】
前記ロックは要求元に付与され、前記ロックは、前記要求元以外のあらゆるエンティティに対し、前記ファイルの前記一部への読出アクセスを拒否する、請求項１に記載の方法。
【請求項４】
前記ロックは要求元に付与され、前記ロックは、前記要求元以外のあらゆるエンティティに対し、前記ファイルの前記一部への書込アクセスを拒否する、請求項１に記載の方法。
【請求項５】
前記ロックは、前記ファイル上のある範囲のバイトへの読出および書込アクセスを付与する、請求項１に記載の方法。
【請求項６】
前記ロックは第１のロックであり、前記一部は第１の部分であり、前記方法はさらに、
要求元から、前記ファイルの第２の部分に対する第２のロックを必要とする第２の要求を受信するステップと、
前記データベースサーバが前記ファイルに対して前記第１のロックを付与したために前記第２の要求が実行されないことを、前記要求元に知らせるステップとを備える、請求項１に記載の方法。
【請求項７】
マシンにより実現される方法であって、
データベースサーバにおいて、ある特定のロックの付与を必要とする操作を実行するようにとの要求をエンティティから受信するステップと、
データベースサーバがエンティティに、ある特定された期間の間、特定のロックを付与するステップと、
予め定められた期間の間、前記エンティティから通信が受信されなかった場合、特定のロックを解除するようにとの要求をエンティティから受信することなく、特定のロックを自動的に解除するステップとを備える、方法。
【請求項８】
前記特定のロックは、前記エンティティ以外のあらゆる要求元に対し、リソースへの読出アクセスを拒否する、請求項７に記載の方法。
【請求項９】
前記特定のロックは、前記エンティティ以外のあらゆる要求元に対し、リソースへの書込アクセスを拒否する、請求項７に記載の方法。
【請求項１０】
前記特定のロックは、前記エンティティに、リソース上のある範囲のバイトへの読出および書込アクセスを付与する、請求項１に記載の方法。
【請求項１１】
前記特定のロックは、前記エンティティに、リソース上のある範囲のバイトへの書込アクセスを付与する、請求項１に記載の方法。
【請求項１２】
前記ロックを付与する前記ステップは、Ｂツリーにエントリを追加するステップを備え、前記エントリは、前記ファイル操作に関与する前記ファイルの前記一部を識別する情報を記憶する、請求項１に記載の方法。
【請求項１３】
前記ロックを付与する前記ステップは、Ｂツリーにエントリを追加するステップを備え、前記エントリは、前記ファイル操作を要求した要求元を識別する情報を記憶する、請求項１に記載の方法。
【請求項１４】
前記ロックを付与する前記ステップは、前記ファイル操作の実行を防ぐ第２のロックが前記ファイルの前記一部に対して付与されていたかどうかを判断するために、Ｂツリーにアクセスするステップを備える、請求項１に記載の方法。
【請求項１５】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１６】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項２に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１７】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項３に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１８】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項４に記載
の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項１９】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項５に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２０】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項６に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２１】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項７に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２２】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項８に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２３】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項９に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２４】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１０に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２５】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１１に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２６】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１２に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２７】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１３に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【請求項２８】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１４に記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【手続補正書】
【提出日】平成20年3月26日(2008.3.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マシンにより実現される方法であって、
データベースサーバにおいて、前記データベースサーバによって管理されるファイルの一部に対してファイル操作を実行するようにとの要求を受信するステップを備え、前記一部は前記ファイル全体よりも小さく、前記方法はさらに、
前記要求を受信する前記ステップに応答して、データベースサーバが、前記ファイル操作に関与する前記ファイルの前記一部のみをカバーするロックを付与し、それにより、ファイルの別の部分に対して並行操作が実行されることを可能にするステップと、
データベースサーバが、前記ファイルの前記一部に対して前記ファイル操作を実行するステップとを備える、方法。
【請求項２】
前記操作は前記ファイルのある範囲のバイト内に該当する情報に関与し、付与される前記ロックは前記範囲のバイトに対応している、請求項１に記載の方法。
【請求項３】
前記ロックは要求元に付与され、前記ロックは、前記要求元以外のあらゆるエンティティに対し、前記ファイルの前記一部への読出アクセスを拒否する、請求項１に記載の方法。
【請求項４】
前記ロックは要求元に付与され、前記ロックは、前記要求元以外のあらゆるエンティティに対し、前記ファイルの前記一部への書込アクセスを拒否する、請求項１に記載の方法。
【請求項５】
前記ロックは、前記ファイル上のある範囲のバイトへの読出および書込アクセスを付与する、請求項１に記載の方法。
【請求項６】
前記ロックは第１のロックであり、前記一部は第１の部分であり、前記方法はさらに、
要求元から、前記ファイルの第２の部分に対する第２のロックを必要とする第２の要求を受信するステップと、
前記データベースサーバが前記ファイルに対して前記第１のロックを付与したために前記第２の要求が実行されないことを、前記要求元に知らせるステップとを備える、請求項
１に記載の方法。
【請求項７】
マシンにより実現される方法であって、
データベースサーバにおいて、ある特定のロックの付与を必要とする操作を実行するようにとの要求をエンティティから受信するステップと、
データベースサーバがエンティティに、ある特定された期間の間、特定のロックを付与するステップと、
予め定められた期間の間、前記エンティティから通信が受信されなかった場合、特定のロックを解除するようにとの要求をエンティティから受信することなく、特定のロックを自動的に解除するステップとを備える、方法。
【請求項８】
前記特定のロックは、前記エンティティ以外のあらゆる要求元に対し、リソースへの読出アクセスを拒否する、請求項７に記載の方法。
【請求項９】
前記特定のロックは、前記エンティティ以外のあらゆる要求元に対し、リソースへの書込アクセスを拒否する、請求項７に記載の方法。
【請求項１０】
前記特定のロックは、前記エンティティに、リソース上のある範囲のバイトへの読出および書込アクセスを付与する、請求項１に記載の方法。
【請求項１１】
前記特定のロックは、前記エンティティに、リソース上のある範囲のバイトへの書込アクセスを付与する、請求項１に記載の方法。
【請求項１２】
前記ロックを付与する前記ステップは、Ｂツリーにエントリを追加するステップを備え、前記エントリは、前記ファイル操作に関与する前記ファイルの前記一部を識別する情報を記憶する、請求項１に記載の方法。
【請求項１３】
前記ロックを付与する前記ステップは、Ｂツリーにエントリを追加するステップを備え、前記エントリは、前記ファイル操作を要求した要求元を識別する情報を記憶する、請求項１に記載の方法。
【請求項１４】
前記ロックを付与する前記ステップは、前記ファイル操作の実行を防ぐ第２のロックが前記ファイルの前記一部に対して付与されていたかどうかを判断するために、Ｂツリーにアクセスするステップを備える、請求項１に記載の方法。
【請求項１５】
１つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１から１４のいずれかに記載の方法を実行させる命令の１つ以上のシーケンスを保持する、コンピュータ読取り可能な媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００３１
【補正方法】変更
【補正の内容】
【００３１】
ＨＴＴＰパケットリーダ２２８は、ＨＴＴＰ要求を含むパケットを読出して構文解析することが可能な任意のソフトウェアまたはハードウェア構成要素を用いて実現されてもよい。ＨＴＴＰパケットリーダ２２８は、ＨＴＴＰパケット内に含まれるＨＴＴＰ操作情報を読出して構文解析し、その後、処理のためにＨＴＴＰ操作情報をプロトコルインタープリタ２１０に通信するよう構成されている。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００６６
【補正方法】変更
【補正の内容】
【００６６】
フレームワークにより生成されたクライアント識別子の取得
図３を参照すると、まずステップ３１０で、要求元のためにクライアント識別子を確立するようにとの第１の要求が、データベースサーバにおいて受信される。ステップ３１０は、プロトコルインタプリタ２１０が、クライアント１１０により通信リンク１３０を通して送信された、第１の要求を含むパケットを受信することによって、実行されてもよい。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００７５
【補正方法】変更
【補正の内容】
【００７５】
ステップ３１４の要求がファイルシステム操作の要求を含むとプロトコルインタプリタ２１０が判断した後で、プロトコルインタプリタ２１０は、ステップ３１４の要求を含むパケットを、そのパケットを読出すためにＮＦＳパケットリーダ２２４に送信してもよい。その後、ＮＦＳパケットリーダ２２４は、第１の未処理のファイルシステム操作（以下、「現在の」ファイルシステム操作と呼ぶ）についての情報をプロトコルインタプリタ２１０に送信する。以下により詳細に説明されるように、現在のファイルシステム操作が処理された後で、フレームワーク２００は、そのパケットにおいて特定されたさらなる未処理のファイルシステム操作を処理する。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００９３
【補正方法】変更
【補正の内容】
【００９３】
ステートレスな要求を読出して構文解析した後で、ＦＴＰパケットリーダ２２６およびＨＴＴＰパケットリーダ２２８は、そのステートレスな要求を識別する情報をプロトコルインタプリタ２１０に送信する。プロトコルインタプリタ２１０は次に、そのステートレスな要求を実行してもよく、または、そのステートレスな要求を実行するためにフレームワーク２００の別の構成要素と通信してもよく、たとえば、リソースをロックするためにリソースロッカ２２２が必要とされてもよい。その要求はステートレスなものであるため、その要求が一旦順調に実行されれば、ステート情報をその要求に割当てる必要はない。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０１０３
【補正方法】変更
【補正の内容】
【０１０３】
さらなる例示のため、以下のファイルシステム操作および時点は以下の順序で起こる。
（１）  時点ｔ１
（２）  要求元１がファイルｆ１を開く
（３）  要求元１がファイルｆ１への変更をコミットする
（４）  時点ｔ２
（５）  要求元２がファイルｆ１を開く
（６）  要求元２がファイルｆ１への変更をコミットする
（７）  時点ｔ３
（８）  要求元１がファイルｆ１を閉じる
（９）  時点ｔ４
（１０）  要求元２がファイルｆ１を閉じる
（１１）  時点ｔ５
時点ｔ３では、ファイルｆ１の一貫性のあるバージョンは時点ｔ１でのファイルであり、そのファイルの一貫性のないバージョンは時点ｔ３でのファイルである。時点ｔ４では、ファイルｆ１の一貫性のあるバージョンは時点ｔ１でのファイルであり、そのファイルの一貫性のないバージョンは時点ｔ４でのファイルである。時点ｔ５では、ファイルｆ１の一貫性のあるバージョンは時点ｔ１でのファイルであり、そのファイルの一貫性のないバージョンは時点ｔ５でのファイルである。一貫性のあるクライアントはリソースの前の状態の閲覧を期待するので、その状態は、リソースに対して最終クローズが実行されるまで保存されなければならない。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】０１２５
【補正方法】変更
【補正の内容】
【０１２５】
ＸＭＬタイプテーブル５１０および任意の入れ子状テーブル５２０は、スキーマベースのリソースの要素についてのデータを記憶する。要求元がスキーマベースのリソースの最初の１００バイトを読出を希望する場合、そのリソースは、その要求に応えるよう再構築されなければならない。なぜなら、ＸＭＬタイプテーブル５１０は、スキーマベースのリソースの各データ要素がどのバイトに現れるかを記述する情報を記憶していないためである。したがって、スキーマベースのリソースからデータが読出される場合、そのスキーマベースのリソースは再構築されてＸＭＬロブ列５０２に記憶されなければならない。要求元がスキーマベースのリソースの最初の１００バイトの読出を希望する場合、そのような要求は、データベースサーバ１２２によって、ＸＭＬロブ列５０２に記憶された再構築されたリソースの最初の１００バイトを読出すことにより、容易に実行され得る。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】０１５６
【補正方法】変更
【補正の内容】
【０１５６】
リアルアプリケーションクラスタにおけるファイルベースのロック
データベース１２４は、リアルアプリケーションクラスタ（ＲＡＣ）で、たとえばオラクル・コーポレイション（Oracle Corporation）のＲＡＣ１０ｇオプションを用いて実現されてもよい。ＲＡＣ環境では、あるリソースに対してファイルベースのロックが付与されると、どのデータベースサーバがそのリソースに対してそのファイルベースのロックを付与したかを記述するデータが、データベース１２４に記憶されなければならない。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】０１５８
【補正方法】変更
【補正の内容】
【０１５８】
データベースサーバ１２２によって採用された上述のファイルベースのロックは、データベースサーバ１２２が、データベース１２４によって保持されたファイルに対してステ
ートフルな要求、たとえば要求されたＮＦＳ操作を処理することを可能にする。したがって、データベース１２２が上述のファイルシステム操作ロックを採用しているため、クライアント１１０は、データ一貫性を保存する態様で、ＮＦＳプロトコルを用いて、データベースサーバ１２２に記憶されたファイルにアクセスしてもよい。
【国際調査報告】
2008524694.tif 000012
2008524694.tif 000013
2008524694.tif 000014