JP2006107519A - バージョンストアのリソース使用を制限する方法およびシステム - Google Patents

Abstract

【課題】バージョンストアのリソース使用を制限するための方法およびシステムを提供する。
【解決手段】新しいトランザクションが開始される前に、新しいトランザクションを完了するのに十分なリソースが残っているかどうかを判定する。残っている場合は、トランザクションは開始し、累計は調整される。残っていない場合は、より多くのリソースが利用可能になるまでトランザクションは待機する。トランザクションが完了したとき、これが最も古い進行中トランザクションである場合は、リソースは解放される。そうでない場合は、このトランザクションに関連するリソースは、このトランザクションよりも前に開始したすべてのトランザクションが完了するまで解放されない。これにより、進行中のトランザクションによって消費することのできるリソースの限度を、バージョンストアのクライアントが超過しないことが保証される。
【選択図】図４

Description

本発明は一般にコンピュータに関し、より詳細にはリソース使用に関する。

クライアントが、データベースなどのバージョンストアとのトランザクションを開始する度に、いくつかのリソースが消費される。これらのリソースは、トランザクションがコミットまたはアボートされた後も、このトランザクションよりも前に開始されたすべてのトランザクションも同様に完了するまで、消費され続ける場合がある。ファイル複製システム（ＦＲＳ）など頻繁に変更されるバージョンストアでは、あるいは同時に行われる複数のトランザクションと比較して少ないリソースを有するバージョンストアでは、進行中のトランザクションによって必要とされるリソースが、利用可能リソースの量を超過することがある。

バージョンストアのリソース使用を制限するための方法およびシステムが必要とされている。

簡単に言えば、本発明は、バージョンストアのリソース使用を制限するための方法およびシステムを提供する。限度が、進行中のトランザクションによって消費することのできるリソースの総量を示す。残っているリソースの量の累計が保持される。新しいトランザクションが開始される前に、この新しいトランザクションを完了するのに十分なリソースが残っているかどうかが判定される。残っている場合は、トランザクションは開始し、累計は調整される。残っていない場合は、より多くのリソースが利用可能になるまでトランザクションは待機する。トランザクションが完了したとき、これが最も古い進行中トランザクションである場合は、リソースは解放される。そうでない場合は、このトランザクションに関連するリソースは、このトランザクションよりも前に開始したすべてのトランザクションが完了するまで解放されない。これにより、進行中のトランザクションによって消費することのできるリソースの限度を、バージョンストアのクライアントが超過しないことが保証される。

その他の利点は、以下の詳細な記述を図面と共に読めば明らかになるであろう。

（例示的な動作環境）
図１に、本発明を実施することのできる適切なコンピューティングシステム環境の例１００を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな限定を意味するものでもない。またコンピューティング環境１００は、この例示的な動作環境１００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。

本発明は、その他多くの汎用または専用コンピューティングシステム環境または構成でも機能する。本発明で使用するのに適するであろう周知のコンピューティングシステム、環境、および／または構成の例には、限定しないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータや、これらのシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的文脈で述べることができる。一般に、プログラムモジュールは、特定のタスクを実施するか、特定の抽象データ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は分散コンピューティング環境で実施することもでき、その場合、タスクは通信ネットワークを介してリンクされたリモート処理デバイスによって実施される。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、限定しないが、処理ユニット１２０と、システムメモリ１３０と、システムメモリを含めた様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含めて、いくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、メザニンバスとも呼ばれるＰＣＩ（Peripheral Component Interconnect）バスが含まれる。

コンピュータ１１０は通常、様々なコンピュータ読み取り可能記憶媒体を備える。コンピュータ読み取り可能記憶媒体は、コンピュータ１１０からアクセスできる任意の利用可能な媒体とすることができ、揮発性と不揮発性の媒体、取外し可能と取外し不可能の媒体の両方がこれに含まれる。限定ではなく例として、コンピュータ読み取り可能記憶媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体が含まれる。コンピュータ記憶媒体には、限定しないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、またはその他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用でき、コンピュータ１１０からアクセスできるその他の任意の媒体が含まれる。通信媒体は通常、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波やその他のトランスポート機構などの被変調データ信号に組み入れるものであり、任意の情報送達媒体がこれに含まれる。用語「被変調データ信号」は、信号中の情報が符号化される形で、１つまたは複数の特性が設定または変更される信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークや直接有線接続などの有線媒体と、音響、無線周波数、赤外線などの無線媒体およびその他の無線媒体とが含まれる。以上のいずれかの組合せも、コンピュータ読み取り可能記憶媒体の範囲に含めるべきである。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（basic input/output system）１３３が記憶されている。ＲＡＭ１３２は通常、処理ユニット１２０がすぐにアクセス可能な、および／または処理ユニット１２０が現在作用している、データおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７を示す。

コンピュータ１１０は、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例にすぎないが、図１には、取外し不可能な不揮発性の磁気媒体に対して読み書きするハードディスクドライブ１４１と、取外し可能な不揮発性の磁気ディスク１５２に対して読み書きする磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭやその他の光媒体など取外し可能な不揮発性の光ディスク１５６に対して読み書きする光ディスクドライブ１５５を示す。この例示的な動作環境で使用できるその他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体には、限定しないが、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インタフェース１４０などの取外し不可能メモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０などの取外し可能メモリインタフェースでシステムバス１２１に接続される。

以上に論じ、図１に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、その他のデータの記憶域をコンピュータ１１０に提供する。例えば、図１には、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７を記憶しているのが示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７と同じものとすることもでき、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７が少なくとも異なるコピーであることを示すために、異なる番号を付けてある。ユーザは、キーボード１６２、マウスやトラックボールやタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力デバイスを介して、コンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、ハンドヘルドＰＣやその他のライティングタブレットのタッチセンシティブ画面などを含めることができる。これらおよびその他の入力デバイスは、システムバス１２１に結合されたユーザ入力インタフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、その他のインタフェースおよびバス構造で接続されてもよい。モニタ１９１またはその他のタイプの表示デバイスも、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、スピーカ１９７やプリンタ１９６など、その他の周辺出力デバイスも備えることができ、これらは出力周辺インタフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードとすることができ、通常はコンピュータ１１０に関して上述した要素の多くまたはすべてを備えるが、図１にはメモリ記憶デバイス１８１だけが示してある。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、インターネットでよくみられる。

ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２またはその他の手段を備える。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１上にあるのが示されている。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するためのその他の手段を使用してもよいことは理解されるであろう。

（消費リソースの制限）
図２は、本発明の様々な態様による、本発明を実施するのに使用できる例示的なバージョンストアを表すブロック図である。バージョンストアは、データベース２０５と、トランザクションログ２１０と、いくつかのトランザクションのための消費リソース２１５〜２１７とを備える。消費リソース２１５〜２１７は、部分的にまたは完全に、トランザクションログ２１０に記憶することができる。各トランザクションの下付き文字は、トランザクションが開始された時間順を示す。例えば、トランザクションＴ_１はトランザクションＴ_２よりも前に開始され、トランザクションＴ_２はトランザクションＴ_３よりも前に開始された。

バージョンストア中では、クライアント（図示せず）がデータベース２０５とのトランザクションを開始する度に、データベースの「スナップショット」が作成される。論理的には、「スナップショット」は、特定の時点におけるデータベースの複製である。スナップショット作成時にデータベースのまったく新しいコピーを作成するのではなく、トランザクションログを使用してトランザクション開始時からのデータベース中の差分（例えばデルタ）を追跡することができ、したがって、トランザクション開始時のデータベースの状態をトランザクションログから得ることができる。

トランザクションには、原子性、一貫性、分離性、持続性がある。トランザクション中、様々なレコードの変更が生じることがある。データベース中でレコードを直接変更する代わりに、変更すべきレコードをコピーし、このコピーを修正することができる。データベースの他のクライアントは、トランザクションがコミットされるまで、これらの変更を見ることができないものとすることができる。トランザクションがコミットされると、これらの変更は原子性の動作でデータベースに伝搬される。変更は、修正されたコピーを再びデータベースにコピーすることによって、データベースに伝搬することができる。トランザクションがアボートされた場合は、変更は破棄され、データベースに伝搬されない。変更は、少なくともトランザクションがコミットまたはアボートされるまでは、トランザクションログ２１０に記憶することができる。

トランザクション中、変更すべきレコードをトランザクションログ２１０にコピーすることができる。コピーされたこれらのレコードは、トランザクションログ２１０中のリソースを消費する。トランザクションがすべて固定サイズである場合は、各トランザクションにつき消費されるリソースの量も固定とすることができる。トランザクションのサイズが様々であるかもしれない場合は、各トランザクションにつき消費されるリソースの量もまた様々であることがある。

バージョンストアは他の方法で実現することもできるが、そのようなバージョンストア中でも、リソースは、トランザクションが進行中のときは消費され、また、トランザクションがコミットまたはアボートした後も消費され続けることがある。バージョンストアは、本発明の趣旨または範囲を逸脱することなく様々な方法で実現することができる。

一度に複数のトランザクションが進行している場合がある。進行中のトランザクションに関連するリソースは、このトランザクションよりも前に開始されたすべてのトランザクションが完了（すなわちコミットまたはアボート）するまで、再使用のために返すことができない場合がある。これを、トランザクションのための消費リソース２１５〜２１７間の依存矢印で示す。例えば、Ｔ_１が進行中の間にＴ_３が発生し、次いでＴ_３がコミットした場合、Ｔ_３のための消費リソース２１７は、Ｔ_１のための消費リソース２１５が解放されるまで解放できないことがある。

より正式には、時間順に発行されるトランザクションＴ_１からＴ_ｎがある場合に（すなわちＴ_１はＴ_２に先行し、Ｔ_２はＴ_３に先行し、以下同様）、δ_１からδ_ｎは、各トランザクションによって消費されるリソースの量を表すものとする。この場合、Σδ_ｉ（１≦ｉ≦ｎ）は、トランザクションＴ_１からＴ_ｉが進行中のときの、任意の時点における消費リソースの総量である。

しかし、トランザクションＴ_ｋが完了したとき、解放できるリソースの量は次のうちのどちらかである。
１．未処理のトランザクションＴ_ｉ（ｉ＜ｋ）が存在する場合は０である。
２．ｊがあり、ｊ＞ｋであってＴ_ｊが進行中のトランザクションである場合、解放できるリソースの量は、（（ｋ＜ｉ＜ｊ）かつ（Ｔ_ｉは完了済み））であるようなすべてのｉについてのΣδ_ｉである。ｊは、Ｔ_ｋよりも後に開始されてまだ進行中であるトランザクションはないことを示すことができることに留意されたい。ｊを無限大に設定するかまたは最大値を示す数に設定することによって、これを示すことができる。

上述のリソース解放条件を別の言い方で言うと、Ｔ_ｋの完了時、Ｔ_ｋが最も古いトランザクションでない限り（すなわち、Ｔ_ｉが進行中トランザクションであるような、ｉ＜ｋがない場合でない限り）、リソースを解放することはできない。

所与の時点で消費できるリソース総量よりも多くのリソースを必要とするのを避けるために、バージョンストアのクライアントに、このクライアントが超過することのできないリソース限度を割り当てることができる。クライアントは、トランザクションを開始することで限度を超過するかもしれないかどうかを判定して、十分なリソースが利用可能になるまでブロック（例えば待機）することができ、それにより、開始しようとするトランザクションは何でも、消費できるリソース総量を超過せずに完了できることを保証することができる。所与の時点でクライアントが消費できるリソース総量を、以下ではΘとして表すことがある。

リソースが利用可能になるまでクライアントにブロックさせることによって進行中トランザクションの数を制限するために、ＩｎｉｔｉａｌｉｚｅＲｅｓｏｕｒｃｅ（ρ）、ＡｃｑｕｉｒｅＲｅｓｏｕｒｃｅ（Ｔ，δ）、ＲｅｌｅａｓｅＲｅｓｏｕｒｃｅ（Ｔ）の３つのプリミティブを使用することができる。

ＩｎｉｔｉａｌｉｚｅＲｅｓｏｕｒｃｅ（ρ）は、第１のトランザクションが開始される前の任意の時点で呼び出すことができる。ＩｎｉｔｉａｌｉｚｅＲｅｓｏｕｒｃｅ（ρ）が呼び出されると、消費されるリソースの総数（以下σ）が、進行中のトランザクションがないときに消費されるリソースの残量に割り当てられる。例えば、データ構造の作成など、バージョンストアの維持に関連するオーバーヘッドがある場合がある。このオーバーヘッドはＩｎｉｔｉａｌｉｚｅＲｅｓｏｕｒｃｅ（ρ）によって明らかにすることができ、ρは、進行中のトランザクションがないときに消費されるリソースの量に等しい。σ＜Θでない限り、トランザクションの開始は許可されないものとすることができる。

ＡｃｑｕｉｒｅＲｅｓｏｕｒｃｅ（Ｔ，δ）は、Ｔで識別されるトランザクションを開始する前に呼び出すことができる。Ｔは、呼出し元によってトランザクションごとに割り振られるメモリ中の固有オブジェクトである。ＡｃｑｕｉｒｅＲｅｓｏｕｒｃｅ（Ｔ，δ）は、条件（δ＋σ）≦Θをチェックし、この条件が真である場合は戻り、δに達する量のリソースを消費する新しいトランザクションを、呼出し元が開始するのを可能にする。この条件が偽である場合は、ＡｃｑｕｉｒｅＲｅｓｏｕｒｃｅ（Ｔ，δ）は、この条件が満たされるまでブロックし、σをδ＋σに割り当て、次いで戻る。

ＲｅｌｅａｓｅＲｅｓｏｕｒｃｅ（Ｔ）は、トランザクションＴが完了した後で呼び出すことができる。ＲｅｌｅａｓｅＲｅｓｏｕｒｃｅ（Ｔ）は、非ブロッキングプリミティブとして実施することができる。

本発明の一実施形態では、δは、各トランザクションにおける更新の予測数になるように選択することができる。概して、この数は定数になる。この場合、δは１になるように選択することができ、あるいは、Θがδで計算される限り、その他の任意の定数になるように選択することができる。δがトランザクションごとに異なるかもしれない場合、δは、リソースのベースライン数の倍数として表すことができる。例えば、呼出し元は、バージョンストア中の４つのレコードを修正することを知っており、１つのレコードだけを修正する場合に渡されるδの４倍のδを渡すことができる。

本発明の別の実施形態では、δはクレジットの形で特性を示すことができ、利用可能なクレジット総計はΘに等しく、δは呼出し元によって各トランザクションにつき計算される。

典型的なセマフォを使用して、リソース使用を追跡することができる。セマフォは、整数値に初期化することのできる変数であり、以下の３つの操作を提供する。
Ｉ（セマフォ，δ）：この操作は、セマフォをδに初期化する。
Ｐ（セマフォ，δ）：この操作は、セマフォ≧δまでブロックし、次いで、戻る前にδをセマフォから引く。
Ｖ（セマフォ，δ）：この操作は、δをセマフォに加え、セマフォに対してブロックされたスレッドがあればそのスレッドを起動し（wake up）、次いで戻る。

上述の各操作は原子性である。理想的には、Ｖは、δが満たせるのとちょうど同数のスレッドを起動することになる。様々なＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムでは、これらの操作は、ＣｒｅａｔｅＳｅｍａｐｈｏｒｅ（）、ＷａｉｔＦｏｒＳｉｎｇｌｅＯｂｊｅｃｔ（）、ＲｅｌｅａｓｅＳｅｍａｐｈｏｒｅ（）によってそれぞれ実施することができる。他のオペレーティングシステムは、本発明の趣旨または範囲を逸脱することなく、他の呼出しでこれらの操作を実施することができる。

上述のプリミティブが与えられた場合、σは、消費することが許されるリソースの総量であるΘに初期化される、セマフォとして実現することができる。ＡｃｑｕｉｒｅＲｅｓｏｕｒｃｅ（）を実施して、Ｐ（σ，δ）を発行することができる。これは、消費リソース総量が≦Θになることを保証する。

ＲｅｌｅａｓｅＲｅｓｏｕｒｃｅ（）は、Ｔよりも古い進行中トランザクションがある場合は、セマフォＶ（σ，δ）を送らなくてもよい。より古い進行中トランザクションがあるかどうか判定するために、図３に示す双方向リンクリスト３００を利用することができる。リスト３００に含まれるノードがヘッドノード３０５とニルノード３１５だけのときは、リストは空である。ヘッドノード３０５によってリンクされた第１のノードがニルノード３１５でない限り、リストの先頭はこの第１のノード（すなわちノード３１０）である。内部ノード３１０〜３１２はそれぞれ、１つのトランザクションに対応するものとすることができ、識別子Ｔと、そのトランザクションによって消費されるリソースの量とを含むことができる。

所与の時点で、この双方向リンクリストは、

を構成することができ、トランザクションは時間順に左から右に並んでいる。Ｔによって消費されるリソースの量を返す機能を実施することができる。以下、Ｔによって消費されるリソースの量をΔ（Ｔ）として表すことがある。各ノードに関連するリソース量を記憶するために、各ノード中でメモリを予約することができる。

リストに対する相互排他を保証するためのロックを実施することもできる。いくつかの例示的なロックには、スピンロック、ミューテックス、同期イベントなどが含まれる。ただし、本発明の趣旨または範囲を逸脱することなく、リストに対する相互排他を保証する任意のロックを使用してよいことは理解されるであろう。ロックを使用して、リストの挿入または走査または検索の間にリストが別のプロセスによって変更されないよう保護することができる。この文書では、これらのロックプリミティブをＡｃｑｕｉｒｅＬｉｓｔＬｏｃｋ（）およびＲｅｌｅａｓｅＬｉｓｔＬｏｃｋ（）として表すことがある。

トランザクションのためのリソースを獲得する例示的なアルゴリズムは以下のとおりである。

上記のアルゴリズムは、トランザクションの開始前に呼び出されるものであり、これを図４に示す。図４は、本発明の様々な態様による、トランザクションを開始するためにリソースを獲得する際に行うことのできる動作を全体的に表す流れ図である。

ブロック４０５でプロセスは開始する。ブロック４０７で、δ＞Θであるかどうか判定する。そうである場合は、処理はブロック４１２に分岐し、エラーと共に戻る。そうでない場合は、処理はブロック４１０に分岐する。δ＞Θであることは、このトランザクションが、使用を許されるリソース総量よりも多くのリソースを使用する可能性があることを示す。十分なリソースが利用可能になるのを（そうなることはないが）待機して、永遠にブロックするのではなく、ブロック４１２でエラーが返される。

ブロック４１０で、ノードのためのメモリを得る。ブロック４１５で、トランザクションＴによって必要とされる可能性のあるリソースを示すノード中の変数をδに初期化する。ブロック４２０で、Ｐ（σ，δ）を実行する。これは、（より多くのリソースが利用可能になるまで）ブロックすることができる。ブロック４２５で、リンクリストに対するロックを獲得する。ブロック４３０で、ノードをリストの末尾に挿入する。ブロック４３５で、ロックを解除する。ブロック４４０で、プロセスは、成功の指示と共に戻る。

図５は、本発明の様々な態様による、トランザクション完了後にリソースを解放する前に行うことのできる動作を、全体的に表す流れ図である。このプロセスは、トランザクションのコミットまたはアボートの前に呼び出される。ブロック５０５でプロセスは開始する。ブロック５１０で、リンクリストに対するロックを獲得する。ブロック５１２で、完了したばかりのトランザクションに関連するノード（すなわちＴ）を突き止める。ブロック５１５で、Ｔがリストの先頭であるかどうか判定する。ヘッドノードがＴを指している場合に、Ｔはリストの先頭であることを想起されたい。Ｔがリストの先頭である場合は、処理はブロック５２０に分岐し、そうでない場合は、処理はブロック５２５に分岐する。

ブロック５２０で、Ｔで示される消費リソースをセマフォに加え、セマフォに対してブロックされたスレッドがあれば、それらを起動する（awake）。Ｔで示される消費リソースは、このノードのすぐ右にあるノードに関連するトランザクションが完了したときに、上方に調整できることに留意されたい（例えばブロック５２５および５３０参照）。

ブロック５２５および５３０で、Ｔで示されるリソースを、Ｔのすぐ左にあるノード（すなわちＴ’）に加えるための準備を行う。Ｔがリストの先頭ではないので、Ｔ’の存在が保証されることに留意されたい。ブロック５２５でＴ’を突き止める。ブロック５３０で、Ｔで示される消費リソースをＴ’で示される消費リソースに加える。

ブロック５３５で、Ｔをリンクリストから除去する。ブロック５４０で、リンクリストに対するロックを解除する。ブロック５４５でプロセスは戻る。

前述のプリミティブによって、このアルゴリズムを以下のように表すことができる。

図３〜５を双方向リンクリストに関して述べ、したがって獲得／解放プリミティブについてＯ（１）実装形態が達成されたが、ハッシュテーブル、単方向リンクリスト、アレイ、階層構造など、他のデータ構造を使用してもよいことは理解されるであろう。実際、本発明の趣旨および範囲を逸脱することなく、トランザクションの時間順を維持することのできる任意のデータ構造を使用することができる。

図６は、本発明の様々な態様による、本発明を実施することのできる例示的な環境を表すブロック図である。この環境は、クライアント６０５、サーバ６１０、バージョンストア６１５を含む。本発明の一実施形態では、図４および５に関して述べたプロセスはクライアント６０５上で実行され、サーバ６１０は、バージョンストア要求を受け取り、バージョンストア６１５を維持するのに必要な動作を実施する。本発明のこの実施形態では、クライアントがそのトランザクションを制限するのに使用するリソース限度を、クライアント、サーバ、専用プログラム、コンピュータ管理者などが選択することができる。本発明の一実施形態では、クライアント６０５は、サーバ６１０に照会して、サーバ６１０が他のクライアントに対する性能を大きく低下させることなく、いくつのリソースをクライアント６０５のために確保できるかを決定することができる。本発明の趣旨または範囲を逸脱することなく、クライアント６０５、サーバ６１０、バージョンストア６１５のいずれかが、共に１つのマシン上に含まれてもよく、あるいは別々のマシン上にあってもよいことに留意されたい。

図７は、本発明の様々な態様による、本発明を実施することのできる別の例示的な環境を表すブロック図である。この環境は、サーバ７０５、バージョンストア７１０、４つのクライアント７１５〜７１８を含む。図７に示す実施形態では、各クライアント７１５〜７１８がバージョンストア７１０とのトランザクションを開くことを試みることができる。クライアントの活動が組み合わさることによって、トランザクション実施の際に消費されるリソースが、全体的な限度を超過することがないよう保証するために、各クライアントに限度を割り当て、すべてのクライアントがその限度に達しても全体的な限度を超過しないようにすることができる。各クライアントに対するリソース限度は、クライアント、サーバ、クライアント間の交渉、専用プログラム、コンピュータ管理者などが決定することができる。各クライアントに対するリソース限度の決定は、クライアントがバージョンストア７１０とのトランザクションに携わる前に行うことができ、動的に変更することができる。例えば、クライアント７１５は頻繁にブロックしているがクライアント７１６は一定量以上のリソースを消費しない場合は、クライアント７１６に関連するリソース限度を低減させ、クライアント７１５に割り当てられたリソース限度を増大させることができる。

以上の詳細な記述からわかるように、バージョンストアのリソース使用を制限するための方法およびシステムが提供される。本発明は様々な修正および代替構造が可能だが、そのいくつかの例示的な実施形態を詳細に図示および上述した。ただし理解されたいが、開示した特定の形に本発明を限定する意図はなく、反対に、本発明の趣旨および範囲に含まれるすべての修正、代替構造、均等物をカバーするものとする。

本発明を組み込むことのできるコンピュータシステムを表すブロック図である。 本発明の様々な態様による、本発明を実施するのに使用することのできる例示的なバージョンストアを表すブロック図である。 本発明の様々な態様による例示的なデータ構造を示すブロック図である。 本発明の様々な態様による、トランザクションを開始するためにリソースを獲得する際に行うことのできる動作を全体的に表す流れ図である。 本発明の様々な態様による、トランザクション完了後にリソースを解放する前に行うことのできる動作を全体的に表す流れ図である。 本発明の様々な態様による、本発明を実施することのできる例示的な環境を表すブロック図である。 本発明の様々な態様による、本発明を実施することのできる別の例示的な環境を表すブロック図である。

Claims (36)

1. コンピュータ実行可能命令を有するコンピュータ読み取り可能記憶媒体であって、前記命令は、
   バージョンストアに関係する複数のトランザクションを完了するのに使用可能なリソースの量を追跡すること、
   新しいトランザクションを開始する前に、前記新しいトランザクションを完了するのに十分なリソースが利用可能かどうか判定すること、
   十分なリソースが利用可能な場合に、前記新しいトランザクションを開始すること、および、
   十分なリソースが利用可能でない場合に、より多くのリソースが利用可能になるまで待機すること
   を含むことを特徴とするコンピュータ読み取り可能記憶媒体。
2. 前記複数のトランザクションのうち少なくとも１つは進行中であることを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
3. 前記命令は、前記複数のトランザクションによって使用可能なリソースの量に対する限度を設定することをさらに含むことを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
4. 前記バージョンストアは、各トランザクションが開始する前にデータベースの新しいスナップショットを作成することを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
5. 前記スナップショットは、差分としてログファイル中で保持されることを特徴とする請求項４に記載のコンピュータ読み取り可能記憶媒体。
6. 前記データベースは、前記新しいスナップショットが作成される前の第１の状態を有し、前記データベースの前記第１の状態は、前記データベースの第２の状態と共に前記ログファイルから作成可能であることを特徴とする請求項４に記載のコンピュータ読み取り可能記憶媒体。
7. より多くのリソースが利用可能になるまで待機することは、前記リソースが利用可能になるまでスレッドをブロックすることを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
8. 前記命令は、
   前記バージョンストアに関係する複数のトランザクションを完了するのに使用可能なリソースの量を追跡するデータ構造のロックを得ること、
   前記新しいトランザクションに関係する情報を含めるように前記データ構造を修正すること、および、
   その後で前記ロックを解除すること
   をさらに含むことを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
9. 前記データ構造は双方向リンクリストを含み、前記新しいトランザクションに関係する情報を含めるように前記データ構造を修正することは、前記データ構造にノードを追加することを含むことを特徴とする請求項８に記載のコンピュータ読み取り可能記憶媒体。
10. 前記データ構造は前記トランザクションを時間順に順序付けることを特徴とする請求項８に記載のコンピュータ読み取り可能媒体。
11. 前記命令は、トランザクションを完了し、前記トランザクションが他のまだ進行中のトランザクションのいずれかよりも前に開始したものである場合に、前記複数のトランザクションを完了するのに使用可能な前記リソース量を修正することをさらに含むことを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
12. 前記命令は、トランザクションを完了し、前記トランザクションが他のまだ進行中のトランザクションのいずれかよりも後に開始したものである場合に、使用可能な前記リソース量を修正しないことをさらに含むことを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
13. 前記命令は、前記完了したトランザクションによって使用可能なリソースの量を追加するために、前の進行中トランザクションに関連するデータを修正することをさらに含むことを特徴とする請求項１２に記載のコンピュータ読み取り可能記憶媒体。
14. 前記命令は、前記前のトランザクションを完了し、使用可能な前記リソース量を修正して、前記データによって示されるリソース量を解放することをさらに含むことを特徴とする請求項１３に記載のコンピュータ読み取り可能記憶媒体。
15. バージョンストアに関係する複数のトランザクションを完了するのに使用可能なリソースの量を追跡することは、セマフォに対してブロックすることを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能記憶媒体。
16. リソース使用を制限する方法であって、
    進行中のトランザクションによって消費することのできるリソースの総量を示す限度を設定すること、
    いずれかの新しいトランザクションによって使用されることになる残りのリソース残量を示す累計を保持すること、および、
    前記累計と、新しいトランザクションを完了するのに必要な可能性のあるリソース必要量とに基づいて、前記新しいトランザクションを完了するのに十分なリソースがあるかどうか判定すること
    を含むことを特徴とする方法。
17. 前記累計を前記限度に初期化することをさらに含むことを特徴とする請求項１６に記載の方法。
18. 前記新しいトランザクションを開始するのに十分なリソースがある場合に、前記新しいトランザクションを開始することをさらに含むことを特徴とする請求項１６に記載の方法。
19. 前記新しいトランザクションを開始するのに十分なリソースがあるかどうか判定することは、前記累計から前記リソース必要量を引いて結果を出し、前記結果が０以上かどうかを判定することを含むことを特徴とする請求項１６に記載の方法。
20. データ構造に対するロックを得て前記データ構造を修正することをさらに含むことを特徴とする請求項１６に記載の方法。
21. 前記データ構造は、進行中のトランザクションの開始時に従って時間順に順序付けられた双方向リンクリストであることを特徴とする請求項２０に記載の方法。
22. 完了したばかりのトランザクションに関連する、前記双方向リンクリストのノードが、前記双方向リンクリストの先頭にあるかどうか判定することをさらに含むことを特徴とする請求項２０に記載の方法。
23. 前記ノードが前記双方向リンクリストの先頭にある場合は、前記ノードで示される量だけ前記累計を増加させることを特徴とする請求項２２に記載の方法。
24. 前記ノードが前記双方向リンクリストの先頭にない場合は、前記ノードで示されるリソースを、前記双方向リンクリスト中で前記ノードに先行する別のノードに追加し、前記ノードを除去することを特徴とする請求項２２に記載の方法。
25. トランザクションが完了した後で前記累計を増加させ、開始するのに十分なリソースがないためにブロックしていた新しいトランザクションに関連するスレッドがあればそれらを起動することをさらに含むことを特徴とする請求項１６に記載の方法。
26. リソース使用を制限するためのシステムであって、
    バージョンストアと対話するように構成された第１のクライアントを備え、前記第１のクライアントはさらに、
    前記第１のクライアントが前記バージョンストアとのトランザクションに携わる結果として消費することのできるリソースの総量を示す第１の限度を得る動作と、
    前記第１のクライアントによって開始されるいずれかの新しいトランザクションによって使用されることになる残りのリソース残量を示す第１の総計を保持する動作と、
    前記第１の総計と、新しいトランザクションを完了するのに必要な可能性のあるリソース必要量とに基づいて、前記新しいトランザクションを開始するのに十分なリソースがあるかどうか判定する動作と
    を実施するように構成されたことを特徴とするシステム。
27. 前記バージョンストアと対話するように構成された第２のクライアントをさらに備え、前記第２のクライアントはさらに、
    前記第２のクライアントが前記バージョンストアとのトランザクションに携わる結果として消費することのできるリソースの総量を示す第２の限度を得る動作と、
    前記第２のクライアントによって開始されるいずれかの新しいトランザクションによって使用されることになる残りのリソース残量を示す第２の総計を維持する動作と、
    前記第２の総計と、新しいトランザクションを完了するのに必要な可能性のあるリソース必要量とに基づいて、前記新しいトランザクションを開始するのに十分なリソースがあるかどうか判定する動作と
    を実施するように構成されたことを特徴とする請求項２６に記載のシステム。
28. 前記第１および第２の限度は、前記クライアント間の交渉を介して得られることを特徴とする請求項２７に記載のシステム。
29. 前記第１および第２の限度は、各クライアントに関するシステム設定を介して得られることを特徴とする請求項２７に記載のシステム。
30. 前記第１および第２の限度は、ユーザ入力を介して得られることを特徴とする請求項２７に記載のシステム。
31. 定期的に実行され、前記第１および第２の総計の履歴に基づいて前記第１および第２の限度を調整するように構成されたプログラムをさらに備えることを特徴とする請求項２７に記載のシステム。
32. 前記バージョンストアへのアクセスを提供するように構成されたサーバをさらに備えることを特徴とする請求項２７に記載のシステム。
33. 各クライアントはさらに、前記サーバと通信して、各クライアントによって消費することのできるリソースの総量を示す各クライアントの限度を設定するように構成されたことを特徴とする請求項２７に記載のシステム。
34. 前記第１の限度を得る動作は、前記第１のクライアント上のストアから前記第１の限度を取り出す動作を含むことを特徴とする請求項２６に記載のシステム。
35. 前記第１の限度を得る動作は、サーバと通信する動作を含むことを特徴とする請求項２６に記載のシステム。
36. 前記バージョンストアは、ファイル複製システムに使用されることを特徴とする請求項２６に記載のシステム。
    

Images