JP3606542B2 - 基礎データの変更がオブジェクトにどのように影響するかの判定方法およびプログラム記憶装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、改良されたデータ処理システムに関する。具体的な態様は、ワールド・ワイド・ウェブ、データベースおよびトランザクション処理システムに関する。より具体的な態様は、ワールド・ワイド・ウェブのダイナミック・ドキュメントのキャッシュ記憶に関する。
【０００２】
【従来の技術】
ワールド・ワイド・ウェブからダイナミック・ドキュメントを取り出すことのできる速度は、ウェブが情報転送および電子商取引のサポートのためにどれほど有用であるかに関する最も重要な要因の１つである。ウェブ・サーバは、コンテンツをユーザにすばやくサービスすることができなければならない。ウェブ・サーバによって配布されるデータは、次の２つの範疇に分類できる。
（１）静的データ。このデータは、コンピュータに格納されたファイルから取得される。静的データは、比較的すばやくサービスすることができる。単一のＲＳ／６０００ ５９０ノードなどのコンピュータ上で走行する高性能ウェブ・サーバは、通常は、毎秒数百ファイルを配布できる。
（２）動的データ。このデータは、要求が行われた時点でプログラムを実行することによって取得される。動的データは、作成が高くつくことがしばしばである。多くの場合に、動的データは、静的データの取得より１桁から２桁高くつく。
【０００３】
高い比率の動的データを含むウェブ・サイトの場合、動的データの性能がボトルネックになる可能性がある。高い比率の動的データを含むサイトの例には、ＬＬ Ｂｅａｎ社のウェブ・サイト（ｗｗｗ．ｌｌｂｅａｎ．ｃｏｍ）などのＩＢＭ社のｎｅｔ．Ｃｏｍｍｅｒｃｅソフトウェアを使用する電子商取引サイトや、ＩＢＭ社の１９９６年オリンピック・ウェブ・サイトが含まれる。
【０００４】
動的データのオーバーヘッドを減らす方法の１つが、プログラムによってダイナミック・ページを作成した後に、そのページをキャッシュに格納することである（リュウ（Ｙ．Ｈ．Ｌｉｕ）、ダンチッヒ（Ｐ．Ｄａｎｔｚｉｇ）、ウー（Ｃ．Ｅ．Ｗｕ）、チャレンジャ（Ｊ．Ｃｈａｌｌｅｎｇｅｒ）、ナイ（Ｌ．Ｍ．Ｎｉ）共著、「Ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｗｅｂ Ｓｅｒｖｅｒ ａｎｄ ｉｔｓ Ｐｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｓｉｓ ｏｎ Ｍｕｌｔｉｐｌｅ Ｐｌａｔｆｏｒｍｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｆｏｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ、１９９６年５月を参照されたい）。この方法では、これらのページへのアクセスを必要とする後続の要求で、キャッシュ内のコピーにアクセスすることができる。あるページは、プログラムによって１回計算するだけでよい。複数の要求に応答して同一のページを複数回再計算するためのオーバーヘッドが、削減または除去される。
【０００５】
キャッシュ記憶は、すべてのダイナミック・ウェブ・ページに適用できるわけではない。一部のダイナミック・ページは、ページが要求されるたびに必ず発生する状態変化を引き起こす。このようなページは、キャッシュ記憶することができない。
【０００６】
【発明が解決しようとする課題】
キャッシュ記憶できるページの場合、１つまたは複数のウェブ・ページの値に影響する可能性がある基礎データに対する変更が発生した時に、キャッシュを更新する方法の必要が残っている。たとえば、ダイナミック・ウェブ・ページは、データベースから構築されることがしばしばである。データベースが変更された時には、データベース変更の結果として古くなったキャッシュ・オブジェクトの判定が、極端に困難になる可能性がある。本発明は、この問題に対する解決を提供する。この解決は非常に一般的であり、基礎データに対する変更がオブジェクトの値にどのように影響するかを知る必要がある他の状況で使用することができる。
【０００７】
もう１つの問題は、基礎データのソースとキャッシュが地理的に異なる位置にある時に、１つまたは複数のキャッシュの組を更新された状態に保つ方法である。本発明は、動的データと静的データの両方の代理キャッシュ記憶に関連するこの問題に対する解決を有する。
【０００８】
第３の問題は、１つまたは複数のキャッシュに対する更新の組の一貫性を保ち、その結果、すべての更新が同時に行われ、システムによって受け取られる要求が、更新に関して、後に受け取られた要求より後のシステムの状態を見ることがなくなるようにする方法である。本発明は、静的データと動的データの両方の代理キャッシュ記憶に関連する一貫性の問題に対する解決を有する。これは、必ずしもキャッシュを使用しないトランザクション・システムにも関連する。
【０００９】
当技術分野には、コンピュータ・プログラムの作成に必要なファイルの間の依存性を管理するためのユーティリティが存在する。たとえば、単一のプログラムが、複数のソース・ファイルおよびオブジェクト・ファイルから構築される場合がある。ソース・ファイル、オブジェクト・ファイルおよび実行可能ファイルの間の依存性を管理するためのツールが開発されてきた。このような依存性を管理するための周知のユーティリティの１つが、Ｕｎｉｘのｍａｋｅコマンドである（たとえば、ＩＢＭ ＡＩＸ Ｖｅｒｓｉｏｎ ４のオンライン・マニュアルを参照されたい）。ｍａｋｅなどのユーティリティでは、ユーザが、メイクファイルと称する特殊なファイルでファイル間の依存性を指定する必要がある。たとえば、次のファイル依存性の指定
ｆｏｏ： ｆｏｏ．ｈ ｆｏｏ．ｃ
ｃｃ −ｏ ｆｏｏ ｆｏｏ．ｃ
をメイクファイルに記述して、「ｆｏｏ」が「ｆｏｏ．ｈ」と「ｆｏｏ．ｃ」に依存することを示す。「ｆｏｏ．ｈ」または「ｆｏｏ．ｃ」のいずれかに対する変更があれば、次にコマンド「ｍａｋｅ ｆｏｏ」が発行された時に、コマンド「ｃｃ −ｏ ｆｏｏ ｆｏｏ．ｃ」を使用して、「ｆｏｏ」が再コンパイルされることになる。
【００１０】
ｍａｋｅなどのユーティリティは、以下を含む複数の制限を有する。
（１）ｍａｋｅでは、ファイル間の依存性しか指定できない。ファイルとファイル以外のものの間の依存性を指定することはできない。キャッシュに格納できるオブジェクトと、キャッシュ記憶することができないグラフ・オブジェクト（基礎データを含む）との間の依存性を指定できるようにする方法が必要である。（２）ｍａｋｅによるアプローチを使用する場合、ファイルがどれほど古いかに無関係に、古いとわかったファイルは「ｍａｋｅ」コマンドによって必ずすべてが更新される。古いオブジェクトを必ず更新することを必要としない方法の必要も存在する。たとえば、その結果、ほんのわずかに古いオブジェクトをキャッシュに保持することができる。
（３）ｍａｋｅによるアプローチでは、ファイル・システム内に同時には１つのバージョンのファイルだけが存在することを許可される。同一オブジェクトの複数のバージョンが同一のキャッシュ内に同時に存在することを許容する方法の必要が存在する。
（４）あるオブジェクトがどの程度古いかを判定する、ｍａｋｅなどのツールが提供しない定量的な方法を提供する方法の必要も存在する。
（５）同一オブジェクトの２つのバージョンがどの程度類似しているかを判定する、ｍａｋｅなどのツールが提供しない定量的な方法を提供する方法の必要が存在する。
（６）おそらく古いオブジェクトの一貫性のあるセットを保持する、ｍａｋｅなどのツールが提供しない方法の必要も存在する。
（７）関係データベースの一部とすることのできる関係オブジェクトと称するオブジェクト間の依存性を簡潔に指定するための、ｍａｋｅなどのツールが提供しない方法の必要が存在する。
【００１１】
本発明は、これらの必要に対処する。
【００１２】
【課題を解決するための手段】
多くの場合に、オブジェクトの値は、基礎データに依存する。本発明は、基礎データに対する変更がオブジェクトの値にどのように影響するかの判定を対象とする。
【００１３】
１例として、データベースから動的にページが作成されるウェブ・サイトを検討する。この状況では、ダイナミック・ウェブ・ページはオブジェクトであり、基礎データにデータベースが含まれる。一部の場合には、ウェブ・ページがより単純なウェブ・ページに対する依存性を有し、後者のウェブ・ページがデータベースに対する依存性を有する場合がある。オブジェクトが他のオブジェクトに依存し、そのオブジェクトが他のオブジェクトに依存する、依存性の全体階層を有することが可能である。また、オブジェクトの組のうちのいずれかのオブジェクトに対する変更が、その組の他のすべてのオブジェクトの値に影響する、１組のオブジェクトの間の共同依存性（ｃｏ−ｄｅｐｅｎｄｅｎｃｙ）を有することも可能である。
【００１４】
本発明のもう１つの態様は、コンピュータ・システムが、基礎データの変更の後にシステム内の全オブジェクトに更新を伝播できるようにする、オブジェクトと基礎データの間の依存性を指定するための方法を対象とする。この方法には、以下の特徴のうちの１つまたは複数が含まれる。
１．オブジェクトが他のオブジェクトに依存し、そのオブジェクトが他のオブジェクトに依存するなど、階層的な形で依存性を指定することができる。
２．オブジェクトの組が共同依存性を有することができる。たとえば、２つのオブジェクトが、お互いの間で依存性を有することができ、これによって、一方のオブジェクトが変更された時に必ずもう一方のオブジェクトの値が変更されることが示される。
３．オブジェクトが依存する基礎データのいずれかに変更が行われた時に、必ずオブジェクトが更新（または無効化）されることを確実にする方法。
４．あるオブジェクトの旧バージョンが現行バージョンとどれほど異なるかを判定するための定量的な方法。
５．オブジェクトが現行バージョンと十分異なる時に、必ずそのオブジェクトが更新されるか無効化されるようにする方法。これは、常にオブジェクトを現行に保つことに伴うオーバーヘッドが多すぎる時に有用である。
６．オブジェクトの新バージョンは、その値を再計算するたびに作られる。同一オブジェクトの複数バージョンを保持することができる。同一オブジェクトの２つのコピーに対して、以下の判定を行うことができる。
（ａ）２つのオブジェクトが同一バージョンに対応し、したがって、同一であるかどうか
（ｂ）（ａ）の結果が否定の場合に、どちらのバージョンがより新しい（すなわち、後で作成された）か
（ｃ）（ａ）の結果が否定の場合に、オブジェクトの相違の定量的な表示。
７．すべてのオブジェクトが現行であることを必要とせずに、オブジェクトの組の間で一貫性を維持する方法。これは、すべてのオブジェクトが現行であることを必要とすることによって一貫性を維持すると、オーバーヘッドが高くなりすぎる時に有用である。
８．関係オブジェクト間の暗黙のデータ依存性がオブジェクト・マネージャによって自動的に追加される、関係オブジェクトを管理する方法。
【００１５】
本発明の応用分野の例には、以下の状況が含まれる。
１．ダイナミック・ウェブ・ページのキャッシュ記憶。
２．クライアント−サーバ・アプリケーション。多くのクライアント−サーバ・アプリケーションでは、サーバが複数のクライアントにオブジェクトを送る。オブジェクトは、常に変化しつつある。オブジェクトが要求された時に応じて、同一オブジェクトの異なるバージョンが異なるクライアントに送られる可能性がある。サーバには、どのバージョンをどのクライアントに送ったかと、そのバージョンがどれほど古いかを記録する方法が必要である。
３．オブジェクトの複数のバージョンを維持し、それらを一意に識別し、それらが古くなりすぎた場合に更新し、同一オブジェクトの２つのバージョンの相違を定量的に評価し、オブジェクトの組の間で一貫性を維持することが必要であるすべての状況。
【００１６】
好ましい実施例では、オブジェクト依存性グラフ（Ｇ）と称する、オブジェクト間のデータ依存性を表す有向グラフを使用する。オブジェクトｏ１から別のオブジェクトｏ２への一辺は、ｏ２がｏ１に対する依存性を有することを示す。ｏ１に対する更新があれば、ｏ２の現行値も変更される。代替実施例では、辺のそれぞれに、データ依存性の重要さを表す重みと称する負でない数を関連付けることができる。たとえば、大きい数で重要な依存性を表し、小さい数で重要でない依存性を表すことができる。オブジェクトには、ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ（閾重み）と称する値を関連付けることもできる。現行の入方向のデータ依存性に対応する重みの合計がｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ未満になった時には必ず、そのオブジェクトは非常に古いとみなされる。このようなオブジェクトは、最新のバージョンのオブジェクトを必要とするアプリケーションのために更新しなければならない。各オブジェクトは、ｏｂｊｅｃｔ＿ｉｄ（オブジェクトＩＤ）フィールドとｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ（バージョン番号）フィールドを有することが好ましい。ｏｂｊｅｃｔ＿ｉｄフィールドは、アプリケーション・プログラムがオブジェクトの識別に使用するもの（たとえばＵＲＬ）に対応するが、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、同一のｏｂｊｅｃｔ＿ｉｄを有する複数のオブジェクトを維持し、一意に識別するのに使用される。
【００１７】
具体的に言うと、オブジェクト・マネージャと称するプロセスが、データ依存性情報を維持する。オブジェクトが新規作成されるかデータ依存性が変更された時には、必ず、オブジェクト・マネージャが、適当な情報を更新する責任を負う。オブジェクトが更新された時には、必ず、オブジェクト・マネージャが、オブジェクト依存性グラフの情報を使用して、データ依存性によって必要とされるシステムに対する他の更新を伝播する。
【００１８】
各オブジェクトｏ１も、ｏ１との一貫性を保たなければならないオブジェクトのリストを含む一貫性リストを有することができる。２つのオブジェクトｏ１およびｏ２は、
（１）両方のオブジェクトが現行であるか、
（２）過去のある時点ｔで、両方のオブジェクトが現行であった。
のいずれかの場合に、一貫性を有する。ｏ１に対する更新は、ｏ１の一貫性リストに含まれる他のオブジェクトに対する更新を必要とする可能性がある。
【００１９】
関係データベースの関係に類似の関係に属する１つまたは複数のレコードとオブジェクトを関連付けることが可能である。このようなオブジェクトを、関係オブジェクトと称する。本発明は、関係オブジェクト間の依存性を自動的に追加する機能も有する。
【００２０】
【発明の実施の形態】
用語集
通常の辞書の意味は本明細書で使用される単語にも適用されるが、以下の用語集は有用であろう。
【００２１】
キャッシュとは、記憶区域である。これは、メモリ内、ディスク上、または一部をメモリ内、一部をディスク上とすることができる。キャッシュに対応する物理アドレスまたは仮想アドレスは、固定することができる。その代わりに、時間に伴って変化するアドレスとすることができる。キャッシュの定義には、以下が含まれるが、これに制限されるものではない。
・ＩＢＭ Ｉｎｔｅｒｎｅｔ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｒｖｅｒのプロキシ・キャッシュやＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒのブラウザ・キャッシュなどの、ウェブ・ドキュメント用のキャッシュ
・ＩＢＭ社のＤＢ２データベースのキャッシュなどのデータベース・キャッシュ
・ＩＢＭ ＲＳ／６０００系列のコンピュータのキャッシュなどのプロセッサ・キャッシュ
・少なくとも一部のデータについて、記憶リポジトリ・プログラムがデータが格納される仮想アドレスまたは物理アドレスの明示的な制御を有しない、高水準プログラミング言語で記述されたデータの記憶リポジトリ
【００２２】
キャッシュ・ユニオンとは、システム内の全キャッシュの組み合わせである。
【００２３】
オブジェクトとは、１つまたは複数のキャッシュに格納できるデータである。
【００２４】
複数バージョン・キャッシュとは、同一オブジェクトの複数のバージョンを含むことが許容されるキャッシュである。
【００２５】
単一バージョン・キャッシュとは、同一オブジェクトの１つのバージョンだけを含むことができるキャッシュである。
【００２６】
現行バージョン・キャッシュとは、すべてのキャッシュ記憶されたオブジェクトのバージョンが現行でなければならない、単一バージョン・キャッシュである。
【００２７】
基礎データには、１つまたは複数のオブジェクトの値に影響する可能性があるシステム内のすべてのデータが含まれる。基礎データは、システム内の全オブジェクトのスーパーセットである。
【００２８】
複合オブジェクトとは、基礎データに対する１つまたは複数の依存性を有するオブジェクトである。
【００２９】
オブジェクト・マネージャとは、基礎データに対する変更がオブジェクトの値にどのように影響するかを判定するプログラムである。
【００３０】
グラフＧ＝（Ｖ，Ｅ）は、有限個の頂点Ｖ（ノードとも称する）の空ではない集合と、頂点の対からなる辺Ｅの組からなる。辺が頂点の順序付きの対（ｖ，ｗ）である場合には、そのグラフは、ｖが辺の始点、ｗが辺の終点の有向グラフと呼ばれる。
【００３１】
マルチグラフは、グラフに類似している。主な相違は、頂点の対の間に複数の辺が存在できることである。マルチグラフは、グラフのスーパーセットである。
【００３２】
重み付きグラフまたは重み付きマルチグラフは、任意選択で、各辺に重みと称する数値を関連付けることができるグラフである。
【００３３】
オブジェクト依存性グラフは、有向マルチグラフである。オブジェクト依存性グラフの頂点を、グラフ・オブジェクトと称する。グラフ・オブジェクトは、オブジェクトのスーパーセットであり、グラフ・オブジェクトには下記が含まれる。
（１）オブジェクト
（２）オブジェクトではない基礎データ
（３）仮想オブジェクト
これらのグラフ・オブジェクトは、実際のデータには対応しない。これらは、データ依存性を伝播するための手段として使用される。仮想オブジェクトは、（１）や（２）ほど頻繁には使用されない。
【００３４】
グラフ・オブジェクトｏ１からｏ２への辺は、ｏ１からｏ２へのデータ依存性（単に依存性と称する場合もある）を示す。これは、ｏ１に対する変更によってｏ２も変更される可能性があることを意味する。依存性は、推移的である。したがって、ａがｂに対するデータ依存性を有し、ｂがｃに対するデータ依存性を有する場合には、ａはｃに対する依存性を有する。
【００３５】
グラフ・オブジェクトは、関係オブジェクト（ＲＯ）でもある場合がある。ＲＯは、関係指定子を関連付けられている。ＲＯの例を２つ示す。
１．単一レコード・オブジェクト（ＳＲＯ） 関係指定子が単一のレコードを表す。
２．複数レコード・オブジェクト（ＭＲＯ） 関係指定子が複数のレコードを表す。
【００３６】
ＲＯ ｒ２によって表されるすべてのレコードがＲＯ ｒ１によって表される場合に、ＲＯ ｒ２はＲＯ ｒ１に含まれる。
【００３７】
ノードｖの出隣接リストとは、辺（ｖ，ｗ）がＥに含まれるノードｗのすべてを含むリストである。
【００３８】
ノードｖの入隣接リストとは、辺（ｗ，ｖ）がＥに含まれるノードｗのすべてを含むリストである。
【００３９】
葉ノードとは、どの辺の終点でもないノードである。
【００４０】
固有葉ノードとは、少なくとも１つの辺の始点である葉ノードである。
【００４１】
極大ノードとは、どの辺の始点でもないノードである。
【００４２】
固有極大ノードとは、少なくとも１つの辺の終点である極大ノードである。
【００４３】
単純依存性グラフとは、各ノードが葉ノードまたは極大ノードである有向グラフである。
【００４４】
２つのオブジェクトｏ１およびｏ２は、
（１）両方のオブジェクトが現行であるか、
（２）過去の時点ｔで、両方のオブジェクトが現行であった。
のいずれかの場合に、一貫性を有する。
【００４５】
バージョン番号とは、同一オブジェクトの異なるバージョンを一意に識別できるようにするためのデータである。１実施例では、バージョン番号に整数を使用し、新たに作成された現行バージョンに、その前のバージョンのバージョン番号＋１のバージョン番号を割り当てる。しかし、他の実施態様も可能であり、バージョン番号が数値である必要もない。たとえば、テキスト文字列を使用してバージョン番号を実施することもできる。
【００４６】
オブジェクトの最新バージョンを、現行バージョンと称する。
【００４７】
ここで図面を参照すると、図１は、本発明の特徴を有するクライアント−サーバ・アーキテクチャの例を示す図である。図からわかるように、クライアント９０は、ネットワーク９５を介してサーバ１００に要求を通信する。サーバ１００は、１つまたは複数のキャッシュ２を維持する。通常通り、サーバ１００は、キャッシュ２を使用して、性能を改善し、クライアント９０の要求を満足するためのＣＰＵ時間を減らす。図１には、単一のサーバに関連するキャッシュ２が示されているが、キャッシュ２は、複数のサーバにまたがって維持することもできる。当業者であれば、クライアント−サーバ・ベースではない他の応用例に本発明を簡単に適合させることができるはずである。
【００４８】
サーバ１００上で走行するアプリケーション・プログラム９７は、オブジェクトを作成し、その後、これらのオブジェクト（たとえば、要求時に状態変化を引き起こさないダイナミック・ページ）を、１つまたは複数のキャッシュ２に格納する。サーバ１００は、プロキシ・サーバとすることもでき、この場合、データベース９９内の基礎データのソースとキャッシュ２が地理的に分離される。この実施例では、オブジェクトは、１つまたは複数のキャッシュ２に格納できるデータである。オブジェクトは、データベース９９に格納された基礎データから構築することができる。基礎データには、キャッシュ２に格納される１つまたは複数のオブジェクトの値に影響する可能性があるシステム内の全データが含まれる。基礎データは、システム内の全オブジェクトのスーパーセットである。複合オブジェクトは、基礎データに対する１つまたは複数の依存性を有するオブジェクトである。
【００４９】
また、キャッシュ・ユニオン内のキャッシュ２のすべてが、現行バージョン・キャッシュであるものとする。現行バージョン・キャッシュは、キャッシュ記憶されたオブジェクトのバージョンが現行でなければならない単一バージョン・キャッシュであることと、単一バージョン・キャッシュは、同一オブジェクトの１つのバージョンだけを含むことができるキャッシュであることを想起されたい。
【００５０】
本発明によれば、キャッシュ・マネージャ１（オブジェクト・マネージャの１例である）は、基礎データに対する変更がオブジェクトの値にどのように影響するかを判定する。図１には、単一のサーバに常駐するキャッシュ・マネージャ１が示されているが、キャッシュ・マネージャを複数のサーバにまたがって分散することもできる。キャッシュ・マネージャ１は、サーバ１００（またはクライアント９０）などのコンピュータ上での実行のためにプログラム記憶装置上で具体的に実施されるコンピュータ実行可能コードとして実施されることが好ましい。当業者であれば、本発明に従って、キャッシュ２、キャッシュ・マネージャ１およびデータベース９９をクライアント９０に同様に関連付けることができることを諒解するであろう。
【００５１】
キャッシュ・マネージャ１は、キャッシュ記憶されたオブジェクトが、たとえばデータベース・レコードなど、どの基礎データに依存するかを指定するためのＡＰＩ（図６）を提供する。キャッシュ・マネージャ１は、これらの依存性を記憶する。あるプロセスがキャッシュ内の複合オブジェクトの値に影響する可能性のある状態を変更する時には、必ず、そのプロセスが、更新する基礎データを指定する。その後、キャッシュ・マネージャは、更新される基礎データに依存するキャッシュ記憶されたオブジェクトのすべてを無効化する。
【００５２】
図２は、本発明の特徴を有するオブジェクト依存性グラフＧ１２１’の例を示す図である。この実施例のＧ１２１’は、代替実施例（図１５）より単純であることに留意されたい。この場合、Ｇ１２１’は、単純依存性グラフ、すなわち各ノードが葉ノードｒ１…ｒ４または極大ノードｃｏ１およびｃｏ２である有向グラフである。葉ノードは、どの辺の終点でもないノードであり、極大ノードは、どの辺の始点でもないノードであることを想起されたい。また、すべての経路が、長さ１であり、辺の重みを指定する必要がないことに留意されたい。さらに、固有極大ノード（少なくとも１つの辺の終点である極大ノード）ｃｏ１およびｃｏ２は、それぞれがオブジェクトであり、Ｇの固有葉ノードｒ１…ｒ４（少なくとも１つの辺の始点である葉ノード）は、オブジェクトではない基礎データを表す。固有葉ノードｒ１…ｒ４によって表される基礎データを、レコードと称する（このレコードは、第２の実施例に使用されるレコードと同義ではない）。固有極大ノードｃｏ１およびｃｏ２によって表されるオブジェクトは、複合オブジェクトである。
【００５３】
キャッシュ・マネージャ１は、Ｇ１２１’を表す基礎データの構造（図４および図５参照）を維持する。アプリケーション・プログラム９７は、１組のキャッシュＡＰＩ（図６参照）を介して、キャッシュ・マネージャ１にオブジェクト依存性グラフの構造を通信する。アプリケーションは、ＡＰＩを使用して、変更されたレコードｒ１…ｒ４についてもキャッシュ・マネージャ１に通知する。キャッシュ・マネージャ１は、レコードｒ１…ｒ４に対する変更について通知された時に、複合オブジェクトｃｏ１およびｃｏ２のどれが影響を受けたかを識別しなければならず、識別された複合オブジェクトを、それを含むキャッシュ２から削除（または更新）させなければならない。キャッシュ・マネージャ１は、Ｇの辺を調べることによって、どの複合オブジェクトが変更されたかを判定できる（図１３参照）。
【００５４】
たとえば、キャッシュ・マネージャ１が、ｒ１が変更されたことの通知を受けたと仮定する。Ｇ１２１’から、ｃｏ１も変更されていることが示される。キャッシュ・マネージャ１は、ｃｏ１が、それを含むすべてのキャッシュ２から削除（または更新）されるようにしなければならない。もう１つの例として、ｒ２が変更されたと仮定する。Ｇ１２１’から、ｃｏ１とｃｏ２も影響を受けることが示される。この場合、キャッシュ・マネージャは、ｃｏ１とｃｏ２の両方が、それらを含むすべてのキャッシュ２から削除（または更新）されるようにしなければならない。
【００５５】
言い換えると、基本的なアプローチは、アプリケーション・レベルで複合オブジェクトを構築し、その結果、複合オブジェクトが１組のレコードに依存するようにすることである。アプリケーションは、複合オブジェクトｃｏ１およびｃｏ２が依存するレコードｒ１…ｒ４を指定できなければならない。キャッシュ記憶された複合オブジェクトの値に影響する可能性がある形で状態を変更するプロセスのすべてについて、アプリケーション・プログラムは、どのレコードが影響を受けるかを指定できなければならない。この種の複合オブジェクトを、正規形式であると称する。多くの既存のウェブ・アプリケーションは、すでに正規形式になっているキャッシュ記憶可能な複合オブジェクトを作成する。これらのアプリケーションでキャッシュ記憶を使用するためには、複合オブジェクトの基礎となるレコードを認識し、提供されるＡＰＩを介してアプリケーションをキャッシュにインターフェースすることだけが必要である。アプリケーションに対するこれ以外の変更は不要である。
【００５６】
キャッシュ・マネージャ１は、１つまたは複数のキャッシュ２の記憶を管理する、長期間走行するプロセスであることが好ましい。しかし、当業者であれば、以下のいずれかのキャッシュ・マネージャに本発明を簡単に適合させることができる。
１．時間的に重なり合わない、複数の別個のプロセス。
２．一部が時間的に重なり合う、複数の別個のプロセス。これには、キャッシュ・システムのスループットを改善するために設計された複数の並列キャッシュ・マネージャが含まれる。
【００５７】
図３は、ダイナミック・ウェブ・ページをキャッシュ記憶するための、本発明によるシステムの例を示す図である。図からわかるように、複数のページ（ページ１…ページ５）が１つまたは複数のデータベース９９から動的に作成され、１つまたは複数のキャッシュ２に格納される、通常のウェブ・サイトであるサーバ１００を検討する。本発明に適応可能なデータベース９９およびデータベース管理システムの例が、ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ社によって商標ＤＢ２の下で販売されているデータベースである。ここでは、ダイナミック・ウェブ・ページ（ページ１…ページ５）がオブジェクトであり、基礎データ（テーブルまたはレコード）には、データベース９９の各部が含まれる。
【００５８】
本発明によれば、キャッシュ・マネージャ１は、キャッシュ記憶されたオブジェクトが依存するレコードをアプリケーション・プログラム９７が指定できるようにするＡＰＩ（図６）を提供する。キャッシュ・マネージャ１は、これらの依存性を記憶する。アプリケーション・プログラム９７が、レコードを変更するか、キャッシュ内の複合オブジェクトの値に影響する可能性があるレコードに対する変更について知った時には、アプリケーション・プログラム９７は、必ず、更新されたレコードについてキャッシュ・マネージャ１に通知する。キャッシュ・マネージャ１は、変更されたレコードに対する依存性を有するキャッシュ記憶されたオブジェクトのすべてを無効化するか更新する。
【００５９】
たとえば、図３に示されたＨＴＭＬページ（ページ１…ページ５）を検討する。このＨＴＭＬページは、複合オブジェクトであるが、データベース９９から構築され、キャッシュ３に格納される。各ＨＴＭＬページは、テーブルＴ１、Ｔ２、…、Ｔ６と記されたデータベースの部分である１つまたは複数のレコードに対する依存性を有する可能性がある。テーブルとページの間の対応は、ハッシュ・テーブル１９およびレコード・リストによって維持できる。たとえば、キャッシュ・マネージャ１は、テーブルＴ１に対する変更について通知された場合に、ページ１を無効化（または更新）する。同様に、キャッシュ・マネージャは、テーブルＴ２に対する変更について通知された場合に、ページ１、ページ２およびページ３を無効化（または更新）する。
【００６０】
図４は、キャッシュ２の例を示す図である。図からわかるように、各キャッシュ２は、４つの記憶区域すなわち、キャッシュ記憶されたオブジェクトのそれぞれに関する情報を維持するディレクトリ３と、オブジェクト６を格納するためのオブジェクト記憶域４と、他の状態情報（たとえばキャッシュによって維持される統計）を含む補助状態情報５と、ハッシュ・テーブル項目２５内にレコードに関する情報が格納されるハッシュ・テーブル１９とを有することが好ましい。
【００６１】
好ましい実施例では、ハッシュ・テーブル項目２５に、ｒｅｃｏｒｄ＿ｉｄ（レコードＩＤ）１２とオブジェクト・リスト８が含まれ、オブジェクト・リスト８には、その値がデータベース９９の一部である可能性があるレコードに依存するオブジェクト、すなわちｏｂｊｅｃｔ＿ｉｄ９のリストが含まれる。しかし、本発明では、他の種類の情報をハッシュ・テーブル項目に格納することもできる。ハッシュ・テーブルの目的は、特定のテーブル／レコードに関する情報を見つけるための効率的な方法を提供することである。ハッシュは、ｒｅｃｏｒｄ＿ｉｄ１２に基づくキーを使用することが好ましい。ハッシュ・テーブルは、当技術分野で周知である（たとえば、エイホ（Ａｈｏ）、ホップクロフト（Ｈｏｐｃｒｏｆｔ）、ウルマン（Ｕｌｌｍａｎ）共著、「Ｔｈｅ Ｄｅｓｉｇｎ ａｎｄ Ａｎａｌｙｓｉｓ ｏｆ Ｃｏｍｐｕｔｅｒ Ａｌｇｏｒｉｔｈｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ刊、１９７４年を参照）。ハッシュ・テーブルは、本発明にとって効率的なデータ構造をもたらす。しかし、本発明は、広範囲の他のデータ構造との互換性を有し、ハッシュ・テーブルの使用に制限されるものではない。
【００６２】
ディレクトリ３には、キャッシュに格納されたオブジェクト６のそれぞれについて１つのオブジェクト情報ブロック（ＯＩＢ）１０が含まれる。ＯＩＢ１０の構成要素の１つが、複合オブジェクトｃｏ１およびｃｏ２に関連するレコードｒ１…ｒ４を識別するｒｅｃｏｒｄ＿ｉｄ１２のすべてを格納するのに使用されるレコード・リスト１１（図５）である。ここでは、複合オブジェクトが、キャッシュ２に格納されたダイナミック・ウェブ・ページ（ページ１…ページ５）であり、レコードは、データベース９９の一部である可能性がある。好ましい実施例ではレコードＩＤにテキスト文字列を使用するが、他の方法も互換性を有する。
【００６３】
アプリケーション・プログラムは、１組のＡＰＩ関数を介してキャッシュ・マネージャ１と通信する。本発明によるＡＰＩの例を、図６に示す。当業者は、多数の追加ＡＰＩを本発明の趣旨および範囲の中で簡単な形で実施できることを諒解するであろう。図からわかるように、このＡＰＩの例には以下の関数が含まれる。
【００６４】
ｃａｃｈｅ＿ｏｂｊｅｃｔ （ｏｂｊｅｃｔ＿ｉｄ， ｏｂｊｅｃｔ， ｃａｃｈｅ＿ｉｄ） ４１０：キーｏｂｊｅｃｔ＿ｉｄ ９の下でｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２（図４）にｏｂｊｅｃｔ−ｉｄによって識別されるオブジェクト６を格納する。同一のキーを有する前のオブジェクト６は上書きされる。本発明は、ｏｂｊｅｃｔ＿ｉｄ、ｏｂｊｅｃｔおよびｃａｃｈｅ＿ｉｄに関して、広範囲の型と互換性を有する。好ましい実施例では、オブジェクト６は、複数の型のいずれかとすることができ、ｏｂｊｅｃｔ＿ｉｄはバイト文字列、ｃａｃｈｅ＿ｉｄはキャラクタ文字列である。ここでは、同一のキーを有する複数の項目が、同一のキャッシュ内に同時に存在することを許容されないことが好ましい。しかし、当業者であれば、同一のキーを有する複数の項目が同一キャッシュ内に同時に存在できる状況で本発明を使用することも簡単である。
【００６５】
ｌｏｏｋｕｐ＿ｏｂｊｅｃｔ （ｏｂｊｅｃｔ＿ｉｄ， ｃａｃｈｅ＿ｉｄ） ４１５：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２内でキーｏｂｊｅｃｔ＿ｉｄ ９を有するオブジェクト６を探す。そのようなオブジェクト６が存在する場合には、そのオブジェクトをアプリケーション・プログラムに返す。
【００６６】
ｄｅｌｅｔｅ＿ｏｂｊｅｃｔ （ｏｂｊｅｃｔ＿ｉｄ， ｃａｃｈｅ＿ｉｄ） ４２０：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ内でキーｏｂｊｅｃｔ＿ｉｄ ９を有するオブジェクト６を探す。そのようなオブジェクト６が存在する場合には、そのオブジェクトを削除する。
【００６７】
ａｄｄ＿ｄｅｐｅｎｄｅｎｃｙ （ｏｂｊｅｃｔ＿ｉｄ， ｃａｃｈｅ＿ｉｄ， ｒｅｃｏｒｄ＿ｉｄ） ４３０：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２内でキーｏｂｊｅｃｔ＿ｉｄ ９を有するオブジェクト６を探す。そのようなオブジェクト６が存在し、そのオブジェクト６と、引数ｒｅｃｏｒｄ＿ｉｄに関連するｒｅｃｏｒｄ＿ｉｄ １２によって識別されるレコードの間に依存性が存在しない場合には、依存性を追加する。
【００６８】
ｄｅｌｅｔｅ＿ｄｅｐｅｎｄｅｎｃｙ （ｏｂｊｅｃｔ＿ｉｄ， ｃａｃｈｅ＿ｉｄ， ｒｅｃｏｒｄ＿ｉｄ） ４４０：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ内でキーｏｂｊｅｃｔ＿ｉｄ ９を有するオブジェクト６を探す。そのようなオブジェクト６が存在し、そのオブジェクト６と、ｒｅｃｏｒｄ＿ｉｄ １２によって識別されるレコードの間に依存性が存在する場合には、その依存性を削除する。
【００６９】
ｉｎｖａｌｉｄａｔｅ＿ｒｅｃｏｒｄ （ｃａｃｈｅ＿ｉｄ， ｒｅｃｏｒｄ＿ｉｄ） ４５０：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２から、ｒｅｃｏｒｄ＿ｉｄによって識別されるレコードに依存するキャッシュ・オブジェクトをすべて削除する。
【００７０】
ｓｈｏｗ＿ｄｅｐｅｎｄｅｎｔ＿ｏｂｊｅｃｔｓ （ｃａｃｈｅ＿ｉｄ， ｒｅｃｏｒｄ＿ｉｄ） ４６０：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２内で、ｒｅｃｏｒｄ＿ｉｄによって識別されるレコードに依存する全オブジェクトのｏｂｊｅｃｔ＿ｉｄ ９のリストを返す。この関数は、ｒｅｃｏｒｄ＿ｉｄによって識別されるレコードに対応するハッシュ・テーブル項目２５のオブジェクト・リスト８を返すことによって実装することができる。キャッシュ２またはハッシュ・テーブル項目２５のいずれかが見つからない場合を示すために、状況変数を返すこともできる。
【００７１】
ｓｈｏｗ＿ａｓｓｏｃｉａｔｅｄ＿ｒｅｃｏｒｄｓ （ｃａｃｈｅ＿ｉｄ， ｏｂｊｅｃｔ＿ｉｄ） ４７０：ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２内でｏｂｊｅｃｔ＿ｉｄによって識別されるオブジェクト６が依存する全レコードのｒｅｃｏｒｄ＿ｉｄ １２のリストを返す。この関数は、ｃａｃｈｅ＿ｉｄによって識別されるキャッシュ２内でｏｂｊｅｃｔ＿ｉｄによって識別されるオブジェクト６のレコード・リスト１１（図５）を返すことによって実装することができる。キャッシュまたはオブジェクト６のいずれかが見つからない場合を示すために、状況変数を返すこともできる。
【００７２】
図７は、キャッシュ・マネージャ１のロジックの例を示す図である。図からわかるように、ステップ１０１０で、キャッシュ・マネージャが、アプリケーション・プログラムからコマンド（図６）を受け取る。ステップ１０２０で、キャッシュ・マネージャは、コマンド（図６）を読み取り、そのコマンドに基づいて、下で説明する異なるロジック１１００から１６００を呼び出す。
【００７３】
図８は、ｃａｃｈｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｏｂｊｅｃｔ，ｃａｃｈｅ＿ｉｄ）４１０コマンドのためのキャッシュ・マネージャのロジック１２００の例を示す図である。図からわかるように、ステップ１２００で、キャッシュ・マネージャ１は、ｃａｃｈｅ＿ｉｄパラメータが有効なキャッシュ２を指定しているかどうかを判定する。有効でない場合には、ステップ１２４５で、アプリケーション・プログラムに返される状況変数を適当に設定する。ｃａｃｈｅ＿ｉｄが有効なキャッシュ２を指定している場合には、複数のプロセスがキャッシュに同時にアクセスしないように、キャッシュ２をロックすることが好ましい。これによって、一貫性が保たれる。当業者であれば、他のロック方式を使用して、より高いレベルの並列性を実現できることを諒解するであろう。本発明は、好ましい実施例に使用される例のほかに、広範囲の従来のロック方式との互換性を有する。
【００７４】
ステップ１２０５で、キャッシュ・マネージャ１は、ディレクトリ３（図４）を調べることによってオブジェクト６を探す。オブジェクト６の前のコピーが見つかった場合には、ステップ１２１５で、オブジェクト６のＯＩＢ１０を更新し、オブジェクト記憶域４にあるオブジェクト６の古いバージョンを新しいバージョンに置換し、状況変数を適当に設定する。ステップ１２０５で、オブジェクト６の前のコピーが見つからない場合には、ステップ１２１０で、オブジェクト６の新しいＯＩＢ１０を作成し、初期設定し、ディレクトリ３に格納する。キャッシュ・マネージャ１は、オブジェクト６をオブジェクト記憶域４に格納し、状況変数を適当に設定する。
【００７５】
ステップ１２３０で、キャッシュのロックを解除して、他のプロセスがそのキャッシュを更新できるようにする。ステップ１２４０で、コマンドの結果を示す状況変数をアプリケーション・プログラムに返す。その後、処理はステップ１０１０（図７）に戻る。
【００７６】
図９は、ｌｏｏｋｕｐ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ）４１５コマンドのロジックの例を示す図である。図からわかるように、ステップ１６００で、キャッシュ・マネージャ１は、ｃａｃｈｅ＿ｉｄパラメータが有効なキャッシュ２を指定しているかどうかを判定する。有効でない場合には、ステップ１６４０で、状況変数を適当に設定し、ステップ１６８０で、その状況変数をアプリケーション・プログラムに返す。ｃａｃｈｅ＿ｉｄが有効なキャッシュを指定している場合には、ステップ１６１０で、キャッシュ２をロックする。
【００７７】
ステップ１６２０で、キャッシュ・マネージャ１は、ディレクトリ３（図４）を調べることによって、ｏｂｊｅｃｔ＿ｉｄパラメータに対応するオブジェクト６を探す。オブジェクト６が見つからない場合には、ステップ１６５０でキャッシュ２のロックを解除し、ステップ１６７０で状況変数を設定し、ステップ１６８０で状況変数をアプリケーション・プログラムに返す。ステップ１６２０でオブジェクト６が見つかった場合には、ステップ１６３０でキャッシュ２のロックを解除し、ステップ１６６０でオブジェクト６をアプリケーション・プログラムに返す。
【００７８】
図１０は、ｄｅｌｅｔｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ）４２０コマンドのロジックの例を示す図である。図からわかるように、ステップ１１００で、キャッシュ・マネージャ１は、ｃａｃｈｅ＿ｉｄパラメータに対応するキャッシュ２が有効であるかどうかを判定する。有効でない場合、ステップ１１０３で、状況変数を適当に設定し、ステップ１１５０で、状況変数をアプリケーション・プログラムに返す。
【００７９】
ステップ１１００で、ｃａｃｈｅ＿ｉｄが有効なキャッシュ２を指定している場合には、ステップ１１０５でそのキャッシュをロックする。ステップ１１０７で、キャッシュ・マネージャ１は、ディレクトリ３（図４）を調べることによって、ｏｂｊｅｃｔ＿ｉｄパラメータに対応するオブジェクト６を探す。オブジェクト６が見つからない場合には、ステップ１１０８でキャッシュのロックを解除し、ステップ１１０９で状況変数を設定し、ステップ１１５０で状況変数をアプリケーション・プログラムに返す。ステップ１１０７でオブジェクト６が見つかった場合には、ステップ１１１０で、キャッシュ・マネージャ１が、レコード・リスト１１（図５）に関連するオブジェクトを削除し、対応するオブジェクト・リスト８（図４）を更新する。キャッシュ・マネージャ１は、オブジェクト６に対応するレコード・リスト１１（図５）のｒｅｃｏｒｄ＿ｉｄ１２のそれぞれを走査する。レコード・リスト１１の各ｒｅｃｏｒｄ＿ｉｄ１２は、対応するオブジェクト・リスト８（図４）を有することに留意されたい。削除されるオブジェクト６に対応するｏｂｊｅｃｔ＿ｉｄ９（図４）へのポインタが、そのようなオブジェクト・リスト８からすべて削除される。この結果、オブジェクト・リスト８が空になった場合、それに対応するハッシュ・テーブル項目２５も削除される。レコード・リスト１１の各要素を調べた後に、その要素を削除することができる。
【００８０】
ステップ１１２０で、オブジェクト６をオブジェクト記憶域４から削除する。ステップ１１３０で、対応するＯＩＢ１０を削除する。ステップ１１２０は、ステップ１１１０およびステップ１１３０と同時にまたはこれらの前に実行できることに留意されたい。ステップ１１４０で、キャッシュのロックを解除し、ステップ１１５０で、状況変数をアプリケーション・プログラムに返す。
【００８１】
図１１は、ａｄｄ＿ｄｅｐｅｎｄｅｎｃｙ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ，ｒｅｃｏｒｄ＿ｉｄ）４３０コマンドのロジックの例を示す図である。図からわかるように、ステップ１３００で、キャッシュ・マネージャは、ｃａｃｈｅ＿ｉｄパラメータが有効なキャッシュ２を指定しているかどうかを判定する。有効でない場合には、ステップ１３０２で状況変数を適当に設定し、ステップ１３６０で状況変数をアプリケーション・プログラムに返す。
【００８２】
ステップ１３００で、ｃａｃｈｅ＿ｉｄが有効なキャッシュを指定していると判定された場合には、ステップ１３０５でキャッシュ２をロックする。ステップ１３１０で、キャッシュ・マネージャ１は、ディレクトリ３（図４）を調べることによって、ｏｂｊｅｃｔ＿ｉｄに対応するオブジェクト６を探す。ステップ１３１０でオブジェクト６が見つからない場合には、ステップ１３１５でキャッシュ２のロックを解除し、ステップ１３１７で状況変数を設定し、ステップ１３６０で適当な状況変数をアプリケーション・プログラムに返す。ステップ１３１０でオブジェクト６が見つかった場合には、ステップ１３２０で、キャッシュ・マネージャ１が、レコード・リスト１１（図５）を検査して、オブジェクト６と、ｒｅｃｏｒｄ＿ｉｄによって識別されるレコードとの間の関連（すなわち依存性情報）がすでに存在するかどうかを調べる。その代わりに、ｒｅｃｏｒｄ＿ｉｄに対応するレコードがハッシュ・テーブル項目２５を有するかどうかを判定し、有する場合にはオブジェクト・リスト８でｏｂｊｅｃｔ＿ｉｄ９を探すことができる。ステップ１３２０で、オブジェクトへの依存性が存在する場合には、ステップ１３２５でキャッシュ２のロックを解除し、ステップ１３２７で状況変数を適当に設定し、ステップ１３６０で適当な状況変数をアプリケーション・プログラムに返す。ステップ１３２０で、オブジェクトへの依存性が見つからない場合には、ステップ１３３０で、ｏｂｊｅｃｔ＿ｉｄ９をレコードのオブジェクト・リスト８に追加する。必要であれば、そのレコードのためのハッシュ・テーブル項目２５とオブジェクト・リスト８を作成する。ステップ１３４０で、ｒｅｃｏｒｄ＿ｉｄ１２を、オブジェクト６のレコード・リスト１１（図５）に追加する。ステップ１３４０は、ステップ１３３０と同時にまたはその前に実行できることに留意されたい。ステップ１３５０でキャッシュ２のロックを解除し、ステップ１３６０で、状況変数をアプリケーション・プログラムに返す。
【００８３】
図１２は、ｄｅｌｅｔｅ＿ｄｅｐｅｎｄｅｎｃｙ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ，ｒｅｃｏｒｄ＿ｉｄ）４４０コマンドのロジックの例を示す図である。図からわかるように、ステップ１４００で、キャッシュ・マネージャ１は、ｃａｃｈｅ＿ｉｄパラメータが有効なキャッシュ２を指定しているかどうかを判定する。有効でない場合、ステップ１４０２で、状況変数を適当に設定し、ステップ１４６０で、状況変数をアプリケーション・プログラムに返す。
【００８４】
ステップ１４００で、ｃａｃｈｅ＿ｉｄが有効なキャッシュを指定していると判定された場合には、ステップ１４０５で、キャッシュをロックする。ステップ１４１０で、キャッシュ・マネージャ１は、ディレクトリ３（図４）を調べることによって、ｏｂｊｅｃｔ＿ｉｄに対応するオブジェクト６を探す。ステップ１４１０でオブジェクト６が見つからない場合には、ステップ１４１２でキャッシュ２のロックを解除し、ステップ１４１５で状況変数を設定し、ステップ１４６０で状況変数をアプリケーション・プログラムに返す。ステップ１４１０でオブジェクト６が見つかった場合には、ステップ１４２０で、キャッシュ・マネージャ１がレコード・リスト１１（図５）を調べて、オブジェクト６とｒｅｃｏｒｄ＿ｉｄによって識別されるレコードの間に関連（すなわち依存性情報）がすでに存在するかどうかを調べる。その代わりに、ｒｅｃｏｒｄ＿ｉｄに対応するレコードがハッシュ・テーブル項目２５を有するかどうかを判定し、有する場合にはオブジェクト・リスト８でｏｂｊｅｃｔ＿ｉｄ９を探すことができる。ステップ１４２０で依存性が見つからない場合には、ステップ１４２２でキャッシュ２のロックを解除し、ステップ１４２５で状況変数を適当にセットし、ステップ１４６０で適当な状況変数をアプリケーション・プログラムに返す。ステップ１４２０でオブジェクトに対する依存性が見つかった場合には、ステップ１４３０で、そのレコードのオブジェクト・リスト８からｏｂｊｅｃｔ＿ｉｄ９を削除する。これによってオブジェクト・リストが空になった場合には、そのレコードのハッシュ・テーブル項目２５を削除する。ステップ１４４０で、オブジェクト６のレコード・リスト１１（図５）からｒｅｃｏｒｄ＿ｉｄ１２を削除する。ステップ１４４０は、ステップ１４３０と同時にまたはその前に実行できることに留意されたい。ステップ１４５０でキャッシュのロックを解除し、ステップ１４６０で状況変数をアプリケーション・プログラムに返す。
【００８５】
図１３は、ｉｎｖａｌｉｄａｔｅ＿ｒｅｃｏｒｄ（ｃａｃｈｅ＿ｉｄ，ｒｅｃｏｒｄ＿ｉｄ）４５０コマンドのロジックの例を示す図である。図からわかるように、ステップ１５００で、キャッシュ・マネージャ１は、ｃａｃｈｅ＿ｉｄパラメータが有効なキャッシュ２を指定しているかどうかを判定する。そのキャッシュが有効でない場合には、ステップ１５０２で状況変数を適当に設定し、ステップ１５５０で状況変数をアプリケーション・プログラムに返す。
【００８６】
ステップ１５００で、キャッシュ・マネージャ１が、ｃａｃｈｅ＿ｉｄパラメータが有効なキャッシュ２を指定していると判定した場合には、ステップ１５０５でキャッシュ２をロックする。ステップ１５１０で、キャッシュ・マネージャは、オブジェクト６のいずれかの値が、ｒｅｃｏｒｄ＿ｉｄに関連するレコードに依存するかどうかを、レコードがハッシュ・テーブル項目２５（図４）を有するかどうかを調べることによって判定する。そのレコードのハッシュ・テーブル項目２５が見つからない場合には、ステップ１５１５でキャッシュのロックを解除し、ステップ１５１７で状況変数を設定する。
【００８７】
ステップ１５１０で、そのレコードのハッシュ・テーブル項目２５が見つかった場合には、ステップ１５２０で、キャッシュ・マネージャ１が、そのレコードのオブジェクト・リスト８を走査する。オブジェクト・リスト８にｏｂｊｅｃｔ＿ｉｄ９があるオブジェクト６のそれぞれを、キャッシュから削除する。各オブジェクト６を削除する際に、他のオブジェクト・リスト８からのそのオブジェクト６への参照も、すべて削除する。このような参照は、削除するオブジェクト６のレコード・リスト１１（図５）をトラバースすることによって見つけることができる。そのような参照を削除した結果、オブジェクト・リストが空になった場合には、対応するハッシュ・テーブル項目を削除する。ｒｅｃｏｒｄ＿ｉｄ１２（ｒｅｃｏｒｄ＿ｉｄパラメータに対応する）に関連するオブジェクト・リスト８の各要素を調べた後に、その要素を削除することができる。ステップ１５３０で、そのレコードのハッシュ・テーブル項目２５を削除する。ステップ１５４０でキャッシュのロックを解除し、ステップ１５５０で、状況変数をアプリケーション・プログラムに返す。
【００８８】
当業者が実装できるｉｎｖａｌｉｄａｔｅ＿ｒｅｃｏｒｄ関数の簡単な拡張は、ｒｅｃｏｒｄ＿ｉｄパラメータに依存する１つまたは複数のオブジェクトを、無効化するのではなく更新することである。
【００８９】
ステップ１０９９は、キャッシュ・マネージャが処理できる他のコマンドを表す。
【００９０】
当業者であれば、本発明の趣旨および範囲の中に、多数の拡張および変形が存在することを諒解するであろう。たとえば、１つの変形は、オブジェクト６がキャッシュ記憶される前とオブジェクト６がキャッシュから除去された後の両方で、キャッシュ・マネージャ１が、オブジェクト６のＯＩＢ１０（図４）を保持し、更新できるようにすることである。このアプローチを使用する場合、オブジェクト６がキャッシュから除去される時に、オブジェクト６のレコード・リスト１１を削除する必要がなくなり、すべてのオブジェクト・リスト８からオブジェクト６を除去する必要もなくなるはずである。この形で、オブジェクト６がキャッシュ内にない場合であっても、依存性情報を保持し、更新できるようになる。
【００９１】
もう１つの変形は、オブジェクトがオブジェクト・リスト８に追加される前とオブジェクト・リスト８が空になった後の両方で、言い換えると、キャッシュ・マネージャがレコードに対する依存性に気付く前と、キャッシュ・マネージャが気付いているレコードに対する依存性のすべてが古くなった後の両方で、キャッシュ・マネージャ１が、レコードのハッシュ・テーブル項目２５を維持し、更新できるようにすることである。これは、ハッシュ・テーブル項目２５に、ｒｅｃｏｒｄ＿ｉｄ１２およびオブジェクト・リスト８以外の情報も含まれる場合に、特に価値があるはずである。
【００９２】
代替実施例
図１４は、本発明の特徴を有するシステムのもう１つの例を示す図である。この実施例ならびに前の実施例では、本発明は、通常のクライアント−サーバ環境でのサーバ・アプリケーションの性能を改善するのに使用することができる。当業者であれば、クライアント−サーバ・ベースではない他の応用例に本発明を簡単に適合させることができるはずである。図からわかるように、このクライアント−サーバ・アーキテクチャでは、クライアント９０がネットワーク９５を介してサーバ１００と通信する。サーバ１００は、１つまたは複数のキャッシュ２’を維持する。通常通り、サーバ１００は、キャッシュ２’を使用して、性能を改善し、クライアント９０の要求を満足するためのＣＰＵ時間を減らす。図１４には、単一のサーバに関連するキャッシュ２’が示されているが、キャッシュ２’は、複数のサーバにまたがって維持することもできる。
【００９３】
サーバ１００上で稼動するアプリケーションは、オブジェクトを作成し、１つまたは複数のキャッシュ２’にこれらのオブジェクトを格納する。このシステムは、データベース９９内の基礎データのソースとキャッシュ２’が地理的に分離されたアーキテクチャとすることもできる。この実施例では、オブジェクトは、１つまたは複数のキャッシュ２’に格納することができるデータである。オブジェクトは、データベース９９に格納された基礎データから構築することができる。基礎データには、１つまたは複数のオブジェクトの値に影響する可能性がある、システム内の全データが含まれる。基礎データは、システム内の全オブジェクトのスーパーセットである。
【００９４】
本発明によれば、オブジェクト・マネージャ１２０は、サーバ１００（またはクライアント９０）などのコンピュータでの実行のためにコンピュータ可読媒体内で具体的に実施されたコンピュータ実行可能コード（プログラム）として実施されることが好ましい。オブジェクト・マネージャ１２０は、基礎データに対する変更がキャッシュ２’内のオブジェクトの値にどのように影響するかを判定するのを助ける。図１４には、単一のサーバに常駐するオブジェクト・マネージャが図示されているが、オブジェクト・マネージャは、複数のサーバにまたがって分散することができる。オブジェクト・マネージャ１２０は、１つまたは複数のキャッシュ２’の記憶域を管理する長期間走行するプロセスであることが好ましい。キャッシュという用語は、非常に包括的であり、これには、通常の意味のキャッシュに加えて、アプリケーション（たとえばクライアント９０アプリケーション）を含めることができる。当業者であれば、以下のいずれかであるオブジェクト・マネージャのために本発明を簡単に適合させることができるはずである。
１．時間的に重なり合わない複数の別個のプロセス
２．一部が時間的に重なり合う、複数の別個のプロセス。これには、システムのスループットを改善するために設計された複数の並列オブジェクト・マネージャが含まれる。
【００９５】
図１５は、本発明の特徴を有するオブジェクト依存性グラフＧ１２１の例を示す図である。オブジェクト依存性グラフＧ１２１は、グラフ・オブジェクトｇｏｂｊ１…ｇｏｂｊｎの間のデータ依存性を表す。ここでは、ｇｏｂｊ１…ｇｏｂｊ７が、異なるグラフ・オブジェクトを表し、グラフの辺ｅは、データ依存性を表す。たとえば、ｇｏｂｊ１からｇｏｂｊ５への辺は、ｇｏｂｊ１が変更された場合に、ｇｏｂｊ５も変更されていることを示す。辺の重みｗは、辺の始点であるオブジェクトに対する変更が、その辺の終点であるオブジェクトにどれほど影響するかを示す。たとえば、ｇｏｂｊ１に対する変更は、ｇｏｂｊ５にｇｏｂｊ２よりも大きな変更をもたらすことを意味する。これは、ｇｏｂｊ１からｇｏｂｊ５への辺ｅの重みｗが、ｇｏｂｊ２からｇｏｂｊ５への辺ｅの重みｗの５倍になっているからである。
【００９６】
オブジェクト・マネージャ１２０は、オブジェクト依存性グラフを表す基礎となるデータ構造（図１４から図２１を参照）を維持する責任を負う。アプリケーション・プログラムは、１組のＡＰＩ（図２２参照）を介してオブジェクト・マネージャにオブジェクト依存性グラフの構造を通信する。また、アプリケーションは、ＡＰＩを使用して、変更された基礎データについてオブジェクト・マネージャに通知する。オブジェクト・マネージャ１２０は、基礎データに対する変更について通知された時に、他のどのオブジェクトが変更されたかを判定し、その変更をキャッシュ２’に通知しなければならない。オブジェクト・マネージャは、オブジェクト依存性グラフ（図２６参照）の辺をたどることによって、他のどのオブジェクトが変更されたかを判定する。
【００９７】
たとえば、オブジェクト・マネージャ１２０が、ｇｏｂｊ１が変更されたという通知を受けたと仮定する。オブジェクト依存性グラフＧ１２１の辺をｇｏｂｊ１からたどることによって、オブジェクト・マネージャは、ｇｏｂｊ５とｇｏｂｊ７も変更されたと判定する。もう１つの例として、オブジェクト・マネージャが、ｇｏｂｊ７が変更されたという通知を受けたと仮定する。ｇｏｂｊ７が始点になっている辺はこのオブジェクト依存性グラフに存在しないので、オブジェクト・マネージャは、他のオブジェクトは影響を受けないと結論する。
【００９８】
図１６は、本発明の特徴を有するオブジェクト・マネージャ１２０の例を示す図である。図からわかるように、オブジェクト・マネージャ１２０には、以下の複数の記憶域が含まれる。
１．複数の依存性情報ブロック（ＤＩＢ）１２８によって実施されるオブジェクト依存性グラフＧ１２１（図１７参照）。当業者であれば、さまざまなデータ構造を使用してＤＩＢを格納できることを諒解するであろう。通常のハッシュ・テーブルを使用し、ｏｂｊｅｃｔ＿ｉｄ１６０によってＤＩＢをインデクシングすることが好ましい。ハッシュ・テーブルは、たとえば、エイホ（Ａｈｏ）、ホップクロフト（Ｈｏｐｃｒｏｆｔ）、ウルマン（Ｕｌｌｍａｎ）共著、「Ｔｈｅ Ｄｅｓｉｇｎ ａｎｄ Ａｎａｌｙｓｉｓ ｏｆ Ｃｏｍｐｕｔｅｒ Ａｌｇｏｒｉｔｈｍｓ」、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ刊、１９７４年に記載されている。
２．複数レコード・ツリー（ＭＲＴ）１２２（図３２および図３３を参照）。
３．単一レコード・ツリー（ＳＲＴ）１２３（図３２および図３３を参照）。
４．以下を含むがこれらに制限されない、補助状態情報１２４。
ａ．ｎｕｍ＿ｕｐｄａｔｅｓ（更新回数）１２５：オブジェクト・マネージャがグラフを介して伝播した更新の回数を追跡するためにオブジェクト・マネージャが維持するカウンタ。
ｂ．一貫性スタック１２８．５：更新中に一貫性を維持するために使用される。
ｃ．関係情報区域１２９（図３２および図３３を参照）。
５．プログラム・ロジック１２６。
【００９９】
図１８は、各キャッシュ１２７によって維持される記憶域の例を示す図である。各キャッシュは、それを識別するｃａｃｈｅ＿ｉｄ１３５を有する。主な記憶域は以下の３つである。
１．ディレクトリ１３０：オブジェクトに関する情報が維持される。ディレクトリ１３０には、複数のオブジェクト情報ブロック（ＯＩＢ）１０’が含まれる。あるオブジェクトに関する情報は、そのオブジェクトがキャッシュから出た後に、ＯＩＢ１０’（図１９）に保存することができる。当業者であれば、さまざまなデータ構造を使用してＯＩＢを格納できることを諒解するであろう。通常のハッシュ・テーブルを使用し、ｏｂｊｅｃｔ＿ｉｄ１６０によってＯＩＢをインデクシングすることが好ましい。
２．オブジェクト記憶域１３２：キャッシュに含まれるオブジェクトが格納される。
３．補助状態情報１２４：たとえばｃａｃｈｅ＿ｉｄ１３５など、他の状態情報を含む。
【０１００】
図１９は、ＯＩＢ１０’の例を示す図である。ＯＩＢには、以下が含まれることが好ましい。
ｏｂｊｅｃｔ＿ｉｄ１６０：以下の説明のために、あるオブジェクトがｏｂｊｅｃｔ＿ｉｄ ｏ１を有すると仮定する。
ｖｅｒｓｉｏｎ＿ｎｕｍ（バージョン番号）１４１：オブジェクト・マネージャが、同一オブジェクトの異なるバージョンを一意に識別できるようにする。
ｔｉｍｅｓｔａｍｐ（タイムスタンプ）１４２：オブジェクトがどれほど最近に計算されたかを示す数。
ａｃｔｕａｌ＿ｗｅｉｇｈｔ（実際の重み）１４３：グラフ・オブジェクトｏ１のキャッシュ記憶されたバージョンが、グラフ・オブジェクトｏ２の現行バージョンとの一貫性を有するようにするための、ｏ２からｏ１へのすべての辺の重みの合計。
ｄｅｐ＿ｌｉｓｔ（依存性リスト）１４４：オブジェクトｏ１への依存性を表すリスト。
【０１０１】
図２０は、ｄｅｐ＿ｌｉｓｔ１４４の要素の例を示す図である。図からわかるように、各リストには、以下が含まれることが好ましい。
ｏｂｊｅｃｔ＿ｉｄ１６０：ｏ１への依存性の辺を有するグラフ・オブジェクトｏ２（すなわち、ｏ２が始点、ｏ１が終点）を表す。
ｗｅｉｇｈｔ＿ａｃｔ（実重み）１５２：ｏ２の最も最近のバージョンがｏ１のキャッシュ記憶されたバージョンとどれほどの一貫性を有するかを表す数。好ましい実施例では、０の値（全く一貫性がない）またはＤＩＢ１２８（図２１）の対応する辺のｗｅｉｇｈｔ（重み）１６５（図２１）（完全な一貫性を有する）を使用する。簡単な拡張は、これら２つの極端な値の間の値によって一貫性の度合を表せるようにすることである。
ｖｅｒｓｉｏｎ＿ｎｕｍ１５３：ｏ１のキャッシュ記憶されたバージョンとの一貫性を有するｏ２のｖｅｒｓｉｏｎ＿ｎｕｍ。
【０１０２】
図２１は、図１６のＤＩＢ１２８の例を示す図である。図からわかるように、ＤＩＢ１２８には、以下のフィールドが含まれることが好ましい。
ｏｂｊｅｃｔ＿ｉｄ１６０：アプリケーション・プログラムがグラフ・オブジェクトを識別するのに使用する。以下の説明のために、あるグラフ・オブジェクトがｏｂｊｅｃｔ＿ｉｄ ｏ１を有すると仮定する。
ｖｅｒｓｉｏｎ＿ｎｕｍ１６１：グラフ・オブジェクトの現行バージョンのバージョン番号。
ｔｉｍｅｓｔａｍｐ１６２：グラフ・オブジェクトの現行バージョンのタイムスタンプ。
ｓｔｏｒａｇｅ＿ｌｉｓｔ（記憶域リスト）１６３（オブジェクトであるグラフ・オブジェクトの場合）：そのオブジェクトを含む全キャッシュのｃａｃｈｅ＿ｉｄのリスト。
ｉｎｃｏｍｉｎｇ＿ｄｅｐ（入依存性）１６４：ｏ１への依存性辺を有するグラフ・オブジェクトｏ２のすべての（ｏｂｊｅｃｔ＿ｉｄ１６０，ｗｅｉｇｈｔ１６５）対のリスト。ｗｅｉｇｈｔ１６５は、依存性の重要さを表す。たとえば、大きい数は、より重要な依存性を表すことができる。
ｏｕｔｇｏｉｎｇ＿ｄｅｐ（出依存性）１６６：ｏ１から発する依存性辺が存在するすべてのオブジェクトのｏｂｊｅｃｔ＿ｉｄのリスト。
ｓｕｍ＿ｗｅｉｇｈｔ（重み合計）１６７：ｏ１に入る依存性辺のすべての重みの合計。
ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８（オブジェクトであるグラフ・オブジェクトの場合）：あるオブジェクトが非常に古いとみなされる時を表す数。ＯＩＢ１０’（図１９）のａｃｔｕａｌ＿ｗｅｉｇｈｔ１４３フィールドが、そのオブジェクトのｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８フィールド未満になった時には、必ず、そのオブジェクトは非常に古いとみなされ、キャッシュから無効化されるか、更新されなければならない。
ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ（一貫性リスト）１６９（オブジェクトであるグラフ・オブジェクトの場合）：現行オブジェクトとの一貫性を維持されなければならない他のオブジェクトに対応するｏｂｊｅｃｔ＿ｉｄ１６０のリスト。一貫性は、同一キャッシュ内のオブジェクトの間でのみ実施されることが好ましい。簡単な拡張は、複数のキャッシュにまたがってオブジェクトの一貫性を実施することである。もう１つの簡単な拡張は、ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９の全オブジェクトが、ｏｂｊｅｃｔ＿ｉｄがキャッシュ内にある時にはキャッシュ内にあり、ｏｂｊｅｃｔ＿ｉｄがキャッシュ外にある時にはキャッシュ外にあることを必要とすることである。
ｌａｔｅｓｔ＿ｏｂｊｅｃｔ（最新オブジェクト）１６０１（オブジェクトであるグラフ・オブジェクトの場合）：そのオブジェクトの最新バージョンを指すポインタ。オブジェクト・マネージャがそのようなコピーを知らない場合にはｎｕｌｌになる。このフィールドを使用すると、毎回値を再計算することなく、複数のキャッシュ内でオブジェクトを更新できるようになる。
ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ（関係文字列）１６０２：グラフ・オブジェクトが関係オブジェクトでない場合にはｎｕｌｌになる。そうでない場合には、ＳＲＯの場合はｒｅｌａｔｉｏｎ＿ｎａｍｅ（関係名）（２５，３０）、ＭＲＯの場合はｒｅｌａｔｉｏｎ＿ｎａｍｅ（＞＝５０）という形になる。以下の項目は、ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２がｎｕｌｌでない場合に限って関連する。
ｍｕｌｔｉｐｌｅ＿ｒｅｃｏｒｄｓ（複数レコード）１６０３：グラフ・オブジェクトが複数レコード・オブジェクト（ＭＲＯ）の場合は真、単一レコード・オブジェクト（ＳＲＯ）の場合は偽になる。
以下の項目は、ｍｕｌｔｉｐｌｅ＿ｒｅｃｏｒｄｓ１６０３が真の場合に限って関連する。
ｍｒｏ＿ｄｅｐ＿ｗｅｉｇｈｔ（ＭＲＯ依存重み）１６０４：別の関係オブジェクトからｏ１への暗黙の依存性に割り当てられる重み。
ｍｒｏ＿ｔｈｒｅｓｈｏｌｄ＿ｉｎｃｒｅｍｅｎｔ（ＭＲＯ閾値増分）１６０５：ｏ１に対する暗黙の依存性のそれぞれについて、ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔを増分する量。
【０１０３】
図１４から図１７を参照すると、オブジェクト・マネージャは、グラフを介してオブジェクト・マネージャが更新を伝播した回数を記録するカウンタであるｎｕｍ＿ｕｐｄａｔｅｓ１２５（当初は０）を維持することが好ましい。オブジェクト・マネージャは、キャッシュ内のオブジェクト間の一貫性を維持するのに使用される一貫性スタック１２８．５（図１６）と称するデータ構造（当初は空）も維持する。
【０１０４】
アプリケーション・プログラム９７は、１組のＡＰＩを介してオブジェクト・マネージャと通信することが好ましい。図２２は、本発明による複数のＡＰＩの例を示す図である。当業者であれば、本発明に鑑みて簡単な拡張である他のＡＰＩを実施できることを諒解するであろう。
【０１０５】
図２３は、異なるＡＰＩ関数を処理するためのオブジェクト・マネージャ１２０のロジックの例を示す図である。これらの関数は、後程詳細に説明する。概要を示すと、オブジェクト依存性グラフＧ１２１内のノードは、オブジェクト・マネージャに対するＡＰＩ呼出しｃｒｅａｔｅ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ）１８１を介して作成できる。グラフ内の既存ノード間の依存性は、ＡＰＩ呼出しａｄｄ＿ｄｅｐｅｎｄｅｎｃｙ（ｓｏｕｒｃｅ＿ｏｂｊｅｃｔ＿ｉｄ，ｔａｒｇｅｔ＿ｏｂｊｅｃｔ＿ｉｄ，ｄｅｐ＿ｗｅｉｇｈｔ）１８２を介して作成できる。オブジェクト「ｏｂｊ＿ｉｄ」に対応するｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９は、ＡＰＩ呼出しｄｅｆｉｎｅ＿ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ（ｏｂｊ＿ｉｄ，ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８３を介して設定できる。ノードは、ＡＰＩ ｄｅｌｅｔｅ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ）１８４を介してＧから削除できる。ＡＰＩ ｃａｃｈｅ＿ｌａｔｅｓｔ＿ｖｅｒｓｉｏｎ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ）１８５では、オブジェクトの最新バージョンがキャッシュに追加される。ＡＰＩ ｃｏｐｙ＿ｏｂｊｅｃｔ（ｏｂｊ＿ｉｄ，ｔｏ＿ｃａｃｈｅ＿ｉｄ，ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄ）１８６は、あるバージョンのオブジェクトをあるキャッシュから別のキャッシュにコピーしようと試みる。オブジェクトは、ＡＰＩ呼出しｄｅｌｅｔｅ＿ｏｂｊｅｃｔ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ）１８７を介してキャッシュから削除される。
【０１０６】
基礎データの値を変更するアプリケーション・プログラムは、オブジェクト・マネージャに知らせなければならない。これを達成するための２つのＡＰＩ呼出しが、ｏｂｊｅｃｔ＿ｈａｓ＿ｃｈａｎｇｅｄ（ｏｂｊ＿ｉｄ）１８８（ｏｂｊ＿ｉｄパラメータでグラフ・オブジェクトを識別する）と、ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８９（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓパラメータにグラフ・オブジェクト（へのポインタ）のリストが含まれる）である。
【０１０７】
ＳＲＯに対応するノードは、ＡＰＩ呼出しｃｒｅａｔｅ＿ｓｒｏ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ，ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓ）１９０を介して作成される。
【０１０８】
ＭＲＯは、ＡＰＩ ｃｒｅａｔｅ＿ｍｒｏ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ，ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓ，ｒｅｌ＿ｄｅｆａｕｌｔ＿ｗｅｉｇｈｔ，ｒｅｌ＿ｄｅｆａｕｌｔ＿ｔｈｒｅｓｈｏｌｄ）１９１を介して作成される。
【０１０９】
ＡＰＩ ｃｏｍｐａｒｅ＿ｏｂｊｅｃｔｓ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ＿ｉｄ１，ｃａｃｈｅ＿ｉｄ２）１９２は、ｃａｃｈｅ＿ｉｄ１とｃａｃｈｅ＿ｉｄ２にあるｏｂｊ＿ｉｄのバージョンがどれほど似ているかを判定するのに使用することができる。ＡＰＩ ｕｐｄａｔｅ＿ｃａｃｈｅ（ｃａｃｈｅ）１９３によって、キャッシュ内のすべての項目が現行であることが保証される。ＡＰＩ ｄｅｆｉｎｅ＿ｒｅｌａｔｉｏｎ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓ）１９４によって、オブジェクト・マネージャに対して関係が識別される。１つまたは複数のレコードが変更された時には、オブジェクト・マネージャは、ＡＰＩ ｒｅｃｏｒｄ＿ｈａｓ＿ｃｈａｎｇｅｄ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓ）１９５およびｒｅｃｏｒｄｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓ）１９６を介して変更に関する通知を受けることができる。
【０１１０】
オブジェクト依存性グラフＧ１２１内のノードは、オブジェクト・マネージャに対するＡＰＩ呼出しｃｒｅａｔｅ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ）１８１を介して作成される。当業者であれば、本発明の趣旨および範囲の中で、簡単な形で多数の追加ＡＰＩを実施できることを諒解するであろう。たとえば、ノードを作成した後に、ｏｂｊｅｃｔ＿ｉｄ１６０、ｖｅｒｓｉｏｎ＿ｎｕｍ１６１およびｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８を変更するためにＡＰＩを追加することができる。
【０１１１】
グラフ内の既存ノードの間の依存性は、ＡＰＩ呼出しａｄｄ＿ｄｅｐｅｎｄｅｎｃｙ（ｓｏｕｒｃｅ＿ｏｂｊｅｃｔ＿ｉｄ，ｔａｒｇｅｔ＿ｏｂｊｅｃｔ＿ｉｄ，ｄｅｐ＿ｗｅｉｇｈｔ）１８２を介して作成される。
【０１１２】
当業者であれば、本発明の趣旨および範囲の中で、簡単な形で多数の追加ＡＰＩを実施できることを諒解するであろう。たとえば、依存性を削除するＡＰＩや、依存性の重みを変更するＡＰＩを追加することもできる。
【０１１３】
オブジェクト「ｏｂｊ＿ｉｄ」に対応するｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９は、ＡＰＩ呼出しｄｅｆｉｎｅ＿ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ（ｏｂｊ＿ｉｄ，ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８３を介して設定される。ｏｂｊ＿ｉｄのｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔには、ｏｂｊ＿ｉｄをメンバとして含めることができないようになっていることが好ましい。このＡＰＩでは、これが不可能にされている。
【０１１４】
本発明の趣旨および範囲の中で、作成後にｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９を変更するためのＡＰＩを追加することも同様に可能である。
【０１１５】
あるオブジェクトがキャッシュ記憶された後に、そのオブジェクトのＤＩＢ１２８（図２１）に変更を加えると、１つまたは複数のキャッシュ１２７に対する更新が必要になる場合がある。これは簡単である。新しいグラフ・オブジェクトｏ２からキャッシュ記憶されたオブジェクトｏ１への新しい依存性の場合、新しい依存性は、オブジェクト・マネージャｏ２がいつ作成されたかを知らない場合、またはｏ２のＤＩＢのｔｉｍｅｓｔａｍｐ１６２＞ｏ１のＯＩＢのｔｉｍｅｓｔａｍｐ１４２の場合に古くなる。ノードは、ＡＰＩ ｄｅｌｅｔｅ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ）１８４を介してＧから削除できる。
【０１１６】
オブジェクトは、ＡＰＩ ｃａｃｈｅ＿ｌａｔｅｓｔ＿ｖｅｒｓｉｏｎ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ）１８５およびｃｏｐｙ＿ｏｂｊｅｃｔ（ｏｂｊ＿ｉｄ，ｔｏ＿ｃａｃｈｅ＿ｉｄ，ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄ）１８６を介して、キャッシュに明示的に追加することができる。これらのＡＰＩでは、オブジェクトのＯＩＢ１０’が存在しない場合に、キャッシュ・ディレクトリ内に新しいＯＩＢ１０’が作成される。
【０１１７】
図２４は、ＡＰＩ ｃａｃｈｅ＿ｌａｔｅｓｔ＿ｖｅｒｓｉｏｎ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ）１８５の例を示す図である。図からわかるように、ステップ２０３０で、ｏｂｊ＿ｉｄパラメータが既存のオブジェクトを指定し、ｃａｃｈｅパラメータが既存のキャッシュを指定しているかどうかを検証する。そうである場合には、処理はステップ２０４０に進む。そうでない場合には、適当な状況メッセージを返し、処理はステップ２０１０に進む。ステップ２０４０では、ｃａｃｈｅにｏｂｊ＿ｉｄの最新バージョンがあるかどうかを判定する。そうである場合には、処理はステップ２０１０に継続する。そうでない場合には、ステップ２０５０で、ＤＩＢ１２８（図２１）のｌａｔｅｓｔ＿ｏｂｊｅｃｔ１６０１フィールドからｏｂｊ＿ｉｄの最新バージョンを取得する試みを行う。このフィールドがｎｕｌｌの場合、ステップ２０５０で、ｏｂｊ＿ｉｄの最新値を計算し（および、おそらくはＤＩＢのｌａｔｅｓｔ＿ｏｂｊｅｃｔ１６０１フィールドを介してその値にアクセスできるようにし）、ＤＩＢ１２８（図２１）のｖｅｒｓｉｏｎ＿ｎｕｍ１６１を更新する。ステップ２０５０では、ｏｂｊ＿ｉｄの新しいバージョンを完全に再計算するか、その一部だけを再計算し、新しい部分を既存のバージョンからの部分と合併するかのいずれかを行う。後者の方法は、しばしば前者より効率的である。
【０１１８】
ｃａｃｈｅのディレクトリ１３０にｏｂｊ＿ｉｄのＯＩＢ１０’が存在しない場合には、そのＯＩＢ１０’を作成する。ｃａｃｈｅに以前にｏｂｊ＿ｉｄのバージョンが含まれていたことがない場合には、ｏｂｊ＿ｉｄのｓｔｏｒａｇｅ＿ｌｉｓｔ１６３をｃａｃｈｅに追加する。ＯＩＢ１０’（図１９）のｖｅｒｓｉｏｎ＿ｎｕｍ１４１およびｔｉｍｅｓｔａｍｐ１４２には、ＤＩＢ１２８（図２１）のｖｅｒｓｉｏｎ＿ｎｕｍ１６１およびｔｉｍｅｓｔａｍｐ１６２をセットする。ＯＩＢ１０’（図１９）のａｃｔｕａｌ＿ｗｅｉｇｈｔ１４３には、ＤＩＢのｓｕｍ＿ｗｅｉｇｈｔ１６７をセットする。ＯＩＢ１０’（図１９）のｄｅｐ＿ｌｉｓｔ１４４に属する（ｏ２，ｗｅｉｇｈｔ＿ａｃｔ，ｖｅｒｓｉｏｎ＿ｎｕｍ）の組のそれぞれについて、ｗｅｉｇｈｔ＿ａｃｔ１５２に、ＤＩＢのｉｎｃｏｍｉｎｇ＿ｄｅｐ１６４上の対応する辺のｗｅｉｇｈｔ１６５をセットする。ｖｅｒｓｉｏｎ＿ｎｕｍ１５３には、ｏ２のＤＩＢに含まれるｖｅｒｓｉｏｎ＿ｎｕｍ１６１をセットする。ステップ２０６０で、確実に一貫性が保たれるようにする。この関数では、ｏｂｊ＿ｉｄのｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９に含まれる現行でないオブジェクトｏｂｊ２のすべてが、ｏｂｊ２のＯＩＢ１０’のｔｉｍｅｓｔａｍｐ１４２がｏｂｊ＿ｉｄのＤＩＢ１２８のｔｉｍｅｓｔａｍｐ１６２より以前である時に必ず更新または無効化されることを、再帰的に確実にする。そのようなｏｂｊ２をこの処理で更新する場合には、前記ｏｂｊ２のそれぞれのｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９に対して同様の手順を再帰的に適用する。ステップ２０５０とステップ２０６０の順序は、この実施例の正しさにとって特に重要ではない。
【０１１９】
図２５は、ＡＰＩ ｃｏｐｙ＿ｏｂｊｅｃｔ（ｏｂｊ＿ｉｄ，ｔｏ＿ｃａｃｈｅ＿ｉｄ，ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄ）１８６の例を示す図である。図からわかるように、ステップ２１００で、パラメータｏｂｊ＿ｉｄ、ｔｏ＿ｃａｃｈｅ＿ｉｄおよびｆｒｏｍ＿ｃａｃｈｅ＿ｉｄが、オブジェクト・マネージャによってすべて認識されることを検証する。そうである場合には、ステップ２１１０で、ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄがｏｂｊ＿ｉｄのコピーを有するかどうかを判定する。そうでない場合には、何も行われず、処理はステップ２０１０に進む。これ（他の場合も同様）のために状況変数を適当に設定し、アプリケーション・プログラムに返して、何が起きたかを示す。そうでない場合には、処理はステップ２１２０に継続し、ｔｏ＿ｃａｃｈｅ＿ｉｄとｆｒｏｍ＿ｃａｃｈｅ＿ｉｄにｏｂｊ＿ｉｄの同一バージョンが含まれるかどうかを判定する。そうである場合には、コピーを行う必要はなく、処理はステップ２０１０に継続する。そうでない場合には、ステップ２１３０で、ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄにｏｂｊ＿ｉｄの最新バージョンが含まれるかどうかを判定する。そうである場合には、ステップ２１４０で、オブジェクトをｔｏ＿ｃａｃｈｅ＿ｉｄのオブジェクト記憶域１３２にコピーし、ディレクトリ１３０を更新する。ｔｏ＿ｃａｃｈｅ＿ｉｄのディレクトリ１３０にｏｂｊ＿ｉｄのＯＩＢ１０’が存在しない場合には、これを作成する。以前にｏｂｊ＿ｉｄのどのバージョンもｔｏ＿ｃａｃｈｅ＿ｉｄに含まれたことがない場合には、ｏｂｊ＿ｉｄのｓｔｏｒａｇｅ＿ｌｉｓｔ１６３にｔｏ＿ｃａｃｈｅ＿ｉｄを追加する。ステップ２１７０で、ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９にある現行でないオブジェクトのうち、ｏｂｊ＿ｉｄのＤＩＢのｔｉｍｅｓｔａｍｐ１６２より前のＯＩＢのｔｉｍｅｓｔａｍｐ１４２を有するオブジェクトのすべてを、更新または無効化することよって、一貫性を保つ。そうではなく、ステップ２１３０の結果が否定の場合には、ステップ２１５０で、（１）ｏｂｊ＿ｉｄのｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９に含まれるオブジェクトのうちで、現行でないバージョンがｔｏ＿ｃａｃｈｅ＿ｉｄに格納されているオブジェクトのすべてが、ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄにあるｏｂｊ＿ｉｄのバージョンのｔｉｍｅｓｔａｍｐ１４２と同一のｔｉｍｅｓｔａｍｐ１４２を有し、（２）ｏｂｊ＿ｉｄのｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９に含まれるオブジェクトのうちで、現行バージョンがｔｏ＿ｃａｃｈｅ＿ｉｄに格納されているオブジェクトのすべてが、ｆｒｏｍ＿ｃａｃｈｅ＿ｉｄにあるｏｂｊ＿ｉｄのバージョンのｔｉｍｅｓｔａｍｐ１４２と同一かこれより以前のｔｉｍｅｓｔａｍｐ１４２を有する場合でなければ、オブジェクトのコピーは許可されない。この両方の条件が満たされる場合には、ステップ２１６０で、ｏｂｊ＿ｉｄがｆｒｏｍ＿ｃａｃｈｅ＿ｉｄからｔｏ＿ｃａｃｈｅ＿ｉｄにコピーされる。
【０１２０】
ｔｏ＿ｃａｃｈｅ＿ｉｄのディレクトリ１３０内にｏｂｊ＿ｉｄのＯＩＢ１０’が存在しない場合には、これを作成する。以前にｏｂｊ＿ｉｄのどのバージョンもｔｏ＿ｃａｃｈｅ＿ｉｄに含まれたことがない場合には、ｏｂｊ＿ｉｄのｓｔｏｒａｇｅ＿ｌｉｓｔ１６３にｔｏ＿ｃａｃｈｅ＿ｉｄを追加する。
【０１２１】
ＡＰＩ ｃｏｐｙ＿ｏｂｊｅｃｔおよびｃａｃｈｅ＿ｌａｔｅｓｔ＿ｖｅｒｓｉｏｎに対する簡単な拡張は、一貫性リストの他のオブジェクトも更新を必要としている場合に、オブジェクトが格納されないようにするフラグである。もう１つの簡単な拡張は、キャッシュにｏｂｊｅｃｔ＿ｉｄのどのバージョンも含まれたことがない場合に、キャッシュにｏｂｊｅｃｔ＿ｉｄを置くだけの追加フラグである。
【０１２２】
もう１つの簡単な拡張は、オブジェクト・マネージャがオブジェクトの以前のバージョンのすべてを維持するシステムである。この場合、特定の（ｏｂｊｅｃｔ＿ｉｄ，ｖｅｒｓｉｏｎ＿ｎｕｍ）対によって識別される特定のオブジェクトをキャッシュに追加するためのＡＰＩを有することができる。
【０１２３】
オブジェクトは、ＡＰＩ呼出しｄｅｌｅｔｅ＿ｏｂｊｅｃｔ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ）１８７を介してキャッシュから削除される。当業者であれば、この詳細な説明に従ってこの関数を実施することが簡単であることを諒解するであろう。このＡＰＩ呼出しによって実行される機能の例が、ｏｂｊ＿ｉｄによって識別されるオブジェクトのＤＩＢ１２８（図２１）のｓｔｏｒａｇｅ＿ｌｉｓｔ１６３からのｃａｃｈｅの除去である。
【０１２４】
基礎データの値を変更するアプリケーション・プログラムは、オブジェクト・マネージャに知らせなければならない。これを達成するための２つのＡＰＩ呼出しが、ｏｂｊｅｃｔ＿ｈａｓ＿ｃｈａｎｇｅｄ（ｏｂｊ＿ｉｄ）１８８（ｏｂｊ＿ｉｄパラメータでグラフ・オブジェクトを識別する）と、ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８９（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓパラメータにグラフ・オブジェクト（へのポインタ）のリストが含まれる）である。
【０１２５】
ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓの複数のグラフ・オブジェクトが、共通の他の多数のグラフ・オブジェクトに影響する場合には、リストのグラフ・オブジェクトごとに１回ずつｏｂｊｅｃｔ＿ｈａｓ＿ｃｈａｎｇｅｄ ＡＰＩを呼び出すよりも、ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ ＡＰＩの方が効率的である。
【０１２６】
図２６は、ＡＰＩ ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８９の例を示す図である。当業者であれば、この図から、ＡＰＩ ｏｂｊｅｃｔ＿ｈａｓ＿ｃｈａｎｇｅｄ（ｏｂｊ＿ｉｄ）の実装が簡単であることを諒解するであろう。
【０１２７】
説明を簡単にするために、ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓの各要素がＧの有効なノードに対応し、ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓの２つの要素が同一のノードを参照することがないと仮定する。詳細な説明から、これがあてはまらない状況にこの関数を適合させるのは簡単である。図からわかるように、ステップ２４００で、カウンタｎｕｍ＿ｕｐｄａｔｅｓ１２５（図１６）を１つだけ増分する。ステップ２４０２で、ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓパラメータによって指定されたグラフ・オブジェクトに対応するノードのすべてを訪れたかどうかを判定する。そうである場合には、ステップ２４０３で、更新伝播段階（図２７参照）に進み、ステップ２４０４で、一貫性検査段階（図３１参照）に進む。そうでない場合には、ステップ２４０５で、ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓのグラフ・オブジェクトに対応する新しいノードに進む。ｏｂｊ＿ｉｄが、そのノードのｏｂｊｅｃｔ＿ｉｄ１６０であるものとする。オブジェクト・マネージャは、ｏｂｊ＿ｉｄのＤＩＢ１２８（図２１）のｖｅｒｓｉｏｎ＿ｎｕｍ１６１を１つだけ増分し、ｔｉｍｅｓｔａｍｐ１６２フィールドにｎｕｍ＿ｕｐｄａｔｅｓ１２５の値をセットする。ステップ２４０６とステップ２４０８は、ｏｂｊ＿ｉｄを含むキャッシュｃ１（ｓｔｏｒａｇｅ＿ｌｉｓｔ１６３から取得する）のそれぞれに、ｏｂｊ＿ｉｄのバージョンを更新または無効化するように通知するループを表す。ステップ２４０６で、関数ｕｐｄａｔｅ＿ｏｒ＿ｉｎｖａｌｉｄａｔｅ（ｃ１，ｏｂｊ＿ｉｄ）（図３０参照）を呼び出して、これを行う。
【０１２８】
当業者であれば、ｏｂｊ＿ｉｄのコピーを更新または無効化しなければならないキャッシュをステップ２４０６で決定する際に、選択性を適用することが単純であることを諒解するであろう。
【０１２９】
図３０は、ｕｐｄａｔｅ＿ｏｒ＿ｉｎｖａｌｉｄａｔｅ（ｃａｃｈｅｉｄ，ｏｂｊｅｃｔｉｄ）のロジックの例を示す図である。これは、現在ｃａｃｈｅｉｄにあるｏｂｊｅｃｔｉｄのバージョンを更新または無効化しなければならない時（たとえば図２６のステップ２４０６）に必ず呼び出される。図からわかるように、ステップ２４０７で、ｏｂｊｅｃｔｉｄをｃａｃｈｅｉｄ内で更新しなければならないかどうかを判定する。回答が否定の場合、ステップ２４４０でキャッシュからｏｂｊｅｃｔｉｄを無効化し、ステップ２４４１でこの手順はリターンする。回答が肯定の場合、ステップ２４４２で、ｏｂｊｅｃｔｉｄのＯＩＢ１０’（図１９）に対して以下の変更を行う。
１．ｖｅｒｓｉｏｎ＿ｎｕｍ１４１フィールドとｔｉｍｅｓｔａｍｐ１４２フィールドに、ＤＩＢ１２８（図２１）に含まれる現行のｖｅｒｓｉｏｎ＿ｎｕｍ１６１とｔｉｍｅｓｔａｍｐ１６２をセットする。
２．ａｃｔｕａｌ＿ｗｅｉｇｈｔ１４３に、ＤＩＢのｓｕｍ＿ｗｅｉｇｈｔ１６７をセットする。
３．ｄｅｐ＿ｌｉｓｔ１４４（図２０）を更新する。ｄｅｐ＿ｌｉｓｔ１４４の各メンバは、ｏｂｊｅｃｔｉｄによって識別されるオブジェクトに対する依存性を有するグラフ・オブジェクトｏ２に対応する。ｗｅｉｇｈｔ＿ａｃｔ１５２が、Ｇの同一の辺に対応するＤＩＢ１２８（図２１）のｗｅｉｇｈｔ１６５と異なる場合には、ｗｅｉｇｈｔ＿ａｃｔ１５２にこのｗｅｉｇｈｔ１６５をセットする。さらに、ｖｅｒｓｉｏｎ＿ｎｕｍ１５３が、ｏ２のＤＩＢに含まれるｖｅｒｓｉｏｎ＿ｎｕｍ１６１と異なる場合には、ｖｅｒｓｉｏｎ＿ｎｕｍ１５３にこのｖｅｒｓｉｏｎ＿ｎｕｍ１６１をセットする。
【０１３０】
ステップ２４４４で、オブジェクト記憶域１３２に格納されたｏｂｊｅｃｔｉｄの実際の値を更新する。まず、ＤＩＢ１２８（図２１）のｌａｔｅｓｔ＿ｏｂｊｅｃｔ１６０１フィールドからｏｂｊｅｃｔｉｄの更新されたバージョンの取得を試みる。これに成功した場合、ステップ２４４４は終了である。これに失敗した（すなわち、このポインタがｎｕｌｌである）場合、たとえばｏｂｊｅｃｔｉｄの新バージョンを完全に計算するか、一部だけを再計算し、新しい部分を既存のバージョンの他の部分と合併するかのいずれかなどによって、ｏｂｊｅｃｔｉｄの更新されたバージョンを計算する。後者の計算は、しばしば前者より効率的である。どちらの場合でも、オブジェクト・マネージャは、ＤＩＢのｌａｔｅｓｔ＿ｏｂｊｅｃｔ１６０１フィールドを更新し、その結果、ｏｂｊｅｃｔｉｄの最新バージョンを必要とする他のキャッシュが、それを再計算する代わりに単純にコピーできるようにするという選択肢を有する。
【０１３１】
いくつかの場合では、ステップ２４４４で、ｏｂｊｅｃｔｉｄの後のバージョン、好ましくは、実際には現行でない簡単にアクセスできる最終バージョン（一般に、最も高いｖｅｒｓｉｏｎ＿ｎｕｍ１４１を有するキャッシュ記憶されたバージョン）を用いて、ｏｂｊｅｃｔｉｄの実際の値を更新することができる。これは、ｏｂｊｅｃｔｉｄの現行値の計算が、非現実的に高コストの場合に有利である。このタイプの更新は、以下のどちらかが真の場合には許可されないことが好ましい。
１．ｏｂｊｅｃｔｉｄが、ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）に渡されるリストに含まれるオブジェクトの１つであるか、
２．ｏｂｊｅｃｔｉｄの後のバージョンでも、ａｃｔｕａｌ＿ｗｅｉｇｈｔ１４３＜ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８である。
【０１３２】
ステップ２４４３で、ｃａｃｈｅｉｄによって識別されるキャッシュに含まれる、ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９のオブジェクトごとに、（ｏｂｊｅｃｔ＿ｉｄ１６０，ｃａｃｈｅ＿ｉｄ）対を一貫性スタック１２８．５（図１６）に追加する。オブジェクト・マネージャ１２０は、一貫性スタック１２８．５上のキャッシュ記憶された項目のすべてが一貫性を有することを、一貫性検査段階（図３１）で確認する。
【０１３３】
一貫性スタックは、複数の形で実施することができるが、可能な２つの構造が、リストと平衡木（ｂａｌａｎｃｅｄ ｔｒｅｅｓ）である（参考文献、エイホ（Ａｈｏ）、ホップクロフト（Ｈｏｐｃｒｏｆｔ）、ウルマン（Ｕｌｌｍａｎ））。リストには、挿入が一定時間で行えるという長所がある。短所は、項目の重複したコピーが存在する可能性があることである。木には、重複した項目を格納する必要がないという長所がある。短所は、ｎが一貫性スタックの項目数であるとして、挿入時間がＯ（ｌｏｇ（ｎ））になることである。
【０１３４】
ステップ２４４３では、任意選択として、一貫性スタックにオブジェクトを追加する前に、さらに選択性を適用することができる。ｏｂｊｅｃｔ＿ｉｄ２が、ｃａｃｈｅｉｄ内のｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９に含まれるオブジェクトであるものとする。ｃａｃｈｅｉｄにｏｂｊｅｃｔ＿ｉｄ２の現行バージョンが含まれる場合、（ｏｂｊｅｃｔ＿ｉｄ２，ｃａｃｈｅｉｄ）を一貫性スタックに追加する必要はない。このバージョンが現行バージョンであるのは、以下の両方が真の場合である。
１．ｏｂｊｅｃｔ＿ｉｄ２に対応する頂点に、ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８９への現在の呼出しの処理中にすでに訪れている。これが真になるのは、ｏｂｊｅｃｔ＿ｉｄ２のＤＩＢ１２８（図２１）のｔｉｍｅｓｔａｍｐ１６２がｎｕｍ＿ｕｐｄａｔｅｓ１２５と等しい場合だけである。
２．ＯＩＢ１０’（図１９）のｖｅｒｓｉｏｎ＿ｎｕｍ１４１とｏｂｊｅｃｔ＿ｉｄ２のＤＩＢのｖｅｒｓｉｏｎ＿ｎｕｍ１６１が同一である。
【０１３５】
ステップ２４４３で、（１）と（２）の両方が真であると判定された場合には、（ｏｂｊｅｃｔ＿ｉｄ２，ｃａｃｈｅｉｄ）は、一貫性スタックに追加されない。（１）が真だが（２）が偽の場合、ステップ２４４３で、ｏｂｊｅｃｔ＿ｉｄ２とｃａｃｈｅｉｄに対してｕｐｄａｔｅ＿ｏｒ＿ｉｎｖａｌｉｄａｔｅを再帰的に呼び出すことができ、これによって、（ｏｂｊｅｃｔ＿ｉｄ２，ｃａｃｈｅｉｄ）を一貫性スタックに追加する必要がなくなる。
【０１３６】
当業者は、この説明から、ステップ２４４２、２４４３および２４４４を任意の順序または並列に実施することが簡単にできるはずである。
【０１３７】
図２７は、ｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８９の更新伝播段階の例を示す図である。ステップ２４０３および２４１６によって実行される基本的な機能は、ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓからアクセスできるグラフＧのすべての辺をトラバースすることである。好ましい技法は、深さ優先探索（「ｄｆｓ」）（参考文献、エイホ（Ａｈｏ）、ホップクロフト（Ｈｏｐｃｒｏｆｔ）、ウルマン（Ｕｌｌｍａｎ））に類似の技法である。しかし、当業者であれば、幅優先探索などの他のグラフ・トラバース法と共に機能するように技法を適合させることが簡単にできるはずである。
【０１３８】
図２８は、基礎データに対する変更に応答して、深さ優先の形（ｄｆｓ）でオブジェクト依存性グラフを介して変更を伝播するための方法の一部の例を示す図である。第１のノードｏｂｊ１から第２のノードｏｂｊ２への辺をトラバースした直後であると仮定する。ステップ２４１６では、ノードｏｂｊ２を訪れたことがあるかどうかを判定する。回答が肯定になるのは、ｏｂｊ２のｔｉｍｅｓｔａｍｐ１６２（図２１）＝ｎｕｍ＿ｕｐｄａｔｅｓ１２５（図１６）の場合に限る。
【０１３９】
ステップ２４１６の結果が真の場合、処理はステップ２４１２に継続する。このステップは、ｓｔｏｒａｇｅ＿ｌｉｓｔ１６３（図２１）に含まれるすべてのキャッシュを検査して、そのキャッシュにｏｂｊ２のコピーが含まれるかどうかを調べるループの一部である。各オブジェクトは、ｏｂｊｅｃｔ＿ｉｄフィールドとｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドを有することが好ましいことを想起されたい。ｏｂｊｅｃｔ＿ｉｄフィールドは、アプリケーション・プログラムがオブジェクトを識別するのに使用するもの（たとえばＵＲＬ）に対応するが、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒフィールドは、同一のｏｂｊｅｃｔ＿ｉｄを有する複数のオブジェクトを維持し、一意に識別するのに使用される。ステップ２４２０で、そのようなキャッシュｃａｃｈｅｉｄのそれぞれについて、ＯＩＢ１０’（図１９）のｖｅｒｓｉｏｎ＿ｎｕｍ１４１とＤＩＢ１２８（図２１）のｖｅｒｓｉｏｎ＿ｎｕｍ１６１を比較することによって、ｏｂｊ２のバージョンが現行であるかどうかを判定する。ステップ２４２０の結果が肯定の場合、ステップ２４２１で、ｏｂｊ２のｄｅｐ＿ｌｉｓｔ１４４上で、ｏｂｊ１に対応する要素が、ｏｂｊ１のＤＩＢのｖｅｒｓｉｏｎ＿ｎｕｍ１６１と等しいｖｅｒｓｉｏｎ＿ｎｕｍ１５３を有するようにする。
【０１４０】
ステップ２４２０の結果が否定の場合、すなわち、ｏｂｊ２のバージョンが現行でない場合には、関数ｄｅｃｒｅａｓｅ＿ｗｅｉｇｈｔ（ｃａｃｈｅｉｄ，ｏｂｊ１，ｏｂｊ２）を呼び出す（図２９参照）。各辺に、データ依存性の重要さを表す、重みと称する負でない数を関連付けることができることを想起されたい。たとえば、大きい数で重要な依存性を表し、小さい数で重要でない依存性を表すことができる。また、オブジェクトに、ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ（閾重み）と称する値を関連付けることもできることを想起されたい。現行の入方向のデータ依存性に対応する重みの合計がｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ未満になった時には必ず、そのオブジェクトは非常に古いとみなされる。このようなオブジェクトは、最近のバージョンのオブジェクトを必要とするアプリケーションのために更新または無効化しなければならない。
【０１４１】
ステップ２４１６の結果が偽の場合、ステップ２４２３で、ｏｂｊ２のｖｅｒｓｉｏｎ＿ｎｕｍ１６１を増分し、ｔｉｍｅｓｔａｍｐ１６２にｎｕｍ＿ｕｐｄａｔｅｓ１２５（図１６）をセットして、ｏｂｊ２に訪れたことを示す。ステップ２４２４は、ｓｔｏｒａｇｅ＿ｌｉｓｔ１６３上のすべてのキャッシュを検査して、そのキャッシュにｏｂｊ２のコピーが含まれるかどうかを調べるループの一部である。そのようなキャッシュｃａｃｈｅｉｄのそれぞれについて、ステップ２４２５で、関数ｄｅｃｒｅａｓｅ＿ｗｅｉｇｈｔ（ｃａｃｈｅｉｄ，ｏｂｊ１，ｏｂｊ２）を呼び出す。このループを抜けた後に、ステップ２４２６で、ｏｂｊ２から出る辺のすべてに対して再帰的にｄｆｓロジック（図２８）を呼び出す。
【０１４２】
図２９は、ｄｅｃｒｅａｓｅ＿ｗｅｉｇｈｔ（ｃａｃｈｅｉｄ，ｆｒｏｍ＿ｏｂｊ，ｔｏ＿ｏｂｊ）のロジックの例を示す図である。図からわかるように、ステップ２４２５で、ｔｏ＿ｏｂｊのａｃｔｕａｌ＿ｗｅｉｇｈｔ１４３をｗだけ減分する。このｗは、ｆｒｏｍ＿ｏｂｊからｔｏ＿ｏｂｊへの辺に対応するｗｅｉｇｈｔ＿ａｃｔ１５２である。ステップ２４３５で、ａｃｔｕａｌ＿ｗｅｉｇｈｔ１４３＜ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８であるかどうかを判定する。回答が肯定の場合、関数ｕｐｄａｔｅ＿ｏｒ＿ｉｎｖａｌｉｄａｔｅ（ｃａｃｈｅｉｄ，ｔｏ＿ｏｂｊ）を呼び出す。回答が否定の場合、ステップ２４３６で、ｆｒｏｍ＿ｏｂｊからｔｏ＿ｏｂｊへの辺に対応するｗｅｉｇｈｔ＿ａｃｔ１５２に、０をセットする。
【０１４３】
更新伝播段階の後に、オブジェクト・マネージャは、ｃｏｎｓｉｓｔｅｎｃｙ＿ｌｉｓｔ１６９が実際に一貫性を有するようにしなければならない。これは、図３１に示された一貫性検査段階で行われる。図からわかるように、ステップ２４０４は、一貫性スタック１２８．５（図１６）内の対（ｏｂｊｅｃｔ＿ｉｄ１６０，ｃａｃｈｅ＿ｉｄ１３５）のそれぞれを調べるループの一部である。そのような対のそれぞれについて、ステップ２４５１で、ｖｅｒｓｉｏｎ＿ｎｕｍ１４１とｖｅｒｓｉｏｎ＿ｎｕｍ１６１を比較することによって、キャッシュｃａｃｈｅ＿ｉｄ内のｏｂｊｅｃｔ＿ｉｄのバージョンが現行であるかどうかを判定する。回答が肯定の場合、処理はステップ２４０４に戻る。そうでない場合には、オブジェクトの更新または無効化のいずれかを行わなければならない。ステップ２４５５で、オブジェクトを更新するかどうかを判定する。回答が否定の場合、前に説明したステップ２４４０（図３０）でオブジェクトを無効化する。回答が肯定の場合、前に説明したステップ２０５０（図２４）で最新の値をキャッシュに追加し、やはり前に説明したステップ２０６０（図２４）で、新しい一貫性の制約を満足させる。ステップ２０５０とステップ２０６０の順序は、この実施例の正しさにとって特に重要ではない。
【０１４４】
もう１つのＡＰＩであるｕｐｄａｔｅ＿ｃａｃｈｅ（ｃａｃｈｅ）１９３は、キャッシュ内のすべての項目を現行にするＡＰＩである。これは、キャッシュ内のすべてのオブジェクトのＯＩＢを調べ、古い項目を無効化または更新することによって行われる。すべてのオブジェクトが現行になり、したがって、この関数の完了後には一貫性が保たれているので、一貫性リストは無視される。
【０１４５】
関係
本発明は、関係データベース（メルトン（Ｊ．Ｍｅｌｔｏｎ）およびサイモン（Ａ．Ｒ．Ｓｉｍｏｎ）共著「Ｕｎｄｅｒｓｔａｎｄｉｎｇ ｔｈｅ Ｎｅｗ ＳＱＬ： Ａ Ｃｏｍｐｌｅｔｅ Ｇｕｉｄｅ」、Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎ刊、１９９３年を参照）の一部とすることのできるレコード（このレコードは、好ましい実施例に使用されるレコードと同義ではない）を処理するための特殊な特徴を有する。
【０１４６】
たとえば、関係ｒｅｌ＿ｎａｍｅが、どちらもｉｎｔｅｇｅｒ型の属性ａｇｅ（年齢）およびｗｅｉｇｈｔ（体重）を有すると仮定する。以下では、ｒｅｌ＿ｎａｍｅ（ａｇｅ＝２５、ｗｅｉｇｈｔ＝３４）が単一レコードを表し、ｒｅｌ＿ｎａｍｅ（ａｇｅ＝２５）が、複数レコード指定子（ＭＲＳ）であり、ｒｅｌ＿ｎａｍｅに属しａｇｅ＝２５であるすべてのレコードを表す。
【０１４７】
本発明は、単一レコードまたは複数レコードのいずれかに対応するオブジェクトを管理できるようにする特徴を有する。このようなオブジェクトを、関係オブジェクトと称する。単独のオブジェクトが、同一の関係からの複数のレコードを表すことができる。このようなオブジェクトを、複数レコード・オブジェクト（ＭＲＯ）と称し、単一のレコードに対応するオブジェクトを、単一レコード・オブジェクト（ＳＲＯ）と称する。関係オブジェクトｏｂｊ２に対応するレコードのセットが、ＭＲＯであるｏｂｊ１に対応するレコードのセットのサブセットである場合に、ｏｂｊ１にｏｂｊ２が含まれる。オブジェクト・マネージャは、関係オブジェクトからそれを含むＭＲＯへの依存性を自動的に追加する。
【０１４８】
オブジェクト・マネージャは、複数レコード・ツリー（ＭＲＴ）１２２と称する平衡木を維持する。このＭＲＴ１２２には、ＧのすべてのＭＲＯノードへのポインタが含まれ、ＭＲＴ１２２は、ＤＩＢ１２８（図２１）のｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によってアルファベット順にインデクシングされる。単一関係木（ＳＲＴ）と称する平衡木には、ＧのすべてのＳＲＯノードへのポインタが含まれ、ＳＲＴも、ＤＩＢのｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によってアルファベット順にインデクシングされる。この説明から簡単に実施できる代替アプローチは、単一関係と複数関係の両方のための単独の平衡木を維持することである。もう１つの変形は、この情報を維持するために平衡木以外のデータ構造を使用することである。
【０１４９】
本発明によれば、関係オブジェクトを作成する前に、ＡＰＩ ｄｅｆｉｎｅ＿ｒｅｌａｔｉｏｎ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓ）１９４を介してオブジェクト・マネージャに対して関係を識別しなければならない。
【０１５０】
引数ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓの各要素は、属性の名前と型を含む対である。ＡＰＩ ｄｅｆｉｎｅ＿ｒｅｌａｔｉｏｎ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓ）１９４では、関係に関する情報が、関係情報区域１２９（図１６）に格納される。
【０１５１】
図３２は、単一レコード・オブジェクト（ＳＲＯ）に対応するノードを作成するためのロジックの例を示す図である。単一のレコードに対応するオブジェクトを、単一レコード・オブジェクト（ＳＲＯ）と称することを想起されたい。単一関係木（ＳＲＴ）と称する平衡木には、ＧのすべてのＳＲＯノードへのポインタが含まれ、ＳＲＴは、ＤＩＢ（図２１）のｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によってアルファベット順にインデクシングされる。ＳＲＯに対応するノードは、ＡＰＩ ｃｒｅａｔｅ＿ｓｒｏ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ，ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓ）１９０（図２２）を介して作成される。図３２を参照すると、ステップ２３００で、すべての入力パラメータが有効であるかどうか（たとえば、正しい型であるかどうかなど）を判定する。関係情報区域１２９を調べることによって、関係「ｒｅｌａｔｉｏｎ＿ｎａｍｅ」が以前にｄｅｆｉｎｅ＿ｒｅｌａｔｉｏｎ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓ）１９４を介して定義されたことを検証する。ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓに正しい個数の値が含まれ、すべての値が正しい型であることも検証する。ｏｂｊ＿ｉｄのノードまたは同一レコードに対応するノードがまだ存在しないことも検証する（ｏｂｊ＿ｉｄのノードがすでに存在する場合に、古いノードを上書きするように設計を変更することは簡単である。同一のｏｂｊ＿ｉｄを有する複数のノードが存在可能になるように設計を変更することも簡単である。同一レコードに対応する複数のノードを許容することも簡単である）。すべてのパラメータが有効であると判定された場合、処理はステップ２３０５に継続する。そうでない場合には、ｃｒｅａｔｅ＿ｓｒｏ＿ｎｏｄｅは、ステップ２３２０で適当な状況メッセージを返す。
【０１５２】
ステップ２３０５では、ｏｂｊｅｃｔ＿ｉｄ１６０にｏｂｊ＿ｉｄをセットし、ｖｅｒｓｉｏｎ＿ｎｕｍ１６１にｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍをセットし、ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８にｔｈｒｅｓｈ＿ｗｅｉｇｈｔをセットし、ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２に、属性値のすべてを連結されたｒｅｌａｔｉｏｎ＿ｎａｍｅをセットすることによって初期設定を行い、Ｇに新しいノードを作成する。ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２を構成する関係と属性値は、区切り文字によって分離されることが好ましい。そうすれば、関係と属性値のそれぞれを、ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２から簡単に識別できるようになる。ｍｕｌｔｉｐｌｅ＿ｒｅｃｏｒｄｓ１６０３（図２１）フィールドには偽をセットする。ステップ２３１０で、ノードへのポインタをＳＲＴに追加する。ＳＲＴでの新しいポインタの位置は、ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２から決定される。ステップ２３１５で、ｏｂｊ＿ｉｄからそれを含む複数レコード・オブジェクト（ＭＲＯ）のそれぞれへの依存性を追加する。このようなＭＲＯは、ＭＲＴ１２２を調べることによって見つかる。ＭＲＴは、ＧのすべてのＭＲＯノードへのポインタを含む平衡木であることが好ましく、ＤＩＢ１２８（図２１）のｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によってアルファベット順にインデクシングされる。ｒｅｌａｔｉｏｎ＿ｎａｍｅに関するＭＲＯを調べることだけが必要である。そのようなＭＲＯは、ＭＲＯの総数をｎ、ｒｅｌａｔｉｏｎ＿ｎａｍｅに関するＭＲＯの数をｍとして、Ｏ（ｌｏｇ（ｎ）＋ｍ）命令ですべてを識別できる。
【０１５３】
ｏｂｊ＿ｉｄを含むＭＲＯ「ｏｂｊ２＿ｉｄ」のそれぞれについて、ｏｂｊ＿ｉｄからｏｂｊ２＿ｉｄへの依存性を作成する。図２１を参照すると、依存性は、ｏｂｊ２＿ｉｄのｍｒｏ＿ｄｅｐ＿ｗｅｉｇｈｔ１６０４の重みを用いて初期設定されることが好ましい。ｏｂｊ２＿ｉｄのｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８は、ｏｂｊ２＿ｉｄのｍｒｏ＿ｔｈｒｅｓｈｏｌｄ＿ｉｎｃｒｅｍｅｎｔ１６０５だけ増分される。このアルゴリズムの簡単な拡張は、依存性に重みを割り当て、ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８を変更するのに他の技法を使用することである。図３２に戻って、ステップ２３２０で、この処理は状況メッセージを返す。ステップ２３０５、２３１０および２３１５の順序は、変更することができる。さらに、これらのステップは、並行に実行することができる。
【０１５４】
図３３は、複数レコード・オブジェクト（ＭＲＯ）を作成するためのロジックの例を示す図である。ＭＲＯは、ＡＰＩ ｃｒｅａｔｅ＿ｍｒｏ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ，ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓ，ｒｅｌ＿ｄｅｆａｕｌｔ＿ｗｅｉｇｈｔ，ｒｅｌ＿ｄｅｆａｕｌｔ＿ｔｈｒｅｓｈｏｌｄ）１９１を介して作成され、ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓの属性条件は、「＝２５」、「＞９６」、「＞４５ ａｎｄ ＜１００」などの形式である。属性条件は、ｎｕｌｌとすることもでき、これは、属性値に対する制約がないことを意味する。
【０１５５】
単独のオブジェクトが、同一の関係からの複数のレコードを表すことができることを想起されたい。このようなオブジェクトを、複数レコード・オブジェクト（ＭＲＯ）と称し、単一のレコードに対応するオブジェクトを、単一レコード・オブジェクト（ＳＲＯ）と称する。関係オブジェクトｏｂｊ２に対応するレコードのセットが、ＭＲＯであるｏｂｊ１に対応するレコードのセットのサブセットである場合に、ｏｂｊ１にｏｂｊ２が含まれる。オブジェクト・マネージャは、関係オブジェクトからそれを含むＭＲＯへの依存性を自動的に追加する。オブジェクト・マネージャは、ＭＲＴ１２２と称する平衡木を維持することが好ましく、このＭＲＴ１２２には、ＧのすべてのＭＲＯノードへのポインタが含まれ、ＤＩＢ１２８（図２１）のｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によってアルファベット順にインデクシングされる。単一関係木（ＳＲＴ）と称する平衡木には、ＧのすべてのＳＲＯへのポインタが含まれ、ＳＲＴも、ＤＩＢのｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によってアルファベット順にインデクシングされる。
【０１５６】
図からわかるように、ステップ２６００で、すべての入力パラメータが有効である（たとえば、正しい型であるなど）かどうかを判定する。さらに、関係情報区域１２９（図１６）を調べることによって、関係「ｒｅｌａｔｉｏｎ＿ｎａｍｅ」が以前にｄｅｆｉｎｅ＿ｒｅｌａｔｉｏｎ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓ）１９４への呼出しを介して定義されたことを検証する。また、ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓが有効であることと、ｏｂｊ＿ｉｄのノードまたは同一セットのレコードに対応するノードがまだ存在しないことも検証する。当業者であれば、ｏｂｊ＿ｉｄのノードがすでに存在する場合に、古いノードを上書きするように設計を変更することが簡単であることを諒解するであろう。また、同一のｏｂｊ＿ｉｄを有する複数のノードが存在できるように設計を変更することも簡単である。また、同一セットのレコードに複数ノードが対応することを可能にすることも簡単である。ステップ２６００の結果、全パラメータが有効であると判定された場合には、処理はステップ２６０５に継続する。そうでない場合には、ｃｒｅａｔｅ＿ｍｒｏ＿ｎｏｄｅは、ステップ２６２０で、適当な状況メッセージを返す。
【０１５７】
ステップ２６０５では（図２１も参照されたい）、ｏｂｊｅｃｔ＿ｉｄ１６０にｏｂｊ＿ｉｄをセットし、ｖｅｒｓｉｏｎ＿ｎｕｍ１６１にｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍをセットし、ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８にｔｈｒｅｓｈ＿ｗｅｉｇｈｔをセットし、ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２に、属性条件のすべてを連結されたｒｅｌａｔｉｏｎ＿ｎａｍｅをセットすることによって初期設定を行い、Ｇ（図２２）に新しいノードを作成する。ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２を構成する関係と属性条件は、すべてが区切り文字によって分離される。この形で、関係と属性条件のそれぞれをｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２から簡単に識別できるようになる。ｍｕｌｔｉｐｌｅ＿ｒｅｃｏｒｄｓ１６０３フィールドには真をセットし、ｍｒｏ＿ｄｅｐ＿ｗｅｉｇｈｔ１６０４にはｒｅｌ＿ｄｅｆａｕｌｔ＿ｗｅｉｇｈｔをセットし、ｍｒｏ＿ｔｈｒｅｓｈｏｌｄ＿ｉｎｃｒｅｍｅｎｔ１６０５にはｒｅｌ＿ｄｅｆａｕｌｔ＿ｔｈｒｅｓｈｏｌｄをセットする。
【０１５８】
ステップ２６１０で、ノードへのポインタをＭＲＴに追加する。ＭＲＴでの新しいポインタの位置は、ｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２によって決定される。ステップ２６１５では、ステップ２３１５と同一の形で、ｏｂｊ＿ｉｄからそれを含むＭＲＯのそれぞれへの依存性を追加する。
【０１５９】
ｏｂｊ＿ｉｄに含まれるオブジェクトｏｂｊ２＿ｉｄのそれぞれについて、ステップ２６２５で、ｏｂｊ２＿ｉｄからｏｂｊ＿ｉｄへの依存性を追加する。このような依存オブジェクトは、ＭＲＴ１２２とＳＲＴ１２３の両方を検索し、ｒｅｌａｔｉｏｎ＿ｎａｍｅに関する他のすべての関係オブジェクトを検討することによって見つかる。依存性のそれぞれに、ｏｂｊ＿ｉｄのｍｒｏ＿ｄｅｐ＿ｗｅｉｇｈｔ１６０４の重みを割り当てる。このような依存性のそれぞれについて、ｏｂｊ＿ｉｄのｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８を、ｏｂｊ＿ｉｄのｍｒｏ＿ｔｈｒｅｓｈｏｌｄ＿ｉｎｃｒｅｍｅｎｔ１６０５だけ増分する。当業者であれば、依存性への重みの割り当てとｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔ１６８の変更に他の技法を使用できることを諒解するであろう。ステップ２６２０で、ｃｒｅａｔｅ＿ｍｒｏ＿ｎｏｄｅは状況メッセージを返す。ステップ２６０５、２６１０、２６１５および２６２５の順序は、変更することができる。さらに、これらのステップは、並行に実行することができる。
【０１６０】
その代わりに、関係オブジェクトｏｂｊ１からそれを含むＭＲＯ ｏｂｊ２への依存性の重みを、ｏｂｊ１にも含まれるｏｂｊ２に対応するレコードの比率と重要さに基づくものとすることができる。この変形は、ステップ２３１５、２６１５または２６２５に適用することができる。もう１つの代替案は、２つのＭＲＯのどちらもが他方のサブセットではないが、２つのＭＲＯが１つまたは複数の共通のレコードを有する時に、このＭＲＯの間に選択的に依存性を追加することである。
【０１６１】
図２１に戻って、当業者は、本発明の趣旨および範囲の中で、関係オブジェクトがｃｒｅａｔｅ＿ｓｒｏ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ，ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓ）１９０またはｃｒｅａｔｅ＿ｍｒｏ＿ｎｏｄｅ（ｏｂｊ＿ｉｄ，ｉｎｉｔｉａｌ＿ｖｅｒｓｉｏｎ＿ｎｕｍ，ｔｈｒｅｓｈ＿ｗｅｉｇｈｔ，ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓ，ｒｅｌ＿ｄｅｆａｕｌｔ＿ｗｅｉｇｈｔ，ｒｅｌ＿ｄｅｆａｕｌｔ＿ｔｈｒｅｓｈｏｌｄ）１９１を介して定義された後に、そのオブジェクトのｒｅｌａｔｉｏｎａｌ＿ｓｔｒｉｎｇ１６０２、ｍｕｌｔｉｐｌｅ＿ｒｅｃｏｒｄｓ１６０３、ｍｒｏ＿ｄｅｐ＿ｗｅｉｇｈｔ１６０４およびｍｒｏ＿ｔｈｒｅｓｈｏｌｄ＿ｉｎｃｒｅｍｅｎｔ１６０５を変更するためのＡＰＩを追加できることを諒解するであろう。
【０１６２】
１つまたは複数のレコードが変更された時には、オブジェクト・マネージャは、ＡＰＩ（図２２）ｒｅｃｏｒｄ＿ｈａｓ＿ｃｈａｎｇｅｄ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓ）１９５およびｒｅｃｏｒｄｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓ）１９６を介してその変更に関する通知を受けることができる。これらのＡＰＩによって、依存性の階層全体に変更が自動的に伝播される。
【０１６３】
図３４は、ｒｅｃｏｒｄｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓ）１９６ＡＰＩを実施できる方法の例を示す図である。当業者であれば、この図からｒｅｃｏｒｄ＿ｈａｓ＿ｃｈａｎｇｅｄ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅｓ）１９５ＡＰＩを実施することが簡単であることを諒解するであろう。
【０１６４】
図からわかるように、ステップ２７００で、入力パラメータが有効であるかどうかを判定する。また、関係情報区域１２９（図１６）を調べることによって、関係ｒｅｌａｔｉｏｎ＿ｎａｍｅが以前に（ｄｅｆｉｎｅ＿ｒｅｌａｔｉｏｎ（ｒｅｌａｔｉｏｎ＿ｎａｍｅ，ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅｓ）１９４ＡＰＩ（図２２）への呼出しを介して）定義されたことを検証する。また、ｌｉｓｔ＿ｏｆ＿ａｔｔｒｉｂｕｔｅ＿ｃｏｎｄｉｔｉｏｎｓが有効であることも検証する。入力パラメータが有効である場合には、処理はステップ２７１０に進む。そうでない場合には、ステップ２７３０で、適当な状況メッセージを返してこの手順を打ち切る。
【０１６５】
ステップ２７１０で、変更されたレコードを少なくとも１つ含む関係オブジェクトをすべて見つける。これは、ｒｅｌａｔｉｏｎ＿ｎａｍｅに対応するＭＲＴ１２２およびＳＲＴ１２３（図１６）にある関係オブジェクトのすべてを調べることによって行われる。ステップ２７２０で、ステップ２７１０で識別された全オブジェクトのリストに対してｏｂｊｅｃｔｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ（ｌｉｓｔ＿ｏｆ＿ｏｂｊｅｃｔｓ）１８９を呼び出すことによって、Ｇの他のノードに変更を伝播することができる。
【０１６６】
最後に、ステップ２７３０で、ｒｅｃｏｒｄｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄが適当な状況メッセージを返す。
【０１６７】
ｒｅｃｏｒｄｓ＿ｈａｖｅ＿ｃｈａｎｇｅｄ ＡＰＩの簡単な変形は、変更情報をＧ全体に伝播する方法を決定する際に、関係オブジェクトの変更されたレコードの比率と重要さを検討することである。
【０１６８】
ＡＰＩ ｃｏｍｐａｒｅ＿ｏｂｊｅｃｔｓ（ｏｂｊ＿ｉｄ，ｃａｃｈｅ＿ｉｄ１，ｃａｃｈｅ＿ｉｄ２）１９２（図２２）は、ｃａｃｈｅ＿ｉｄ１とｃａｃｈｅ＿ｉｄ２にあるｏｂｊ＿ｉｄのバージョンがどれほど似ているかを判定するのに使用することができる。たとえば、２つのバージョンが同一であるかどうかを調べるために、ｖｅｒｓｉｏｎ＿ｎｕｍ１４１を比較することができる。これらが異なる場合には、たとえばｖｅｒｓｉｏｎ＿ｎｕｍ１４１とｔｉｍｅｓｔａｍｐ１４２（図１９）の差によって、どちらのオブジェクトが他方よりどれほど新しいかを示すことができる。
【０１６９】
オブジェクトの２つのバージョンが異なる場合、０（似ていない）以上１未満（１は同一のバージョンに対応する）の範囲の類似性スコアを計算することができる。類似性スコアは、ｃａｃｈｅ＿ｉｄ１内のｏｂｊ＿ｉｄとの一貫性を有するｏｂｊ＿ｉｄ２のバージョンが、ｃａｃｈｅ＿ｉｄ２内のｏｂｊ＿ｉｄとの一貫性を有するｏｂｊ＿ｉｄ２のバージョンと同一であるグラフ・オブジェクトｏｂｊ＿ｉｄ２からｏｂｊ＿ｉｄに入る方向の依存性の重さの合計に基づくことが好ましい。類似性スコア（ＳＳ）は、次式を使用して計算できる。
ＳＳ＝ｃｏｍｍｏｎ＿ｗｅｉｇｈｔ／ｓｕｍ＿ｗｅｉｇｈｔ１６７
ただし、ｃｏｍｍｏｎ＿ｗｅｉｇｈｔは、グラフ・オブジェクトｏｂｊ＿ｉｄ２からｏｂｊ＿ｉｄへの辺に対応するｗｅｉｇｈｔ１６５のうちで、その辺に対応するｖｅｒｓｉｏｎ＿ｎｕｍ１５３がｏｂｊ＿ｉｄの両方のバージョンと同一であるものの合計である。ｃｏｍｐａｒｅ＿ｏｂｊｅｃｔｓのロジックは、２つのバージョンが非常に異なるか否かの判定にも使用することができる。２つのバージョンが非常に異なるのは、ｃｏｍｍｏｎ＿ｗｅｉｇｈｔ＜ｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔの場合に限られる。
【０１７０】
拡張
本発明の簡単な拡張は、ＯＩＢ（図１９）にｔｈｒｅｓｈｏｌｄ＿ｗｅｉｇｈｔフィールドを含め、このフィールドと独立にキャッシュ２’（図１８）を設定させることである。もう１つの簡単な拡張は、異なるキャッシュに対応する同一のオブジェクトのために異なる一貫性リストを使用可能にすることである。
【０１７１】
もう１つの拡張は、グラフ・オブジェクトｏｂｊ１から別のグラフ・オブジェクトｏｂｊ２への、異なる重みを有する複数の依存性が存在可能なシステムである。アプリケーション・プログラムは、これらの複数の依存性を独立に変更できる。
【０１７２】
もう１つの拡張は、オブジェクトが古くなった時を、オブジェクトへの古いリンクに基づいて判定するために他のアルゴリズムを使用することである。
【０１７３】
グラフ・オブジェクトが変更された時には、好ましい実施例では、依存性グラフＧを介してその情報を伝播する時に、グラフ・オブジェクトがどのように変化したかを考慮していない。グラフ・オブジェクトが変更されたという事実だけを考慮に入れている。もう１つの拡張は、他のグラフ・オブジェクトに変更を伝播するために、グラフ・オブジェクトがどのように変更されたかを検討することである。これは、次の形で実行できる。
１．ｏｂｊｅｃｔ＿ｈａｓ＿ｃｈａｎｇｅｄなどの関数へのパラメータを介して、グラフ・オブジェクトがどのように変更されたかに関する追加情報を提供することによって実行する。この情報は、グラフ・オブジェクトからその値に依存する他のグラフ・オブジェクトへのリンクを変更するのに使用され、その後、そのグラフ・オブジェクトを継承するオブジェクトがどのように変更されたかを判定するのに使用される。
２．オブジェクト・マネージャ１２０は、グラフ・オブジェクトｏ２が変更されたと判定した時に、その親のうちのどれが変更されたかと、親がどのように変更されたかについて再帰的に収集された情報との両方を検討することができる。その後、オブジェクト・マネージャは、この情報を使用して、ｏ２がどのように変更されたかを判定する。ｏ２がどのように変更されたかに関する情報は、ｏ２に依存する他のグラフ・オブジェクトへのリンクの変更に使用され、その後、ｏ２を継承するオブジェクトがどのように変更されたかの判定に使用される。
【０１７４】
たとえば、図３５を検討する。ｕ２とｕ３は、変更された基礎データである。オブジェクト・マネージャは、この変更情報をｏ１とｏ３に伝播する。オブジェクト・マネージャは、変更情報をｏ２に伝播する時に、ｏ２のキャッシュ記憶されたコピーを更新または無効化する方法を決定する上で、ｏ１およびｏ３からｏ２への辺の重みだけを検討するのではなく、ｕ２、ｕ３、ｏ１およびｏ３に対する変更の性質も検討する。この情報は、ｏ４のキャッシュ記憶されたバージョンを更新または無効化する方法を決定するのにも使用できる。
【０１７５】
他の応用分野
本発明は、基礎データを更新するか否かをアプリケーションが決定しなければならないシステムでも使用することができる。オブジェクト依存性グラフを調べることによって、そのシステムは、基礎データに対する変更によって影響を受ける他のオブジェクトを判定することができる。この集合が満足であれば、変更を行うことができる。そうでない場合には、そのシステムは、基礎データに対する変更を止めることもできる。
【０１７６】
当業者であれば、動作を効率的にスケジューリングするために、コンパイラ、実行時システムまたはデータベースによって本発明を使用することもできることを諒解するであろう。異なるスケジュールは、基礎データに対する異なる変更をもたらす可能性がある。オブジェクト依存性グラフを分析することによって、スケジューリングの決定を行うプログラムが、動作をスケジューリングするのに好ましい方法を判定できるようになる。
【０１７７】
キャッシュを維持し、一貫性のある形で更新するためのスケーラブルな方法の詳細な説明
本発明のこの実施例は、ネットワークによって接続された１つまたは複数の物理（コンピュータ）システムの集合に対して機能するように設計されている。このシステムの集合には、本発明の複数の実体が常駐する可能性がある。本発明の複数の実体を区別するための案内として、以下に用語の定義を示す。
【０１７８】
オブジェクト・ソース。オブジェクト・ソースには、ＩＢＭ社が商標ＤＢ２の下で販売する製品や、Ｌｏｔｕｓ社が商標ＬＯＴＵＳ ＮＯＴＥＳおよびＤＯＭＩＮＯ Ｓｅｒｖｅｒの下で販売する製品などの１つまたは複数の製品と、より複雑なオブジェクト（ＨＴＭＬページなど）を構築するデータまたはオブジェクトを含む他のソース３０３０が含まれる。
【０１７９】
トリガ。データの変更に応答して動作を自動的に発生させるのに使用することのできる手段。トリガは、ＩＢＭ社が商標ＤＢ２の下で販売するものやＬｏｔｕｓ社が商標ＬＯＴＵＳ ＮＯＴＥＳおよびＤＯＭＩＮＯ Ｓｅｒｖｅｒの下で販売するものなどの多数の標準的なオブジェクト・ソースの、データの変更に応答して自動的に動作を発生させるための標準の特徴である。本発明の１実施例では、新規の形でトリガを使用して、オブジェクト・ソースに格納されたデータから構築されるオブジェクトを、データと同期した状態に保つ。
【０１８０】
トリガ通知。これは、オブジェクト・ソース内で呼び出されたトリガに応答して本発明に送られるメッセージである。
【０１８１】
キャッシュ・トランザクション。キャッシュ・オブジェクトの読取、更新または削除のためのキャッシュ・マネージャに対する要求を含む。
【０１８２】
トリガ・モニタ。キャッシュ・マネージャによって管理されるキャッシュ内のオブジェクトを、関連する遠隔データと同期した状態に保つための、本発明によるロジックの例。トリガ・モニタは、キャッシュ・マネージャによって管理されるキャッシュに格納された複合オブジェクトを基礎データと同期した状態に保つ目的で遠隔データ・ソースを監視する、長期間走行する単一のプロセスとすることができる。
【０１８３】
マスタ・トリガ・モニタ。これは、トリガ・モニタのインスタンスのうちで、トリガ通知を受け取るインスタンスである。
【０１８４】
スレーブ・トリガ・モニタ。これは、トリガ・モニタのインスタンスのうちで、マスタ・トリガ・モニタ３０００’からトリガ通知を転送される（すなわち、オブジェクト・ソースから直接ではなく）インスタンスである。
【０１８５】
局所キャッシュ。これは、そのキャッシュ自体と同一の物理計算機上に常駐するトリガ・モニタのインスタンスによって更新されるキャッシュ（または、ファイル・システムなどの他の標準的なオブジェクト記憶域）である。
【０１８６】
遠隔キャッシュ。これは、そのキャッシュ自体とは異なる物理計算機上に常駐するトリガ・モニタのインスタンスによって更新されるキャッシュ（または、ファイル・システムなどの他の標準的なオブジェクト記憶域）である。
【０１８７】
本発明は、マスタ・トリガ・モニタ３０００’（トリガ・イベントを受け取る場合）およびスレーブの遠隔トリガ・モニタ３０００ａ（あるマスタからトリガ・イベントの通知を受け取る場合）の両方の役割を演じることが可能である。
【０１８８】
ここで図面を参照すると、図３６は、本発明の特徴を有するシステムの例のブロック図である。図からわかるように、このシステムには、（１つまたは複数の）遠隔ノード３１０８が含まれる。遠隔ノード３１０８は、ウェブ・サーバ（ｈｔｔｐｄ３０８０）を介してクライアントにウェブ・ページを供給するサーバとすることができる。各ウェブ・サーバは、データベース３０１０から構築される、かなりの比率のダイナミック・ウェブ・ページを供給することができる。そのようなサーバ１００のそれぞれは、ウェブ・ページの生成に伴うコストが原因で、ダイナミック・ウェブ・ページなどの複合オブジェクトを含む１つまたは複数のオブジェクト３００４をキャッシュ記憶する。同一のダイナミック・ページに関する複数の要求を、キャッシュ３００３から満足することができ、したがって、オーバーヘッドが減る。
【０１８９】
サーバとして複数の遠隔ノード３１０８を使用すると、システムがサービスできる要求の量が増える。必須ではないが、サーバとしての遠隔ノード３１０８は、地理的に長距離の間隔を設けることができる。
【０１９０】
本発明によれば、データベース３０１０などのオブジェクト・ソースに対する変更が発生し、キャッシュ３００３に格納されている１つまたは複数のオブジェクト３００４の値に影響する可能性がある時には、トリガ・モニタ３０００が、値を変更されたオブジェクトについてキャッシュ・マネージャ３００１のそれぞれに通知する。トリガ・モニタ３０００は、キャッシュ３００３内のオブジェクト３００４が変更されたことをキャッシュ・マネージャ３００１に知らせることができる。この場合、キャッシュ・マネージャ３００１は、そのオブジェクト３００４のコピーを無効化することができる。その代わりに、トリガ・モニタ３０００は、オブジェクト３００４が変更されたことをキャッシュ・マネージャ３００１に知らせ、オブジェクト３００４の新しい値を供給することができる。当業者であれば、オブジェクト３００４の新しい値を、データ・サーバ・ノード３１０２ならびに遠隔ノード３１０８またはプロキシ・ノードなどの他の中間ノードで計算できることを諒解するであろう。どちらの場合でも、キャッシュ・マネージャは、オブジェクト３００４を無効化する必要なしに、たとえば新しいバージョンを格納するなど、オブジェクト３００４を動的に更新するという選択肢を有する。
【０１９１】
図３７は、トリガ・モニタ３０００の詳細な例を示す図である。ここでは、トリガ・モニタ３０００は、マスタ・トリガ・モニタ３０００’としてインスタンス化されている。図からわかるように、複合オブジェクト３００４ｓを含むキャッシュ３００３の維持は、トリガ・モニタ３０００と称する本発明によるプロセス（またはプロセスの集合）によって行われる。トリガ・モニタ３０００は、キャッシュ・マネージャ３００１の内容を基礎データと同期した状態に保つためにオブジェクト・ソース３０５０を監視する、長期間走行する単一のプロセスであることが好ましい。マスタ・トリガ・モニタ３０００’は、トリガ・イベント３０２０を受け取るトリガ・モニタ３０００のインスタンスである。マスタ・トリガ・モニタ３０００’には、トリガ・モニタ・ドライバ３０４０、オブジェクトＩＤ分析（ＯＩＡ）３０４１ロジック、オブジェクト・ジェネレータ３０４２ロジックおよび分配マネージャ３０４３が含まれる。
【０１９２】
マスタ・トリガ・モニタ３０００’は、オブジェクト・ソース３０５０と、キャッシュ・マネージャ３００１（局所キャッシュ・マネージャと称する）と、０個以上のスレーブ・トリガ・モニタ３０００”（図３８）および他の物理計算機に常駐する遠隔キャッシュ・マネージャ３００２と共に動作する。オブジェクト・ソース３０５０には、１つまたは複数の実体、たとえば、ＩＢＭ Ｃｏｒｐ．社が商標ＤＢ２の下で販売するものなどのデータベース３０１０や、より複雑なオブジェクト（ＨＴＭＬページなど）を構築する、Ｌｏｔｕｓ Ｃｏｒｐ．社が商標ＤＯＭＩＮＯの下で販売するサーバなどの他のソース３０３０が含まれる。
【０１９３】
オブジェクト・ソース３０５０が変更を検出した時に、トリガが呼び出される。トリガは、上記などの多数の標準的なオブジェクト・ソース３０５０の標準的な特徴であるが、通常は、データの変更に応答して動作を自動的に発生させるのに使用される。本発明は、新規の形でトリガを使用して、オブジェクト・ソースに格納されたデータから構築されるオブジェクト３００４をデータと同期した状態に保つ。トリガに関連するのが、トリガ・モニタ・ドライバ３０４０へメッセージを送らせるＡＰＩ ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６（図３９）である。これに応答して、トリガ・モニタ・ドライバ３０４０は、トリガ・イベント３０２０と称するトランザクション（図４０）を生成することができる。
【０１９４】
トリガ・イベント３０２０は、（通常の手段によって）レコードＩＤ３０１２に変換でき、変換のためにキャッシュ・マネージャ３００１に転送される。キャッシュ・マネージャ３００１は、対応するオブジェクトＩＤ３００９のリストを返し、このリストは、ＯＩＡ３０４１へ待ち行列化される。ＯＩＡ３０４１は、周知の手段によって、オブジェクトＩＤ３００９ごとに１組のオブジェクト処置ブロック（ＯＤＢ）３１００（下で説明する）を生成する。
【０１９５】
図４１は、ＯＤＢ３１００の例を示す図である。オブジェクトＩＤ３００９は、後程オブジェクトを置換または削除する時に、キャッシュ３００３内のオブジェクト３００４の識別に使用される。キャッシュＩＤ３２００は、オブジェクト３００４が属するキャッシュ３００３の識別に使用される。外部ＩＤ３１０１は、オブジェクト・ジェネレータ３０４２がオブジェクトを知るのに使用する可能性がある追加の識別子である。要求処置３１０３は、オブジェクト・ジェネレータがオブジェクト更新要求３０２２または遠隔オブジェクト削除要求３０２５（図４０）を生成するのに使用する。要求処置３１０３がＤｉｓｐＲｅｇｅｎｅｒａｔｅ３１３０である場合には、ＯＤＢ３１００によって表されるオブジェクト３００４が、システムによって再生成され、分配される。要求処置３１０３がＤｉｓｐＩｎｖａｌｉｄａｔｅ３１３１である場合には、オブジェクト３００４は、すべてのシステムから削除される。
【０１９６】
図４２は、キャッシュＩＤ３２００の例を示す図である。図からわかるように、キャッシュＩＤには、キャッシュ名３２０１、キャッシュ・ホスト３２０２の識別子およびキャッシュ・ポート３２０３の識別子が含まれることが好ましい。
【０１９７】
図３７に戻って、ＯＤＢ３１００は、オブジェクト・ジェネレータ３０４２に送られる。オブジェクト・ジェネレータは、ＯＤＢ３１００を調べ、ａ）遠隔オブジェクト削除要求３０２５を生成するか、ｂ）オブジェクト・ソース３０５０との接続を確立し、オブジェクト３００４を再構築し、オブジェクト更新要求３０２２を作成するかのいずれかを行う。
【０１９８】
トリガ・モニタ・ドライバ３０４０は、遠隔オブジェクト削除要求３０２５またはオブジェクト更新要求３０２２を分配マネージャ３０４３に渡す。
【０１９９】
分配マネージャ３０４３は、構成された遠隔キャッシュ・マネージャ３００２またはスレーブ・トリガ・モニタ３０００”（図３８）のそれぞれとの接続を確立し、要求のそれぞれを分配する。要求がトリガ転送要求３０２１の場合、その要求は、スレーブ・トリガ・モニタ３０００”（図３８）に送られる。要求がオブジェクト更新要求３０２２の場合、新しいオブジェクトが、ｃａｃｈｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｏｂｊｅｃｔ，ｃａｃｈｅ＿ｉｄ）４１０ＡＰＩ（図６）を介してキャッシュ・マネージャ３００１に送られる。要求が遠隔オブジェクト削除要求３０２５の場合、オブジェクト３００４が、ｄｅｌｅｔｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ）４２０ＡＰＩ（図６）を介してキャッシュ・マネージャ３００１から除去される。
【０２００】
図３８は、トリガ・モニタ３０００のもう１つの例を示す図である。ここでは、トリガ・モニタ３０００は、スレーブ・トリガ・モニタ３０００”としてインスタンス化されている。マスタ・トリガ・モニタ３０００’が、正確に１つのシステムを維持している場合、または、オブジェクト３００４が、再生成される（すなわち、削除されない）場合には、図３７で説明した処理を使用してこれを完全に維持することができる。トリガ・モニタ３０００が複数のシステムを維持している場合には、オブジェクト３００４が、すべてではなく一部のキャッシュに存在することが可能である。具体的に言うと、オブジェクト３００４は、トリガ・イベント３０２０を受け取るトリガ・モニタ３０００と同一のキャッシュ内に存在しない可能性がある。この場合を処理するために、スレーブ・トリガ・モニタ３０００”（図３８）が、構成されたノードのそれぞれで実行される。図からわかるように、スレーブ・トリガ・モニタ３０００”は、トリガ転送要求３０２１を受け取る。これは、要求がオブジェクト・ジェネレータ３０４２に達するまでは、トリガ・イベント３０２０と同一の形で処理される。ＯＤＢ３１００が、ＤｉｓｐＲｅｇｅｎｅｒａｔｅ３１３０に等しい要求処置３１０３を有する場合、この要求は破棄される。要求処置３１０３がＤｉｓｐＩｎｖａｌｉｄａｔｅ３１３１である場合には、局所オブジェクト削除要求３０２３が構築され、スレーブの局所キャッシュに送られる。
【０２０１】
図３８に戻って、トリガ・モニタ３０００は、オブジェクト・ソース３０５０を監視する、単一の長期間走行するプロセスとして実施されることが好ましい。当業者であれば、コンポーネントごとに１つまたは複数のプロセスからなり、プロセスの一部が時間的に重なり合ってシステムのスループットが改善されるように本発明を適合させることが簡単にできるはずである。また、当業者は、基礎となるシステムがプロセスのスレッド化をサポートする場合に、単一プロセス内の複数のスレッドの動作を使用するように本発明を適合させ、各スレッドが１つまたは複数のコンポーネントを実装し、一部が時間的に重なり合うようにすることが簡単にできるはずである。
【０２０２】
トリガ・イベント３０２０およびトリガ転送要求３０２１を受け取って、これらの要求が、配布された後に完了までシステム内にとどまることをオブジェクト・ソース３０５０に保証するために、多相コミットや持続性データ・オブジェクトなどの通常の機構を使用することが好ましい。再試行や多相コミットなどの従来の機構を使用して、待ち行列化されたアウトバウンド要求（図４０に示されたもの）が、完了までシステム内にとどまることの保証を提供することが好ましい。
【０２０３】
ＯＩＡ３０４１は、オブジェクトＩＤ３００９をＯＤＢ３１００（図４１）に変換する。ＯＩＡ３０４１は、構成オプションとして、ＡＰＩとしてまたは他の標準的な方法で指定し、インターフェースすることができる。当業者は、このような機構を簡単に構築できるはずである。
【０２０４】
オブジェクト・ジェネレータ３０４２は、ＯＤＢ３１００の情報を、図４０に示し下で説明するトランザクション・タイプに変換する。トリガ・モニタ３０００は、構成オプション、ＡＰＩまたは他の標準的な技法を使用して、このコンポーネントへのインターフェースを提供する。オブジェクト・ジェネレータ３０４２の例は、ＩＢＭ社が商標ＮＥＴ．ＤＡＴＡの下で販売する製品、Ｌｏｔｕｓ Ｃｏｒｐｏｒａｔｉｏｎ社が商標ＤＯＭＩＮＯ Ｓｅｒｖｅｒの下で販売する製品、または、ＨＴＭＬページを取り出すことができるウェブ・サーバである。
【０２０５】
図３９は、ｓｅｎｄ＿ｔｒｉｇｇｅｒ ＡＰＩの例を示す図である。図からわかるように、ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６を用いると、オブジェクト・ソース３０５０が、トリガ・モニタ・ドライバ３０４０と通信できるようになる。ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６は、トリガを一意に識別し、トリガ・イベント３０２０を構築するのに十分な情報（メッセージ・パラメータ）を含むメッセージを送る。当業者は、標準的な技法（可変長パラメータ・リストなど）を使用して、その情報を簡単に定義し、指定することができるはずである。
【０２０６】
図４０は、本発明に従って使用されるトランザクション・タイプの例を示す図である。図からわかるように、複数のトランザクション３０２０から３０２５をシステム内で生成することができる。
【０２０７】
トリガ・イベント３０２０は、ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６を介して送られたメッセージの受取に応答して生成される。トリガ・イベント３０２０は、ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６によって送られたデータを１つまたは複数の依存オブジェクト表示要求３０２４に変換し、システムを介してそれ自体を正しく追跡し、案内するのに十分な情報を維持する構造体である。
【０２０８】
トリガ転送要求３０２１は、ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６を介して送られたトリガ・イベント３０２０の受取に応答して生成される。トリガ転送要求３０２１は、１つまたは複数の依存オブジェクト表示要求３０２４を生成し、システムを介してそれ自体を正しく追跡し、案内するのに十分な情報を維持する構造体である。
【０２０９】
オブジェクト更新要求３０２２は、新しいオブジェクトを分配マネージャ３０４３を介して遠隔キャッシュ・マネージャ３００２へ配布させるためにオブジェクト・ジェネレータ３０４２が生成する。オブジェクト更新要求は、任意のキャッシュ３００３内のオブジェクト３００４を置換するのに十分な情報を維持する構造体である。
【０２１０】
局所オブジェクト削除要求３０２３は、キャッシュ３００３にオブジェクト３００４を削除させるためにオブジェクト・ジェネレータが生成する。局所オブジェクト削除要求３０２３は、キャッシュ・マネージャ３００１からオブジェクト３００４を削除するのに十分な情報を維持する構造体である。
【０２１１】
依存オブジェクト表示要求３０２４は、キャッシュ・マネージャ３００１に依存性情報を要求するために、トリガ・イベント３０２０に応答してトリガ・モニタ・ドライバ３０４０が生成する。依存オブジェクト表示要求３０２４は、トリガ・イベント３０２０またはトリガ転送要求３０２１を分析し、ｓｈｏｗ＿ｄｅｐｅｎｄｅｎｔ＿ｏｂｊｅｃｔｓ（ｃａｃｈｅ＿ｉｄ，ｒｅｃｏｒｄ＿ｉｄ）４６０を呼び出してキャッシュ・マネージャ３００１からオブジェクトＩＤ３００９を取得するのに十分な情報を維持する構造体である。
【０２１２】
遠隔オブジェクト削除要求３０２５は、分配マネージャ３０４３を介してオブジェクト３００４を遠隔キャッシュ・マネージャ３００２から削除させるためにオブジェクト・ジェネレータ３０４２が生成する。遠隔オブジェクト削除要求３０２５は、任意のキャッシュ３００３からオブジェクト３００４を削除するのに十分な情報を維持する構造体である。
【０２１３】
図４３および図４４は、トリガ・モニタ・ドライバ３０４０と分配マネージャ３０４３の高水準の編成と通信経路の例を示す図である。好ましい編成は、独立に実行される複数のコントロールのスレッドからなる。
【０２１４】
受取側スレッド３３００は、トリガ・イベント３０２０とトリガ転送要求３０２１を含む要求を受け取り、これらを持続性記憶域に保管する。入力作業ディスパッチャ・スレッド３３２０は、受取側スレッド３３００からの入力要求を待機解除し、処理のため待ち行列化する。キャッシュ・マネージャ通信スレッド３３４０は、局所オブジェクト削除要求３０２３と依存オブジェクト表示要求３０２４を局所キャッシュ・マネージャ３０６０に送る。オブジェクト・ジェネレータ・スレッド３３６０は、オブジェクト要求すなわち、遠隔オブジェクト削除要求３０２５とオブジェクト更新要求３０２２の生成を調整し、分配のためこれらを待ち行列化する。分配スレッド３０８０（分配マネージャ３０４３の主要構成要素である）は、分配マネージャ待ち行列３３７０から要求を待機解除し、これらをアウトバウンド計算機のすべてに待ち行列化する。アウトバウンド・トランザクション・スレッド３３９５は、遠隔計算機にコンタクトし、計算機アウトバウンド待ち行列３３９０に待ち行列化された作業を転送する。
【０２１５】
通常通り、これらのスレッドは、複数のＦＩＦＯ待ち行列すなわち、入力要求待ち行列３３１０、キャッシュ・マネージャ要求待ち行列３３３０、オブジェクト・ジェネレータ待ち行列３３５０、分配マネージャ待ち行列３３７０および計算機アウトバウンド待ち行列３３９０（分散キャッシュごとに１つ）を介して通信することができる。
【０２１６】
図４５は、受取側スレッド３３００のロジックの例を示す図である。図からわかるように、ステップ３４１０で、入力メッセージ（ｓｅｎｄ＿ｔｒｉｇｇｅｒ３０２６またはトリガ転送要求３０２１のいずれか）がシステムに入り、トリガ・イベント３０２０に変換される。ステップ３４２０で、このメッセージが、受取側スレッド３３００によって永続性待ち行列３４５０に書き込まれ、ステップ３４３０で、入力要求待ち行列３３１０に待ち行列化される。ステップ３４４０で、要求のタイプを検査する。要求がトリガ・イベント３０２０の場合、ステップ３４６０で、トリガ転送要求３０２１を分配マネージャ待ち行列３３７０に待ち行列化する。ステップ３４９０で、受取側スレッド３３００は、作業の待機に戻る。
【０２１７】
図４６は、入力作業ディスパッチャ・スレッド３３２０のロジックの例を示す図である。図からわかるように、ステップ３５１０で、入力作業ディスパッチャ・スレッド３３２０は、作業要求を待機解除する。ステップ３５２０で、依存オブジェクト表示要求３０２４を、キャッシュ・マネージャ要求待ち行列３３３０に待ち行列化する。ステップ３５９０で、受取側スレッド３３００は、作業の待機に戻る。
【０２１８】
図４７は、キャッシュ・マネージャ通信スレッド３３４０のロジックの例を示す図である。図からわかるように、ステップ３６１０で、キャッシュ・マネージャ通信スレッド３３４０が、次の要求を待機解除し、キャッシュ・マネージャ３００１との通信を確立する。ステップ３０２３で、要求が局所オブジェクト削除要求である場合には、ステップ３６５０で、ｄｅｌｅｔｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ）４２０を使用して、キャッシュ３００３からオブジェクトを削除する。ステップ３０２４で、要求が依存オブジェクト表示要求である場合には、ステップ３６２０で、ｓｈｏｗ＿ｄｅｐｅｎｄｅｎｔ＿ｏｂｊｅｃｔｓ（ｃａｃｈｅ＿ｉｄ，ｒｅｃｏｒｄ＿ｉｄ）４６０を使用して、オブジェクトＩＤ３００９を取り出す。ステップ３６３０では、オブジェクトＩＤ３００９をＯＩＡ３０４１に渡し、ＯＩＡ３０４１が、ＯＤＢ３１００を構築する。ステップ３６４０で、ＯＤＢ３１００をオブジェクト・ジェネレータ３０４２に待ち行列化する。最後に、ステップ３６９０で、キャッシュ・マネージャ通信スレッド３３４０は、作業の待機に戻る。
【０２１９】
図４８は、オブジェクト・ジェネレータ・スレッド３３６０のロジックの例を示す図である。図からわかるように、ステップ３７１０で、オブジェクト・ジェネレータ・スレッド３３６０は、オブジェクト・ジェネレータ待ち行列３３５０から次の要求を待機解除する。ステップ３７２０で、オブジェクトの処置を検査する。処置がＤｉｓｐＩｎｖａｌｉｄａｔｅ３１３１の場合はステップ３７５０に進み、ＤｉｓｐＲｅｇｅｎｅｒａｔｅ３１３０の場合はステップ３７３０に進む。ステップ３７３０では、要求のタイプを検査する。トリガ転送要求３０２１の場合はステップ３７７０に進み、トリガ・イベント３０２０の場合はステップ３７４０に進む。ステップ３７４０では、オブジェクト・ソース３０５０にコンタクトして、オブジェクト３００４を再生成する。新しいオブジェクト３００４は、オブジェクト更新要求３０２２を用いて、分配マネージャ待ち行列３３７０に待ち行列化される。その後、処理はステップ３７９０に戻って、作業を待つ。
【０２２０】
ステップ３７５０では、要求のタイプを検査する。トリガ転送要求３０２１の場合はステップ３７８０に進み、トリガ・イベント３０２０の場合はステップ３７６０に進む。ステップ３７６０では、遠隔オブジェクト削除要求３０２５を作成し、分配マネージャ待ち行列３３７０に待ち行列化する。その後、処理はステップ３７９０に戻って、作業を待つ。
【０２２１】
ステップ３７７０では、要求をシステムから削除する。その後、処理はステップ３７９０に戻って、作業を待つ。
【０２２２】
ステップ３７８０では、局所オブジェクト削除要求３０２３をキャッシュ・マネージャ要求待ち行列３３３０に待ち行列化する。その後、処理はステップ３７９０に戻って、作業を待つ。
【０２２３】
図４９は、分配マネージャ・スレッド３３８０のロジックの例を示す図である。図からわかるように、ステップ３８１０で、分配マネージャ・スレッド３３８０は、分配マネージャ待ち行列３３７０から作業を待機解除し、要求のコピーを、計算機アウトバウンド待ち行列３３９０のそれぞれに待ち行列化する。その後、処理はステップ３８９０に戻って、作業を待つ。
【０２２４】
図５０は、アウトバウンド・トランザクション・スレッド３３９５のロジックの例を示す図である。分散更新方式に関与する計算機ごとに１つのアウトバウンド・トランザクション・スレッド３３９５がある。図からわかるように、ステップ３９１０で、このスレッドは、計算機アウトバウンド待ち行列３３９０から作業を待機解除し、要求のタイプを検査する。要求がオブジェクト更新要求３０２２または遠隔オブジェクト削除要求３０２５の場合には、処理はステップ３９２０に進み、要求がトリガ転送要求３０２１の場合には、処理はステップ３９３０に進む。
【０２２５】
ステップ３９２０で、遠隔のキャッシュ・マネージャ３００１にコンタクトする。要求がオブジェクト更新要求３０２２の場合、ステップ３９４０で、ｃａｃｈｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｏｂｊｅｃｔ，ｃａｃｈｅ＿ｉｄ）４１０を使用して、新しいオブジェクト３００４を遠隔キャッシュ・マネージャ３００２に送る。その後、処理はステップ３９９０に戻って、作業を待つ。要求が遠隔オブジェクト削除要求３０２５の場合、ステップ３９５０で、ｄｅｌｅｔｅ＿ｏｂｊｅｃｔ（ｏｂｊｅｃｔ＿ｉｄ，ｃａｃｈｅ＿ｉｄ）４２０を使用して、遠隔キャッシュ・マネージャ３００２からオブジェクト３００４を削除する。その後、処理はステップ３９９０に戻って、作業を待つ。
【０２２６】
ステップ３９３０では、遠隔トリガ・モニタ３０００ａにコンタクトする。ステップ３９６０で、トリガ転送要求３０２１を遠隔のトリガ・モニタ３０００に送る。その後、処理はステップ３９９０に戻って、作業を待つ。
【０２２７】
拡張と変形
本発明の特定の応用例によっては、トリガ・イベント３０２０の完全な分析と動作（オブジェクト更新要求３０２２または遠隔オブジェクト削除要求３０２５など）への変換のために、本明細書に記載されていない他の出口が必要になる可能性がある。
【０２２８】
たとえば、図５１を参照すると、
ａ）ある出口を介して、単一のトリガ・イベント３０２０を複数の依存オブジェクト表示要求３０２４の組に変換すること４０００が有用である場合がある。ｂ）オブジェクト・ジェネレータ３０４２によって作成されたオブジェクト３００４を、オブジェクト更新要求３０２２でそのオブジェクト３００４を待ち行列化する前に、変更または分析すること４０１０が有用である場合がある。
ｃ）オブジェクト３００４をキャッシュ３００３に書き込む代わりに、またはこれに加えて、オブジェクト３００４をファイル・システムに書き込むことが有用である可能性がある。
【０２２９】
トリガ・モニタ３０００のもう１つの用途は、現在キャッシュ内に存在しない可能性があるオブジェクトを処理するために、オブジェクトの生成と分配の能力を再利用することである。
ａ）ｐｒｉｍｅ＿ｃａｃｈｅ ＡＰＩ４０２０を使用して、所与のオブジェクトＩＤ３００９を有するオブジェクト３００４が現在キャッシュ３００３のいずれかに既知であるかどうかに無関係に、そのオブジェクト３００４を生成し、分配することができる。
ｂ）ｇｌｏｂａｌ＿ｄｅｌｅｔｅ ＡＰＩ４０３０を使用して、ある特定のオブジェクト３００４が実際にどこかに存在するかどうかを知ることなしに、システム内のすべてのキャッシュ１からそのオブジェクト３００４を確実に除去することができる。
【０２３０】
トリガ・モニタ３０００は、厳格なＦＩＦＯの順序付けと要求の処理を強制するように実施することができ、また、要求の完全に非同期の処理を許容するように実施することができ、また、周知のスケジューリング方式のいずれかに従って要求を処理するように実施することができ、また、これらの任意の組み合わせを実施することができる。
【０２３１】
一貫性の維持
上で述べたように、本明細書で使用する用語には辞書の意味も含まれるが、案内のために以下に一部の用語の用語集を示す。
【０２３２】
トランザクション・マネージャとは、状態を管理するプログラムである。その例には、キャッシュを管理するキャッシュ・マネージャ、ＤＢ２などのデータベース管理システム、ＣＩＣＳなどのトランザクション処理システムが含まれる。
【０２３３】
トランザクションとは、トランザクション・マネージャに対して別のプログラムが行う要求である。
【０２３４】
状態変化型トランザクションとは、トランザクション・モニタによって管理される状態を変更するトランザクションである。キャッシュ・マネージャに対するキャッシュ・オブジェクトの読取、更新または削除の要求が、トランザクションを構成する。
【０２３５】
データの読取と変更を、アクセスと称する。
【０２３６】
ロックとは、共用データを読み書きするプロセスの能力を制限する実体である。あるプロセスがデータの読取ロックを獲得した時には、他のプロセスは、そのデータにアクセスできるが、そのデータを変更することができなくなる。あるプロセスがデータに対する書込ロックまたは排他ロックを獲得した時には、他のプロセスは、そのデータを読み取ることも変更することもできなくなる。従来技術には、ロックを実装するための方法が複数存在する。たとえば、ヘネシー（Ｈｅｎｎｅｓｓｙ）およびパターソン（Ｐａｔｔｅｒｓｏｎ）著、「Ｃｏｍｐｕｔｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ： Ａ Ｑｕａｎｔｉｔａｔｉｖｅ Ａｐｐｒｏａｃｈ」第２版、Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎ刊、１９９６年を参照されたい。
【０２３７】
Ｓが、１つまたは複数のトランザクション・マネージャを含むシステム上のデータｄを変更するトランザクションのセットであると仮定する。一貫性のある形でＳを実行するための条件は、
（１）ｄのすべてまたは一部にアクセスする、Ｓに含まれない要求ｒ１について、ｒ１によってアクセスされるｄのすべての部分が、Ｓに含まれるすべてのトランザクションによる変更の前の状態またはＳに含まれるすべてのトランザクションによる変更の後の状態のいずれかである。
（２）Ｓに含まれない要求ｒ１およびｒ２について、ｒ２が、ｒ１と同時またはｒ１の後にシステムによって受け取られ、ｒ１とｒ２の両方が、ｄのサブセットｄ’にアクセスし、
（ａ）ｒ１によってアクセスされるｄ’のバージョンが、Ｓに含まれるトランザクションによって変更されている場合、ｒ２によってアクセスされるｄ’のバージョンもＳに含まれるトランザクションによって変更されている。
（ｂ）ｒ２によってアクセスされるｄ’のバージョンが、Ｓに含まれるトランザクションによって変更されていない場合、ｒ１によってアクセスされるｄ’のバージョンもＳに含まれるトランザクションによって変更されていない。
【０２３８】
タイムスタンプとは、システムがトランザクションを受け取ったり、ロックが獲得されるなどのイベントに割り当てることができる属性である。従来技術でタイム・スタンプを実装するための一般的な方法には、クロック時刻およびイベントを順序付ける番号が含まれる。
【０２３９】
本発明のもう１つの特徴は、１つまたは複数のキャッシュに対して１組の一貫性のある更新を行う能力である。本発明は、以下の特性が所望される、１つまたは複数のキャッシュ・マネージャ３００１に対する要求の組Ｓのために有益である。
（１）システムにアクセスするプログラムｐについて、Ｓは原子的に行われなければならない。すなわち、ｐは、Ｓに含まれる要求の一部が満足され、それ以外が満足されていない状態のシステムを見ることができてはならない。
（２）適当なキャッシュ・マネージャ３００１によって同時に受け取られる２つの要求ｒ１およびｒ２について、ｒ１とｒ２は、Ｓに関して同一のシステムの外見を見る。すなわち、ｒ１とｒ２の両方が、Ｓに含まれる要求が満たされる前のシステムの外見を見るか、ｒ１とｒ２の両方が、Ｓに含まれる要求が満たされた後のシステムの外見を見るかのいずれかになる。
（３）ｒ１がキャッシュ・マネージャ３００１によって受け取られた後にｒ２がキャッシュ・マネージャによって受け取られる２つの要求ｒ１およびｒ２について、ｒ１が、Ｓに含まれる要求が満たされた後のシステムの外見を見る場合には、ｒ２も同一の外見を見なければならない。ｒ２が、Ｓに含まれる要求が満たされる前のシステムの外見を見る場合には、ｒ１も同一の外見を見なければならない。
【０２４０】
図５２は、１つまたは複数のキャッシュを含むシステムに対して一貫性のある形で要求の組Ｓを行うためのロジックの例を示す図である。Ｓの要求のそれぞれは、１つのキャッシュ・マネージャ３００１に向けられることが好ましい。Ｓからの要求を受け取るキャッシュ・マネージャの組Ｃは、１つまたは複数の要素を有することができる。
【０２４１】
図からわかるように、ステップ４５００で、要求の組Ｓが、システムによって受け取られる。各要求は、特定のキャッシュ・マネージャ３００１に向けられる。
【０２４２】
ステップ４５０５で、キャッシュ・マネージャがデータをロックする。Ｓから要求を受け取るキャッシュ・マネージャｊのそれぞれについて、キャッシュ・マネージャｊは、Ｓの要求によって変更されるデータの場合は書込ロックを獲得し、Ｓの要求によって読み取られるがＳの要求によって書き込まれないデータの場合は読取ロックを獲得する。このステップでロックされたデータを、以下ではロック済みデータと称する。
【０２４３】
ステップ４６００で、システムは、最後にロックが獲得された時刻ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅを判定する。Ｓから要求を受け取るキャッシュ・マネージャの組Ｃに１つしか要素がない場合には、このステップは、従来技術を使用して簡単に実施できる。Ｃに複数の要素がある場合、ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅは、図５３で説明する形で判定される。
【０２４４】
ステップ４５１０で、ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅの前に受け取られ、ロック済みデータを待っている要求を実行する。ステップ４５２０で、Ｓの要求を実行する。ステップ４５３０で、ロック済みデータからロックを除去し、これによって、ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅの後に受け取られた、ロック済みデータを待っている要求を実行できるようにする。ステップ４５１０、４５２０および４５３０は、この順序で実行しなければならない。
【０２４５】
図５２に示された実施例の代替実施例は、単一のロックを使用して、Ｓの要求によってアクセスされるデータに、他の要求がアクセスできなくすることである。好ましい実施例を用いると、この代替手法よりはるかに高い水準の並列性が可能になる。
【０２４６】
図５３は、Ｓから要求を受け取るキャッシュ・マネージャの組Ｃに複数の要素がある場合に、ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅを判定するためのロジックの例を示す図である。図からわかるように、ステップ４６００で、キャッシュ・マネージャｉと記されたＣの各要素が、ステップ４５０５で最後にロックを獲得した時刻ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉを判定し、キャッシュ・マネージャｉは、ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉをコーディネータ・プログラムと称するプログラムに送る。ステップ４６１０で、コーディネータ・プログラムは、Ｃのすべてのキャッシュ・マネージャからｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉ値を受け取り、ｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅに、受け取ったｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉのうちで最新の値をセットする。ステップ４６１５で、コーディネータ・プログラムが、Ｃのすべてのキャッシュ・マネージャにｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅを送る。
【０２４７】
図５３に示された例に対する変形は、Ｃの各キャッシュ・マネージャｉが、コーディネータ・プログラムにｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉを送るのではなく、ステップ４６００でＣの他のキャッシュ・マネージャとｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉの値を交換することである。ステップ４６１０では、Ｃの各キャッシュ・マネージャｉが、受け取ったｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅ＿ｉの値からｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅを判定する。ステップ４６１５は不要になる。好ましい実施例では、Ｃが大きい時に通信量と比較の回数が減り、したがって、この変形よりスケーラブルである。
【０２４８】
当業者は、トランザクション・マネージャがキャッシュ・マネージャである必要がない、１つまたは複数のトランザクション・マネージャを含む他のシステムで一貫性を達成するように本発明を適合させることが簡単にできるはずである。
【０２４９】
詳細な説明と代替案によって本発明を説明したので、当業者には、さまざまな機能強化、変形および均等物が明白になる。したがって、この詳細な説明は、例示のために提供されたものであって、制限として提供されたものではないことを理解されたい。本発明の正しい範囲は、請求項によって定義される。
【０２５０】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０２５１】
（１）１つまたは複数の複合オブジェクトを格納する１つまたは複数のキャッシュを含むコンピュータ・システムにおいて、
キャッシュ記憶が可能または不可能な基礎データの、少なくとも一部を識別するステップと、
前記基礎データの少なくとも一部に対する１つまたは複数のデータ依存性を有する前記複合オブジェクトのうちの１つまたは複数に、前記基礎データの少なくとも一部をマッピングするステップと
を含む、前記基礎データに対する変更が１つまたは複数の前記複合オブジェクトの値にどのように影響することができるかを判定するための方法。
（２）さらに、複数のコンピュータを含み、第１キャッシュに関連する第１組のコンピュータが、前記マッピング・ステップに関連する第２組のコンピュータから分離されている、上記（１）の方法。
（３）さらに、時間に伴って変化する可能性があるオブジェクト依存性グラフ（Ｇ）を維持するステップを含み、前記オブジェクト依存性グラフが、複数のグラフ・オブジェクトと辺を含み、前記辺が、グラフ・オブジェクト間の１つまたは複数のデータ依存性を示す、上記（１）の方法。
（４）前記マッピング・ステップが、さらに、異なるスケジュールが前記基礎データに対する異なる変更をもたらす可能性があるプログラム・スケジューリング動作のステップを含む、上記（１）の方法。
（５）前記プログラム・スケジューリング動作が、コンパイラ、実行時システムまたはデータベースである、上記（４）の方法。
（６）前記マッピング・ステップが、前記基礎データの少なくとも一部を少なくとも１つの前記複合オブジェクトにマッピングするために前記グラフを使用するステップを含む、上記（３）の方法。
（７）さらに、辺に重みを割り当てるステップを含み、前記重みが、データ依存性の重要さに相関する、上記（３）の方法。
（８）少なくとも１つの辺の重みが、割り当てられた後に変化しない、上記（７）の方法。
（９）（１）グラフ・オブジェクトｏ１の２つのバージョンｏ１＿ｖ１およびｏ１＿ｖ２が存在し、
（２）オブジェクト依存性グラフ（Ｇ）が、ｏ１で終わり、割り当てられた重みを有する少なくとも１つの辺（ｏ２，ｏ１）を含み、
前記ｏ１で終わり組Ｓを構成する１つまたは複数の辺（ｏ２，ｏ１）について、ｏ１＿ｖ１との一貫性を有する前記オブジェクトｏ２のバージョン番号と、ｏ１＿ｖ２との一貫性を有する前記オブジェクトｏ２の第２バージョン番号とを維持するステップと、
前記グラフ・オブジェクトｏ２の同一のバージョンが前記バージョンｏ１＿ｖ１およびｏ１＿ｖ２との一貫性を有する前記組Ｓ内の辺（ｏ２，ｏ１）の重みの合計と、前記組Ｓ内のｏ１で終わるすべての辺の重荷の合計とに基づいて、ｏ１＿ｖ１とｏ１＿ｖ２がどれほど似ているかを判定するステップと
をさらに含む、上記（７）の方法。
（１０）前記２つのバージョンがどれほど似ているかを判定する前記ステップがさらに、前記グラフ・オブジェクトｏ２の同一バージョンが、前記バージョンｏ１＿ｖ１およびｏ１＿ｖ２との一貫性を有する前記組Ｓ内の辺（ｏ２，ｏ１）の重みの前記合計を前記組Ｓ内のｏ１で終わるすべての辺の重みの前記合計によって除算するステップを含む、上記（９）の方法。
（１１）前記マッピング・ステップが、さらに、前記基礎データの少なくとも一部に対して変更を行うかどうか、またはどのような変更を行うかを判定するために、前記基礎データの少なくとも一部に対する変更によって１つまたは複数の前記複合オブジェクトがどのように影響を受けるかに関する情報を使用するステップを含む、上記（１）の方法。
（１２）前記マッピング・ステップを実施するプログラムが、複数プロセスと、複数スレッドと、１つまたは複数の前記キャッシュの記憶域を管理する１つまたは複数の長期間稼動するプロセスまたはスレッドとのうちの１つまたは複数を生成する、上記（１）の方法。
（１３）前記マッピング・ステップが、さらに、
前記基礎データの前記少なくとも一部に対する変更を識別するステップと、
前記基礎データの少なくとも一部に対する変更の前記識別に応答して、１つまたは複数の前記複合オブジェクトがどのように影響されるかを識別するステップと
を含む、上記（１）の方法。
（１４）前記マッピング・ステップを実施するプログラムが、少なくとも１つの長期間走行するプロセスを生成し、さらに、
アプリケーション・プログラムが、前記基礎データの少なくとも一部に対する変更を識別するステップと、
上記アプリケーション・プログラムが、前記基礎データの少なくとも一部に対する識別された変更を、前記マッピング・ステップを実施する前記プログラムに通信するステップと
を含む、上記（１２）の方法。
（１５）さらに、キャッシュに格納された前記複合オブジェクトのバージョンが、前記基礎データの少なくとも一部に対する変更の結果として非常に古くなることを判定するステップを含む、上記（１）の方法。
（１６）さらに、オブジェクトの非常に古いバージョンをキャッシュから削除するステップを含む、上記（１５）の方法。
（１７）オブジェクトのバージョンが現行でない時に、必ずそれが非常に古いとみなされる、上記（１５）の方法。
（１８）オブジェクトのバージョン（ｏ１＿ｖ１）が非常に古いと判定する前記ステップが、
時間に伴って変化する可能性があり、複数のグラフ・オブジェクト（ｏ１，…，ｏｎ）と、グラフ・オブジェクト間の１つまたは複数のデータ依存性を表す複数の辺とを含む、オブジェクト依存性グラフ（Ｇ）を維持するステップと、
ｏ１＿ｖ１がｏ２の現行バージョンと一貫性を有しない辺（ｏ２，ｏ１）の数に基づいて前記ｏ１＿ｖ１が非常に古くなると判定するステップと
を含む、上記（１５）の方法。
（１９）さらに、オブジェクトの非常に古いバージョンを、より新しいバージョンに置換するステップを含む、上記（１５）の方法。
（２０）より新しいバージョンが、オブジェクトの現行バージョンである、上記（１９）の方法。
（２１）キャッシュに格納されたオブジェクトｏ１のバージョンｏ１＿ｖ１が非常に古くなると判定する前記ステップが、
時間に伴って変化する可能性があり、複数のグラフ・オブジェクトと、グラフ・オブジェクト間の１つまたは複数のデータ依存性を表す複数の辺とを含む、オブジェクト依存性グラフ（Ｇ）を維持するステップと、
前記ｏ１で終わる１つまたは複数の辺に対応する、前記ｏ１＿ｖ１のｗｅｉｇｈｔ＿ａｃｔフィールドを初期設定し、維持するステップと、
グラフ・オブジェクトｏ２からグラフ・オブジェクトｏ１への辺が存在し、ｏ１＿ｖ１がｗｅｉｇｈｔ＿ａｃｔフィールドを有する、前記オブジェクトｏ２の現行バージョンに対する１つまたは複数の変更について、辺に対応するｗｅｉｇｈｔ＿ａｃｔフィールドを決定するステップと、
前記ｏ１＿ｖ１のｗｅｉｇｈｔ＿ａｃｔフィールドに基づいて、前記ｏ１＿ｖ１が非常に古くなるかどうかを判定するステップと
を含む、上記（１５）の方法。
（２２）さらに、前記ｏ１＿ｖ１の重みしきい値を維持するステップを含み、
前記ｏ１＿ｖ１のｗｅｉｇｈｔ＿ａｃｔフィールドに基づいて前記ｏ１＿ｖ１が非常に古くなるかどうかを判定する前記ステップが、前記ｏ１＿ｖ１のｗｅｉｇｈｔ＿ａｃｔフィールドの合計と前記重みしきい値を比較するステップを含む上記（２１）の方法。
（２３）データ依存性の重要さに相関する重みを、オブジェクト依存性グラフの辺に割り当てるステップと、
前記ｏ１＿ｖ１の１つまたは複数のｗｅｉｇｈｔ＿ａｃｔフィールドに、オブジェクト依存性グラフの対応する辺の１つまたは複数の重みを初期設定するステップと
をさらに含む、上記（２１）の方法。
（２４）ｏ２の現行バージョンが更新される時に、必ず、オブジェクト依存性グラフ内で前記ｏ２から前記ｏ１への辺に対応する、所定の最小の可能な値より大きいｗｅｉｇｈｔ＿ａｃｔフィールドに、前記所定の最小の可能な値をセットするステップを含む、上記（２１）の方法。
（２５）１つまたは複数の前記キャッシュが、複数バージョン・キャッシュと、単一バージョン・キャッシュと、現行バージョン・キャッシュとのうちの１つまたは複数を含む、上記（１）の方法。
（２６）１つまたは複数の前記キャッシュが、少なくとも１つの単一バージョン・キャッシュｃ１を含み、
少なくとも１つのオブジェクトｏ１について、ｏ１および他のオブジェクトｏ２の両方がｃ１に含まれる時に、必ずｏ１およびｏ２が一貫性を有するように、ｏ２の一貫性セットを維持するステップ
をさらに含む、上記（２５）の方法。
（２７）前記ｏ１および前記ｏ２の両方がｃ１にある場合に、前記ｏ１および前記ｏ２が一貫性を有するようにするステップをさらに含む、上記（２６）の方法。
（２８）おそらくはオブジェクトｏ１の以前のバージョンを置換することによって、単一バージョン・キャッシュに前記オブジェクトｏ１の現行バージョンを追加するステップと、
オブジェクトｏ２の非現行バージョンｏ２＿ｖが前記キャッシュｃ１に格納されており、前記ｏ１の現行バージョンが作成される前に作成された、１つまたは複数の前記オブジェクトｏ２を、ｏ１の一貫性セット内で識別するステップと、
前記キャッシュｃ１から前記ｏ２＿ｖを除去するか、前記オブジェクトｏ２のより新しいバージョンによってｏ２＿ｖを置換するステップと、
１つまたは複数のオブジェクトを識別する前記ステップと、前記キャッシュｃ１から前記ｏ２＿ｖを除去するか、前記オブジェクトのより新しいバージョンによってｏ２＿ｖを置換する前記ステップとを、前記オブジェクトｏ２に関する一貫性セット内のオブジェクトに再帰的に適用するステップと
をさらに含む、上記（２７）の方法。
（２９）おそらくはオブジェクトｏ１の以前のバージョンを置換することによって、単一バージョン・キャッシュにオブジェクトｏ１のバージョンを追加するか否かを決定するために、オブジェクトｏ１の一貫性セットを使用するステップをさらに含む、上記（２６）の方法。
（３０）単一バージョン・キャッシュｃ１内の複数のオブジェクトｏ１ないしｏｎについて、
オブジェクトｏｉの一貫性セットによって強制されるすべての制約が、前記ｏｉの更新と同時に満足されることを確実にすることなく、その代わりに、オブジェクトｏｂｊ１の一貫性を有しないバージョンがｃ１内に存在する可能性がある、前記ｏｉの一貫性セットからのｏｂｊ１を、一貫性スタックに追加することによって、ｃ１内の異なるバージョンを有するオブジェクトｏｉのそれぞれを置換するステップと、
ｃ１内のオブジェクトｏ１ないしｏｎのすべてが現行バージョンに置換された後に、一貫性スタック上の全オブジェクトをトラバースし、一貫性を有しないバージョンがｃ１に存在するオブジェクトｏｂｊ１のそれぞれについて、それをｃ１から除去するか一貫性を有するバージョンと置換するステップと
をさらに含む、上記（２７）の方法。
（３１）前記Ｇが、単純依存性グラフおよびマルチグラフのうちの１つである、上記（３）の方法。
（３２）前記Ｇが、単純依存性グラフであり、前記Ｇの固有極大ノードが、複合オブジェクトであり、前記Ｇの固有葉ノードが、オブジェクトではない基礎データである、上記（３１）の方法。
（３３）オブジェクト依存性グラフを維持する前記ステップが、
少なくとも１つの固有葉ノードｖの出隣接リストを維持するステップと、
少なくとも１つの固有極大ノードｗの入隣接リストを維持するステップと
を含む、上記（３２）の方法。
（３４）さらに、ハッシュ・テーブルを介して、出隣接リストおよび入隣接リストのうちの１つにアクセスするステップを含む、上記（３３）の方法。
（３５）前記オブジェクト依存性グラフを維持するステップが、さらに、
初期に変更されるデータが、固有葉ノードの変更によって表すことのできるデータｄを含む時に、ｄに対応する出隣接リストを探すステップと、
出隣接リストが見つかった場合に、影響を受ける複合オブジェクトを決定するためにリストを調べるステップと
を含む、上記（３３）の方法。
（３６）さらに、前記オブジェクト依存性グラフから少なくとも１つの固有極大ノードｗを削除するステップを含む、上記（３３）の方法。
（３７）前記オブジェクト依存性グラフから少なくとも１つの固有極大ノードｗを削除する前記ステップが、さらに、
ｗの入隣接リスト上の少なくとも１つの固有葉ノードの出隣接リストから前記ｗを削除するステップと、
前記ｗの入隣接リストを削除するステップと
を含む、上記（３６）の方法。
（３８）さらに、前記オブジェクト依存性グラフから少なくとも１つの固有葉ノードｖを削除するステップを含む、上記（３３）の方法。
（３９）前記オブジェクト依存性グラフから少なくとも１つの固有葉ノードｖを削除する前記ステップが、さらに、
ｖの出隣接リスト上の１つまたは複数の固有極大ノードの入隣接リストからｖを削除するステップと、
前記ｖの出隣接リストを削除するステップと
を含む、上記（３８）の方法。
（４０）グラフ・オブジェクトｒが、単一レコード（ＳＲＯ）または複数レコード（ＭＲＯ）を表すことのできる関連関係指定子を有する関係オブジェクト（ＲＯ）であり、前記オブジェクト依存性グラフを維持するステップが、さらに、
（ａ）前記ｒの関係指定子を格納するステップと、
（ｂ）１つまたは複数のグラフ・オブジェクトが前記ｒを含む場合に、前記ｒから前記ｒを含む１つまたは複数のグラフ・オブジェクトへの１つまたは複数の依存性を追加するステップと、
（ｃ）前記ｒが１つまたは複数のグラフ・オブジェクトを含む場合に、前記ｒに含まれる前記１つまたは複数のグラフ・オブジェクトから前記ｒへの１つまたは複数の依存性を追加するステップと
を含む、上記（３）の方法。
（４１）データ依存度の重要さに相関する重みを辺に割り当てるステップをさらに含み、
前記ステップ（ｂ）および（ｃ）のうちの１つが、ＲＯノードｒ２を含むＲＯノードｒ１に対応する依存性のうちの少なくとも１つの重みを、前記ｒ２によって含まれる前記ｒ１のレコードの割合と、前記レコードの相対的な重要さとのうちの一方または両方に従って決定するステップを含む
上記（４０）の方法。
（４２）（ｄ）前記ｒから前記ｒを含まないもう１つのＲＯ ｒ２への１つまたは複数の依存性を、前記ｒ２にも含まれる前記ｒのレコードの比率と、前記ｒ２にも含まれる前記ｒのレコードの相対的な重要さとのうちの一方または両方に基づく測定基準を使用して追加するステップと、
（ｅ）前記ｒが含まないもう１つのＲＯ ｒ３からｒへの１つまたは複数の依存性を、前記ｒにも含まれる前記ｒ３のレコードの比率と、前記ｒにも含まれる前記ｒ３のレコードの相対的な重要さとのうちの一方または両方に基づく測定基準を使用して追加するステップと
のうちの一方または両方をさらに含む、上記（４０）の方法。
（４３）データ依存性の重要さに相関する重みを辺に割り当てるステップと、
同一の測定基準を使用してステップ（ｄ）および（ｅ）の一方または両方で追加された前記１つまたは複数の依存性の重みを計算するステップと
を含む、上記（４２）の方法。
（４４）前記ｒが、新たに作成されたノード、変更された既存ノード、ＳＲＯノードおよびＭＲＯノードのうちの１つである、上記（４０）の方法。
（４５）共通のレコードを有するＲＯの対が、同一のレコード名を所有する高い確率を有するように、１つまたは複数の関係指定子が関係名を含む、上記（４０）の方法。
（４６）さらに、関係名を使用するか、関係名と共に平衡木を使用することによって、ＲＯを分離するステップを含む、上記（４５）の方法。
（４７）基礎データの内の少なくとも一部を識別する前記ステップが、
関係指定子を識別するステップと、
前記関係指定子と共通する１つまたは複数のレコードを有するオブジェクト依存性グラフ内の１つまたは複数のＲＯを突き止めるステップと
を含む、上記（４０）の方法。
（４８）前記マッピングのステップが、
前記基礎データの少なくとも一部に対応する前記オブジェクト依存性グラフ内の１つまたは複数のノードの組（ｕｐｄａｔｅ＿ｓｅｔ）を訪れるステップと、
前記ｕｐｄａｔｅ＿ｓｅｔから到達可能なノードを訪れるために、前記オブジェクト依存性グラフ内の辺をトラバースするステップと
を含む、上記（３）の方法。
（４９）前記トラバースのステップが、深さ優先または幅優先のいずれかで前記オブジェクト依存性グラフをトラバースするステップを含む、上記（４８）の方法。
（５０）前記オブジェクト依存性グラフのトラバースのそれぞれを一意に識別するタイムスタンプを維持するステップと、
トラバース中にある頂点に初めて訪れた時に、必ず、前記オブジェクト依存性グラフの頂点にタイムスタンプを格納するステップと、
頂点のタイムスタンプと現トラバースのタイムスタンプとを比較することによって、現トラバース中に頂点に訪れているかどうかを判定するステップと
をさらに含む、上記（４８）の方法。
（５１）さらに、新しいグラフ・トラバースのたびに、タイム・スタンプを増分するステップを含む、上記（５０）の方法。
（５２）グラフ・オブジェクトｏ１の２つのバージョンｏ１＿ｖ１およびｏ１＿ｖ２が存在し、前記オブジェクト依存性グラフＧが、ｏ１で終わる少なくとも１つの辺（ｏ２，ｏ１）を含む場合に、さらに、
前記ｏ１で終わり組Ｓを構成する１つまたは複数の辺（ｏ２，ｏ１）について、ｏ１＿ｖ１との一貫性を有する前記オブジェクトｏ２のバージョン番号と、ｏ１＿ｖ２との一貫性を有する前記オブジェクトｏ２の第２のバージョン番号とを維持するステップと、
グラフ・オブジェクトｏ２の同一バージョンが、前記バージョンｏ１＿ｖ１およびｏ１＿ｖ２との一貫性を有する前記組Ｓの辺（ｏ２，ｏ１）の数と前記組Ｓのｏ１で終わるすべての辺の数とに基づいて、ｏ１＿ｖ１とｏ１＿ｖ２とがどれほど似ているかを判定するステップと
を含む、上記（３）の方法。
（５３）ｏ１＿ｖ１とｏ１＿ｖ２とがどれほど似ているかを判定する前記ステップが、前記組Ｓのｏ１で終わるすべての辺の数によって、グラフ・オブジェクトｏ２の同一バージョンが前記バージョンｏ１＿ｖ１およびｏ１＿ｖ２との一貫性を有する前記組Ｓの辺（ｏ２，ｏ１）の数を除算するステップを含む、上記（５２）の方法。
（５４）オブジェクトのうちの少なくともいくつかが、ウェブ・ドキュメントであり、基礎データのうちの少なくともいくつかが、１つまたは複数のデータベースの一部である、上記（１）の方法。
（５５）前記キャッシュに格納された前記複合オブジェクトｏ１のバージョンが非常に古くなると判定する前記ステップが、ｏ１の前記バージョンが前記ｏ２の現行バージョンとの一貫性を有しない辺（ｏ２，ｏ１）の数を判定するステップを含む、上記（１５）の方法。
（５６）前記キャッシュに格納された前記複合オブジェクトｏ１のバージョンが非常に古くなると判定する前記ステップが、さらに、前記ｏ１で終わる辺の総数に基づく、上記（５５）の方法。
（５７）さらに、１つまたは複数のグラフ・オブジェクトの組ｓ＿ｕｐｄａｔｅに含まれる１つまたは複数のオブジェクトに対する依存性を、直接にまたは前記オブジェクト依存性グラフによって推移的に指定される少なくとも１つの他のグラフ・オブジェクトが、どのように影響を受けるかを判定するために、前記オブジェクト依存性グラフと共に、基礎データに対する変更によって前記ｓ＿ｕｐｄａｔｅがどのように影響を受けるかに関する情報を使用するステップを含む、上記（３）の方法。
（５８）さらに、前記オブジェクトへの参照をリンク・リスト上に格納することによって一貫性スタックを実施するステップを含む、上記（３０）の方法。
（５９）前記一貫性スタックを実施するために１つまたは複数の平衡木を使用するステップと、
少なくとも１つのオブジェクトｏｂｊ１について、前記ｏｂｊ１への参照を一貫性スタックに追加する前に、前記ｏｂｊ１への参照が一貫性スタックにまだ含まれていないことを検証するステップと
をさらに含む、上記（３０）の方法。
（６０）前記一貫性セットが、１つまたは複数のリンク・リストを使用して実施される、上記（２６）の方法。
（６１）１つまたは複数の複合オブジェクトを格納する１つまたは複数のキャッシュと、オブジェクトのうちの１つまたは複数の現在値に影響する可能性がある基礎データを格納した１つまたは複数の遠隔データ・ソースとを含むコンピュータ・システムにおいて、
時間に伴って変化する可能性があり、複数のグラフ・オブジェクトと、前記グラフ・オブジェクト間の１つまたは複数のデータ依存性を示す複数の辺とを含むオブジェクト依存性グラフを維持するステップと、
前記基礎データのうちの少なくとも一部が変更された時を認識するステップと、
変更された、前記基礎データのうちの少なくとも一部に関する情報と、変更された前記基礎データの結果として値を変更された少なくとも１つのオブジェクトの識別を含む情報と、変更された前記基礎データの結果として値を変更された少なくとも１つのオブジェクトの識別を判定できるようにする情報とのうちの１つまたは複数を前記キャッシュに通信するステップと、
前記通信するステップに応答して、前記キャッシュからオブジェクトを除去するか、前記キャッシュ内のオブジェクトの新バージョンを更新するステップと
を含む方法。
（６２）前記基礎データの少なくとも一部が、１つまたは複数の遠隔データ・ソースに格納され、さらに、
変更された前記基礎データの少なくとも一部に関する情報と、変更された前記基礎データの結果として値を変更された少なくとも１つのオブジェクトの識別を含む情報と、変更された前記基礎データの結果として値を変更された少なくとも１つのオブジェクトの識別を判定できるようにする情報とのうちの１つまたは複数の前記キャッシュに通信するステップと、
前記通信するステップに応答して、前記キャッシュからオブジェクトを除去するか、前記キャッシュ内のオブジェクトの新バージョンを更新するステップと
を含む、上記（１３）の方法。
（６３）上記（１）ないし（１１）、（１３）、（１８）、（２１）ないし（２４）、（２６）ないし（３０）、（４０）、（４５）、（４７）、（４８）または（５０）のいずれかによる、基礎データに対する変更が１つまたは複数の複合オブジェクトにどのように影響することができるかを判定するための方法ステップを実行するため計算機によって実行可能な命令のプログラムを具体的に実施する、計算機によって可読のプログラム記憶装置。
【図面の簡単な説明】
【図１】本発明の特徴を有するシステムの例を示す図である。
【図２】本発明の特徴を有するオブジェクト依存性グラフの例を示す図である。
【図３】本発明の特徴を有するシステムの例を示す図である。
【図４】本発明に従って使用されるキャッシュの例を示す図である。
【図５】本発明に従って使用されるオブジェクト情報ブロック（ＯＩＢ）の例を示す図である。
【図６】本発明によるＡＰＩ関数の例を示す図である。
【図７】図６のＡＰＩ関数を実装する方法のブロック図である。
【図８】オブジェクトをキャッシュに追加するＡＰＩ関数のブロック図である。
【図９】キャッシュ内のオブジェクトを探すＡＰＩ関数のブロック図である。
【図１０】キャッシュからオブジェクトを削除するＡＰＩ関数のブロック図である。
【図１１】レコードからオブジェクトへの依存性を追加するＡＰＩ関数のブロック図である。
【図１２】レコードからオブジェクトへの依存性を削除するＡＰＩ関数のブロック図である。
【図１３】レコードが変更された時に呼び出されるＡＰＩ関数のブロック図である。
【図１４】本発明の特徴を有するシステムのもう１つの例を示す図である。
【図１５】本発明の特徴を有するオブジェクト依存性グラフのもう１つの例を示す図である。
【図１６】図１４のオブジェクト・マネージャの例を示す図である。
【図１７】本発明の特徴を有するオブジェクト依存性グラフのもう１つの図である。
【図１８】本発明の実施例に従って使用されるキャッシュの例を示す図である。
【図１９】本発明に従って使用されるオブジェクト情報ブロック（ＯＩＢ）の例を示す図である。
【図２０】本発明に従って使用される依存性リストの例を示す図である。
【図２１】本発明に従って使用される依存性情報ブロック（ＤＩＢ）の例を示す図である。
【図２２】本発明によるＡＰＩ関数のもう１つの例を示す図である。
【図２３】図２２のＡＰＩ関数を実装する方法のブロック図である。
【図２４】最新バージョンのオブジェクトをキャッシュに追加するキャッシュＡＰＩ関数のブロック図である。
【図２５】あるバージョンのオブジェクトをあるキャッシュから別のキャッシュにコピーしようとするＡＰＩ関数のブロック図である。
【図２６】基礎データが変更された時に呼び出すことのできるＡＰＩ関数のブロック図である。
【図２７】基礎データに対する変更に応答してオブジェクト依存性グラフを介して変更を伝播する方法の一部を示すブロック図である。
【図２８】基礎データに対する変更に応答して、深さ優先の形でオブジェクト依存性グラフを介して変更を伝播する方法の一部を示すブロック図である。
【図２９】基礎データに対する変更に応答して特定のグラフ・オブジェクトに変更を伝播する方法の一部を示すブロック図である。
【図３０】基礎データに対する変更に応答して、キャッシュ記憶されたバージョンのオブジェクトを更新または無効化する方法の一部を示すブロック図である。
【図３１】基礎データに対する変更に応答して、１つまたは複数のオブジェクトが１つまたは複数のキャッシュに追加された時に一貫性を維持するための方法の一部を示すブロック図である。
【図３２】単一レコード・オブジェクト（ＳＲＯ）に対応するグラフ・ノードを作成するキャッシュＡＰＩ関数のブロック図である。
【図３３】複数レコード・オブジェクト（ＭＲＯ）に対応するグラフ・ノードを作成するＡＰＩ関数のブロック図である。
【図３４】レコードが変更された時に呼び出すことのできるＡＰＩ関数のブロック図である。
【図３５】オブジェクト依存性グラフと、これを使用してグラフ・オブジェクトに変更を伝播する方法のもう１つの例を示す図である。
【図３６】キャッシュをスケーラブルに維持し、一貫性のある形で更新するための、本発明の特徴を有するシステムの例を示すブロック図である。
【図３７】マスタ・トリガ・モニタとしてインスタンス化された図３６のトリガ・モニタの詳細な例を示す図である。
【図３８】スレーブ・モニタとしてインスタンス化されたトリガ・モニタの例を示す図である。
【図３９】図３７のｓｅｎｄ＿ｔｒｉｇｇｅｒ ＡＰＩの例を示す図である。
【図４０】本発明によるトランザクション・タイプの例を示す図である。
【図４１】図３７のオブジェクト処置ブロック（ＯＤＢ）の例を示す図である。
【図４２】図４１のキャッシュＩＤの例を示す図である。
【図４３】図４４と共に、トリガ・モニタ・ドライバと分配マネージャの高水準の編成および通信経路の例を示す図である。
【図４４】図４３と共に、トリガ・モニタ・ドライバと分配マネージャの高水準の編成および通信経路の例を示す図である。
【図４５】図４３および図４４の受取側スレッド・ロジックの例を示す図である。
【図４６】図４３および図４４の入力作業ディスパッチャ・スレッド・ロジックの例を示す図である。
【図４７】図４３および図４４のキャッシュ・マネージャ通信スレッド・ロジックの例を示す図である。
【図４８】図４３および図４４のオブジェクト・ジェネレータ・スレッド・ロジックの例を示す図である。
【図４９】図４３および図４４の分配マネージャ・スレッド・ロジックの例を示す図である。
【図５０】図４３および図４４のアウトバウンド・トランザクション・スレッド・ロジックの例を示す図である。
【図５１】トリガ・イベントの分析と変換のための拡張と変形の例を示す図である。
【図５２】１つまたは複数のキャッシュからなるシステムに対して１組の要求を一貫性のある形で行うためのロジックの例を示す図である。
【図５３】要求を受け取るキャッシュ・マネージャの組が複数の要素を有する場合にｌａｓｔ＿ｌｏｃｋ＿ｔｉｍｅを決定するためのロジックの例を示す図である。
【符号の説明】
１ キャッシュ・マネージャ
２ キャッシュ
２’ キャッシュ
３ ディレクトリ
４ オブジェクト記憶域
５ 補助状態情報
６ オブジェクト
８ オブジェクト・リスト
９ ｏｂｊｅｃｔ＿ｉｄ
１０ オブジェクト情報ブロック（ＯＩＢ）
１０’ オブジェクト情報ブロック（ＯＩＢ）
１１ レコード・リスト
１２ ｒｅｃｏｒｄ＿ｉｄ（レコードＩＤ）
１９ ハッシュ・テーブル
２５ ハッシュ・テーブル項目
９０ クライアント
９５ ネットワーク
９７ アプリケーション・プログラム
９９ データベース
１００ サーバ

Claims (58)

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. グラフ・オブジェクトｒが、単一レコード（ＳＲＯ）または複数レコード（ＭＲＯ）を表すことのできる関連関係指定子を有する関係オブジェクト（ＲＯ）であり、
    前記オブジェクト依存性グラフを維持することが、
    （ａ）前記ｒの関係指定子を格納すること、
    （ｂ）１つまたは複数のグラフ・オブジェクトが前記ｒを含む場合に、前記ｒから前記ｒを含む１つまたは複数のグラフ・オブジェクトへの１つまたは複数の依存性を追加すること、
    （ｃ）前記ｒが１つまたは複数のグラフ・オブジェクトを含む場合に、前記ｒに含まれる前記１つまたは複数のグラフ・オブジェクトから前記ｒへの１つまたは複数の依存性を追加すること
    をさらに含む、請求項１記載の方法。
37. データ依存性の重要さに相関する重みを前記辺に割り当てることをさらに含み、
    前記（ｂ）および（ｃ）の複数の依存性を追加することのうちの１つが、ＲＯノードｒ２を含むＲＯノードｒ１に対応する依存性のうちの少なくとも１つの重みを、前記ｒ２によって含まれる前記ｒ１のレコードの割合と、前記レコードの相対的な重要さとのうちの一方または両方に従って決定するステップを含む
    請求項３６記載の方法。
38. （ｄ）前記ｒから前記ｒがｒ２を含まないもう１つのＲＯ ｒ２への１つまたは複数の依存性を、前記ｒ２にも含まれる前記ｒのレコードの比率と、前記ｒ２にも含まれる前記ｒのレコードの相対的な重要さとのうちの一方または両方に基づく測定基準を使用して追加すること、
    （ｅ）ｒがｒ３を含まないもう１つのＲＯ ｒ３から前記ｒへの１つまたは複数の依存性を、前記ｒにも含まれる前記ｒ３のレコードの比率と、前記ｒにも含まれる前記ｒ３のレコードの相対的な重要さとのうちの一方または両方に基づく測定基準を使用して追加すること
    のうちの一方または両方をさらに含む、請求項３６記載の方法。
39. データ依存性の重要さに相関する重みを辺に割り当てること、
    同一の測定基準を使用して前記（ｄ）および（ｅ）の一方または両方で追加された前記１つまたは複数の依存性の前記重みを計算すること
    を含む、請求項３８記載の方法。
40. 前記ｒが、新たに作成されたノード、変更された既存ノード、ＳＲＯノードおよびＭＲＯノードのうちの１つである、請求項３６記載の方法。
41. 共通のレコードを有するＲＯの対が、同一のレコード名を所有する高い確率を有するように、１つまたは複数の関係指定子が関係名を含む、請求項３６記載の方法。
42. 関係名を使用するか、関係名と共に平衡木を使用することによって、ＲＯを分離することをさらに含む、請求項４１記載の方法。
43. 基礎データの内の少なくとも一部を識別することが、
    関係指定子を識別すること、
    前記関係指定子と共通する１つまたは複数のレコードを有するオブジェクト依存性グラフ内の１つまたは複数のＲＯを突き止めること
    を含む、請求項３６記載の方法。
44. 前記マッピングするステップが、
    前記基礎データの少なくとも一部に対応する前記オブジェクト依存性グラフ内の１つまたは複数のノードの組（ｕｐｄａｔｅ＿ｓｅｔ）を訪れること、
    前記ｕｐｄａｔｅ＿ｓｅｔから到達可能なノードを訪れるために、前記オブジェクト依存性グラフ内の辺をトラバースすること
    を含む、請求項１記載の方法。
45. 前記トラバースすることが、深さ優先または幅優先のいずれかで前記オブジェクト依存性グラフをトラバースすることを含む、請求項４４記載の方法。
46. 前記オブジェクト依存性グラフのトラバースのそれぞれを一意に識別するタイムスタンプを維持すること、
    トラバース中にある頂点に初めて訪れた時に、必ず、前記オブジェクト依存性グラフの頂点にタイムスタンプを格納すること、
    頂点のタイムスタンプと現トラバースのタイムスタンプとを比較することによって、現トラバース中に頂点に訪れているかどうかを判定すること
    をさらに含む、請求項４４記載の方法。
47. 新しいグラフ・トラバースのたびに、タイムスタンプを増分することをさらに含む、請求項４６記載の方法。
48. グラフ・オブジェクトｏ１の２つのバージョンｏ１＿ｖ１およびｏ１＿ｖ２が存在し、前記オブジェクト依存性グラフＧが、ｏ１で終わる少なくとも１つの辺（ｏ２，ｏ１）を含む場合に、
    前記ｏ１で終わり組Ｓを構成する１つまたは複数の辺（ｏ２，ｏ１）について、ｏ１＿ｖ１との一貫性を有する前記オブジェクトｏ２のバージョン番号と、ｏ１＿ｖ２との一貫性を有する前記オブジェクトｏ２の第２のバージョン番号とを維持すること、
    グラフ・オブジェクトｏ２の同一バージョンが、前記バージョンｏ１＿ｖ１およびｏ１＿ｖ２との一貫性を有する前記組Ｓの辺（ｏ２，ｏ１）の数と前記組Ｓのｏ１で終わるすべての辺の数とに基づいて、ｏ１＿ｖ１とｏ１＿ｖ２とがどれほど似ているかを判定すること
    をさらに含む、請求項１又は２のいずれか記載の方法。
49. ｏ１＿ｖ１とｏ１＿ｖ２とがどれほど似ているかを判定すること、前記組Ｓのｏ１で終わるすべての辺の数によって、グラフ・オブジェクトｏ２の同一バージョンが前記バージョンｏ１＿ｖ１およびｏ１＿ｖ２との一貫性を有する前記組Ｓの辺（ｏ２，ｏ１）の数を除算することを含む、請求項４８記載の方法。
50. オブジェクトのうちの少なくともいくつかが、ウェブ・ドキュメントであり、基礎データのうちの少なくともいくつかが、１つまたは複数のデータベースの一部である、請求項１記載の方法。
51. 前記キャッシュに格納された前記複合オブジェクトｏ１のバージョンが古くなると判定することが、ｏ１の前記バージョンが前記ｏ２の現行バージョンとの一貫性を有しない辺（ｏ２，ｏ１）の数を判定することを含む、請求項１記載の方法。
52. 前記キャッシュに格納された前記複合オブジェクトｏ１のバージョンが古くなると判定することが、前記ｏ１で終わる辺の総数にさらに基づく、請求項５１記載の方法。
53. １つまたは複数のグラフ・オブジェクトの組ｓ＿ｕｐｄａｔｅに含まれる１つまたは複数のオブジェクトに対する依存性を、直接にまたは前記オブジェクト依存性グラフによって推移的に指定される少なくとも１つの他のグラフ・オブジェクトが、どのように影響を受けるかを判定するために、前記オブジェクト依存性グラフと共に、基礎データに対する変更によって前記ｓ＿ｕｐｄａｔｅがどのように影響を受けるかに関する情報を使用することをさらに含む、請求項１記載の方法。
54. 前記オブジェクトへの参照をリンク・リスト上に格納することによって一貫性スタックを実施することをさらに含む、請求項２６記載の方法。
55. 前記一貫性スタックを実施するために１つまたは複数の平衡木を使用すること、
    少なくとも１つのオブジェクトｏｂｊ１について、前記ｏｂｊ１への参照を一貫性スタックに追加する前に、前記ｏｂｊ１への参照が一貫性スタックにまだ含まれていないことを検証すること
    をさらに含む、請求項２６記載の方法。
56. 前記一貫性セットが、１つまたは複数のリンク・リストを使用して実施される、請求項２２記載の方法。
57. 前記基礎データの少なくとも一部が、１つまたは複数の遠隔データ・ソースに格納され、
    変更された前記基礎データの少なくとも一部に関する情報と、変更された前記基礎データの結果として値を変更された少なくとも１つのオブジェクトの識別を含む情報と、変更された前記基礎データの結果として値を変更された少なくとも１つのオブジェクトの識別を判定できるようにする情報とのうちの１つまたは複数の前記キャッシュに通信すること、そして
    前記通信することに応答して、前記キャッシュからオブジェクトを除去するか、前記キャッシュ内のオブジェクトの新バージョンを更新すること
    をさらに含む、請求項１記載の方法。
58. １つまたは複数の複合オブジェクトを格納する１つまたは複数のキャッシュを含むコンピュータ・システムにおいて、基礎データに対する変更が１つまたは複数の前記複合オブジェクトの値にどのように影響を及ぼすかを判定するためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記基礎データは、前記１つまたは複数の複合オブジェクトの値に影響する可能性があるデータを含み、
    前記コンピュータ・システムに、
    前記コンピュータ・システム上で稼働するアプリケーション・プログラムによって複合オブジェクトを生成するステップであって、前記複合オブジェクトは前記基礎データから構築される、前記生成するステップと、
    前記生成された複合オブジェクトを前記１つまたは複数のキャッシュに格納するステップと、
    前記基礎データの少なくとも一部を識別するステップであって、前記複合オブジェクトのうちの１つまたは複数は、前記基礎データの識別された前記少なくとも一部に対して、１つまたは複数のデータ依存性を有する、前記識別するステップと
    前記複合オブジェクトのうちの１つまたは複数に、前記基礎データの少なくとも一部をマッピングするステップであって、前記マッピングが、前記基礎データの前記少なくとも一部に対する変更を識別すること、そして前記基礎データの少なくとも一部に対する変更の前記識別に応答して、１つまたは複数の前記複合オブジェクトが影響されるかどうかを識別する、前記マッピングするステップと、
    オブジェクト依存性グラフ（Ｇ）をキャッシュ・マネージャ内に維持するステップであって、前記オブジェクト依存性グラフ（Ｇ）は、オブジェクト依存性グラフの頂点であるグラフ・オブジェクトと、他の頂点である複数のグラフ・オブジェクトと、前記グラフ・オブジェクトと前記複数のグラフ・オブジェクトとの間のデータ依存性を示す１又は複数の辺とを含み、前記オブジェクト依存性グラフの頂点は複合オブジェクトであり、前記他の頂点である複数のグラフ・オブジェクトは複合オブジェクト又は基礎データであり、前記オブジェクト依存性グラフ（Ｇ）は、時間に伴って変化する可能性がある、前記維持するステップと、
    前記基礎データの少なくとも一部に対する変更の結果、キャッシュに格納された前記複合オブジェクトのバージョンが、そのバージョンが古くなることを判定するステップであって、前記判定は、前記オブジェクト依存性グラフ（Ｇ）の辺を調べることによって、どの複合オブジェクトが変更したかを判定する、前記判定するステップと、
    前記古くなることの判定に応答して、前記複合オブジェクトの古いバージョンをキャッシュから削除するステップ又は前記複合オブジェクトの古いバージョンを、それより新しいバージョンに置換するステップと、
    を実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images