| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
TopLinkキャッシュは、クラスと主キーの値に基づいて最近読み取られたり書き込まれたオブジェクトが格納される、インメモリー・リポジトリです。TopLinkでは、次の目的でこのキャッシュが利用されます。
最近読み取られたり書き込まれたオブジェクトを保持し、メモリー内でそれらにアクセスしてデータベースへのアクセスを最小限にすることで、パフォーマンスを向上させます。
ロックと分離レベルを管理します。
オブジェクト・アイデンティティを管理します。
この章の内容は次のとおりです。
TopLinkでは、2種類のキャッシュが使用されます。セッション・キャッシュには、データ・ソースから取得されたオブジェクトやデータ・ソースに書き込まれたオブジェクトが保持され、作業ユニット・キャッシュには、トランザクションに参加しているオブジェクトが保持されます。作業ユニットがデータ・ソースに正常にコミットされると、それと同一の内容にセッション・キャッシュが更新されます。
図102-1に示すように、セッション・キャッシュと作業ユニット・キャッシュは、データ・ソース接続と連携して、TopLinkアプリケーションのオブジェクトを管理します。オブジェクトのライフ・サイクルは、この3つのメカニズムに依存しています。
セッション・キャッシュは、特定のセッションにアタッチされたクライアントに対してサービスを提供する共有キャッシュです。クライアント・セッションを使用してデータ・ソースに対してオブジェクトの読取りや書込みを行うと、親サーバー・セッションのキャッシュにオブジェクトのコピーが保存され、このコピーがセッション内のその他すべてのプロセスからアクセスできるようになります。
TopLinkでは、オブジェクトが次の場所からセッション・キャッシュに追加されます。
データ・ストア: 読取り操作が実行された場合
作業ユニット・キャッシュ: 作業ユニットがトランザクションを正常にコミットした場合
独立クライアント・セッションは、クライアント・セッションの特殊なタイプで、その親サーバー・セッションの共有オブジェクト・キャッシュから独立した独自のセッション・キャッシュを備えています。独立クライアント・セッション・キャッシュを使用すると、ユーザーごとのセキュリティの向上や、揮発性の高いデータのキャッシュの回避が可能です。詳細は、87.5項「独立クライアント・セッション」を参照してください。
この項では、TopLinkのキャッシュに固有の概念について説明します。この項の内容は次のとおりです。
TopLinkでは、そのキャッシュを介し、永続エンティティの主キー属性を使用して、オブジェクト・アイデンティティを管理します。これらの属性は、順序付けによって割り当てられる場合と割り当てられない場合があります（15.2.6項「プロジェクトおよび順序付け」を参照）。Javaアプリケーションでは、メモリー内の各オブジェクトが1つのみのオブジェクト・インスタンスによって表される場合にオブジェクト・アイデンティティが維持されます。同じオブジェクトの複数取得は、同一オブジェクトの複数コピーを返すのではなく、同一オブジェクト・インスタンスへの参照を返します。
アプリケーションのオブジェクト・モデルにオブジェクト間の循環参照が含まれる場合、オブジェクト・アイデンティティの保持はきわめて重要です。2つのオブジェクトが、それぞれのコピーではなく、相互を直接参照するようにしてください。オブジェクト・アイデンティティは、アプリケーションの複数の部分によって同じオブジェクトが同時に変更される場合に重要になります。
オブジェクト・アイデンティティは、常に保持することをお薦めします。オブジェクト・アイデンティティの無効化は、読取り専用オブジェクトの場合など、やむを得ない場合にかぎり、行ってください（119.3項「読取り専用ディスクリプタの構成」を参照）。
オブジェクト・アイデンティティをクラス単位でどのように管理するかを構成することができます。ClassDescriptorオブジェクトでは、表102-1で説明するキャッシュおよびアイデンティティ・マップのオプションが使用できます。
表102-1 キャッシュおよびアイデンティティ・マップのオプション
| オプション（アイデンティティ・マップ） | キャッシュ | アイデンティティの保証 | メモリー使用量 |
|---|---|---|---|
|
|
○ |
○ |
非常に多い |
|
|
○ |
○ |
少ない |
|
|
○ |
○ |
多い |
|
ソフト・キャッシュ弱アイデンティティ・マップおよびハード・キャッシュ弱アイデンティティ・マップ |
○ |
○ |
中程度 |
|
|
× |
× |
なし |
詳細は、102.2.1.6項「キャッシュおよびアイデンティティ・マップの構成のガイドライン」を参照してください。
このオプションでは、完全なキャッシュとアイデンティティの保証を行います。オブジェクトは、実際に削除されるまでメモリーからフラッシュされません。
すべてのオブジェクトがキャッシュされ、キャッシュから削除されることはありません。キャッシュ・サイズは、最大サイズに達すると2倍まで許容されます。この方法を使用すると、多くのオブジェクトが読み取られる場合、メモリーの負荷が高くなることがあります。このオプションはバッチ操作には使用しないでください。
このアイデンティティ・マップは、データ・セットのサイズが小さく、メモリーの容量が大きい場合に使用することをお薦めします。
このオプションは完全アイデンティティ・マップの類似マップですが、相違点は、このマップでは弱参照を使用してオブジェクトを保持することです。この方法では、完全なガベージ・コレクションを許可し、完全なキャッシュとアイデンティティの保証を行います。
弱アイデンティティ・マップでは、使用するメモリーが完全アイデンティティ・マップより少ないかわりに、クライアント/サーバー・トランザクション全体にわたる永続キャッシュ方法も使用しません。オブジェクトは、サーバー側（つまり、サーバーJVM内）でアプリケーションによって参照されなくなると、ガベージ・コレクションの対象になります。
このオプションは弱アイデンティティ・マップの類似マップですが、相違点は、このマップでは弱参照ではなくソフト参照を使用することです。この方法では、完全なガベージ・コレクションを許可し、完全なキャッシュとアイデンティティの保証を行います。
ソフト・アイデンティティ・マップではオブジェクトのキャッシュを最適化でき、メモリー残量が少ない場合はJVMでオブジェクトのガベージ・コレクションを行うことも可能です。
これらのオプションは弱アイデンティティ・マップの類似マップですが、相違点は、これらのマップでは最も頻繁に使用されるサブキャッシュを保持することです。サブキャッシュでは、ソフトまたはハード参照を使用して、システムのメモリー残量が少ない場合にのみオブジェクトがガベージ・コレクションされるようにします。
ソフト・キャッシュ弱アイデンティティ・マップとハード・キャッシュ弱アイデンティティ・マップでは、より効率よくメモリーを使用します。これらのマップでは、ガベージ・コレクションされたオブジェクトを解放します（最近使用された一定数のオブジェクトは除く）。弱参照でキャッシュされたオブジェクトは、トランザクションが複数のクライアント/サーバー起動にわたって使用される場合、フラッシュされる可能性があることに注意してください。サブキャッシュのサイズは、ClassDescriptorメソッドsetIdentityMapSizeで指定されるアイデンティティ・マップのサイズに比例します。このキャッシュ・サイズは、トランザクションで参照される（同じタイプの）オブジェクトの最大数にしてください（119.12項「ディスクリプタ・レベルでのキャッシュ・タイプとサイズの構成」を参照）。
このアイデンティティ・マップは、キャッシュで使用されるメモリーを制御する手段として、ほとんどの場合に使用をお薦めします。
詳細は、102.2.1.7項「ソフト/ハード弱アイデンティティ・マップの内部について」を参照してください。
このオプションでは、オブジェクト・アイデンティティは保持されず、オブジェクトはキャッシュされません。
アイデンティティ・マップなしオプションの使用はお薦めしません。かわりに、キャッシュの無効化および独立キャッシュという代替手段を確認してください。
キャッシュの構成は、プロジェクト・レベル（117.10項「プロジェクト・レベルでのキャッシュ・タイプとサイズの構成」を参照）またはディスクリプタ・レベル（119.12項「ディスクリプタ・レベルでのキャッシュ・タイプとサイズの構成」を参照）で行うことができます。
キャッシュおよびアイデンティティ・マップの構成時には、次のガイドラインに従ってください。
存続期間の長いオブジェクトを使用していて、オブジェクト・アイデンティティが重要な場合は、SoftIdentityMap、SoftCacheWeakIdentityMapまたはHardCacheWeakIdentityMapポリシーを使用します。いずれかを選択するタイミングの詳細は、102.2.1.7項「ソフト/ハード弱アイデンティティ・マップの内部について」を参照してください。
オブジェクト・アイデンティティは重要だがキャッシュは重要でない場合は、WeakIdentityMapポリシーを使用します。
オブジェクトの存続期間が長い、オブジェクトが頻繁なアクセスを必要とする、またはオブジェクト・アイデンティティが重要な場合は、FullIdentityMapポリシーを使用します。
|
警告:
|
オブジェクトの存続期間が短いか、またはオブジェクトが頻繁なアクセスを必要とし、かつアイデンティティが重要でない場合は、CacheIdentityMapポリシーを使用します。
オブジェクトがデータベースからの読取り後すぐに破棄される場合は（バッチ操作など）、NoIdentityMapポリシーを使用します。NoIdentityMapでは、オブジェクト・アイデンティティは保持されません。
|
注意: CacheIdentityMapおよびNoIdentityMapポリシーの使用は避けることをお薦めします。 |
WeakIdentiyMapおよびSoftIdentityMapでは、JVM弱およびソフト参照を使用して、アプリケーションによって参照されるオブジェクトがキャッシュ内に保持されるようにします。アプリケーションでオブジェクト参照を解除すると、JVMでは自由にオブジェクトのガベージ・コレクションを実行します。弱およびソフト参照がガベージ・コレクションされるタイミングは、JVMによって決定されます。通常、各JVMガベージ・コレクタで弱参照がガベージ・コレクションされ、JVMによりメモリー残量が少ないと判断された場合、ソフト参照がガベージ・コレクションされることを想定しています。
SoftCacheWeakIdentityMapおよびHardCacheWeakIdentityMapタイプのアイデンティティ・マップでは、次の2つのキャッシュが使用されます。
参照キャッシュ: それぞれソフトまたはハード参照を含めたLinkedListとして実装されるキャッシュ
弱キャッシュ: 弱参照を含めたHashMapとして実装されるキャッシュ
サイズを指定してSoftCacheWeakIdentityMapまたはHardCacheWeakIdentityMapを作成すると、参照キャッシュLinkedListは正確にそのサイズに等しくなります。弱キャッシュHashMapは、指定サイズの100パーセントに初期化されます。弱キャッシュは、指定サイズより多くのオブジェクトが読み取られると、サイズが大きくなります。TopLinkではガベージ・コレクションは制御しないため、JVMは、適切と判断した場合はいつでも、弱参照で保持されたオブジェクトを取得できます。
参照キャッシュはLinkedListとして実装されるので、新しいオブジェクトはこのリストの末尾に追加されます。このため、必然的に最低使用頻度（LRU）キャッシュになります。サイズは固定であり、最大サイズに達すると、リストの上位のオブジェクトが削除されます。
SoftCacheWeakIdentityMapおよびHardCacheWeakIdentityMapは、基本的に同じタイプのアイデンティティ・マップであり、前者は後者のサブクラスです。HardCacheWeakIdentityMapは、一部のJVMでの問題を回避するために構成されました。SoftCacheWeakIdentityMapは、この機能を継承しています。
アプリケーションを実行しているシステムでメモリー不足の状態が頻繁に発生する場合や、プラットフォームのJVMで弱い参照とソフト参照が同様に扱われる場合には、参照キャッシュ内のオブジェクトのガベージ・コレクションが頻繁に行われるため、参照キャッシュによるパフォーマンス向上の利点は得られません。この場合、HardCacheWeakIdentityMapの使用をお薦めします。これはSoftCacheWeakIdentityMapと同じですが、参照キャッシュでハード参照を使用する点が異なります。そうすることで、アプリケーションは参照キャッシュによるパフォーマンス向上の利点を確実に得ることができます。
HardCacheWeakIdentityMapまたはSoftCacheWeakIdentityMap内のオブジェクトは、参照キャッシュから削除されると、弱キャッシュに格納されます。このオブジェクトは引き続きキャッシュされていますが、JVMは弱参照をガベージ・コレクションすることを随時決定できるため、どれくらいの間キャッシュに保持されるかはTopLinkでは保証できません。
共有セッション・キャッシュに対して実行される問合せは、インメモリー問合せと呼ばれます。インメモリー問合せを綿密に構成すると、パフォーマンスを向上できます（108.16.2項「インメモリー問合せの使用方法」を参照）。
デフォルトでは、主キーに基づいてシングル・オブジェクトを検索する問合せは、必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみ、データ・ソースで検索を行います。その他すべての問合せタイプの場合は、デフォルトでデータベースを最初に検索します。特定の問合せをインメモリー・キャッシュまたはデータベース、あるいはその両方に対して実行するよう指定できます。
詳細は、108.16項「問合せとキャッシュ」を参照してください。
失効したデータは、データ・ソースにコミットされた最新バージョンでないオブジェクトをキャッシュした結果として発生します。失効したデータの発生を防止するには、適切なキャッシュ・ロック方法を実装します。
TopLinkでは、デフォルトで、読取りまたは書込み操作中のキャッシュ・ロックを最小限に抑えるために同時実行性が最適化されます。非常に明確な理由があって変更する場合を除き、TopLinkの分離レベルはデフォルトのまま使用してください。TopLinkの分離レベルの詳細は、102.2.7項「キャッシュの分離」を参照してください。
キャッシュ・ロックにより、プロセスがオブジェクトを読み取る、または書き込むタイミングを制御します。キャッシュ・ロックの構成に応じて、別のプロセス内で使用されているオブジェクトの読取りまたは書込みが可能かどうかが決まります。
キャッシュを適切に管理すると、アプリケーションの効率が高まります。キャッシュはデータベース・アクセスを減少させ、オブジェクト・アイデンティティの管理の重要な部分を占めるため、キャッシュを完全にオフにすることはほとんどありません。
キャッシュを最大限に活用し、失効したデータがアプリケーションに使用されることを最小限に抑えるために、次のことをお薦めします。
ロック・ポリシーを構成しておくことで、変更中のオブジェクトの値が変更されるのを防止するか、または少なくとも変更された時間を識別することができます。これは通常、オプティミスティック・ロックを使用して行います。TopLinkでは、数値バージョン・フィールド、タイムスタンプ・バージョン・フィールド、一部のフィールド、すべてのフィールドなど、複数のロック・ポリシーでロックできます。
詳細は、119.26項「ロック・ポリシーの構成」を参照してください。
特定のクラスで使用するデータを他のアプリケーションが変更できる場合、そのクラスには弱いスタイルのキャッシュを使用します。たとえば、SoftCacheWeakIdentityMapまたはWeakIdentityMapを指定すると、参照対象として削除されたオブジェクトをキャッシュが保持する期間は最も短くなります。
詳細は、119.12項「ディスクリプタ・レベルでのキャッシュ・タイプとサイズの構成」を参照してください。
すべての問合せには、選択したオブジェクトの最新バージョンをデータ・ソースで検索し、その情報でキャッシュを更新することをTopLinkに強制するフラグを含めることができます。
詳細は、次を参照してください。
ディスクリプタAPIを使用すると、オブジェクトを無効として設定できます。すなわち、問合せで無効オブジェクトを読み取ろうとすると、TopLinkではデータ・ソースでそのオブジェクトの最新バージョンが検索され、その情報でキャッシュが更新されます。オブジェクトを無効として設定するには、手動で行うか、または、CacheInvalidationPolicyを使用して無効となる条件を設定します。
詳細は、102.2.5項「キャッシュの無効化」を参照してください。
アプリケーションが読取り中心で、変更がすべて、複数の分散セッションで実行されている同一Javaアプリケーションによって行われる場合は、TopLinkのキャッシュ・コーディネーション機能の使用が有効なことがあります。これは、データの失効は防止しませんが、できるかぎり最小限に抑えます。
詳細は、102.2.6項「キャッシュ・コーディネーション」を参照してください。
分散システムの中には、システム内のサーバー全体で少数のオブジェクトのみが一貫していればよいものがあります。逆に、いくつかの特定のオブジェクトが、負荷に関係なく、常に最新の状態であることを求めるシステムもあります。そのようなシステムを構築する場合は、分散キャッシュ・コーディネーションを行うほどの負荷をかけずに、データベースから選択したオブジェクトを適切な間隔で明示的にリフレッシュすることができます。
このタイプの方法を実装するには、次の手順を実行します。
必要なオブジェクトをリフレッシュする一連の問合せを構成します。
適切なリフレッシュ・ポリシーを設定します。
必要に応じて問合せを起動し、オブジェクトをリフレッシュします。
問合せを実行すると、必要なオブジェクトがキャッシュ内に存在する場合は、より新しいバージョンがないかどうかデータベースをチェックすることなく、キャッシュされたオブジェクトが返されます。これにより、データベースの結果から作成する必要のあるオブジェクトの数が減るため、この方法はコーディネートされていないキャッシュ環境に最適です。ただし、コーディネートされたキャッシュ環境では必ずしも最善の方法ではありません。
この動作をオーバーライドするには、データベースのオブジェクトがキャッシュ内のオブジェクトよりも常に優先されることを示すリフレッシュ・ポリシーを設定します。この場合、キャッシュされたオブジェクトがデータベースのデータで更新されます。
このタイプのリフレッシュ・ポリシーは、アプリケーションの特性に応じて、TopLinkの各ディスクリプタに実装することも、特定の問合せのみに実装することもできます。
詳細は、次を参照してください。
デフォルトでは、オブジェクトは明示的に削除されるまで（114.7項「オブジェクトの削除」を参照）、または弱アイデンティティ・マップの使用時はガベージ・コレクションされるまで、セッション・キャッシュに保持されます（117.10項「プロジェクト・レベルでのキャッシュ・タイプとサイズの構成」を参照）。
あるいは、キャッシュされたオブジェクトが無効となる条件を、CacheInvalidationPolicyにより自動または手動でオブジェクトに構成できます。これにより、問合せで無効オブジェクトを読み取ろうとすると、TopLinkではデータ・ソースでそのオブジェクトの最新バージョンを検索し、その情報でキャッシュを更新します。
次のいずれかのCacheInvalidationPolicyインスタンスを使用できます。
DailyCacheInvalidationPolicy: 毎日指定の時間に無効フラグがオブジェクトに自動的に設定されます。
NoExpiryCacheInvalidationPolicy: oracle.toplink.sessions.IdentityMapAccessorメソッドinvalidateObjectを明示的にコールした場合にのみ、オブジェクトに無効フラグを設定できます。
TimeToLiveCacheInvalidationPolicy: オブジェクトの読取りから指定時間が経過した後に、無効フラグがオブジェクトに自動的に設定されます。
キャッシュの無効化ポリシーは次のレベルで構成できます。
すべてのオブジェクトに適用されるプロジェクト・レベル（117.13項「プロジェクト・レベルでのキャッシュの有効期限の構成」を参照）
プロジェクト・レベルの構成をオブジェクト単位でオーバーライドするディスクリプタ・レベル（119.16項「ディスクリプタ・レベルでのキャッシュ有効期限の構成」を参照）
問合せで返された結果に適用される問合せレベル（111.13.2項「問合せレベルにおけるキャッシュの有効期限の構成方法」を参照）
結果を独自の内部キャッシュにキャッシュするように問合せを構成すると（108.16.7項「問合せキャッシュへの問合せ結果のキャッシュ方法」を参照）、問合せレベルで構成するキャッシュの無効化ポリシーは、セッション・キャッシュに適用されるのと同様の方法で、問合せの内部キャッシュに適用されます。
コーディネート・キャッシュを使用している場合は（102.2.6項「キャッシュ・コーディネーション」を参照）、オブジェクトに無効フラグが設定されていることを通知する方法をカスタマイズできます。詳細は、119.15項「ディスクリプタ・レベルでのキャッシュ・コーディネーション変更伝播の構成」を参照してください。
すべてのアプリケーションのデータを最新の状態に維持する必要性は、分散アプリケーションを構築する際の設計上の大きな課題です。環境内のサーバー数が増加するにつれて、この課題の難しさも増していきます。TopLinkには、分散アプリケーションのデータを最新の状態に維持する、分散キャッシュ・コーディネーション機能が用意されています。
キャッシュ・コーディネーションにより、分散アーキテクチャで発生するオプティミスティック・ロック例外の数は減少し、アプリケーションで失敗するトランザクションや繰り返されるトランザクションの数も減少します。とはいえ、キャッシュ・コーディネーションを行っても、効果的なロック・ポリシーが不要になることはありません。最新データが効率的に使用できるように、キャッシュ・コーディネーションはオプティミスティックまたはペシミスティック・ロックとともに使用する必要があります。キャッシュ・コーディネーションをオプティミスティック・ロック・ポリシーとともに使用することをお薦めします（119.26項「ロック・ポリシーの構成」を参照）。
キャッシュの無効化を使用すると、キャッシュ・コーディネーションが高速になります。詳細は、102.2.5項「キャッシュの無効化」を参照してください。
詳細は、102.3項「キャッシュ・コーディネーション」を参照してください。
独立クライアント・セッションには、共有サーバー・セッション・キャッシュを無効化するメカニズムがあります。独立クラスとしてマークされたクラスは、すべてクライアント・セッションのライフ・サイクルを基準としてオブジェクトをキャッシュします。これらのクラスは、共有サーバー・セッション・キャッシュを使用しません。このメカニズムでは、キャッシュを一部のクラスに許可し、一部のクラスに禁止するようクラス単位で構成できるため、キャッシュを抑制するのに最適です。
詳細は、87.5項「独立クライアント・セッション」を参照してください。
TopLinkでは、デフォルトで、読取りまたは書込み操作中のキャッシュ・ロックを最小限に抑えるために同時実行性が最適化されます。非常に明確な理由があって変更する場合を除き、TopLinkのトランザクション分離構成はデフォルトのまま使用してください。
詳細は、115.15項「データベース・トランザクション分離レベル」を参照してください。
TopLinkキャッシュをクラスごとにチューニングすると、分散キャッシュ・コーディネーションが不要になります。この設定のチューニングは、キャッシュ・コーディネーションを実装する前に必ず行ってください。
詳細は、12.10項「キャッシュの最適化」を参照してください。
図102-2に示すように、キャッシュ・コーディネーションは、セッションの複数のインスタンス（大部分の場合、分散されている）が相互にオブジェクト変更をブロードキャストできるようにするセッション機能であり、これにより、各セッションのキャッシュは、最新の状態に保たれるか、次回読み取るデータ・ソースを基にオブジェクトを更新する必要があることを通知されます。
セッションが分散されている場合、つまり、アプリケーションに複数のセッションが含まれている場合（同一JVM内、複数JVM内、あるいは複数サーバー上）、セッションをホスティングしているサーバーがネットワーク上で相互接続されているかぎり、セッションはキャッシュ・コーディネーションに参加できます。検出サービスを必要とするタイプのコーディネート・キャッシュでは、サーバーでユーザー・データグラム・プロトコル（UDP）通信およびマルチキャスト構成がサポートされることも必要です（詳細は、102.3.2項「コーディネート・キャッシュのアーキテクチャ」を参照してください）。
この項の内容は次のとおりです。
詳細は、第103章「コーディネート・キャッシュの構成」を参照してください。
キャッシュ・コーディネーションにより、パフォーマンスが向上し、次の特性を持つアプリケーションに対して失効データが発生する可能性が低下します。
変更はすべて、複数の分散セッションで実行されている同一Javaアプリケーションにより実行されます。
読取り中心です。
同一オブジェクトを定期的にリクエストおよび更新します。
これらの特性を持たないアプリケーションでは、パフォーマンスを最大化するため、キャッシュ・コーディネーションを使用しないでください。キャッシュ・コーディネーションにとってかわる機能としては、12.10項「キャッシュの最適化」を参照してください。
キャッシュ・コーディネーションでは、主にデータ・ソースへのアクセスを回避することでパフォーマンスが向上します。
キャッシュ・コーディネーションでは、分散キャッシュが変更を反映して最新の状態に維持される頻度と、次回読み取るデータ・ソースを基にオブジェクトを分散キャッシュの1つが更新するタイミングを通知される頻度を増加させることで、失効データの発生を削減します。
キャッシュ・コーディネーションにより、分散アーキテクチャで発生するオプティミスティック・ロック例外の数は減少し、アプリケーションで失敗するトランザクションや繰り返されるトランザクションの数も減少します。とはいえ、キャッシュ・コーディネーションを行っても、効果的なロック・ポリシーが不要になることはありません。最新データが効率的に使用できるように、キャッシュ・コーディネーションはオプティミスティックまたはペシミスティック・ロックとともに使用する必要があります。キャッシュ・コーディネーションをオプティミスティック・ロック・ポリシーとともに使用することをお薦めします（119.26項「ロック・ポリシーの構成」を参照）。
失効データの発生頻度を削減する他のオプションについては、102.2.3項「失効したデータの処理」を参照してください。
TopLinkには、次のような各種テクノロジを使用して、検出およびメッセージ・トランスポート・サービスを実行する、コーディネート・キャッシュ実装が用意されています。
Java Message Service（JMS）: 102.3.3.1項「JMSコーディネート・キャッシュ」を参照
Remote Method Invocation（RMI）:102.3.3.2項「RMIコーディネート・キャッシュ」を参照
Common Object Request Broker Architecture（CORBA）: 102.3.3.3項「CORBAコーディネート・キャッシュ」を参照
使用する検出およびメッセージ・トランスポートのタイプを問わず、コーディネート・キャッシュ機能がある主要オブジェクトは次のとおりです。
セッションでは、変更の伝播が有効な場合、JMS、RMI、CORBAまたはOracle Application Serverクラスタを使用した検出およびメッセージ・トランスポート・サービスが提供されます。
検出サービスにより、セッションがキャッシュ・コーディネーションに参加している他のセッションに参加を通知するようになります。検出サービスでは、セッションがコーディネート・キャッシュに加わるとき、およびキャッシュを離れるときに、UDP通信およびマルチキャスト構成を使用してそのセッションを監視します。検出サービスは、JMSを除くすべてのコーディネート・キャッシュ・タイプにおいて必須です。
セッションの作業ユニットが変更をコミットする際、このセッションは、メッセージ・トランスポート・サービスにより、キャッシュ・コーディネーションに参加している他のセッションにオブジェクト変更通知をブロードキャストできます。
オブジェクト変更をディスクリプタ単位でどのようにブロードキャストするかを構成することができます。これにより、行う通知のタイプを微調整できます。
たとえば、属性がわずかなオブジェクトに対しては、オブジェクト変更を送信するようにそのディスクリプタを構成できます。属性の多いオブジェクトに対しては、オブジェクトに無効フラグが設定されるように（つまり、次回読み取るデータ・ソースを基にオブジェクトを更新する必要があることを他のセッションが認識するように）そのディスクリプタを構成する方が効率的な場合があります。
キャッシュ・コーディネーションを有効にすると、作業ユニットによりコミットされた変更のみが伝播されます。作業ユニットでは、影響を受けるオブジェクトのディスクリプタ構成に基づいて適切なチェンジ・セットを計算します。
次のタイプのコーディネート・キャッシュを作成できます。
JMSコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身のJNDIネーミング・サービス情報を使用してJMSサーバーへの接続を検索および作成します。すべての参加セッションが同一JMSサーバー上の同一トピックに接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、同一JMSおよびJNDIネーミング・サービス情報を使用して、同一コーディネート・キャッシュに参加しているすべてのセッションを構成できます。
JMSトピックへの接続に必要な情報は手動で指定する必要があるため、JMSコーディネート・キャッシュでは検出サービスは使用しません。
キャッシュ・コーディネーションを使用する場合は、JMSキャッシュ・コーディネーションを使用することをお薦めします。JMSは、堅牢で構成しやすく、非同期の変更伝播を高速で行うことができます。
詳細は、第104章「JMSコーディネート・キャッシュの構成」を参照してください。
JMS構成の詳細は、『Oracle Fusion Middleware Services Guide for Oracle Containers for Java EE』を参照してください。
RMIコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身の接続をそのネーミング・サービス（RMIレジストリまたはJNDI）にバインドし、通知メッセージ（そのセッション自身のネーミング・サービス情報を含む）を作成し、この通知メッセージをそのマルチキャスト・グループにブロードキャストします（103.4項「マルチキャスト・グループ・アドレスの構成」および103.5項「マルチキャスト・ポートの構成」を参照）。同一マルチキャスト・グループに属するセッションは、この通知を受信すると、通知メッセージ内のネーミング・サービス情報を使用して、新たに通知されたセッションのコーディネート・キャッシュとの双方向接続を確立します。すべての参加セッションがこの方法で相互接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、セッションがデプロイされているホストを識別するネーミング情報を使用して、各セッションを構成できます。
キャッシュ・コーディネーションを使用する場合は、同期変更伝播が必要な場合のみ、RMIキャッシュ・コーディネーションの使用をお薦めします（103.2項「同期変更伝播モードの構成」を参照）。
TopLinkでは、RMI over IIOP（Internet Inter-ORB Protocol）を使用したキャッシュ・コーディネーションもサポートしています。RMI/IIOPコーディネート・キャッシュでは、検出およびメッセージ・トランスポート・サービスにRMI（およびJNDIネーミング・サービス）を使用します。
|
注意: RMIコーディネート・キャッシュを使用する場合は、やむを得ない場合にかぎり、RMI/IIOPを使用することをお薦めします。 |
詳細は、第105章「RMIコーディネート・キャッシュの構成」を参照してください。
CORBAコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身の接続をJNDIにバインドし、通知メッセージ（そのセッション自身のJNDIネーミング・サービス情報を含む）を作成し、この通知メッセージをそのマルチキャスト・グループにブロードキャストします（103.4項「マルチキャスト・グループ・アドレスの構成」および103.5項「マルチキャスト・ポートの構成」を参照）。同一マルチキャスト・グループに属するセッションは、この通知を受信すると、通知メッセージ内のネーミング・サービス情報を使用して、新たに通知されたセッションのコーディネート・キャッシュとの双方向接続を確立します。すべての参加セッションがこの方法で相互接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、セッションがデプロイされているホストを識別するネーミング情報を使用して、各セッションを構成できます。
現在、TopLinkではSun社のオブジェクト・リクエスト・ブローカをサポートしています。
CORBAコーディネート・キャッシュの構成の詳細は、第106章「CORBAコーディネート・キャッシュの構成」を参照してください。
oracle.toplink.remotecommandパッケージのクラスを使用すると、カスタム・ソリューション用の独自のコーディネート・キャッシュを定義できます。詳細は、TopLinkのサポート担当者にお問い合せください。
必須のキャッシュ・コーディネーション・クラスを作成した後でユーザー定義コーディネート・キャッシュを構成する方法の詳細は、第107章「カスタム・コーディネート・キャッシュの構成」を参照してください。
TopLinkのキャッシュを構成するには、次のオブジェクトの適切なAPIを使用します。
オブジェクト・アイデンティティは、例102-1に示すClassDescriptor APIを使用して構成します。
詳細は、119.12項「ディスクリプタ・レベルでのキャッシュ・タイプとサイズの構成」を参照してください。
キャッシュ・リフレッシュは、例102-2に示すClassDescriptor APIを使用して構成します。
例102-2 キャッシュ・リフレッシュのClassDescriptor API
alwaysRefreshCache alwaysRefreshCacheOnRemote disableCacheHits disableCacheHitsOnRemote onlyRefreshCacheIfNewerVersion
キャッシュ・リフレッシュは、次のAPIコールを使用して構成することもできます。
Session: refreshObjectメソッド
DatabaseSessionおよびUnitOfWork: refreshAndLockObjectメソッド
ObjectLevelReadQuery: refreshIdentityMapResultおよびrefreshRemoteIdentityMapResultメソッド
詳細は、119.9項「キャッシュ・リフレッシュ機能の構成」を参照してください。
キャッシュの無効化を構成するには、ClassDescriptorメソッドgetCacheInvalidationPolicyおよびsetCacheInvalidationPolicyを使用してoracle.toplink.descriptors.invalidation.CacheInvalidationPolicyを構成します。
次のいずれかのCacheInvalidationPolicyインスタンスを使用できます。
DailyCacheInvalidationPolicy: 毎日指定の時間に無効フラグがオブジェクトに自動的に設定されます。
NoExpiryCacheInvalidationPolicy: oracle.toplink.sessions.IdentityMapAccessorメソッドinvalidateObjectを明示的にコールした場合にのみ、オブジェクトに無効フラグを設定できます。
TimeToLiveCacheInvalidationPolicy: オブジェクトの読取りから指定時間が経過した後に、無効フラグがオブジェクトに自動的に設定されます。
キャッシュの無効化は、Sessionを通じてアクセスできる様々なAPIコールを使用して構成することもできます。oracle.toplink.sessions.IdentityMapAccessorでは、次のメソッドを提供しています。
getRemainingValidTime: 指定したオブジェクトの残りの存続期間を返します。この期間は、オブジェクトの次の失効時間とその読取り時間の差異を表します。
invalidateAll: TopLinkアイデンティティ・マップですべてのクラスのすべてのオブジェクトを無効化するよう設定します。
invalidateClass(Class klass)およびinvalidateClass(Class klass, boolean recurse): TopLinkアイデンティティ・マップで特定のクラスのすべてのオブジェクトを無効化するよう設定します。
invalidateObject(Object object)、invalidateObject(Record rowWithPrimaryKey, Class klass)およびinvalidateObject(Vector primaryKey, Class klass): TopLinkアイデンティティ・マップで1つのオブジェクトを無効化するよう設定します。
invalidateObjects(Expression selectionCriteria)およびinvalidateObjects(Vector collection): TopLinkアイデンティティ・マップで特定の式（コレクション）に基づくすべてのオブジェクトを無効化するよう設定します。
isValid(Record recordContainingPrimaryKey, Class theClass)、isValid(Object object)およびisValid(java.util.Vector primaryKey, Class theClass): TopLinkアイデンティティ・マップでオブジェクトが有効の場合にtrueを返します。
詳細は、次を参照してください。
キャッシュ・コーディネーションは、例102-3に示すSessionメソッドを使用して構成します。
オブジェクト変更が伝播される方法は、例102-4に示すClassDescriptorメソッドを使用して構成します。
詳細は、103.1項「共通コーディネート・キャッシュ・オプションの構成」を参照してください。
例102-3 キャッシュ・コーディネーションのセッションAPI
Session.getCommandManager().
setShouldPropagateAsynchronously(boolean)
Session.getCommandManager().getDiscoveryManager().
setAnnouncementDelay()
setMulticastGroupAddress()
setMulticastPort()
setPacketTimeToLive()
Session.getCommandManager().getTransportManager().
setEncryptedPassword()
setInitialContextFactoryName()
setLocalContextProperties(Hashtable)
setNamingServiceType() passing in one of:
TransportManager.JNDI_NAMING_SERVICE
TransportManager.REGISTRY_NAMING_SERVICE
setPassword()
setRemoteContextProperties(Hashtable)
setShouldRemoveConnectionOnError()
setUserName()
