(57)【要約】  ロッキングメカニズムが管理するリソースに対して予測的変更を行なうための方法およびシステムが提供される。リソースを修正するリソース要求許可を修正することを欲するエンティティ（たとえばデータベースシステムにおけるトランザクション）がある。しかしながら、許可を受取る前に、それらはリソースのプライベートバージョンに対して予測的変更を行なう。これらのエンティティは、変更を行なう許可を受取るまで、これらの予測的変更を確定するのを妨げられる。許可を受ける前に変更を行い得るとともに他の動作に進み得るので、許可を受取る際の遅延がそれらの性能に与える悪影響はより少なくなる。
2009526324.tif 000002
【特許請求の範囲】
【請求項１】
特定のリソースに関係する変更を行なう許可を求める要求を送るステップと、
前記許可を受取る前に、前記変更が確定するのを妨げつつ前記変更を行なうステップと、
前記変更を行なった後、前記変更を行なう許可を受取るステップと、
前記変更を行なう許可を受取った後、前記変更が確定するのを妨げるのを中止するステップとを含む、機械実行される方法。
【請求項２】
前記変更はトランザクションのある部分として行なわれ、前記変更が確定するのを妨げつつ前記変更を行なうステップは、
特定のリソースのプライベートコピーに対して前記変更を行なうステップと、
トランザクションがコミットするのを妨げるステップとを含む、請求項１に記載の方法。
【請求項３】
トランザクションがまだ許可されていない変更を行なったかどうかを示す追跡情報を維持するステップと、
追跡情報がトランザクションがまだ許可されていない変更を行なったことを示す限り、トランザクションがコミットするのを妨げるステップとをさらに含む、請求項２に記載の方法。
【請求項４】
前記変更を行なう許可を求める要求はリクエスタからリソースのマスタに送られ、
前記方法はさらに、
マスタが（ａ）リソースに対する現在付与されているロックのいずれかがリソースを修正する許可を付与するかどうか、および（ｂ）保留状態のロック要求のいずれかがリソースを修正する許可を求める要求であるかどうかを判断するステップと、
リソースに対する現在付与されているロックがリソースを修正する許可を付与せず、かつ保留状態のロック要求がリソースを修正する許可を求める要求でないという判断に応答して、マスタはリクエスタに開始メッセージを送るステップとを含み、
リクエスタは開始メッセージの受取に応答して変更を行なう、請求項１に記載の方法。
【請求項５】
リソースに対する現在付与されているロックがリソースを修正する許可を付与せず、かつ保留状態のロック要求がリソースを修正する許可を求める要求でないという判断に応答して、マスタは、修正する許可を求める要求をリソースについての保留状態のロック要求のキューの先頭に置くステップをさらに含む、請求項４に記載の方法。
【請求項６】
前記変更を行なう許可を求める要求はリクエスタからリソースのマスタに送られ、
リクエスタが要求を送るとき、リクエスタはリソースに対する共有ロックを保持するとともにリソースの現在のバージョンのプライベートコピーを有し、
前記変更を行なうステップは、リソースの現在のバージョンのプライベートコピーに対して変更を行なうステップを含む、請求項１に記載の方法。
【請求項７】
前記変更を行なう許可を求める要求はリクエスタからリソースのマスタに送られ、
リクエスタが要求を送るとき、別の処理がリソースに対する排他ロックを保持し、
前記変更を行なうステップは、
プロキシバッファに対して変更を行なうステップと、
リクエスタがリソースの現在のバージョンのコピーを受取ると、プロキシバッファからリソースの現在のバージョンのコピーに変更をマージするステップとを含む、請求項１に記載の方法。
【請求項８】
プロキシバッファに対して変更を行なうことに応答して、リドゥーを生成するステップをさらに含む、請求項７に記載の方法。
【請求項９】
前記変更は、制約違反について検査することなしにプロキシバッファに対して行なわれ、
制約違反について検査した後でのみ、変更は現在のバージョンのコピーにマージされる、請求項７に記載の方法。
【請求項１０】
前記変更を行なう許可を求める要求はリクエスタからリソースのマスタに送られ、
リクエスタが要求を送るとき、リクエスタはリソースに対する共有ロックを保持しないが、１つ以上の他の処理のセットがリソースに対する共有ロックを保持し、
前記方法はさらに、前記処理のセットのある処理にリソースのカレントコピーをリクエスタへ送らせるステップを含む、請求項１に記載の方法。
【請求項１１】
開始メッセージの受取に応答して、リクエスタは変更を行ない、
前記方法はさらに、前記処理のセットの前記処理に、リソースのカレントコピーとともに前記開始メッセージを含ませるステップを含む、請求項１０に記載の方法。
【請求項１２】
開始メッセージの受取に応答して、リクエスタは変更を行ない、
前記方法はさらに、リソースのマスタに開始メッセージをリクエスタへ送らせるステップを含む、請求項１０に記載の方法。
【請求項１３】
リクエスタから要求をリソースのマスタで受取るステップを含み、要求はリソースを修正する許可を求めるものであり、さらに、
リソースを修正する許可をマスタがリクエスタに付与するのを１つ以上の現在付与されているロックが妨げている間、マスタは、ユーザがリソースに対して予測的変更を行なうことを許すが当該変更が確定するのを禁止する開始メッセージをリクエスタに受取らせるステップと、
リソースを修正する許可をマスタがリクエスタに付与するのを現在付与されているロックが妨げない場合、マスタは、リクエスタが変更を確定するのを許すロック付与メッセージをリクエスタに送るステップとを含む、機械実行される方法。
【請求項１４】
以前に受取られた、リソースについての他のロック要求の前で、要求キューの先頭に要求をマスタに置かせるステップをさらに含む、請求項１３に記載の方法。
【請求項１５】
前記要求を受取ると、マスタは付与されたまたは要求されたロックのいずれかがリソースを修正する許可を付与するロックであるかどうか判断するステップと、
付与されたまたは要求されたロックがリソースを修正する許可を付与するロックではないとの判断に応答して、マスタが開始メッセージをリクエスタに受取らせるステップとをさらに含む、請求項１３に記載の方法。
【請求項１６】
リクエスタはリソースに対する共有ロックを保持し、
マスタは開始メッセージをリクエスタに送ることにより、リクエスタに開始メッセージを受取らせる、請求項１３に記載の方法。
【請求項１７】
リクエスタはリソースに対する共有ロックを保持せず、
マスタは、リソースに対する共有ロックを保持する処理に（ａ）リクエスタへのリソースのカレントコピーと（ｂ）開始メッセージとを、リクエスタへ送らせることにより開始メッセージをリクエスタに受取らせる、請求項１３に記載の方法。
【請求項１８】
実行されると、１つ以上のプロセッサに請求項１〜請求項１７のいずれか１つに記載の方法を行なわせる命令を記憶する、コンピュータ読取可能媒体。
【請求項１９】
１つ以上のプロセッサと、当該１つ以上のプロセッサによって実行されると、コンピュータシステムに請求項１〜請求項１７のいずれか１つに記載の方法を行なわせる命令を含むメモリとを含む、コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
この発明はコンピュータシステム内でのリソースに対するアクセスを制御するためのメカニズムに関する。
【背景技術】
【０００２】
背景
コンピュータは、コンピュータプログラムの実行の間、メモリ、モデム、およびプリンタのようなリソースを用いる。このようなリソースの多くは、任意の所与のコンピュータプログラムによって周期的にしか用いられない。たとえば、ワードプロセッシングアプリケーションが文書を印刷するのにプリンタを必要とする時間量は典型的には、ワードプロセッシングアプリケーションが文書を作成するのに用いられる時間量に対して少ない。このプリンタにアクセスする唯一の処理が単一のワードプロセッシングアプリケーションならば、プリンタは殆どの時間、アイドル状態のままであろう。
【発明の開示】
【課題を解決するための手段】
【０００３】
リソースを完全に活用するよう、多くのコンピュータ装置または「ノード」上で実行される処理がリソースを共有し得るコンピュータネットワークが開発されている。したがって、ユーザは、コンピュータごとにプリンタを１台購入しなければならない代わりに、多くのコンピュータを有するネットワークに接続され得る単一のプリンタを購入し得る。ネットワーク上の各コンピュータ上の処理は、当該処理がプリンタを必要とするときにのみプリンタにアクセスする。
【０００４】
上述したようにリソースは共有され得るが、多くのリソースは所与の時間に１つより多い処理によって利用され得ない。たとえば、ほとんどのプリンタは１度に１つより多い文書を印刷することができない。記憶媒体のデータブロックまたは記憶媒体に記憶されるテーブルのような他のリソースは、いくつかの点（たとえば読出）では複数の処理によって同時にアクセスされ得るが、他の点（たとえば書込）では１度に１つの処理によってしかアクセスされ得ない。結果、リソースへのアクセスを制御するメカニズムが開発されている。
【０００５】
１つのこのようなメカニズムはロックと呼ばれる。ロックは、リソースに対するある権限が特定の処理に付与されていることを示すデータ構造である。多くのタイプのロックが存在する。あるタイプのロックは多くの処理によって共有され得、別のタイプのロックは同じリソースに対して任意の他のロックが付与されることを妨げる。
【０００６】
たとえば、あるテーブルに対するＮＵＬＬモードロックの所有（ownership）は、いかなる態様でもそのテーブルにアクセスする許可を処理に付与しない。同時読出ロックの所有は、そのテーブルを読出す許可を処理に付与するが、他の処理が同時にそのテーブルに書込みをしていないことを保証しない。保護読出ロックの所有は、そのテーブルを読出す許可を処理に付与するとともに、他の処理がそのテーブルに同時に書込みをしていないことを保証する。同時書込ロックの所有は、そのテーブルに書込む許可を処理に付与するが、別の処理が同様にそのテーブルに書込みをしていないことを保証しない。保護書込ロックの所有は、テーブルに書込む許可を処理に付与するとともに、別の処理が同様にそのテーブルに書込みをしていないことを保証する。排他モードロックの所有は、あるテーブルに対して何をしてもよい許可を処理に付与するとともに、別の処理がそのテーブルに対し
ていかなる動作も行なっていないことを保証する。
【０００７】
これらのロックに関連付けられるさまざまな許可および保証のため、あるロックの組合せは許されない。たとえば、ある処理があるリソースに対して排他モードロックを所有するならば、他の処理にはＮＵＬＬモードロック以外のいかなるロックも付与され得ない。ある処理が保護書込ロックを所有するならば、他の処理には、排他モードロック、保護書込ロック、保護読出ロック、または同時書込ロックが付与され得ない。ある処理が保護読出ロックを所有するならば、他の処理には排他モードロック、保護書込ロック、または同時書込ロックが付与され得ない。ある処理が同時書込ロックを所有するならば、他の処理には排他モードロック、保護書込ロック、または保護読出ロックが付与され得ない。ある処理が同時読出ロックを所有するならば、他の処理には排他モードロックが付与され得ない。
【０００８】
１度に１つの処理より多い処理によって保持され得る種類のロックは共有ロックと呼ばれる。たとえば、同時読出ロックは、２つの処理が同時に同じリソースに対して同時読出ロックを保持し得るので、共有ロックである。説明目的のため、以下の記載では、排他モードロック、共有ロック、およびＮＵＬＬモードロックについて言及する。
【０００９】
ある処理があるリソースに対して動作を行ない得る前に、その処理は、リソースに対して所望の動作を行なう権限を当該処理に付与するロックを得る必要がある。ロックを得るよう、処理はロックを求める要求をロックマネージャに送信する。ロックマネージャは、１つ以上のリソースに対するロックを付与すること、キューに入れること、および追跡することを担う処理である。ネットワークシステムにおけるリソースの利用を管理するよう、ロックマネージャはネットワークの１つ以上のノード上で実行される。
【００１０】
一先行技術実現例に従えば、ロックマネージャは２つの種類のオブジェクト、すなわちリソースオブジェクトおよびロック、を実現する。リソースオブジェクトとは、実際のリソースに対応するデータ構造である。ロックマネージャを用いるアプリケーションは、実際のリソースとリソースオブジェクトとの間にマッピングを確立する。各リソースオブジェクトは２つのキューを有する。すなわち付与済キューと変換キューとである。付与済キューは、付与されたロックの順序付けされないリストである。変換キューは、要求されたがまだ付与されていないロックの部分的に順序付けされたリストである。典型的には、ロックを保持する処理が、自身が保持するロックを１つのモードのロックから異なるモードのロックに変換することを要求している場合、ロックを求める要求は実際には変換要求である。
【００１１】
ロックは、処理およびロックモードを特定するデータ構造である。ロックマネージャはロックをリソースオブジェクトの付与キューに付加し、ロックにおいて特定される処理には、ロックが付加されるリソースオブジェクトに対応するリソースに対するロックにおいて示されるタイプのロックが付与されたことを示す。
【００１２】
図１は典型的なロックマネージャ１０６を示すブロック図である。ロックマネージャ１０６はメモリ１０８に記憶されるリソースオブジェクト１００を管理するよう構成される処理である。リソースオブジェクトは付与済キュー１０２および変換キュー１０４を含む。ロックマネージャ１０６は３つのロック１１０、１１２、および１１４を付与済キュー１０２に付加し、１つの変換要求１３０を変換キュー１０４に付加した。
【００１３】
すべてのロックおよび変換要求は、処理ＩＤ部分およびロックモード部分を有する。ロック１１０の処理ＩＤ部分１１６は処理ＰＲＯＣ＿１がロック１１０を所有することを示し、ロック１１０のロックモード部分１１８はロック１１０が排他ロックであることを示
す。ロック１１２の処理ＩＤ部分１２０はロック１１２が処理ＰＲＯＣ＿２によって所有されることを示し、ロック１１２のロックモード部分１２２はロック１１２がＮＵＬＬモードロックであることを示す。ロック１１４の処理ＩＤ部分１２４はロック１１４が処理ＰＲＯＣ＿３によって所有されることを示し、ロック１１４のロックモード部分１２６はロック１１４がＮＵＬＬロックであることを示す。変換要求１３０の処理ＩＤ部分１３２は変換要求１３０が処理ＰＲＯＣ＿４と関連付けられることを示し、変換要求１３０のロックモード部分１３６はＰＲＯＣ＿４が現在リソースに対してＮＵＬＬモードロックを保持することを示す。ロックモード部分１３６に加えて、変換要求１３０はＰＲＯＣ＿４が排他モードロックを要求していることを示す要求モード部分１３４を有する。
【００１４】
ロックマネージャ１０６はロック１１０、１１２、および１１４を付与済キュー１０２に付加し、ＰＲＯＣ＿１がリソースオブジェクト１００に対応するリソースの排他的所有権を現在有することを示す。ロックマネージャ１０６は変換要求１３０を変換キュー１０４に付加し、ＰＲＯＣ＿４はリソースオブジェクト１００が関連付けられるリソースに対する排他モードロックを要求したが、ＰＲＯＣ＿４には当該排他モードロックが未だ付与されていないことを示す。
【００１５】
任意の所与のリソースに関する情報は、当該リソースに対応するリソースオブジェクトに記憶されてもよい。各リソースオブジェクトは単一のノードのメモリに記憶される。リソースオブジェクトが記憶されるノードは、リソースオブジェクトについてのマスタノードと呼ばれる。
【００１６】
一ロック管理アプローチに従えば、処理はまず、当該処理がおそらく使うであろうすべてのリソースに対してＮＵＬＬモードロックを確立する。次いで、処理があるリソースへのアクセスを実際に必要とすると、処理はそのＮＵＬＬモードロックを、所望の動作を行なう権限を当該処理に付与するロックに変換することを要求する。
【００１７】
たとえば、テーブルを消去するには、処理はそのテーブルに対応するリソースオブジェクトに対する排他モードロックを得なければならない。排他モードロックを得るよう、処理はそのテーブルに対応するリソースオブジェクトを制御するロックマネージャにメッセージを送信する。そのメッセージにおいて、処理は自身の現在のＮＵＬＬモードロックを排他モードロックに変換することを要求する。他の処理が変換を要求しておらず、かつ現在付与されているロックが排他モードロックの付与を妨げないならば、要求を行っている処理が保持する現在のロックは排他モードロックに変換される。ロックマネージャがひとたび要求された変換を行なうと、ロックマネージャは、要求された変換処理がなされたということを示すよう、要求を行っている処理にメッセージを送信する。
【００１８】
ある処理がテーブルからデータを読出すようアクセスを必要とする場合、その処理は共有ロックを得なければならない。共有ロックを得るよう、その処理は、テーブルに対応するリソースオブジェクトを制御するロックマネージャに、自身の現在のロックを共有ロックに変換するよう要求する。他の処理が変換を要求しておらず、かつ現在付与されているロックが共有ロックの付与を妨げないならば、要求を行っている処理が保持する現在のロックは共有ロックに変換される。
【００１９】
当該テーブルについて排他モードロックが既に付与されているならば、共有ロックは付与され得ない。これらの状況下では、ロック変換要求はリソースオブジェクトの変換キューに置かれる。妨げている処理が自身の排他ロックを解放する準備ができると、この妨げている処理はロックマネージャにロックダウングレード要求を送り得る。ロックマネージャは、排他モードロックを共有ロックの付与を可能にする下位のロックに変換することにより応答する。次いで、要求キューから付与済キューに共有ロック要求を移動するととも
に、共有ロックが付与されたことを、要求を行っている処理に知らせるメッセージを要求を行っている処理に送信することによりことにより共有ロックは付与される。
【００２０】
リソースオブジェクトの変換キューは、すべての未決定（未付与）のロック要求を保持する部分的に順序付けされたリストである。未決定のロック要求のいずれも許可されていないならば、許可されていないロック要求の１つが変換キューの「先頭」に移されることになる。たとえ現在付与されているロックがロックマネージャが特定のロック要求を許可するのを妨げなくても、ロック要求は変換キューが空でないならば変換キューに置かれる。このやり方により、システムにおいて１つの処理が進行し得ないが他の処理が進行し得る場合に、「ライブロック（livelock）」を防止する。
【００２１】
多くの処理が、あるリソースに対して共有ロックを同時に保持することはよくある。特定のリソースに対して共有ロックを保持する処理のセットを、ここではまとめて「共有ロックホルダ」と呼ぶ。
【００２２】
共有ロックホルダのうちの１つ（「リクエスタ（requester）」）が排他モードロックに変換することを欲するとすると、そのリクエスタはまず変換要求をリソースのマスタノードに送らなければならない。この共有から排他への要求がリソースのマスタノードにおける変換キューの先頭に辿り着くと、マスタノードはすべての共有ロックホルダにダウンコンバート要求メッセージを送り、それらのロックをダウンコンバートまたはクローズすることを求める。すべての共有ロックホルダが自身のロックをダウンコンバートしたのをマスタに通知した後でないと、マスタノードはリクエスタに排他ロックを付与し得ない。リクエスタがアップグレード要求を送る時間と、排他ロックが付与される時間との間は、リクエスタが既に自身のキャッシュにリソースのカレントコピーを有していても、リクエスタは待たなければならず、リソースをアップデートし始め得ず、またはいかなるその後のワークも行い得ない。
【００２３】
このセクションで記載されたアプローチは追求され得たアプローチであるが、必ずしもこれまでに認識または追求されたアプローチではない。したがって、そうでないことが示されなければ、このセクションに記載されるアプローチのいずれもが、このセクションに含まれるということだけで、先行技術とみなされると想定されるべきではない。
【００２４】
この発明は、同様の参照番号が同様の要素を指す添付の図面の図において、限定目的ではなく例示目的で示される。
【発明を実施するための最良の形態】
【００２５】
詳細な説明
以下の記載では、説明目的のために、さまざまな具体的な詳細がこの発明の完全な理解を提供するよう記載される。しかしながら、この発明はこれらの具体的な詳細なしに実施されてもよいことは明らかである。他の場合では、この発明を不必要に不明確にするのを避けるよう、公知の構造および装置がブロック図の形で示される。
【００２６】
（概略）
ある処理があるリソースを修正する許可を要求するときと、その処理がリソースを修正し始めるのが許されるときとの間の遅延を低減するための技術が以下に記載される。説明目的のため、リソースがディスクブロックであり、その場合ディスクブロックのコピーがバッファキャッシュに記憶される例が与えられる。しかしながら、これは当該技術が適用されてもよいリソースの単なる一例である。本技術は任意の特定のタイプのリソースに限定されない。
【００２７】
ある処理がディスクブロックに対する共有ロックを保持するとき、典型的にはディスクブロックのカレントコピーが、その処理が実行されているノードのバッファキャッシュに既に存在する。以下に記載される技術は、リソースを修正することを望む処理（「リクエスタ」）が、リソースのマスタがリソースを修正する許可を付与するのを待つことなくリソースのそれらのプライベートコピーをアップデートすることを可能にする。結果として、リクエスタがリソースをアップデートするよう要求する時間とリソースがアップデートされる時間との間の遅延が低減される。
【００２８】
（共有から排他へのアップグレード）
例示目的のために、あるリクエスタがあるリソースに対する共有ロックを保持するとともに、そのリソースに対する排他ロックを望んでいると想定する。共有から排他へのリクエスタが、当該リクエスタに排他ロックが付与される前でさえ、（リクエスタが既に有する）ブロックのプライベートカレントコピーを修正し始めることを可能にする技術が提供される。
【００２９】
一実施例に従えば、あるリソースについて共有から排他への要求があるときはいつでも、リソースのマスタは他のタイプの変換要求とは異なってこの要求を取扱う。具体的には、このような要求を受取ると、マスタはこの要求がすぐ付与され得るかどうかを判断する。この要求がすぐに許可され得ない場合、単にこの要求を変換キューに置くのではなく、マスタは（１）付与キュー上に共有ロックホルダしかない（排他ホルダがない）かどうか、および（２）変換キュー上に保留状態の排他要求があるかどうかを判断する。
【００３０】
付与キュー上に共有ロックホルダしかなく、変換キュー上に保留状態の排他要求がない場合、マスタはこの変換要求を変換キューの先頭に置き、リクエスタに「開始」メッセージを送る。マスタはさらに、すべての現在の共有ロックホルダにダウンコンバート要求メッセージを送る。
【００３１】
重要なのは、開始メッセージは、１つ以上の現在付与されているロックが要求された許可と相容れず、したがって現在のところは許可が付与されることを妨げていても送られることである。したがって、開始メッセージは、要求された許可は付与されそうであるがまだ付与されていないということを示す。
【００３２】
リクエスタが開始メッセージを受取ると、リクエスタはプライベートメモリにおいてブロックをアップデートし始め得る。（１）開始メッセージの後で、かつ（２）要求された許可が付与される前にブロックになされる変更は、ここでは「予測的変更（anticipatory
change）」と呼ばれる。予測的変更を行なう処理のみが予測的変更を含むリソースのコピーにアクセスすることを許される。リドゥー（Redo）レコードが予測的変更について生成されてもよいが、変更されるブロックまたはリドゥーレコードのいずれもが、変更が予測的のままである間はコミット（「確定」）されない。
【００３３】
すべての共有ロックホルダが自身のロックをダウンコンバートし、マスタに確認メッセージを送ると、マスタはリクエスタにロック付与メッセージを送り、リクエスタに排他ロックを付与する。リクエスタがひとたびロック付与メッセージを受取ると、変更は「予測的変更」ではなくなり、「許可された変更」になる。ひとたび変更が許可されると、変更がコミットされ得る。
【００３４】
（トランザクション）
データベースシステムのようないくつかのシステムの中では、動作の連なりが単一の「トランザクション」として行なわれ得る。あるトランザクションによってなされた変更は不分割な単位（atomic unit）としてコミットされなければならない。したがって、トラ
ンザクションがいかなる未決定の予測的変更であっても有している限り、トランザクションによってなされた変更のいずれもがコミットされ得ない。
【００３５】
一実施例に従えば、トランザクションによってなされた予測的変更は追跡（track）される。トランザクションの予測的変更を追跡するために多くのタイプのメカニズムが用いられてもよい。この発明は任意の特定のタイプの追跡メカニズムに限定されない。予測的変更を追跡するのに用いられる情報は、一般的にここでは「追跡情報（tracking information）」と呼ばれる。
【００３６】
トランザクションが特定のリソースを修正する許可を受取ると、トランザクションによってなされたその特定のリソースに対する任意の予測的変更が許可されたということを示すよう追跡情報はアップデートされる。トランザクションによってなされた何らかの予測的変更が許可されていないことを追跡情報が示している限り、トランザクションは（トランザクションのすべての動作が他の点では首尾よく完了している場合でも）コミットすることは許されない。
【００３７】
ひとたび予測的変更のすべてが許可された変更になると、トランザクションはコミットしてもよい。トランザクションがコミットすると、（通常はシステムコミット番号の形である）コミット時間がトランザクションに割り当てられる。コミット時間は、トランザクションについて生成されたリドゥーレコードに必要に応じて加えられる。リドゥーレコードは次いで、ディスクにフラッシュされることになるチェックポイントキューにリンクされ、変更を確定する。これらの変更が確定された後、変更は他の処理またはインスタンスにアクセスされ得る。
【００３８】
（修正要求）
先のセクションでは、リクエスタが共有ロックから排他ロックにアップグレードしていた場合が記載された。しかしながら、ここに記載される技術は、ロックを用いて管理されるリソースを修正する要求に関係するどのような場合にも適用可能である。したがって、この技術は、たとえば、要求が「同時書込」ロックまたは「保護書込」ロックへのアップグレードを求めるのものである場合にも同様に適用可能である。リソースを修正する許可を求める要求は、ここでは「修正要求」と呼ばれる。
【００３９】
（リクエスタの動作）
図２は、この発明の一実施例に従った、予測的変更をサポートするシステムにおけるリソースを修正することを望むトランザクションが行なうステップを示すフローチャートである。具体的には、ステップ２０２では、リソースを修正することを欲するリクエスタがリソースを制御するロックマネージャに修正要求を送る。予測的変更をサポートするシステムでは、リクエスタは開始メッセージを受取る場合がある。開始メッセージが受取られなければ、制御はステップ２０４から、リクエスタがロック付与メッセージを最終的に受取ることになるステップ２０８まで進む。リクエスタがロック付与メッセージを受取った後、リクエスタはリソースを修正してもよい（ステップ２１０）。
【００４０】
リクエスタが開始メッセージを受取る場合は、制御はステップ２０４からステップ２０６へと進む。ステップ２０６では、リクエスタは、修正を行なう許可が付与されることなくても、リソースのプライベートコピーを修正することにより予測的変更を行なう。リクエスタがトランザクションならば、リクエスタはさらにこの予測的変更を反映するよう追跡情報をアップデートする。重要なのは、予測的変更を行なった後、リクエスタは他のワークをするよう進み続け得ることである。当該他のワークには、付加的な予測的変更を行なうことが含まれてもよい。結果として、所与のトランザクションについての追跡情報は未決定のまだ許可されていない変更の任意の数を示してもよい。
【００４１】
リクエスタが予測的変更を行なうよう許可を受取る前に他のワークをするよう進み得るという事実は、重要な性能上の利益をもたらし得る。許可を要求することと許可を受取ることとの間の遅延が長くなればなるほど、許可を待つことなく開始できるという利点は大きくなる。したがって、同じリソースへのアクセスを通常共有する多くのノードを含むシステムでは、予測的変更は特に有益である。予測的変更を行う能力がなければ、共有されるリソースを修正することを欲する処理は、他のノードすべてがダウンコンバートするのを待たなければならない。ノードの数が多くなればなるほど、待つことが長くなりがちである。
【００４２】
予測的変更が許可されるまで、この変更は「確定」されない。変更を確定する実際の処理は、システムごとに異なってもよい。たとえば、あるシステムでは、変更を特定する「リドゥーレコード」をディスクにフラッシュすることにより、当該変更が確定される。あるシステムでは、ブロックの変更されたコピーをディスクにフラッシュすることにより変更が確定されてもよい。他のシステムでは、それによって変更が確定される他のメカニズムを有してもよい。ここに記載される技術は、変更を確定する任意の特定のメカニズムに縛られない。
【００４３】
ステップ２１２では、リクエスタはリソースを修正する許可を受取る。上で説明したように、許可の受取は、リクエスタが行なっている任意の他のワークに対して非同期的であり、唯一の例外は許可の受取は変更の確定に先立って行なわれなければならないことである。
【００４４】
リクエスタがトランザクションならば、リクエスタは予測的変更が許可されたことを反映するよう追跡情報をアップデートする。未決定の予測的変更がなく、リクエスタが他の点で首尾よく完了している（ステップ２１４）ならば、リクエスタによってなされた変更は確定され、他の処理に対して可視化される（ステップ２１６）。リクエスタがトランザクションであり、すべての動作が成功および許可されているわけではないならば、トランザクションはロールバックされる（ステップ２１８）。
【００４５】
（ロックマネージャの動作）
図３は、予測的要求をサポートするシステムにおけるロックマネージャが行うステップを示すフローチャートである。ステップ３０２では、リソースのマスタがリクエスタから修正要求を受取る。ステップ３０４および３０６では、マスタは既に付与された修正要求があるかどうか（ステップ３０４）、および保留状態の修正要求があるかどうか（ステップ３０６）を判断する。
【００４６】
ロックを追跡するようリソースオブジェクトを用いる実施例では、マスタは、付与済キュー上のロックのいずれかが修正特権を付与するロックであるかどうかを判断するようロックオブジェクトの付与済キューを検査することによりステップ３０４を行なってもよい。同様に、マスタは、ロックオブジェクトの変換キュー上の変換要求のいずれかがリソースを修正する許可を求める要求であるかどうかを判断するよう変換キューを検査することによってステップ３０６を行なってもよい。
【００４７】
任意の保留中または付与済の修正要求が存在するならば、制御は修正要求が変換キューに置かれるステップ３２０に進む。しかしながら、保留状態または付与済の修正要求のいずれもが存在しないならば、制御はステップ３０８に進み、ステップ３０８では、マスタがリクエスタに開始メッセージを送り、修正要求を変換キューの先頭に置き、相容れないロックホルダのすべてにダウンコンバート要求を送る。
【００４８】
マスタが相容れないロックホルダすべてからダウンコンバート確認を最終的に受取ると、マスタはロック付与メッセージをリクエスタに送り、修正要求を要求キューの先頭から付与済キューへと移動させる。
【００４９】
（現在共有ロックを保持しないリクエスタによる修正要求）
上記の例では、修正要求はリソースに対する共有ロックを既に保持するリクエスタから送られる。リクエスタは既に共有ロックを保持しているので、リクエスタは典型的には既にリソースの現在のバージョンのコピーを有していることになる。しかしながら、ここで記載される予測的修正技術は、現在共有ロックを保持しないリクエスタから修正要求が送られる状況にも適用されてもよい。
【００５０】
一実施例に従えば、リクエスタが共有ロックを現在保持していない場合、マスタはブロックのカレントコピーをリクエスタに送らせる。リクエスタがブロックのコピーをひとたび受取ると、リクエスタはブロックに対して予測的変更を行ない始め得る。
【００５１】
一実施例では、マスタがブロックのカレントコピーを有しているならば、マスタそれ自体がリクエスタにブロックのカレントコピーを送る。この場合、マスタはブロックを送るのと「開始」メッセージを伝えるのとの両方に同じメッセージを用いてもよい。
【００５２】
マスタがブロックのカレントコピーを有していない場合、マスタは共有ロックホルダの１つにメッセージを送り、共有ロックホルダにリクエスタへブロックのカレントコピーを送らせてもよい。その場合、マスタはリクエスタに「開始メッセージ」を別個に送ってもよい。代替的には、マスタは単に、ブロックのカレントコピーとともに「開始」メッセージをリクエスタへ送るよう共有ロックホルダに命令してもよい。
【００５３】
上記の例では、マスタが修正要求を許可するのを妨げる付与済のロックは共有ロックである。しかしながら、現在付与されている排他ロックがあるため、修正要求が許可され得ないということもあり得る。現在付与されている排他ロックが修正要求が許可されるのを妨げる場合、リクエスタは「プロキシ」バッファに対して予測的変更をし始めてもよい。一実施例では、リクエスタは、ブロックの「過去のイメージ」が利用可能ならば、ブロックの過去のイメージをプロキシバッファとして用いる。ブロックの過去のイメージとは、そのブロックの過去の状態を反映するブロックのコピーである。したがって、ブロックのカレントコピーは過去のイメージの中にないいくつかの変更を含み得る。リソースの現在のバージョンが届くと、リクエスタはプロキシバッファにおける変更をリソースの現在のバージョンにマージし得る。
【００５４】
この場合、典型的にはリクエスタは排他ロックの所有者からリソースの現在のバージョンを受取る。現在のバージョンとともに、排他ロックの所有者はロック付与メッセージを含めてもよく、リクエスタにリソースへの変更を行なう許可を与える。したがって、リクエスタがブロックの現在のバージョンに変更をマージすることができるのと同時に変更が許可される。
【００５５】
一実施例に従えば、ブロックの現在のバージョンを受取ることに先立って、リドゥーがプロキシバッファに対してなされた予測的変更について生成される。ブロックの現在のバージョンがひとたび届くと、このリドゥーはリカバリ動作の「ロールフォワード」段階に似た態様でブロックの現在のバージョンに適用され得る。ブロックの現在のバージョンにリドゥーを適用することにより、ブロックがリドゥーにおいて特定される変更を反映する。
【００５６】
いくつかの状況では、ブロックに対して変更がなされ得るかどうかは、どのような現在
の値がブロックにあるかに基づいて決定してもよい。たとえば、あるブロックがテーブルの複数行についてのデータを含むとする。テーブルの列の１つについて一意性制約が確立されているとする。特定の行が（ブロックを修正することにより）テーブルに挿入され得るかどうかは、この挿入が一意性制約に違反するかどうかに基づいて決定されてもよい。したがって、一実施例に従えば、予測される変更をブロックの現在のバージョンにマージする前に、制約検査がブロックの現在の状態に基づいて行われる。
【００５７】
（ハードウェアの概略）
図４は、この発明の実施例が実現されてもよいコンピュータシステム４００を示すブロック図である。コンピュータシステム４００は、情報を通信するためのバス４０２または他の通信メカニズムと、バス４０２に結合され、情報を処理するためのプロセッサ４０４とを含む。コンピュータシステム４００はさらに、バス４０２に結合され、情報およびプロセッサ４０４によって実行されることになる命令を記憶するためのランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置のようなメインメモリ４０６を含む。メインメモリ４０６は、プロセッサ４０４によって実行されることになる命令の実行の間、一時変数または他の中間情報を記憶するためにも用いられてもよい。コンピュータシステム４００はさらに、バス４０２に結合され、プロセッサ４０４のために静的な情報および命令を記憶するための読出専用メモリ（ＲＯＭ）４０８または他の静的な記憶装置を含む。磁気ディスクまたは光学ディスクのような記憶装置４１０が情報および命令を記憶するために設けられ、バス４０２に結合される。
【００５８】
コンピュータシステム４００はバス４０２を介して、陰極線管（ＣＲＴ）のような、コンピュータユーザに情報を表示するためのディスプレイ４１２に結合されてもよい。英数字およびその他のキーを含む入力装置４１４が、プロセッサ４０４に情報およびコマンド選択を通信するためにバス４０２に結合される。別のタイプのユーザ入力装置は、プロセッサ４０４に方向情報およびコマンド選択を通信するためであるとともに、ディスプレイ４１２上でのカーソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キーのようなカーソル制御部４１６である。この入力装置は典型的には、２つの軸、すなわち第１の軸（たとえばｘ）および第２の軸（たとえばｙ）、において２つの自由度を有し、それによって装置が平面での位置を特定することが可能になる。
【００５９】
この発明は、ここに記載される技術を実現するための、コンピュータシステム４００の利用に関係付けられる。この発明の一実施例に従えば、それらの技術は、プロセッサ４０４がメインメモリ４０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行するのに応答して、コンピュータシステム４００によって実施される。このような命令は記憶装置４１０のような別の機械読取可能媒体からメインメモリ４０６に読込まれてもよい。メインメモリ４０６に含まれる命令のシーケンスの実行により、プロセッサ４０４がここに記載される処理ステップを実行する。代替的実施例では、この発明を実現するよう、配線回路がソフトウェア命令の代わりにか、またはそれらと組合わされて用いられてもよい。したがって、この発明の実施例はハードウェア回路網およびソフトウェアのいかなる具体的な組合せにも限定されない。
【００６０】
ここで用いられる「機械読取可能媒体」という用語は、具体的な形で機械を動作させるデータを提供することに関係する任意の媒体のことを指す。コンピュータシステム４００を用いて実現される実施例では、たとえば実行のためにプロセッサ４０４に命令を供給することに様々な機械読取可能媒体が関わる。このような媒体は多くの形態を取り得、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに限定されない。不揮発性媒体は、たとえば記憶装置４１０のような光学または磁気ディスクを含む。揮発性媒体はメインメモリ４０６のような動的なメモリを含む。伝送媒体は、バス４０２を構成するワイヤを含む、同軸ケーブル、銅線、および光ファイバを含む。伝送媒体はさらに、電波および赤
外線データ通信の間に生成されるような音波または光波の形態を取り得る。
【００６１】
機械読取可能媒体の一般的な形態には、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、もしくは任意の他の磁気媒体、ＣＤ−ＲＯＭ、任意の他の光媒体、パンチカード、紙テープ、穴のパターンを有する任意の他の物理媒体、ＲＡＭ、ＰＲＯＭ、およびＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップもしくはカートリッジ、以下に記載されるような搬送波、またはコンピュータが読出し得る任意の他の媒体が含まれる。
【００６２】
機械読取可能媒体のさまざまな形態は、実行のためにプロセッサ４０４に１つ以上の命令の１つ以上のシーケンスを搬送することに関わり得る。たとえば、命令はリモートのコンピュータの磁気ディスク上に初めは担持されてもよい。リモートのコンピュータはこれらの命令を自身の動的メモリにロードし得、モデムを用いて電話線上に命令を送り得る。コンピュータシステム４００のローカルのモデムは、電話線上でこのデータを受取り得、赤外線送信機を用いてこのデータを赤外線信号に変換し得る。赤外線信号において搬送されるデータを赤外線検知器が受取り得、適切な回路網がこのデータをバス４０２上に置き得る。バス４０２はこのデータをメインメモリ４０６に搬送し、そこからプロセッサ４０４は命令を抽出し実行する。メインメモリ４０６が受取った命令は、随意であるが、プロセッサ４０４による実行の前または後のいずれかに記憶装置４１０上に記憶されてもよい。
【００６３】
コンピュータシステム４００はさらに、バス４０２に結合される通信インターフェイス４１８を含む。通信インターフェイス４１８はローカルネットワーク４２２に接続されるネットワークリンク４２０への２方向データ通信結合を提供する。たとえば、通信インターフェイス４１８は、対応するタイプの電話線にデータ通信接続を与える統合デジタル通信網（ＩＳＤＮ）カードまたはモデムであってもよい。別の例として、通信インターフェイス４１８は、準拠するローカルエリアネットワーク（ＬＡＮ）にデータ通信接続を提供するＬＡＮカードであってもよい。ワイヤレスリンクも実現されてもよい。このような実現例のいずれでも、通信インターフェイス４１８は、さまざまなタイプの情報を示すデジタルデータストリームを搬送する電気、電磁、または光信号を送り、かつ受取る。
【００６４】
ネットワークリンク４２０は典型的には、データ通信を１つ以上のネットワークを介して他のデータ装置に提供する。たとえば、ネットワークリンク４２０はローカルネットワーク４２２を介して接続をホストコンピュータ４２４またはインターネットサービスプロバイダ（ＩＳＰ）４２６によって運用されるデータ機器に提供し得る。立ち代わって、ＩＳＰ４２６は今日一般に「インターネット」４２８と呼ばれるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスを提供する。ローカルネットワーク４２２およびインターネット４２８は両方ともデジタルデータストリームを搬送する電気、電磁、または光信号を用いる。コンピュータシステム４００からおよびコンピュータシステム４００にデジタルデータを搬送する、これらさまざまなネットワークを通る信号ならびにネットワークリンク４２０上にあるとともに通信インターフェイス４１８を通る信号は、情報を運ぶ搬送波の例示的な形態である。
【００６５】
コンピュータシステム４００は、ネットワーク、ネットワークリンク４２０、および通信インターフェイス４１８を介して、メッセージを送り得、プログラムコードを含むデータを受取り得る。インターネットの例では、インターネット４２８、ＩＳＰ４２６、ローカルネットワーク４２２、および通信インターフェイス４１８を介して、アプリケーションプログラムのための要求されたコードをサーバ４３０が送信してもよい。
【００６６】
コードが受取られると、当該受取られたコードはプロセッサ４０４によって実行されて
もよく、および／または後の実行のために記憶装置４１０もしくは他の不揮発性記憶装置に記憶されてもよい。この態様で、コンピュータシステム４００は搬送波の形でアプリケーションコードを得てもよい。
【００６７】
上述の明細書では、この発明の実施例は、実現例ごとに異なってもよい多くの具体的な詳細を参照して記載されてきた。したがって、何がこの発明であるか、および出願人が何がこの発明であると意図するかということを示す唯一かつ排他的なものはこの出願に由来する特許請求の範囲であり、それはこのような特許請求の範囲が提供する具体的な形態にあるとともに、任意のその後の補正を含む。このような特許請求の範囲に含まれる用語について明確にここに記載されるいかなる定義も、特許請求の範囲で用いられる際のこのような用語の意味を決定することになる。したがって、ある請求項において明確に述べられない限定、要素、特性、特徴、利点、または属性はこのような請求項の範囲をどのようにも限定するべきではない。明細書および図面はしたがって、限定的な性質ではなく例示的な性質であるとみなされるべきである。
【図面の簡単な説明】
【００６８】
【図１】あるリソースに対するロックを管理するよう用いられるロックマネージャおよびオブジェクトリソースのブロック図である。
【図２】この発明の実施例に従った、リソースを修正することを望む処理が行うステップを示すフローチャートの図である。
【図３】この発明の実施例に従った、ロックマネージャが行うステップを示すフローチャートの図である。
【図４】この発明の実施例が実現されてもよいコンピュータシステムのブロック図である。
【図１】
2009526324.tif 000003
【図２】
2009526324.tif 000004
【図３】
2009526324.tif 000005
【図４】
2009526324.tif 000006
【手続補正書】
【提出日】平成20年4月9日(2008.4.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
リソースに対する変更を行なう許可を求める要求をマスターノードに送るステップを含み、
前記リソースはデータベースからのデータを含むリソースであり、
前記マスターノードは、リソースに対するロック要求に関する情報を維持するリソースオブジェクトを管理することを担うロックマネージャを含むノードであり、さらに、
前記許可を受取る前であり、かつマスターノードから開始メッセージを受取った後で、前記変更が前記データベース内で確定するのを妨げつつ前記変更をリソースに対して行なうステップと、
前記変更を行なった後、前記変更を行なう許可を受取るステップと、
前記変更を行なう許可を受取った後、前記変更が前記データベースに対して確定するのを妨げるのを中止するステップとを含む、機械実行される方法。
【請求項２】
前記変更はデータベーストランザクションのある部分として行なわれ、
データベーストランザクションは、不分割な単位として１つ以上のデータベース動作を行うことを伴い、
前記変更が確定するのを妨げつつ前記変更を行なうステップは、
リソースのプライベートコピーに対して前記変更を行なうステップと、
データベーストランザクションがコミットするのを妨げるステップとを含む、請求項１に記載の方法。
【請求項３】
データベーストランザクションがまだ許可されていない変更を行なったかどうかを示す追跡情報を維持するステップと、
追跡情報がデータベーストランザクションがまだ許可されていない変更を行なったことを示す限り、データベーストランザクションがコミットするのを妨げるステップとをさらに含む、請求項２に記載の方法。
【請求項４】
前記変更を行なう許可を求める要求はリクエスタからマスタノードに送られ、
前記方法はさらに、
マスタノードが（ａ）リソースに対する現在付与されているロックのいずれかがリソースを修正する許可を付与するかどうか、および（ｂ）保留状態のロック要求のいずれかがリソースを修正する許可を求める要求であるかどうかを判断するステップと、
リソースに対する現在付与されているロックがリソースを修正する許可を付与せず、かつ保留状態のロック要求がリソースを修正する許可を求める要求でないという判断に応答して、マスタノードはリクエスタに開始メッセージを送るステップとを含み、
リクエスタは開始メッセージの受取に応答して変更を行なう、請求項１に記載の方法。
【請求項５】
リソースに対する現在付与されているロックがリソースを修正する許可を付与せず、かつ保留状態のロック要求がリソースを修正する許可を求める要求でないという判断に応答して、マスタノードは、修正する許可を求める要求をリソースについての保留状態のロック要求のキューの先頭に置くステップをさらに含む、請求項４に記載の方法。
【請求項６】
前記変更を行なう許可を求める要求はリクエスタからマスタノードに送られ、
リクエスタが要求を送るとき、リクエスタはリソースに対する共有ロックを保持するとともにリソースの現在のバージョンのプライベートコピーを有し、
前記変更を行なうステップは、リソースの現在のバージョンのプライベートコピーに対して変更を行なうステップを含む、請求項１に記載の方法。
【請求項７】
前記変更を行なう許可を求める要求はリクエスタからマスタノードに送られ、
リクエスタが要求を送るとき、別の処理がリソースに対する排他ロックを保持し、
前記変更を行なうステップは、
プロキシバッファに対して変更を行なうステップと、
リクエスタがリソースの現在のバージョンのコピーを受取ると、プロキシバッファからリソースの現在のバージョンのコピーに変更をマージするステップとを含む、請求項１に記載の方法。
【請求項８】
プロキシバッファに対して変更を行なうことに応答して、リドゥーを生成するステップをさらに含む、請求項７に記載の方法。
【請求項９】
前記変更は、制約違反について検査することなしにプロキシバッファに対して行なわれ、
制約違反について検査した後でのみ、変更は現在のバージョンのコピーにマージされる、請求項７に記載の方法。
【請求項１０】
前記変更を行なう許可を求める要求はリクエスタからマスタノードに送られ、
リクエスタが要求を送るとき、リクエスタはリソースに対する共有ロックを保持しないが、１つ以上の他の処理のセットがリソースに対する共有ロックを保持し、
前記方法はさらに、前記処理のセットのある処理にリソースのカレントコピーをリクエスタへ送らせるステップを含む、請求項１に記載の方法。
【請求項１１】
開始メッセージの受取に応答して、リクエスタは変更を行ない、
前記方法はさらに、前記処理のセットの前記処理に、リソースのカレントコピーとともに前記開始メッセージを含ませるステップを含む、請求項１０に記載の方法。
【請求項１２】
開始メッセージの受取に応答して、リクエスタは変更を行ない、
前記方法はさらに、マスタノードに開始メッセージをリクエスタへ送らせるステップを含む、請求項１０に記載の方法。
【請求項１３】
リクエスタから要求をリソースのマスタノードで受取るステップを含み、
要求はデータベースからのデータを含むリソースを修正する要求であり、
前記マスターノードは、リソースに対するロック要求に関する情報を維持するリソースオブジェクトを管理することを担うロックマネージャを含むノードであり、さらに、
リソースを修正する許可をマスタノードがリクエスタに付与するのを１つ以上の現在付与されているロックが妨げている間、マスタノードは、ユーザがリソースに対して予測的変更を行なうことを許すが当該変更がデータベースに対して確定するのを禁止する開始メッセージをリクエスタに受取らせるステップと、
リソースを修正する許可をマスタノードがリクエスタに付与するのを現在付与されているロックが妨げない場合、マスタノードは、リクエスタが変更をデータベースに対して確定するのを許すロック付与メッセージをリクエスタに送るステップとを含む、機械実行される方法。
【請求項１４】
以前に受取られた、リソースについての他のロック要求の前で、要求キューの先頭に要求をマスタノードに置かせるステップをさらに含む、請求項１３に記載の方法。
【請求項１５】
前記要求を受取ると、マスタノードは付与されたまたは要求されたロックのいずれかがリソースを修正する許可を付与するロックであるかどうか判断するステップと、
付与されたまたは要求されたロックがリソースを修正する許可を付与するロックではないとの判断に応答して、マスタノードが開始メッセージをリクエスタに受取らせるステップとをさらに含む、請求項１３に記載の方法。
【請求項１６】
リクエスタはリソースに対する共有ロックを保持し、
マスタノードは開始メッセージをリクエスタに送ることにより、リクエスタに開始メッセージを受取らせる、請求項１３に記載の方法。
【請求項１７】
リクエスタはリソースに対する共有ロックを保持せず、
マスタノードは、リソースに対する共有ロックを保持する処理に（ａ）リクエスタへのリソースのカレントコピーと（ｂ）開始メッセージとを、リクエスタへ送らせることにより開始メッセージをリクエスタに受取らせる、請求項１３に記載の方法。
【請求項１８】
実行されると、１つ以上のプロセッサに請求項１〜請求項１７のいずれか１つに記載の方法を行なわせる命令を記憶する、コンピュータ読取可能媒体。
【請求項１９】
１つ以上のプロセッサと、当該１つ以上のプロセッサによって実行されると、コンピュータシステムに請求項１〜請求項１７のいずれか１つに記載の方法を行なわせる命令を含むコンピュータ読取可能記憶装置とを含む、コンピュータシステム。
【国際調査報告】
2009526324.tif 000007