(57)【特許請求の範囲】
【請求項１】
コンピュータのメモリ上にオブジェクトキャッシュを構築する方法であって、
前記メモリ上にキャッシュ領域を確保するステップと、
前記キャッシュ領域にキャッシュ対象オブジェクトを格納するステップと、
格納したキャッシュ対象オブジェクトに対するアクセス要求を受け付けるステップと、
を有し、
前記キャッシュ領域に前記キャッシュ対象オブジェクトを格納する際に、
当該キャッシュ対象オブジェクトを、
そのキャッシュ対象オブジェクトそのものの内容を表す被参照オブジェクトと、
その被参照オブジェクトに向けた参照情報を保持する参照オブジェクトと、
に分割して前記キャッシュ領域に格納しておき、
前記キャッシュ領域に格納した被参照オブジェクトに対するアクセス要求を受け付けると、
その被参照オブジェクトのクローンを生成するとともに、
そのクローンに向けた参照情報を保持する参照オブジェクトを生成し、
その参照オブジェクトを介して前記クローンに向けた参照を返し、
その参照を用いて前記クローンにアクセスさせる
ことを特徴とするオブジェクトキャッシュ構築方法。
【請求項２】
前記キャッシュ領域に格納した被参照オブジェクトに対するアクセス要求を受け付けてその被参照オブジェクトのクローンを生成する際には、
その被参照オブジェクトが参照している他のオブジェクトへの参照情報を、
当該クローンが参照する参照先オブジェクトを特定する情報として当該クローンに保持させる
ことを特徴とする請求項１に記載のオブジェクトキャッシュ構築方法。
【請求項３】
前記クローンに対して行った変更を前記キャッシュ領域に反映すべき旨の要求を受け付けるステップと、
その要求に基づき前記変更を前記キャッシュ領域に反映する変更確定ステップと、
を有し、
前記変更確定ステップでは、
変更に係るクローンの元となった被参照オブジェクトに向けた参照情報を保持する参照オブジェクトの当該参照情報を、
変更に係るクローンに向けた参照情報に書き換えることにより、
前記クローンに対して行った変更を前記キャッシュ領域に反映する
ことを特徴とする請求項１または請求項２に記載のオブジェクトキャッシュ構築方法。
【請求項４】
前記キャッシュ領域に前記被参照オブジェクトを格納している場合において、
その被参照オブジェクトに関連付けた新たなキャッシュ対象オブジェクトを前記キャッシュ領域に格納すべき旨の要求を受け付けるステップと、
その要求に基づき新たなキャッシュ対象オブジェクトを前記キャッシュ領域に格納するとともに先に格納されている被参照オブジェクトと関連付ける関連追加確定ステップと、
を有し、
前記関連追加確定ステップでは、
先に前記キャッシュ領域に格納されている被参照オブジェクトのクローンを生成し、
そのクローンと新たなキャッシュ対象オブジェクトを関連付けて前記キャッシュ領域に格納する
ことを特徴とする請求項１ないし請求項３のいずれかに記載のオブジェクトキャッシュ構築方法。
【請求項５】
前記関連追加確定ステップでは、
先に前記キャッシュ領域に格納されている被参照オブジェクトと新たなキャッシュ対象オブジェクトの関連付け情報を保持する関連オブジェクトを生成し、
新たなキャッシュ対象オブジェクトと前記関連オブジェクトを前記キャッシュ領域に格納する
ことを特徴とする請求項４に記載のオブジェクトキャッシュ構築方法。
【請求項６】
前記関連追加確定ステップでは、
先に前記キャッシュ領域に格納されている被参照オブジェクトに、前記関連オブジェクトに対応する参照オブジェクトに向けた参照情報を保持させるとともに、
新たなキャッシュ対象オブジェクトに、前記関連オブジェクトに対応する参照オブジェクトに向けた参照情報を保持させる
ことを特徴とする請求項５に記載のオブジェクトキャッシュ構築方法。
【請求項７】
前記関連追加確定ステップでは、
前記キャッシュ領域に格納した前記関連オブジェクトに、
先に前記キャッシュ領域に格納されている被参照オブジェクトに対応した参照オブジェクトに向けた参照情報を保持させるとともに、
新たなキャッシュ対象オブジェクトに対応した参照オブジェクトに向けた参照情報を保持させる
ことを特徴とする請求項５または請求項６に記載のオブジェクトキャッシュ構築方法。
【請求項８】
前記キャッシュ領域に前記被参照オブジェクトと前記関連オブジェクトを格納している場合において、
前記関連オブジェクトにより関連付けられている被参照オブジェクトを前記キャッシュ領域から削除すべき旨の要求を受け付けるステップと、
その要求に基づきその被参照オブジェクトを前記キャッシュ領域から削除する削除確定ステップと、
を有し、
前記削除確定ステップでは、
前記関連オブジェクトのクローンを生成するとともに、
そのクローンに向けた参照情報を保持する参照オブジェクトを生成し、
その参照オブジェクトを介して、
前記関連オブジェクトにより関連付けられている被参照オブジェクトと、
前記関連オブジェクトとの関連付けを削除する
ことを特徴とする請求項５ないし請求項７のいずれかに記載のオブジェクトキャッシュ構築方法。
【請求項９】
前記関連追加確定ステップにおいて、
その処理を行っている旨を表すフラグ情報を、先に前記キャッシュ領域に格納されている被参照オブジェクトに対応する参照オブジェクトに保持させておき、
この参照オブジェクトに対するアクセス要求を受け付けると、前記フラグ情報を返す
ことを特徴とする請求項４ないし請求項８のいずれかに記載のオブジェクトキャッシュ構築方法。
【請求項１０】
前記削除確定ステップでは、
前記関連オブジェクトに向けた参照情報を保持する参照オブジェクトの当該参照情報を、前記関連オブジェクトのクローンに向けた参照情報に書き換えるとともに、
前記関連オブジェクトにより関連付けられている被参照オブジェクトが保持している、
前記関連オブジェクトに対応する参照オブジェクトに向けた関連付けを削除することにより、
前記関連オブジェクトと関連付けられているオブジェクトの参照情報を削除する
ことを特徴とする請求項８に記載のオブジェクトキャッシュ構築方法。
【請求項１１】
前記削除確定ステップにおいて、
その処理を行っている旨を表すフラグ情報を、前記関連オブジェクトに対応する参照オブジェクトに保持させておき、
この参照オブジェクトに対するアクセス要求を受け付けると、前記フラグ情報を返す
ことを特徴とする請求項８または請求項１０に記載のオブジェクトキャッシュ構築方法。
【請求項１２】
前記キャッシュ領域に格納されている各オブジェクトに対して行う変更を確定する際には、
そのオブジェクトが参照し、またはそのオブジェクトを参照している周辺のオブジェクトに対する変更を禁止する
ことを特徴とする請求項３ないし請求項１１のいずれかに記載のオブジェクトキャッシュ構築方法。
【請求項１３】
前記キャッシュ領域に格納されている複数の被参照オブジェクトを一括して取得すべき旨の要求を受け取るステップを有し、
その要求を受け取る際に、
一括取得を実行するエージェントオブジェクトを併せて受け取り、
前記被参照オブジェクトのクローンを生成することなく、
そのエージェントオブジェクトに、
前記キャッシュ領域に格納されている複数の被参照オブジェクトが保持する属性値を、前記参照情報を用いて直接取得させる
ことを特徴とする請求項１ないし請求項１２のいずれかに記載のオブジェクトキャッシュ構築方法。
【請求項１４】
請求項１ないし請求項１３のいずれかに記載のオブジェクトキャッシュ構築方法を当該コンピュータに実行させる
ことを特徴とするオブジェクトキャッシュ構築プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータのメモリ上にオブジェクトキャッシュを構築する方法、およびそのプログラムに関するものである。
【背景技術】
【０００２】
コンピュータ上で実行されるアプリケーションからデータにアクセスする際に、そのアクセスを高速化する手段として、メモリ上に対象データのキャッシュを構築する手法が、しばしば用いられる。
アプリケーションから利用するキャッシュの分類の仕方として、例えば以下のようなものがある。
【０００３】
（１）ＤＢキャッシュ
アクセス頻度の高いデータ本体や実行頻度の高い処理プログラムをキャッシュ領域にコピーしておくことで、データベースへのアクセス高速化を図る。一般にアプリケーションから利用するキャッシュとは、このＤＢキャッシュを指すことが多い。
【０００４】
（２）オブジェクトキャッシュ
バイナリオブジェクトをキャッシュ領域上に預けて所定のキーと関連付けておき、後にアプリケーションから利用するときは、キーを指定することで、そのバイナリオブジェクトに直接的にアクセスする。
比較的サイズの大きい同一のバイナリオブジェクトを何度も使用するような場合に、キャッシュ領域に預けておいたバイナリオブジェクトを使い回すことで、同一のオブジェクトを何度も生成する負荷を削減する、といった用途に向く。
具体的な実装例としては、格納しておくバイナリオブジェクトと、そのハッシュキーとを関連付けてハッシュマッピング領域に格納しておき、アプリケーションからハッシュキーを指定して、関連付けられたバイナリオブジェクトを取得する、という手法がある。
【０００５】
また、コンピュータのメモリ上のキャッシュに関し、『データの一貫性を維持するとともに、メモリ領域を節約しながら、アプリケーションからのデータアクセスを高速化する。』ことを目的とした技術として、『携帯端末１０のキャッシュ制御部１５は、アプリケーション１３が参照するデータを規定したオブジェクトのインスタンスへのアクセス要求を受け、該オブジェクトのインスタンスが存在しない場合は、オブジェクトのインスタンスと、カウンタを生成する。また、リファレンス設定クラスのインスタンスを生成し、要求されたオブジェクトのインスタンスを参照するリファレンスを設定してアプリケーション１３に返送するとともに、カウンタを１増加させる。リファレンス設定クラスのインスタンスの解放通知を受けた場合は、対応するカウンタを１減算し、該カウンタが０になった場合にオブジェクトのインスタンスを解放する。』というものが提案されている（特許文献１）。
【０００６】
また、オブジェクトキャッシュに関し、『効率的にキャッシュデータを格納できるキャッシュシステムを提供する。』ことを目的とした技術として、『高効率キャッシュシステムは、オブジェクトリレーショナルマッピングにおける高効率キャッシュシステムであって、前記リレーショナルデータベースに保存されているデータから、キャッシュ用オブジェクトと処理用オブジェクトとに変換するデータオブジェクト変換手段と、前記キャッシュ用オブジェクトと前記処理用オブジェクトとを対応付けて相互に変換可能なオブジェクト対応相互変換手段と、前記キャッシュ用オブジェクトを格納するオブジェクトキャッシュ格納手段と、前記リレーショナルデータベースからデータを取得する補充オブジェクトデータ取得手段と、取得したオブジェクトと取得したデータとから、キャッシュ用オブジェクトと、取得要求に対して提供される処理用オブジェクトとを生成するオブジェクト生成手段とを有する。』というものも提案されている（特許文献２）。
【０００７】
【特許文献１】特開２００５−１９０２２１号公報（要約）
【特許文献２】特開２００７−２６５１６４号公報（要約）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記特許文献１に記載の技術は、キャッシュを構築することにより携帯端末１０のオブジェクトアクセスを高速化する手法に関するものであり、アプリケーションからキャッシュを利用することでアプリケーションの便宜に資する観点から述べられている。
これは、上記のキャッシュ分類の仕方によれば、（１）のＤＢキャッシュに近い技術について述べているものと言える。
【０００９】
また、上記特許文献２に記載の技術は、オブジェクトキャッシュに言及しているものの、その用途は（１）のＤＢキャッシュに近いものであり、キャッシュの形式がオブジェクト型であるに過ぎない。
【００１０】
一方、オブジェクトキャッシュそのものについての高速化やデータ一貫性の維持については、従来から要求のあるところであるが、上記特許文献１や特許文献２に記載の技術では、キャッシュそのものの高速化やデータ一貫性の維持については、詳細は述べられておらず、これを可能とするキャッシュ構築手法が望まれている。
【００１１】
本発明は、上記のような課題を解決するためになされたものであり、コンピュータのメモリ上にオブジェクトキャッシュを構築し、キャッシュ自体のアクセスの高速化やデータ一貫性の維持を図ることを目的とする。
【課題を解決するための手段】
【００１２】
本発明に係るオブジェクトキャッシュ構築方法は、コンピュータのメモリ上にオブジェクトキャッシュを構築する方法であって、前記メモリ上にキャッシュ領域を確保するステップと、前記キャッシュ領域にキャッシュ対象オブジェクトを格納するステップと、格納したキャッシュ対象オブジェクトに対するアクセス要求を受け付けるステップと、を有し、前記キャッシュ領域に前記キャッシュ対象オブジェクトを格納する際に、当該キャッシュ対象オブジェクトを、そのキャッシュ対象オブジェクトそのものの内容を表す被参照オブジェクトと、その被参照オブジェクトに向けた参照情報を保持する参照オブジェクトと、に分割して前記キャッシュ領域に格納しておき、前記キャッシュ領域に格納した被参照オブジェクトに対するアクセス要求を受け付けると、その被参照オブジェクトのクローンを生成するとともに、そのクローンに向けた参照情報を保持する参照オブジェクトを生成し、その参照オブジェクトを介して前記クローンに向けた参照を返し、その参照を用いて前記クローンにアクセスさせるものである。
【発明の効果】
【００１３】
本発明に係るオブジェクトキャッシュ構築方法によれば、キャッシュにオブジェクトを格納する際に、被参照オブジェクトと参照オブジェクトに分割して格納しておき、参照オブジェクトを介して被参照オブジェクトにアクセスさせるので、複数のアプリケーションが１つの更新中オブジェクトに同時にアクセスすることを防止でき、データ一貫性が確保される。
また、複数のオブジェクトが関連付けられてキャッシュ領域に格納されている場合に、各関連付けを分割して格納することができるので、取得対象のオブジェクトのみを取り出すことが容易となり、関連付けられた周辺オブジェクトを併せて取得する必要はない。
そのため、１度のオブジェクトアクセス時に消費するメモリ領域を押さえることができるので、オブジェクトアクセスを高速化することができる。
【発明を実施するための最良の形態】
【００１４】
実施の形態１．
図１は、本発明の実施の形態１に係るオブジェクトキャッシュの構成図である。
図１において、キャッシュ領域１００は、コンピュータのメモリ上に確保される一定の領域であり、内部的に、参照オブジェクト領域１１０と被参照オブジェクト領域１２０に分けられている。
参照オブジェクト領域１１０と被参照オブジェクト領域１２０は、例えばハッシュマップなどのコレクション領域や配列領域などを用いて構築することができる。これらの領域については、後述の図２で改めて説明する。
なお、実装上は、参照オブジェクト領域１１０内に、被参照オブジェクト領域１２０を保持させるように構成してもよい。本実施の形態１では、記載の便宜上、図１のように表すこととした。以後の実施の形態でも同様である。
【００１５】
キャッシュ領域１００上に構築された参照オブジェクト領域１１０と被参照オブジェクト領域１２０が、本実施の形態１における狭義のオブジェクトキャッシュに相当し、これにキャッシュマネージャ２００を加えてオブジェクトの格納と取得の手段を追加したものが、本実施の形態１における広義のオブジェクトキャッシュに相当する。
【００１６】
キャッシュマネージャ２００とアプリケーション３００は、キャッシュ領域１００をメモリ上に格納するコンピュータ上のプログラムであり、図示しないＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）やマイコンなどの演算装置上で実行されるものである。
キャッシュマネージャ２００は、当該コンピュータのメモリ上にキャッシュ領域１００を確保し、キャッシュ領域１００にオブジェクトを格納し、あるいはアプリケーション３００からの要求によりキャッシュ領域１００に格納されているオブジェクトを取得する。より詳しくは、後述の図２で改めて説明する。
アプリケーション３００は、キャッシュマネージャ２００を介して、キャッシュ領域１００にオブジェクトを格納し、あるいはキャッシュ領域１００に格納されているオブジェクトを取得する。
【００１７】
図２は、キャッシュ領域１００にオブジェクトを格納するイメージを示すものである。
図２（ａ）は、エンティティＡとエンティティＣが関連Ｂで関連付けられている場合の関係モデルを図示するものである。
図２（ｂ）は、図２（ａ）の関連モデルをオブジェクトモデルで表現したものである。オブジェクトモデルでは、関連Ｂもオブジェクトとして表現される。この場合は、オブジェクトＡとオブジェクトＢが参照関係で関連付けられ、オブジェクトＢとオブジェクトＣが参照関係で関連付けられる。
【００１８】
図２（ｃ）は、図２（ｂ）の各オブジェクトを、本実施の形態１に係るオブジェクトキャッシュに格納した様子を示すものである。
従来のオブジェクトキャッシュでは、図２（ｂ）の各オブジェクトをそのままキャッシュ領域１００に格納するところ、本実施の形態１に係るオブジェクトキャッシュでは、図２（ｂ）の各オブジェクトを、「参照オブジェクト」と「被参照オブジェクト」と呼ぶ２種類のオブジェクトに分割して格納する。
「参照オブジェクト」は参照オブジェクト領域１１０に、「被参照オブジェクト」は被参照オブジェクト領域１２０に、それぞれ格納される。
【００１９】
参照オブジェクトは、対応する被参照オブジェクトに向けた参照情報を保持する。
被参照オブジェクトは、対応する参照オブジェクトから参照されるとともに、関連付けられているオブジェクトに対応した参照オブジェクトに向けた参照情報を保持する。
【００２０】
図２（ｃ）の例では、被参照オブジェクトＢは、参照オブジェクトＡ（図２（ｃ）中の「ＲｅｆＡ」）と参照オブジェクトＣ（図２（ｃ）中の「ＲｅｆＣ」）に向けた参照情報を保持する。
また、被参照オブジェクトＡと被参照オブジェクトＣは、参照オブジェクトＢ（図２（ｃ）中の「ＲｅｆＢ」）に向けた参照情報を保持する。
【００２１】
キャッシュ領域１００に格納された被参照オブジェクトにアクセスするためには、必ず参照オブジェクトを介さなければならず、被参照オブジェクトに直接アクセスすることはできない。この点は、通常のハッシュキーを用いて実現するオブジェクトキャッシュとは異なる。
より詳細なオブジェクトの取得手順については、後述の図４で改めて説明する。
【００２２】
図３は、アプリケーション３００が新たなオブジェクトＡをキャッシュ領域１００に預ける際の手順を説明するものである。以下、図３の各ステップについて説明する。
【００２３】
（１）アプリケーション３００は、キャッシュ領域１００に格納したいオブジェクトＡを生成する。このとき、オブジェクトＡのメンバ変数に、オブジェクトＡの一意の識別キーを格納しておく。
（２）アプリケーション３００は、キャッシュマネージャ２００に、オブジェクトＡをキャッシュ領域１００へ預けるよう依頼する。
（３）キャッシュマネージャ２００は、オブジェクトＡを参照オブジェクトＡと被参照オブジェクトＡに分割し、それぞれの領域に格納する。このとき、参照オブジェクトＡに、被参照オブジェクトＡに向けた参照情報を格納しておく。
【００２４】
なお、参照オブジェクト領域１１０とその中の参照オブジェクトは、弱参照で緩やかに連結される。したがって、参照オブジェクトが他のいずれのオブジェクトからも参照されなくなった時点で、その参照オブジェクトは自動的に参照オブジェクト領域１１０から削除される。
被参照オブジェクト領域１２０とその中の被参照オブジェクトの連結についても、同様である。
オブジェクトが実際に各領域から削除されるのは、例えばキャッシュマネージャ２００の実行環境でガーベジコレクション（Ｇａｒｂａｇｅ  Ｃｏｌｌｅｃｔｉｏｎ）が実行された時点などが候補となり得る。
【００２５】
このように、キャッシュ領域１００に格納されたオブジェクトは、他のオブジェクトから参照されなくなった時点で不要と判断され、キャッシュ領域１００から削除される対象となるので、参照オブジェクト領域１１０と被参照オブジェクト領域１２０は、擬似キャッシュのような役割を果たすことができるのである。
【００２６】
図４は、キャッシュ領域１００に格納されているオブジェクトにアクセスする際の手順を説明するものである。以下、図４の各ステップについて説明する。
【００２７】
（１）アプリケーション３００は、キャッシュマネージャ２００に対し、被参照オブジェクトＢの取得を依頼する。
（２）キャッシュマネージャ２００は、被参照オブジェクトＢそのものを返すのではなく、参照オブジェクトＢを新たに生成し、アプリケーション３００に返す。このとき、内部的には、被参照オブジェクト領域１２０に格納されている被参照オブジェクトＢのクローンが生成され、新たに生成された参照オブジェクトＢから参照されるように設定される。
【００２８】
（３）被参照オブジェクトＢのクローンは、クローン元の被参照オブジェクトＢが保持している、参照オブジェクトＡと参照オブジェクトＣに向けた参照関係を、そのままコピーして保持する。
【００２９】
ステップ（３）において、被参照オブジェクトＢのクローンが保持する参照情報は、当該クローンＢから参照オブジェクトＡ、参照オブジェクトＣに向けた一方向のみの参照である。
このように、クローンＢが保持する参照情報を一方向のみとするのは、アプリケーション３００が被参照オブジェクトＢのクローンに変更を加えている最中に、他のアプリケーションから同オブジェクトにアクセスされないようにするためである。
即ち、もし他の参照情報を生成して、参照オブジェクト領域１１０からクローンＢへの向きにも参照可能としておくと、その参照を辿って、変更中である被参照オブジェクトＢのクローンに他のアプリケーションが到達してしまう可能性があるからである。
【００３０】
以後、アプリケーション３００は、キャッシュマネージャ２００より受け取った新たな参照オブジェクトＢを介して、被参照オブジェクトＢのクローンに対し、同オブジェクトが保持する値の取得など、種々の処理を実行する。
【００３１】
「参照情報」と「識別キー」の差異について、ここで補足しておく。
「参照情報」とは、参照先オブジェクトに対するポインタ情報のようなもので、キャッシュマネージャ２００やアプリケーション３００は、これを取得することにより、参照先のオブジェクトに直接的に到達することができる。例えばＪａｖａ（登録商標）言語の場合は、Ｒｅｆｅｒｅｎｃｅクラスやそのサブクラスで実現される。
「識別キー」とは、当該オブジェクトの一意な識別ＩＤであり、関係データベースでいうところの「主キー」や、ハッシュインデックスにおけるハッシュキーに相当する。キャッシュマネージャ２００やアプリケーション３００は、「識別キー」を指定することで、参照先オブジェクトを間接的に取得することができる。
【００３２】
本実施の形態１に係るオブジェクトキャッシュは、取得対象のオブジェクトが取得できれば用を成すため、関連付けられた他のオブジェクトを併せて取得する必要はないが、もしアプリケーション３００の処理の上で必要であれば、被参照オブジェクトＢのクローンは、参照オブジェクト領域１１０内の参照オブジェクトＡや参照オブジェクトＣに向けた参照関係を保持しているため、これを辿って各オブジェクトに到達することもできる。
ただし、このようにオブジェクトの参照関係を次々と辿るのは、本実施の形態１に係るオブジェクトキャッシュの本来の用途ではないことを付言しておく。
【００３３】
もし、アプリケーション３００が被参照オブジェクトＢのクローンにアクセスしている際に、他のアプリケーションがキャッシュ領域１００に格納されている被参照オブジェクトＢへのアクセスを要求したとしても、当該他のアプリケーションも、図４と同様の手順により被参照オブジェクトＢの新たなクローンを取得することになる。
したがって、アプリケーション３００がアクセスしている被参照オブジェクトＢのクローンに、他のアプリケーションがアクセスすることはなく、更新中の不安定な状態で被参照オブジェクトＢのクローンがアクセスされないことが保証される。
【００３４】
これは換言すると、本実施の形態１に係るオブジェクトキャッシュ上において、データベース上で行われるような「Ｒｅａｄ  Ｃｏｍｍｉｔｔｅｄ」アイソレーションレベルが実現されているに等しいと言うことができる。
即ち、更新中の不安定な状態のオブジェクトがアクセスされることがない、ということは、アプリケーション３００からアクセスされるオブジェクトは必ず更新済のものであることが保証されている、ということであり、これは「Ｒｅａｄ  Ｃｏｍｍｉｔｔｅｄ」アイソレーションレベルそのものである。
【００３５】
以上のように、本実施の形態１で説明した例によれば、キャッシュマネージャ２００は、キャッシュ領域１００にオブジェクト（仮にオブジェクトＢとする）を格納する際に、参照オブジェクトＢと被参照オブジェクトＢに分割してそれぞれの領域に格納しておき、参照オブジェクトＢを介して被参照オブジェクトＢにアクセスさせる。
このように、分割したオブジェクト格納構造を採用したことにより、アクセス要求に対しては、参照オブジェクトＢのみを返せば足り、関連する全てのオブジェクトを返す必要がなくなる。
【００３６】
また、本実施の形態１で説明した例によれば、キャッシュマネージャ２００は、アプリケーション３００から被参照オブジェクトＢに対するアクセス要求を受け付けると、その被参照オブジェクトＢのクローンおよび新たな参照オブジェクトＢを生成して、新たな参照オブジェクトＢをアプリケーション３００に返す。
このとき、被参照オブジェクトＢのクローンには、参照先オブジェクトへ向けた一方向の参照情報のみがコピーされる。
参照オブジェクト領域１１０からクローンＢに向けた参照情報は、コピー元のオブジェクトがそもそもそのような参照情報を保持していないため、クローンＢにはコピーされない。
これにより、アプリケーション３００が被参照オブジェクトＢのクローンを更新している最中は、他のアプリケーションが同オブジェクトにアクセスしないよう防ぐことができる。
【００３７】
また、複数のアプリケーションが被参照オブジェクトＢにアクセスを要求したとしても、各アプリケーションが被参照オブジェクトＢ（のクローン）を更新中に他のアプリケーションが同じオブジェクトへアクセスすることがない。
これにより、上述の一方向の参照情報のみをクローンＢに保持させる手法と合わせて、「Ｒｅａｄ  Ｃｏｍｍｉｔｔｅｄ」アイソレーションレベルが実現される。
即ち、本実施の形態１に係るオブジェクトキャッシュによれば、格納するデータの一貫性を確実に維持できるのである。
【００３８】
実施の形態２．
実施の形態１では、アプリケーション３００は、キャッシュ領域１００に格納されている被参照オブジェクトＢの取得をキャッシュマネージャ２００に要求し、キャッシュマネージャ２００は、被参照オブジェクトＢのクローンを生成して参照オブジェクトＢを返すことを説明した。
本発明の実施の形態２では、被参照オブジェクトＢのクローンに対して行った変更をキャッシュ領域１００に反映して確定させる手順を説明する。なお、オブジェクトキャッシュに係る各構成は実施の形態１と同様であるため、説明を省略する。
【００３９】
図５は、アプリケーション３００が被参照オブジェクトＢのクローンに対して行った変更をキャッシュ領域１００に反映して確定させる手順を説明するものである。以下、図５の各ステップについて説明する。
【００４０】
（１）参照オブジェクトＢを生成して返す
図４のステップ（１）〜（３）と同様の手順により、アプリケーション３００は、被参照オブジェクトＢのクローンに間接的にアクセスできるようになる。
次に、アプリケーション３００は、新たに生成された参照オブジェクトＢを介して、被参照オブジェクトＢのクローンが保持している値の変更などを行う。
【００４１】
（２）オブジェクトＢのクローンとの参照に張り替える
アプリケーション３００は、キャッシュマネージャ２００に対し、被参照オブジェクトＢのクローンに対して行った変更をキャッシュ領域１００に反映して確定するよう要求する。これは、データベースでいうところのコミット要求に相当する。
キャッシュマネージャ２００は、その要求を受け取り、参照オブジェクト領域１１０内の各オブジェクトの参照情報を、被参照オブジェクトＢのクローンとの間の参照情報に張り替える。
これにより、被参照オブジェクト領域１２０内の被参照オブジェクトＢは、被参照オブジェクトＢのクローンと論理的に置き換えられることになる。
【００４２】
図５の例では、参照オブジェクトＢの参照情報を、被参照オブジェクトＢのクローンに向けたものに張り替えている。
参照情報を張り替える際の具体的な実装例としては、参照先オブジェクトを引数として、参照元オブジェクトのメソッドをコールする、という方法がある。
【００４３】
（３）元のオブジェクトは削除対象となる
先に被参照オブジェクト領域１２０内に格納されていた被参照オブジェクトＢは、未だ参照オブジェクトＡと参照オブジェクトＣに向けた参照情報を保持しているものの（図５中では図示省略）、自身はどのオブジェクトからも参照されなくなる。
したがって、先に被参照オブジェクト領域１２０内に格納されていた被参照オブジェクトＢは、キャッシュ領域１００から削除される対象となり、後に自動削除される。
【００４４】
なお、ステップ（２）において、キャッシュマネージャ２００が参照オブジェクト領域１１０内の各オブジェクトの参照情報を張り替えている最中（コミット中に相当）は、他のアプリケーションがキャッシュ領域１００にアクセスしないよう、キャッシュ領域１００は、キャッシュマネージャ２００によりロックされる。
【００４５】
以上のように、本実施の形態２によれば、キャッシュマネージャ２００は、アプリケーション３００が被参照オブジェクトＢのクローンに対して行った変更をキャッシュ領域１００に反映して確定する際には、参照オブジェクト領域Ｂに格納されている参照オブジェクトＢの参照情報を、被参照オブジェクトＢのクローンに向けた参照情報に書き換えることにより、確定処理を実行する。
そのため、キャッシュ領域１００に対する反映を確定する処理が極めて短時間で終了するので、キャッシュ領域１００をロックする時間を短縮し、アプリケーションの同時アクセス性を高めることができる。
【００４６】
実施の形態３．
実施の形態２では、被参照オブジェクトＢのクローンに対して加えた変更をキャッシュ領域１００に反映して確定する手順を説明した。
本発明の実施の形態３では、先にオブジェクトがキャッシュ領域に格納されている場合において、そのオブジェクトに関連付けられた新たなオブジェクトを追加し、キャッシュ領域１００に反映して確定させる手順を説明する。なお、オブジェクトキャッシュに係る各構成は実施の形態１〜２と同様であるため、説明を省略する。
【００４７】
図６は、既存のエンティティＡに関連Ｂをもって新たなエンティティＣを関連付ける様子を、関連モデルで表したものである。
図６（ａ）はエンティティＣの追加前、図６（ｂ）はエンティティＣの追加後を表す。
次に、この関連モデル上の追加を、本実施の形態３に係るオブジェクトキャッシュ上で実施する手順について、図７〜図１０で説明する。
【００４８】
図７は、アプリケーション３００が、キャッシュ領域１００に格納されている被参照オブジェクトＡを取得する様子を示すものである。
キャッシュ領域１００には、図６のエンティティＡに対応した参照オブジェクトＡと被参照オブジェクトＡが格納されている。
アプリケーション３００は、これから関連ＢとエンティティＣに対応したオブジェクトＢとオブジェクトＣを生成するに際し、まずキャッシュ領域１００内のオブジェクトＡを取得する。取得の手順は、実施の形態１の図４（２）で説明したものと同様である。
キャッシュマネージャ２００は、被参照オブジェクトＡのクローンを生成するとともに、アプリケーション３００に、新たに生成した参照オブジェクトＡを返す。
アプリケーション３００は、受け取った参照オブジェクトＡを介して、被参照オブジェクトＡのクローンにアクセスすることができる。
【００４９】
図８は、アプリケーション３００が、新たに追加するオブジェクトＣと、関連を表す関連オブジェクトＢとを生成する様子を示すものである。
図６（ｂ）で説明した関連モデルは、図２（ｂ）で説明したように、オブジェクトＡとオブジェクトＣが関連オブジェクトＢで関連付けられることで、表現される。したがってアプリケーション３００は、図７の手順で取得した被参照オブジェクトＡのクローンに加え、新たにオブジェクトＢとオブジェクトＣを生成する。
【００５０】
このときアプリケーション３００は、本発明におけるオブジェクトの格納構造に準じ、オブジェクトＢとオブジェクトＣを、参照オブジェクトと被参照オブジェクトに分割して生成する。各参照オブジェクトは、それぞれが対応する被参照オブジェクトに向けた参照情報を保持する。
【００５１】
なお、単一のオブジェクトをキャッシュ領域１００に預けるときと同様に、被参照オブジェクトのみを生成してキャッシュマネージャ２００に預け、キャッシュマネージャ２００が参照オブジェクトを生成するようにしてもよい。
ここでは、説明の便宜上、アプリケーション３００側で被参照オブジェクトと参照オブジェクトの双方を生成することとする。
【００５２】
また、下記の参照関係は、参照先オブジェクトの識別キーを用いた論理上のみの参照として保持しておく。
（１）参照オブジェクトＢと被参照オブジェクトＡ／Ｃとの参照関係
（２）被参照オブジェクトＢと参照オブジェクトＡ／Ｃとの参照関係
【００５３】
上記（１）（２）の参照関係について、参照情報を保持させるのではなく、識別キーを用いた論理参照のみとするのは、これらのオブジェクトをキャッシュ領域１００に格納する際に、他のアプリケーションから参照情報を辿って各オブジェクトにアクセスさせないようにするためである。
【００５４】
図９は、アプリケーション３００が取得および生成した各オブジェクトを、キャッシュ領域１００に反映する様子を示すものである。
アプリケーション３００は、各オブジェクトをキャッシュ領域１００に反映するよう、キャッシュマネージャ２００に要求する。これは、データベースでいうところのコミット要求に相当する。
キャッシュマネージャ２００は、以下の手順で各オブジェクトをキャッシュ領域１００に反映する。
【００５５】
（１）キャッシュマネージャ２００は、参照／被参照オブジェクトＢと、参照／被参照オブジェクトＣを、キャッシュ領域１００のそれぞれの領域に格納する。
【００５６】
（２）キャッシュマネージャ２００は、先に参照オブジェクト領域１１０に格納されている参照オブジェクトＡの参照情報を、被参照オブジェクトＡのクローンに向けた参照情報に書き換える。
これにより、被参照オブジェクト領域１２０内の被参照オブジェクトＡは、被参照オブジェクトＡのクローンと論理的に置き換えられることになる。
【００５７】
（３）キャッシュマネージャ２００は、上述のステップ（１）〜（２）を実行している最中、参照オブジェクト領域１１０内の参照オブジェクトＡに、「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」フラグを保持させておく。
これは、この時点で参照オブジェクトＡにアクセスしても、「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」が発生する可能性がある、ということを他のアプリケーションに通知するためのフラグである。
同フラグを保持しているオブジェクトに対するアクセス要求を受け付けると、そのフラグの内容が返される。
【００５８】
図１０は、キャッシュ領域１００へ行った変更を確定する様子を示すものである。
キャッシュマネージャ２００は、図９の処理に続き、図１０に示す各処理を実行することで、キャッシュ領域１００に対して行った変更を確定する。以下、図１０の各ステップについて説明する。
【００５９】
（１）キャッシュマネージャ２００は、キャッシュ領域１００内の各オブジェクト同士のキー参照による論理参照を、参照情報を用いた直接参照に書き換える。
（２）キャッシュマネージャ２００は、上記の処理が終了すると、参照オブジェクト領域１１０内の参照オブジェクトＡに保持させている「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」フラグをクリアする。
【００６０】
（３）先に被参照オブジェクト領域１２０内に格納されていた被参照オブジェクトＡは、どのオブジェクトからも参照されなくなる。したがって、先に被参照オブジェクト領域１２０内に格納されていた被参照オブジェクトＡは、キャッシュ領域１００から削除される対象となり、後に自動削除される。
【００６１】
以上の手順により、先にキャッシュ領域１００に格納されたオブジェクトＡに加え、新たにオブジェクトＢとオブジェクトＣが追加され、図６（ｂ）で説明した関係モデルがキャッシュ領域１００上に反映される。
【００６２】
なお、「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」とは、アプリケーションが以前取得したオブジェクトを再度取得したとき、そのオブジェクトを別のアプリケーションが変更してキャッシュ領域１００に確定させたことにより、以前のオブジェクトではなく、新しいオブジェクトを取得してしまう状態を言う。
図９〜図１０の状態では、キャッシュマネージャ２００はキャッシュ領域１００への反映を確定させている最中（コミット中に相当）であるため、この状態で他のアプリケーションがキャッシュ領域１００にアクセスしても、再度アクセスした時は異なる内容になってしまっている。これは、「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」が発生し得る状態そのものであると言える。
【００６３】
以上のように、本実施の形態３によれば、アプリケーション３００は、先にキャッシュ領域１００に格納されているオブジェクトＡのクローンを取得し、新たにオブジェクトＣおよび関連オブジェクトＢを生成し、これらのオブジェクトをキャッシュ領域１００に格納するよう、キャッシュマネージャ２００に要求する。
この動作により、既存のキャッシュ領域１００内のオブジェクトに、任意の関連を追加することができる。
【００６４】
また、本実施の形態３によれば、キャッシュマネージャ２００は、キャッシュ領域１００内に各オブジェクトを格納した後、各オブジェクト同士のキー参照による論理参照を、参照情報を用いた直接参照に書き換える。
即ち、被参照オブジェクトＡ／Ｃに、参照オブジェクトＢに向けた参照情報を保持させるとともに、被参照オブジェクトＢに、参照オブジェクトＡ／Ｃに向けた参照情報を保持させる。
これにより、キャッシュ領域１００に対する変更を反映して確定している最中に、他のアプリケーションから変更中のオブジェクトに到達することがなくなり、データ一貫性が維持される。
【００６５】
また、本実施の形態３によれば、キャッシュマネージャ２００は、キャッシュ領域１００に対する変更を反映して確定している最中に、参照オブジェクト領域１１０内の参照オブジェクトに「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」フラグを保持させておき、他のアプリケーションから同オブジェクトに対するアクセスがあると、そのフラグの内容に応じた情報を返す。
これにより、他のアプリケーションは、キャッシュ領域１００が更新中であることが分かり、エラー処理を行ったり、一定時間待機したりするなど、適宜適切な対応を取ることができる。
【００６６】
実施の形態４．
実施の形態３では、新たにオブジェクトＣを生成して関連オブジェクトＢでオブジェクトＡと関連付け、キャッシュ領域１００に反映して確定する手順を説明した。
本発明の実施の形態４では、実施の形態３で追加したオブジェクトをキャッシュ領域１００から削除し、オブジェクト追加前の状態に戻す手順を説明する。なお、オブジェクトキャッシュに係る各構成は実施の形態１〜３と同様であるため、説明を省略する。
【００６７】
図１１は、キャッシュ領域１００内のオブジェクトＣを削除する最初のステップを示すものである。
アプリケーション３００は、キャッシュ領域１００内のオブジェクトＣを削除するようキャッシュマネージャ２００に要求する。
キャッシュマネージャ２００は、オブジェクトＡとオブジェクトＣを関連付けているオブジェクトＢのクローンを生成するとともに、対応する参照オブジェクトＢを生成し、アプリケーション３００に返す。この手順は、実施の形態１の図４（２）で説明したものと同様である。
【００６８】
図１２は、被参照オブジェクトＢのクローンをキャッシュ領域１００に反映するステップを示すものである。
アプリケーション３００は、図１１で取得した被参照オブジェクトＢのクローンをキャッシュ領域１００に反映させるよう、キャッシュマネージャ２００に要求する。
キャッシュマネージャ２００は、参照オブジェクト領域１１０に格納されている参照オブジェクトＢの参照情報を、被参照オブジェクトＢのクローンに向けた参照情報に書き換える。
これにより、被参照オブジェクト領域１２０内の被参照オブジェクトＢは、被参照オブジェクトＢのクローンと論理的に置き換えられることになる。
【００６９】
被参照オブジェクトＢのクローンは、参照オブジェクト領域１１０内の参照オブジェクトＡ／Ｃに対する参照情報を保持している。
また、クローンの元となった被参照オブジェクトＢも、参照オブジェクト領域１１０内の参照オブジェクトＡ／Ｃに対する参照情報を未だ保持している。
したがってこの時点で、参照オブジェクトＡ／Ｃは、被参照オブジェクトＢから参照されているため、キャッシュ領域１００から削除される対象にはなっていない。
【００７０】
なお、キャッシュマネージャ２００は、参照オブジェクト領域１１０内の参照オブジェクトＢに、「Ｐｈａｎｔｏｍ  ｒｅａｄ」フラグを保持させておく。
これは、この時点で参照オブジェクトＢにアクセスしても、「Ｐｈａｎｔｏｍ  ｒｅａｄ」が発生する可能性がある、ということを他のアプリケーションに通知するためのフラグである。「Ｐｈａｎｔｏｍ  ｒｅａｄ」の内容については、後述する。
同フラグを保持しているオブジェクトに対するアクセス要求を受け付けると、そのフラグの内容が返される。
【００７１】
図１３は、被参照オブジェクトＡ／Ｃから参照オブジェクトＢに向けた参照情報を削除するステップを示すものである。以下、図１３の各ステップについて説明する。
【００７２】
（１）キャッシュマネージャ２００は、被参照オブジェクトＡ／Ｃから参照オブジェクトＢに向けた参照情報を、削除する。また、被参照オブジェクトＢのクローンから被参照オブジェクトＡ／Ｃに向けた参照情報を削除する。
（２）一方、クローンの元となった被参照オブジェクトＢは、他のいずれのオブジェクトからも参照されていないため、キャッシュ領域１００からの削除対象となる。
【００７３】
図１４〜図１６は、削除対象の各オブジェクトがキャッシュ領域１００から順次削除されていく様子を示すものである。以下、各図について説明する。
なお、被参照オブジェクト領域１１０内の被参照オブジェクトＡは、図示しない他のオブジェクトから参照されており、削除対象にはならないものとする。
【００７４】
図１４では、クローンの元となった被参照オブジェクトＢがキャッシュ領域１００から削除されている。
また、参照オブジェクト領域１１０内の参照オブジェクトＢも、他のいずれのオブジェクトからも参照されなくなるため、キャッシュ領域１００からの削除対象となる。
さらには、アプリケーション３００がキャッシュマネージャ２００から受け取った参照オブジェクトＢは、アプリケーション３００の終了とともに削除される。
アプリケーション３００と参照オブジェクトＢが消滅することにより、被参照オブジェクトＢのクローンは他のいずれのオブジェクトからも参照されなくなり、後に削除される対象となる。
【００７５】
図１５では、参照オブジェクトＣと被参照オブジェクトＢのクローンがキャッシュ領域１００から削除されている。
また、被参照オブジェクトＣも、他のいずれのオブジェクトからも参照されなくなるため、後に削除対象となる。
【００７６】
図１６は、キャッシュ領域１００内の最終的な状態を指す。
最終的に、キャッシュ領域１００内には、図示しない他のオブジェクトから参照されている参照オブジェクトＡと、その参照オブジェクトＡから参照されている被参照オブジェクトＡが、削除対象とならずに残される。
【００７７】
以上の手順により、キャッシュ領域１００内の状態は、図７と同一の状態まで戻る。
これは、図６（ａ）で説明した関連モデルに相当する。
【００７８】
なお、「Ｐｈａｎｔｏｍ  ｒｅａｄ」とは、アプリケーションが以前取得したオブジェクトの集合を同じ条件で再度取得したとき、それらのオブジェクトを別のアプリケーションが変更してキャッシュ領域１００に確定させたことにより、同じ条件でオブジェクトの集合を取得しても、以前のオブジェクト集合が得られない状態を言う。
図１２〜図１３の状態では、キャッシュマネージャ２００が削除を行っている最中の参照オブジェクトＢに他のアプリケーションがアクセスしても、同オブジェクトはその後に削除されてしまうため、再度アクセスしても同じ結果が得られない可能性がある。
これは、「Ｐｈａｎｔｏｍ  ｒｅａｄ」が発生し得る状態そのものであると言える。
【００７９】
以上のように、本実施の形態４によれば、キャッシュマネージャ２００は、先にキャッシュ領域１００に格納されている関連オブジェクトＢのクローンを取得し、先に格納されている関連オブジェクトＢと論理的に入れ替える。
この動作により、関連オブジェクトＢのみから参照されているオブジェクトは、他のいずれのオブジェクトからも参照されなくなり、キャッシュ領域１００から削除される。
【００８０】
また、本実施の形態４によれば、キャッシュマネージャ２００は、参照オブジェクトＢに向けた参照情報を削除する。
これにより、関連オブジェクトＢ自身も、他のいずれのオブジェクトからも参照されなくなり、キャッシュ領域１００から削除される。
【００８１】
また、本実施の形態４によれば、キャッシュマネージャ２００は、オブジェクトＢ／Ｃの削除処理を行っている最中に、参照オブジェクト領域１１０内の参照オブジェクトＢに「Ｐｈａｎｔｏｍ  ｒｅａｄ」フラグを保持させておき、他のアプリケーションから同オブジェクトに対するアクセスがあると、そのフラグの内容に応じた情報を返す。
これにより、他のアプリケーションは、キャッシュ領域１００が更新中であることが分かり、エラー処理を行ったり、一定時間待機したりするなど、適宜適切な対応を取ることができる。
【００８２】
実施の形態５．
実施の形態１〜４では、各オブジェクトに対して行った変更／追加／削除などの処理をキャッシュ領域１００に反映して確定させる（コミットに相当）際に、キャッシュマネージャ２００は、キャッシュ領域１００をロックすることを説明した。
しかし、確定処理は瞬時に終了するとはいえ、キャッシュ領域１００全体をロックすると、キャッシュ領域１００内のオブジェクトに対する平行アクセス性が下がり、全体としてキャッシュのパフォーマンスが下がる可能性がある。
【００８３】
そこで、本発明の実施の形態５では、キャッシュ領域１００の一部のみをロックする手法について説明する。なお、オブジェクトキャッシュに係る各構成は実施の形態１〜４と同様であるため、説明を省略する。
【００８４】
図１７は、本実施の形態５におけるキャッシュ領域１００のロック範囲を説明するものである。
本実施の形態５において、キャッシュマネージャ２００は、キャッシュ領域１００に変更などを反映する際に、対象オブジェクトとその周辺のオブジェクトのみをロック対象とし、その他のオブジェクトは他のアプリケーションから平行してアクセスできるようにしておく。
【００８５】
本実施の形態５におけるロック範囲は、例えば以下のようにすることができる。
（１）変更対象オブジェクトと、そのオブジェクトから参照される下位オブジェクトとを全てロックする。したがって、ロック範囲は更新の度に異なる。
（２）キャッシュ領域１００内をあらかじめ複数の領域に固定的に分割しておき、その領域内のオブジェクトを更新するときは、該当する領域をロック範囲とする。
【００８６】
以上のように、本実施の形態５によれば、キャッシュマネージャ２００は、キャッシュ領域１００に格納している各オブジェクトに対して行った変更を確定させる際は、キャッシュ領域１００全体をロックするのではなく、一部の領域のみを限定的にロックする。
そのため、ロックされていない領域に格納されているオブジェクトに関しては、他のアプリケーションが同時平行してアクセスすることができるので、アプリケーションの同時実効性が上がり、オブジェクトキャッシュとしてのパフォーマンスが向上する。
【００８７】
実施の形態６．
本発明の実施の形態６では、キャッシュ領域１００に格納されているオブジェクトの参照関係を辿って複数のオブジェクトを取得する際に、その処理を高速化する手法について説明する。
まず、本発明に係るオブジェクトキャッシュ（実体はキャッシュ領域１００）から複数のオブジェクトを取得する際の原則的な動作を説明し、その後、本実施の形態６に係るオブジェクト取得動作を説明する。
なお、オブジェクトキャッシュに係る各構成は実施の形態１〜５と同様であるため、説明を省略する。
【００８８】
図１８は、キャッシュ領域１００から複数のオブジェクトを取得する際の原則的手順を説明するものである。以下、図１８の各ステップについて説明する。
【００８９】
（１）参照関係を辿っていく
アプリケーション３００は、被参照オブジェクトＢを取得するよう、キャッシュマネージャ２００に要求する。キャッシュマネージャ２００は、図４（２）と同様の手順で被参照オブジェクトＢのクローンを生成し、新たに生成した参照オブジェクトＢをアプリケーション３００に返す。
アプリケーション３００は、被参照オブジェクトＢのクローンが保持する参照情報を辿って、参照先オブジェクトが参照オブジェクトＣであることを知る。
【００９０】
（２）参照先オブジェクトを取得する
アプリケーション３００は、被参照オブジェクトＢのクローンの参照先である被参照オブジェクトＣを取得するよう、キャッシュマネージャ２００に要求する。キャッシュマネージャ２００は、（１）と同様の手順で被参照オブジェクトＣのクローンを生成し、新たに生成した参照オブジェクトＣをアプリケーション３００に返す。
【００９１】
以後、同様の手順を繰り返すことにより、アプリケーション３００は、キャッシュ領域１００に格納されている複数のオブジェクトを、参照情報を辿りながら順次取得することができる。
【００９２】
ここで、図１８（２）では、アプリケーション３００が被参照オブジェクトを取得する毎に、被参照オブジェクトのクローンが生成されることに着目する。
被参照オブジェクトのクローンを生成するのは、操作中の被参照オブジェクトに他のアプリケーションがアクセスしないようにするためであり、その目的に対して有効な効果を発揮するが、大量の被参照オブジェクトを取得する際には、この手法が不都合となる場合がある。
【００９３】
オブジェクトのクローンを生成する処理は、新たなオブジェクトを生成することに他ならないため、メモリ領域やＣＰＵリソースを一定量消費する。
大量のオブジェクトを取得する場合、これが積み重なり、全体として速度面のパフォーマンスが低下してしまう懸念がある。
【００９４】
そこで、本実施の形態６では、被参照オブジェクトのクローン生成は極力行わないようにし、参照情報を用いた直接参照を行いながら、複数のオブジェクトを取得する手順を説明する。
【００９５】
図１９は、本実施の形態６において、キャッシュ領域１００から複数のオブジェクトを取得する手順を説明するものである。以下、図１９の各ステップについて説明する。
【００９６】
（１）参照オブジェクトＢを取得する
アプリケーション３００は、被参照オブジェクトＢを取得するよう、キャッシュマネージャ２００に要求する。キャッシュマネージャ２００は、図４（２）や図１８（１）と同様の手順により、新たに生成した参照オブジェクトＢをアプリケーション３００に返す。
【００９７】
（２）エージェントを生成して送り込む
アプリケーション３００は、キャッシュ領域１００内のオブジェクトを収集するエージェントオブジェクトを生成し、参照オブジェクトＢ−＞被参照オブジェクトＢのクローンを介して、キャッシュ領域１００に送り込む。
エージェントオブジェクトを送り込む際の具体的な実装例としては、生成したエージェントオブジェクトを引数として、参照オブジェクト領域１１０内の参照オブジェクトＣのメソッドをコールする、という手法が考えられる。
以後、同様にエージェントオブジェクトを引数として参照先オブジェクトのメソッドを順次コールすることで、エージェントオブジェクトがキャッシュ領域１００内を循環し、各オブジェクトの属性値が収集される。
【００９８】
この手法は、図１８で説明した原則的な取得手順と比較すると、最初に被参照オブジェクトＢのクローンとエージェントオブジェクトを生成することを除いて、オブジェクト生成が行われないため、ＣＰＵ処理負荷やメモリ負荷の観点から、図１８の例と比較して格段に有利である。
したがって、アプリケーション３００が大量のオブジェクトを取得する際でも、速度面のパフォーマンスを低下させる懸念がない。
【００９９】
このような、相手方オブジェクトが保持していない機能（本実施の形態６ではオブジェクト収集機能）を有するオブジェクトを引き渡すことで、相手方オブジェクトに機能を追加する手法は、一般に「Ｖｉｓｉｔｏｒパターン」と呼ばれるデザインパターンとして知られている。
ただし、「Ｖｉｓｉｔｏｒパターン」は、一般的なオブジェクトデザイン手法について言及したものであり、汎用的に定義されたものであるのに対し、本発明では、オブジェクトの参照関係を利用したオブジェクト収集を行う点において、「Ｖｉｓｉｔｏｒパターン」一般とは異なる独自の手法であると言える。
【０１００】
図２０は、従来のキャッシュと本実施の形態６に係るオブジェクトキャッシュの、メモリ使用に関する差異点を比較して説明するものである。
図２０（ａ）は、従来のキャッシュにおけるメモリの使用状況を示す。従来のキャッシュでは、ある１つのオブジェクトを入口として、関連する全てのオブジェクトを取得する場合は、関連付けられている全てのオブジェクトをアプリケーション３００側にクローン生成する。
この場合、関連する全てのオブジェクトがインスタンス化されるため、アプリケーションのメモリ領域を圧迫する要因となっていた。
【０１０１】
図２０（ｂ）は、本実施の形態６に係るオブジェクトキャッシュのオブジェクト収集動作状況を示す。
図１９で説明したように、キャッシュ領域１００内の複数のオブジェクトを生成する際には、入口となるオブジェクトのクローンのみを生成し、これを入口としてエージェントオブジェクトを送り込むので、オブジェクトのクローンを大量に生成する必要がなく、メモリ使用量の観点からも有利である。
【０１０２】
以上のように、本実施の形態６では、キャッシュ領域１００内の複数のオブジェクトを取得する際は、入口となるオブジェクトを介してエージェントオブジェクトをキャッシュ領域１００内に送り込む。
この手法により、アクセス速度とメモリ使用量の双方の観点から、オブジェクトキャッシュのパフォーマンスを向上させることができる。
【０１０３】
実施の形態７．
実施の形態６では、エージェントオブジェクトを用いて、キャッシュ領域１００内のオブジェクトを高速に収集する手法について説明した。
本発明の実施の形態７では、エージェントオブジェクトの収集条件について、より具体的に説明する。
【０１０４】
エージェントオブジェクトが、キャッシュ領域１００内の全てのオブジェクトを取得する場合は、特段の措置は必要ないが、ある一定の条件に該当するオブジェクトのみを収集するような場合は、検索条件に相当する情報を、エージェントオブジェクトに渡す必要がある。
そこで、本実施の形態７では、エージェントオブジェクトの検索条件を定義したプロパティファイルを、キャッシュマネージャ２００の配下に渡しておくこととする。
このプロパティファイルには、以下の（１）（２）の情報を記述しておく。
【０１０５】
（１）収集対象オブジェクトのタイプ／ステレオタイプの少なくとも一方
収集対象オブジェクトのタイプ／ステレオタイプを指定して収集するとは、例えば以下のようなことを言う。
（１．１）収集対象オブジェクトのクラス型を、プロパティファイルに指定しておく。例えば、「Ａｃｃｏｕｎｔ」クラスとそのサブクラスのみを収集する、といったような使い方をする。
（１．２）＜＜ｃｏｎｔｒｏｌ＞＞ステレオタイプのオブジェクトのみを収集する、といったような使い方をする。
（１．３）上記の双方を収集条件に指定する。
【０１０６】
（２）エージェントオブジェクトの進行方向
進行方向を指定して収集するとは、オブジェクトの参照先が複数ある場合に、エージェントオブジェクトがいずれの方向に向かって進むかを指定しておくことである。
オブジェクトの参照関係は、キャッシュ領域１００にオブジェクトを預ける際に、アプリケーション３００側で把握しているため、これに基づき、いずれの方向に進んで収集を行うべきかを、アプリケーション３００の側から指定する。
【０１０７】
以上のように、本実施の形態７では、検索条件をプロパティファイルとしてエージェントプログラムから分離したことで、ひとつのエージェントで様々なパターンのデータ収集が可能になる。
【０１０８】
実施の形態８．
以上の実施の形態１〜７では、キャッシュマネージャ２００は、キャッシュ領域１００内のオブジェクトの参照情報を張り替えている最中などには、オブジェクトに「Ｎｏｎ−ｒｅｐｅａｔａｂｌｅ  ｒｅａｄ」フラグや「Ｐｈａｎｔｏｍ  ｒｅａｄ」フラグを保持させておくことを説明した。
アプリケーション３００がこれらのフラグの内容を取得した時、アプリケーション３００がどのように振舞うかは、そのときのトランザクションのポリシーなどによる。
【０１０９】
１つの実装例としては、アプリケーション３００とキャッシュマネージャ２００の間を接続するコネクションオブジェクトを生成し、このコネクションオブジェクトに、上述のようなフラグを受け取った際の振る舞いに関するポリシーをセットしておく、という手法が考えられる。
【０１１０】
実施の形態９．
以上の実施の形態１〜８では、本発明に係るオブジェクトキャッシュの実体は、キャッシュマネージャ２００とキャッシュ領域１００であることを説明した。
キャッシュマネージャ２００の実装形態としては、例えば以下のようなものが考えられる。
【０１１１】
（１）キャッシュマネージャ２００を、コンピュータ上で常時起動してアプリケーション３００からの要求を待ち受ける、サービスとして構成する。
（２）キャッシュマネージャ２００の機能を、クラスライブラリのような機能群として構成しておき、アプリケーション３００にこれを組み込んで、アプリケーション３００にこれと同等の機能を付与する。
【０１１２】
実施の形態１０．
以上の実施の形態１〜９では、オブジェクトキャッシュのアイソレーションレベルとして、「Ｒｅａｄ  Ｃｏｍｍｉｔｔｅｄ」を実現していることを説明したが、その他のアイソレーションレベルも、フラグを適切に設定することにより実現可能である。
【０１１３】
また、以上の実施の形態１〜９では、オブジェクトキャッシュを構築する方法として、キャッシュ領域１００のみならず、キャッシュマネージャ２００を介したオブジェクトの取得や変更などについても説明した。
これは、オブジェクトキャッシュは構築するのみでは用をなさず、格納したオブジェクトを取得や変更することが必須であるからである。
即ち、本発明に係る狭義のオブジェクトキャッシュとは、キャッシュ領域１００のことを指すが、本発明に係るオブジェクトキャッシュをより広義に捉えると、キャッシュ領域１００とキャッシュマネージャ２００の総体を指すものと言えるのである。
【図面の簡単な説明】
【０１１４】
【図１】実施の形態１に係るオブジェクトキャッシュの構成図である。
【図２】キャッシュ領域１００にオブジェクトを格納するイメージである。
【図３】アプリケーション３００が新たなオブジェクトＡをキャッシュ領域１００に預ける際の手順を説明するものである。
【図４】キャッシュ領域１００に格納されているオブジェクトにアクセスする際の手順を説明するものである。
【図５】アプリケーション３００が被参照オブジェクトＢのクローンに対して行った変更をキャッシュ領域１００に反映して確定させる手順を説明するものである。
【図６】既存のエンティティＡに関連Ｂをもって新たなエンティティＣを関連付ける様子を、関連モデルで表したものである。
【図７】アプリケーション３００が、キャッシュ領域１００に格納されている被参照オブジェクトＡを取得する様子を示すものである。
【図８】アプリケーション３００が、新たに追加するオブジェクトＣと、関連を表す関連オブジェクトＢとを生成する様子を示すものである。
【図９】アプリケーション３００が取得および生成した各オブジェクトを、キャッシュ領域１００に反映する様子を示すものである。
【図１０】キャッシュ領域１００へ行った変更を確定する様子を示すものである。
【図１１】キャッシュ領域１００内のオブジェクトＣを削除する最初のステップを示すものである。
【図１２】被参照オブジェクトＢのクローンをキャッシュ領域１００に反映するステップを示すものである。
【図１３】被参照オブジェクトＡ／Ｃから参照オブジェクトＢに向けた参照情報を削除するステップを示すものである。
【図１４】削除対象の各オブジェクトがキャッシュ領域１００から順次削除されていく様子を示すものである。
【図１５】削除対象の各オブジェクトがキャッシュ領域１００から順次削除されていく様子を示すものである。
【図１６】削除対象の各オブジェクトがキャッシュ領域１００から順次削除されていく様子を示すものである。
【図１７】実施の形態５におけるキャッシュ領域１００のロック範囲を説明するものである。
【図１８】キャッシュ領域１００から複数のオブジェクトを取得する際の原則的手順を説明するものである。
【図１９】実施の形態６において、キャッシュ領域１００から複数のオブジェクトを取得する手順を説明するものである。
【図２０】従来のキャッシュと実施の形態６に係るオブジェクトキャッシュの、メモリ使用に関する差異点を比較して説明するものである。
【符号の説明】
【０１１５】
１００  キャッシュ領域、１１０  参照オブジェクト領域、１２０  被参照オブジェクト領域、２００  キャッシュマネージャ、３００  アプリケーション。
【図１】
0005511134.tif 000002
【図２】
0005511134.tif 000003
【図３】
0005511134.tif 000004
【図４】
0005511134.tif 000005
【図５】
0005511134.tif 000006
【図６】
0005511134.tif 000007
【図７】
0005511134.tif 000008
【図８】
0005511134.tif 000009
【図９】
0005511134.tif 000010
【図１０】
0005511134.tif 000011
【図１１】
0005511134.tif 000012
【図１２】
0005511134.tif 000013
【図１３】
0005511134.tif 000014
【図１４】
0005511134.tif 000015
【図１５】
0005511134.tif 000016
【図１６】
0005511134.tif 000017
【図１７】
0005511134.tif 000018
【図１８】
0005511134.tif 000019
【図１９】
0005511134.tif 000020
【図２０】
0005511134.tif 000021