| Oracle Coherence Oracle Coherence*Webユーザーズ・ガイド リリース3.5 B56040-01 |
|
 戻る |
 次へ |
Coherence*Webは、作業環境の要望を満たすために様々な方法で構成できます。そのために、一部のデフォルトのコンフィギュレーション・オプションの変更が必要になる場合があります。この章の目的は、Coherence*Webでサポートされている機能について詳しく説明し、適切なコンフィギュレーションとデプロイメントを読者が判断できるようにすることです。
セッション・モデルは、Coherence内のセッション状態をCoherence*Webでどのように物理的に表現し、保存するかを記述します。Coherence*Webは、セッション状態の柔軟なデータ管理モデルをサポートしています。セッション状態はHttpSessionModelオブジェクトで管理し、すべてのセッションのリストはHttpSessionCollectionオブジェクトで管理します。Coherence*Webは、次のようなすぐに使用できる様々なセッション・モデル実装を備えています。
トラディショナル・モデル: すべてのセッション状態を単一のエンティティとして保存しますが、属性は個別にシリアライズおよびデシリアライズします。
モノリシック・モデル: すべてのセッション状態を単一のエンティティとして保存し、すべての属性を単一の操作でシリアライズおよびデシリアライズします。
スプリット・モデル: トラディショナル・モデルを拡張したモデルですが、大きなセッション属性は独立した複数の物理エンティティに分離します。
TraditionalHttpSessionModelとTraditionalHttpSessionCollectionでは、特定のセッションのすべてのHTTPセッション・データを単一のCoherenceキャッシュ・エントリで管理しますが、HTTPセッション属性（特に、そのシリアライズとデシリアライズ）は個別に管理します。
このモデルは、HTTPセッション・オブジェクトが比較的小型で（10KB以下）、セッション属性間でオブジェクト共有の問題が発生しない用途に最適です（セッション属性間のオブジェクト共有は、1つのセッションにある複数の属性で同じオブジェクトを参照する場合に発生します。このような状況では、HTTPセッションを後でデシリアライズすると、これらの属性のシリアライズとデシリアライズが独立して実行されるので、共有オブジェクトの複数のインスタンスが発生します）。
MonolithicHttpSessionModelとMonolithicHttpSessionCollectionは、トラディショナル・モデルの場合と似ていますが、すべての属性を1つのオブジェクト・ストリームにシリアライズおよびデシリアライズすることで、共有オブジェクトの問題を解決している点が異なります。
そのため、モノリシック・モデルはトラディショナル・モデルよりパフォーマンスが低下することが普通です。
SplitHttpSessionModelとSplitHttpSessionCollectionは、セッションID、作成時刻、最終アクセス時刻などの主要なHTTPセッション・データを、他のすべての小型のセッション属性とともにトラディショナル・モデルと同じ方法で管理します。これにより、セッション・データのブロックを小型に維持できるので、高いパフォーマンスが得られます。すべての大型の属性は、独立したキャッシュ・エントリに分割して別々に管理するので、リクエストが発生するたびにクラスタ内でアクセスまたは更新を必要とするデータ量を増やさずに、大規模なHTTPセッション・オブジェクトをサポートできます。つまり、属性の更新によってネットワーク・オーバーヘッドが発生するのは、特定のリクエストで大型の属性を変更する場合のみです。したがって、一般的にスプリット・モデルでは、主要なHTTPセッション・データへのアクセスでも、またどのセッション属性へのアクセスでもネットワーク・オーバーヘッドがほとんど発生しません（これはニア・キャッシュを使用しているからです）。
スプリット・モデルは、ほとんどの用途にお薦めできるセッション・モデルです。
トラディショナル・モデルは、HTTPセッション・オブジェクトが小型であることがわかっている用途に適しています。
モノリシック・モデルは、複数のセッション属性で1つの共有オブジェクトを参照し、そのオブジェクトを共有オブジェクトとして維持する必要がある場合、それら複数のセッション属性に関連する特定のクラスの問題を解決することを目的としています。
クラスタ環境におけるこれらのモデルの動作は、『Oracle Coherenceスタート・ガイド』の「クラスタ・アプリケーションのセッション管理」を参照してください。
Coherence*Webを使用すると、アプリケーションの境界を越えてセッション・データとセッション属性の両方のスコープをどのように設定するか（共有するか）についてきめ細かな制御が可能になります。
Coherence*Webを使用すると、同じWebコンテナまたは別々のWebコンテナにデプロイした複数のWebアプリケーションでセッション・データを共有できます。これを実現するには、Coherence*WebのCookieコンテキスト・パラメータを正しく構成して、セッション属性に保存したオブジェクトのクラスを各Webアプリケーションで使用できるようにする必要があります。
Cookieを使用してセッションIDを保存している場合（つまり、URLリライティングを使用していない場合）、 coherence-session-cookie-pathコンテキスト・パラメータには、セッション・データを共有するすべてのWebアプリケーションの共通コンテキスト・パスを設定する必要があります。たとえば、/web/HRPortalと/web/InWebのコンテキスト・パスで登録した2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-pathパラメータを/webに設定する必要があります。一方、/HRPortalと/InWebのコンテキスト・パスで2つのWebアプリケーションを登録している場合は、coherence-session-cookie-pathパラメータを「/」に設定する必要があります。
セッション・データの共有を必要とする複数のWebアプリケーションのそれぞれを、互いに別のマシンで実行している別のWebコンテナにデプロイしていて、これらのマシンに共通のロード・バランシングを適用していない場合は、coherence-session-cookie-domainパラメータをこれらのマシンで共有しているドメインに設定することも必要です。たとえば、server1.mydomain.comとserver2.mydomain.comで実行している2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-domainパラメータを.mydomain.comに設定する必要があります。
共有セッションに保存したオブジェクトを適切にシリアライズまたはデシリアライズするには、セッション属性に保存したすべてのオブジェクトのクラスを、セッション・データを共有するWebアプリケーションで使用できるようにする必要があります。複数のWebアプリケーションをそれぞれ別々のコンテナにデプロイしている場合は、WebコンテナまたはWebアプリケーション・クラスパスのどちらにもこれらのクラスを配置できます。一方、複数のアプリケーションを同じWebコンテナにデプロイしている場合、これらのクラスはWebコンテナ・クラスパスに配置する必要があります。この理由は、ほとんどのコンテナが別々のClassLoaderを使用してそれぞれのWebアプリケーションをロードするためです。
|
注意: EARクラスタ・ノードのスコープ設定またはアプリケーション・サーバーJVMクラスタのスコープ設定を採用し、かつ個々のWebアプリケーション間でセッション・データを共有しない高度な用途は、「Webアプリケーション間でのセッション・データ共有の禁止」を参照してください。 |
同じCoherenceクラスタに属する複数のJava EEアプリケーションであっても、HTTPセッション・データを共有しないようにすることが必要な場合があります。たとえば、EJB層でキャッシュ・データを共有する2つのアプリケーションHRPortalおよびInWebがあり、それぞれで使用するセッション・データは互いに別であるとします。この2つのアプリケーションにとって、1つのCoherenceクラスタに属していることは必要ですが、セッション・データについては同じクラスタ・サービスを使用しないようにする必要があります。
複数のJava EEアプリケーション間でセッション・データの共有を禁止するには、アプリケーションごとに異なる一意のセッション・キャッシュ・サービス名を指定します。
各アプリケーションのsession-cache-config.xmlファイルで、<service-name/>パラメータの記述を探します。
このパラメータをアプリケーションごとに異なる一意の値に設定します。
これによって、セッション・データについては、アプリケーションごとに別々のクラスタ・サービスを使用できるようになります。
変更したsession-cache-config.xmlファイルを保存します。
例4-1は、あるHRPortalアプリケーションのsession-cache-config.xmlファイルの例です。HRPortalアプリケーションとInWebアプリケーションとの間でセッション・データを共有しないようにするには、レプリケートするスキーマの<service-name>パラメータの名前をReplicationSessionsMiscHRPに変更します。分散スキームの<service-name>パラメータの名前をDistributedSessionsHRPに変更します。
例4-1 アプリケーション間でセッション・データを共有しないようにするためのコンフィギュレーション
<replicated-scheme> <scheme-name>default-replicated</scheme-name><service-name>ReplicatedSessionsMisc</service-name> // rename this to ReplicatedSessionsMiscHRP<backing-map-scheme> <class-scheme> <scheme-ref>default-backing-map</scheme-ref> </class-scheme> </backing-map-scheme> </replicated-scheme> <distributed-scheme> <scheme-name>session-distributed</scheme-name><service-name>DistributedSessions</service-name> // rename this to DistributedSessionsHRP<lease-granularity>member</lease-granularity> <backing-map-scheme> <class-scheme> <scheme-ref>default-backing-map</scheme-ref> </class-scheme> </backing-map-scheme> </distributed-scheme> <distributed-scheme> <scheme-name>session-certificate</scheme-name><service-name>DistributedSessions</service-name> // rename this to DistributedSessionsHRP<lease-granularity>member</lease-granularity> <backing-map-scheme> <local-scheme> <scheme-ref>session-certificate-autoexpiring</scheme-ref> </local-scheme> </backing-map-scheme> </distributed-scheme>
Cookieを使用してセッションIDを保存している場合は、あるアプリケーションで作成したセッションCookieが別のアプリケーションに伝播されないようにする必要があります。これを実現するには、各アプリケーションのweb.xmlファイルで、そのアプリケーションのセッションCookieのドメインとパスを設定する必要があります。コンテキスト・パラメータcoherence-session-cookie-pathで、Webアプリケーションのコンテキスト・パスを設定します。Cookieが伝播されないようにするには、2つのアプリケーションで同じコンテキスト・パスを共有しないようにします。
たとえば、2つのWebアプリケーションをそれぞれ/web/HRPortalと/web/InWebのコンテキスト・パスで登録しているとします。これらのWebアプリケーションがCookieを通じてセッション・データを共有しないようにするには、一方のアプリケーションのweb.xmlファイルでcoherence-session-cookie-pathパラメータを/web/HRPortalに設定し、もう一方のアプリケーションのweb.xmlファイルで同じパラメータを/web/InWebに設定します。
複数のアプリケーションのそれぞれを、互いに別のマシンで実行している別のWebコンテナにデプロイしている場合は、これらのアプリケーションが同じドメインに存在しないようにコンテキスト・パラメータcoherence-session-cookie-domainを設定します。
たとえば、2つのWebアプリケーションをserver1.mydomain.comとserver2.mydomain.comで実行しているとします。これらのアプリケーションがセッションCookieを共有しないようにするには、一方のアプリケーションのweb.xmlファイルでcoherence-session-cookie-domainパラメータをserver1.mydomain.comに設定し、もう一方のアプリケーションのweb.xmlファイルで同じパラメータをserver2.mydomain.comに設定します。
複数のWebアプリケーションでセッションを共有している場合は、セッション属性をグローバルに認識できるように（すべてのWebアプリケーションからアクセスして変更できるようにする）、または逆に個々のWebアプリケーションのみで認識できるように（他のアプリケーションのインスタンスからはアクセスできないようにする）、個々のセッション属性のスコープをアプリケーションで設定することが必要になる場面が数多くあります。
Coherence*Webでは、この動作をAttributeScopeControllerインタフェースを使用して制御できます。複数のアプリケーションでセッションを共有する場合に、このオプション・インタフェースを使用して属性を選択的にスコープ設定できます。これにより、他のアプリケーションの属性を誤って読取り、更新、削除することなく、複数のアプリケーションでアプリケーション・スコープ状態について同じ属性名を使用できます。セッションでは、アプリケーション別スコープを設定した情報のほか、セッションを共有するすべてのアプリケーションで読取り、更新、および削除できるグローバルな（スコープ設定していない）情報を保持することもできます。
すぐに使用できるこのインタフェースの実装として、ApplicationScopeControllerおよびGlobalScopeControllerの2種類があります。
|
注意: 構成済のAttributeScopeControllerは、作成後、属性名の修飾に使用できるWebアプリケーションの名前を使用して初期化されます。Webアプリケーションの名前は、そのアプリケーションのweb.xmlファイルにあるdisplay-name XML要素を使用して構成できます。 |
Coherence*Webを使用する場合に考慮が必要なデプロイメント・オプションの1つがクラスタ・ノード分離の概念です。
このオプションでは次の点を指定します。
アプリケーション・サーバーJVMに作成されるCoherenceノードの数
Coherenceライブラリのデプロイ先
アプリケーションには、アプリケーション・サーバー・スコープ、EARスコープ、またはWARスコープを設定できます。この項では、これらのオプションについて説明します。これらのオプションのXMLコンフィギュレーションの詳細は、「アプリケーションのパッケージ化とクラスタ・ノードの構成」を参照してください。
このコンフィギュレーションでは、Coherence*Webを使用するコンテナにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。このコンフィギュレーションでは、クラスタに作成されるCoherenceノードの数が最小となります（WebコンテナJVMごとに1つ）。また、Coherenceライブラリ（coherence.jar）がコンテナのクラスパスにデプロイされるので、JVMにロードされるCoherenceクラスのコピーは1つのみです。これによって、リソースの使用が最小限に抑えられます。その一方で、すべてのアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのアプリケーションに不具合があるとすべてのアプリケーションが影響を受けます。
このコンフィギュレーションを使用する場合の要件は次のとおりです。
デプロイする各アプリケーションは、同じバージョンのCoherenceを使用し、同じクラスタに属する必要があります。
HTTPセッションに配置したオブジェクトのクラスは、コンテナのクラスパスに配置する必要があります。
アプリケーション・サーバー・スコープ設定クラスタ・ノードのXMLコンフィギュレーションについては、「アプリケーション・サーバー・スコープ設定クラスタ・ノードのパッケージ化と構成」を参照してください。
|
注意: アプリケーション・サーバー・スコープ設定クラスタ・ノードによるコンフィギュレーションは、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では絶対に使用しないでください。このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・グループでデプロイしている状況が考えられます。このようなコンフィギュレーションでは、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他のコンフィギュレーション設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。 このような理由から、EARスコープ設定クラスタ・ノードによるコンフィギュレーションおよびWARスコープ設定クラスタ・ノードによるコンフィギュレーションの使用を強くお薦めします。どのデプロイメント・トポロジを選択したらよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによるコンフィギュレーションは選択しないでください。 |
このコンフィギュレーションでは、EARごとにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。このコンフィギュレーションでクラスタに作成されるCoherenceノードの数は、アプリケーション・サーバー・スコープ設定によるコンフィギュレーションの次に少ない数になります（Coherence*Webを使用するデプロイ先EARごとに1つずつ）。Coherenceライブラリ（coherence.jar）がアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーはEARごとに1つです。EARにあるすべてのWebアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのWebアプリケーションに不具合があるとEARにあるすべてのWebアプリケーションが影響を受けます。
EARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。1台のアプリケーション・サーバーにデプロイするEARを1つのみとする場合も、このオプションが最適です。
このコンフィギュレーションを使用する場合の要件は次のとおりです。
Coherenceライブラリ（coherence.jar）は、EARファイルの中でデプロイし、META-INF/application.xmlにJavaモジュールとして列挙する必要があります。
HTTPセッションに配置したオブジェクトのクラスも、Java EARモジュールとしてデプロイする必要があります。
EARスコープ設定クラスタ・ノードのXMLコンフィギュレーションについては、「EARスコープ設定クラスタ・ノードのパッケージ化と構成」を参照してください。
このコンフィギュレーションでは、デプロイしたWebアプリケーションごとに専用のCoherenceノードがあります。このコンフィギュレーションでクラスタに作成されるCoherenceノードの数は最多となります（Coherence*Webを使用するデプロイ先WARごとに1つずつ）。Coherenceライブラリ（coherence.jar）がWebアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーの数はデプロイ先WARと同じ数になります。その結果、3種類の構成オプションの中で最もリソース使用率が高くなります。ただし、デプロイしたWebアプリケーションごとに専用のクラスタ・ノードがあるので、いずれかのWebアプリケーションに不具合があっても、他のWebアプリケーションは分離されているので影響を受けません。
WARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。1台のアプリケーション・サーバーにデプロイするWARを1つのみとする場合も、このオプションが最適です。
このコンフィギュレーションを使用する場合の要件は次のとおりです。
Coherenceライブラリ（coherence.jar）は、WARファイル（通常はWEB-INF/libにあります）の中でデプロイする必要があります。
HTTPセッションに配置したオブジェクトのクラスは、WARファイル（WEB-INF/libまたはWEB-INF/classesにあります）の中でデプロイする必要があります。
WARスコープ設定クラスタ・ノードのXMLコンフィギュレーションについては、「WARスコープ設定クラスタ・ノードのパッケージ化と構成」を参照してください。
Oracle Coherenceには、HTTPセッションへの同時アクセスを実現する次のコンフィギュレーション・オプションが用意されています。
オプティミスティック・ロック（デフォルト）: 単一のJVMまたは複数のJVMにある複数のスレッドからセッションに同時アクセスできます。ただし、セッションを同時に変更することはできません。
メンバー・ロック: 同じJVMにある複数のスレッドからセッションに同時にアクセスし、同時にセッションを変更できます。別々のJVMにあるスレッドからは同時にアクセスできません。
アプリケーション・ロック: 同じWebアプリケーション・インスタンスにある複数のスレッドから同時にセッションにアクセスし、同時にセッションを変更できます。別々のWebアプリケーション・インスタンスにあるスレッドからは同時にアクセスできません。
スレッド・ロック: 単一のJVMまたは複数のJVMにある複数のスレッドからセッションには同時にアクセスできず、同時にセッションを変更することもできません。
この項で説明したパラメータの詳細は、付録A「Coherence*Webコンフィギュレーション・パラメータ」を参照してください。
オプティミスティック・ロック・モードを使用すると、1つ以上のJVMにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了後、楽観的なアプローチで同時更新を検出して防止します。Coherence*Webで同時変更が検出されると、ConcurrentModificationExceptionがアプリケーションにスローされるので、この例外をアプリケーションで適切に処理できるように準備しておく必要があります。
このモードは、coherence-session-member-lockingパラメータをfalseに設定して構成できます。
メンバー・ロック・モードを使用すると、同じJVMにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスして変更できますが、別々のJVMにあるスレッドからは同時にアクセスできません。この動作は、リクエストの開始時点でHTTPセッションに対するメンバー・レベルのロックを取得して、リクエストの完了時点でロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Coherence開発者ガイド』の「distributed-scheme」で<lease-granularity>を参照してください。
このモードは、coherence-session-member-lockingパラメータをtrueに設定して構成できます。
アプリケーション・ロック・モードでは、1つのWebアプリケーション・インスタンスにある一連のスレッドからのみセッションに同時にアクセスし、変更できます。この動作は、リクエストの開始時点でHTTPセッションに対するメンバー・レベルのロックとアプリケーション・レベルのロックの両方を取得して、リクエストの完了時点で両方のロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Coherence開発者ガイド』の「distributed-scheme」で<lease-granularity>を参照してください。このモードは、coherence-session-app-lockingパラメータをtrueに設定して構成できます。このパラメータをtrueに設定するということは、coherence-session-member-lockingをtrueに設定することにもなります。
スレッド・ロック・モードでは、1つのJVMにある1つのスレッドからのみセッションに同時にアクセスし、変更できます。この動作は、リクエストの開始時点でHTTPセッションに対するメンバー・レベルのロック、アプリケーション・レベルのロック、およびスレッド・レベルのロックを取得して、リクエストの完了時点でその3つすべてのロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Coherence開発者ガイド』の「distributed-scheme」で<lease-granularity>を参照してください。
このモードは、coherence-session-thread-lockingパラメータをtrueに設定して構成できます。このパラメータをtrueに設定するということは、coherence-session-member-lockingとcoherence-session-app-lockingの両方をtrueに設定することにもなります。
HTTPセッションへのアクセスに対するメンバー・ロック、アプリケーション・ロック、またはスレッド・ロックを有効にすることは、セッションへのアクセスを要求するすべてのHTTPリクエストに対して、Coherence*Webがクラスタ規模のロックを取得することを意味します。ただし、スティッキー・ロード・バランシングが可能で、Coherence*Webのスティッキー・セッション最適化が有効になっている場合を除きます。デフォルトでは、ロックされたセッション（別のJVMにあるスレッドでロックされたセッション）にアクセスしようとするスレッドは、ロックが取得できるまでブロックされます。ロック取得のタイムアウトを有効にする場合は、コンテナの起動スクリプトでtangosol.coherence.servlet.lock.timeoutシステム・プロパティを使用して構成します（例: -Dtangosol.coherence.servlet.lock.timeout=30s）。
多くのWebアプリケーションには、このような厳しい同時処理要件がありません。このようなアプリケーションの場合は、オプティミスティック・ロック・モードを使用することによって、次のようなメリットが得られます。
HTTPリクエストのたびにクラスタ規模のロックを取得して解放することで発生するオーバーヘッドを排除できます。
障害が発生したJVMや応答しないJVMから他の正常なJVMにリクエストをルーティングして負荷分散できます。クラスタ規模でセッションに適用されているロックの解放を、応答しなくなったJVMに要求する必要がありません。
スティッキー・ロード・バランサの対象となっているWebアプリケーションの要件としてメンバー・ロック、アプリケーション・ロック、またはスレッド・ロックがある場合は、HTTPセッションへのアクセスに必要なクラスタ規模のロックの取得をCoherence*Webで最適化できます。その名が示すとおり、スティッキー・ロード・バランサは、セッションに対する各リクエストを、前回そのセッションでリクエストの転送先として使用されたものと同じアプリケーション・サーバーJVMにルーティングしようとします。つまり、最初にそのセッションを作成したアプリケーション・サーバーJVMです。スティッキー・セッション最適化では、セッションに対するクラスタ規模のロックをそのセッションの有効期限が切れるまで、または解放するよう要求されるまで保持することによって、この動作を利用しています。なんらかの理由で、スティッキー・ロード・バランサが同じセッションに対するリクエストを別のアプリケーション・サーバーJVMに送信した場合は、そのJVMから該当セッションのロックを保持しているJVMに対して、できるだけ早くロックを解放するよう要求します。この動作は、起動サービスを使用して実装します。詳細は、表B-2のSessionOwnershipのエントリを参照してください。
スティッキー・セッション最適化は、coherence-sticky-sessionsパラメータをtrueに設定すると有効になります。
Coherence*Webでは、Coherenceで使用できるデプロイメント・トポロジのほとんどを使用できます。これには、インプロセス・トポロジ、アウトオブプロセス・トポロジ（クライアント/サーバー・デプロイメント）、Coherence*Extendを介してクライアントとサーバーをブリッジするトポロジなどがあります。サポートされている主なデプロイメント・トポロジについて次で説明します。
インプロセス・トポロジは、本番環境での使用にはお薦めできません。このトポロジは、主に、開発とテスト用としてサポートされています。このトポロジは、アプリケーション・サーバーを使用してセッション・データをプロセス内で保存することで、容易に起動して、スモーク・テスト、開発、およびテスト用として高速で実行できます。
アウトオブプロセス・デプロイメント・トポロジでは、アプリケーション・サーバー（アプリケーション・サーバー層）をキャッシュ・クライアントとして構成し（tangosol.coherence.distributed.localstorage=false）、クラスタ化データを物理的に保存および管理してキャッシュ・サーバーとして動作する専用のJVMを配置します。
このアプローチには次のようなメリットがあります。
セッション・データ記憶域の負荷を、アプリケーション・サーバー層からキャッシュ・サーバー層に移管できます。これによって、ヒープ使用量やガベージ・コレクション時間などを低減できます。
2つの層の規模を互いに無関係に変更できます。アプリケーションの処理能力が不足している場合は、起動するアプリケーション・サーバーの数を増やすだけで済みます。セッション記憶域の容量が不足している場合は、起動するキャッシュ・サーバーの数を増やすだけです。
アウトオブプロセス・トポロジは、その柔軟性によって、Oracle Coherenceのデフォルトの推奨トポロジになっています。
Coherence*Extendによるアウトオブプロセス・トポロジは、アウトオブプロセス・トポロジに似ていますが、アプリケーション・サーバー層とキャッシュ・サーバー層との通信をCoherence*Extend経由（TCP/IP）で行う点が異なります。このシナリオの構成手順は、「Coherence*ExtendによるCoherence*Webの構成」を参照してください。
このアプローチには、アウトオブプロセス・トポロジと同じメリットがあるほか、アプリケーション・サーバーとキャッシュ・サーバーのデプロイメントをセグメント化する機能もあります。この特性は、UDPをサポートしていないネットワーク上にアプリケーション・サーバーが存在する環境に最適です。TCPを使用してクラスタにアプリケーション・サーバーを接続した上で、独立した専用のネットワークにキャッシュ・サーバーを配置できます。
|
注意: この項では、Coherence*Web JMXの管理と監視を有効にするために、Coherenceクラスタ化JMXフレームワークがすでに設定されているものとします。このフレームワークを設定するには、『Oracle Coherence開発者ガイド』のJMXでのCoherenceの管理方法に関する項で、コンフィギュレーションとインストールの手順を参照してください。 |
HTTPセッション管理でCoherence*Webを使用しているWebアプリケーションの管理属性および操作は、HttpSessionManagerMBeanインタフェース（com.tangosol.coherence.servlet.management.HttpSessionManagerMBean）から利用できます。
設定中に、Coherence*WebのWebアプリケーションごとにHttpSessionManagerMBeanのインスタンスが1つ登録されます。このMBeanは、該当のWebアプリケーションを終了すると登録解除されます。表4-1は、登録で使用されるMBeanのオブジェクト名を示しています。
表4-1 HttpSessionManagerMBeanのオブジェクト名
| マネージドBean | オブジェクト名 |
|---|---|
|
HttpSessionManagerMBean |
type=HttpSessionManager, nodeId=cluster node id, appId=web application id |
表4-2は、HttpSessionManagerMBeanから返される情報を示しています。操作を表すresetStatistics以外の名前はすべて属性を表します。
MBean属性の中には、次の接頭辞を使用しているものがあります。
LocalSession: クラスタの一部のメンバーにのみ分散されるセッションを意味します。分散元のサーバーに対して、このセッションはその存続期間中の特定の時点まで「ローカル」のままです。
LocalAttribute: クラスタの一部のメンバーにのみ分散されるセッション属性を意味します。
Overflow: 普通は、高速なフロントエンド・キャッシュから排除されたエントリを捕捉する、大容量で低速なバックエンド・キャッシュです。
表4-2 HttpSessionManagerMBeanから返される情報
| 名前 | データ型 | 説明 |
|---|---|---|
|
String |
使用中の |
|
|
String |
使用中の |
|
|
String |
分散されないセッション属性を保存するローカル・キャッシュの名前。この属性がnullの場合、セッション属性のローカル記憶域は無効です。 |
|
|
Integer |
セッション属性のローカル・キャッシュに保存された分散されないセッション属性の数。この属性が |
|
|
String |
分散されないセッションを保存するローカル・キャッシュの名前。この属性が |
|
|
Integer |
セッションのローカル・キャッシュに保存された分散されないセッションの数。この属性が |
|
|
Integer |
統計を前回リセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の平均サイズ（バイト数）。この属性が |
|
|
String |
所定のサイズより大きいことから、シリアライズしたセッション・オブジェクト自体の一部としてではなく、個別のキャッシュ・エントリとしたほうが効率的に管理できると判断される「大型の属性」を保存するクラスタ・キャッシュの名前。 |
|
|
Integer |
統計を前回リセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の最大サイズ（バイト数）。 |
|
|
Integer |
大型の属性向けに確保されている独立した「オーバーフロー」キャッシュに属性値を格納できるようにするために、その属性値のシリアライズした形式で確保する必要がある最小長さ（バイト数）。 |
|
|
Integer |
統計を最後にリセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の更新回数。 |
|
|
Integer |
統計を最後にリセットした時点以降、有効期限切れまたは明示的な無効化によって無効になったセッション・オブジェクトの平均存続期間（秒数）。 |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの平均サイズ（バイト数）。 |
|
|
String |
シリアライズしたセッション・オブジェクトを保存するクラスタ・キャッシュの名前。 |
|
|
Integer |
生成されたセッションIDの長さ（文字数）。 |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの最大サイズ（バイト数）。 |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの最小サイズ（バイト数）。 |
|
|
Integer |
Webアプリケーションのこのインスタンスに関連付けられたセッション・オブジェクトの数。スティッキー・セッション最適化が無効になっている場合、この属性は |
|
|
Integer |
セッションの存続期間（秒数）。セッションが無期限の場合、この属性は |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに保存されたセッション・オブジェクトの更新回数。 |
|
|
String |
javax.servlet. |
|
|
String |
Webアプリケーション |
|
|
void |
セッション管理統計をリセットします。 |
図4-11は、JConsoleブラウザに表示されたHttpSessionManagerMBeanを示しています。
Coherence*Webセッション管理モジュールの一環として、HTTPセッションは最終的にセッション・リーパーによってクリーンアップされ、関連付けられているメモリーが解放されます。セッション・リーパーは、JVM固有のガベージ・コレクション（GC）機能に似たサービスを提供します。つまり、有効期限が切れたときに不要になったと判定されたすべてのセッションを破棄する役目を担います。
各HTTPセッションには、有効期限がいつ切れたかを判定する2つの情報が保持されます。1つ目は、そのセッションを最後に使用したアクティビティのタイムスタンプを示すLastAccessedTimeセッション・プロパティです。2つ目は、アクティビティがない状態でのセッションの存続時間を指定するMaxInactiveIntervalセッション・プロパティです。一般に、このプロパティの値は30分に指定されます。MaxInactiveIntervalプロパティは、デフォルトでcoherence-session-expire-secondsコンフィギュレーション・オプションで指定された値に設定されますが、セッションごとに変更することも可能です。
サーバーがHTTPリクエストを受信したときに、そのリクエストに関連付けられたHTTPセッションがある場合は、その都度セッションのLastAccessedTimeプロパティが現在の時刻に自動的に更新されます。そのセッションは、関連するリクエストが送信され続けるかぎり存続します。ただし、アクティビティのない時間がMaxInactiveIntervalプロパティで指定された時間を超過すると、そのセッションは期限切れとなります。セッションの期限切れは受動的に、すなわち時間の経過によってのみ発生します。Coherence*Webセッション・リーパーは、期限切れとなったセッションをスキャンし、見つかった場合はそれらをクリーンアップします。
セッション・リーパーは、次の3つの基本的な質問に基づいて構成されます。
どのサーバーでリーパーを実行するか
どのくらいの頻度でリーパーを実行するか
リーパーを実行するときに、どのサーバー上で期限切れのセッションを検出するか
セッション・リーパーは、アプリケーション・サーバーの一部として実行されます。つまり、キャッシュ・サーバーで構成される個別のキャッシュ層を提供するようにCoherenceが構成されている場合、セッション・リーパーはそれらのキャッシュ・サーバー上では実行されません。
Coherence*Webに使用される3種類のトポロジについて考えてみましょう。
インプロセス・トポロジ: Coherence*Webを実行するアプリケーション・サーバーは記憶域が有効であるため、HTTPセッションの記憶域はアプリケーション・サーバーと同じ場所に配置されます。HTTPセッションの記憶域に個別のキャッシュ・サーバーは使用されません。
アウトオブプロセス・トポロジ: Coherence*Webを実行するアプリケーション・サーバーは、Coherenceクラスタの記憶域が無効なメンバーです。HTTPセッションの記憶域には個別のキャッシュ・サーバーが使用されます。
Coherence*Extendによるアウトオブプロセス・トポロジ: Coherence*Webを実行するアプリケーション・サーバーは、Coherenceクラスタには属しません。Coherence*Extendを使用して、HTTPセッションの記憶域に使用されるキャッシュ・サーバーが属すCoherenceクラスタに接続されます。
セッション・リーパーは、Coherence*Webを実行するすべてのアプリケーション・サーバーで実行されます。デフォルトでは、セッション・リーパーはすべてのアプリケーション・サーバーで同時に実行されるため、期限切れのセッションを特定してクリーンアップするためのワークロードをすべてのサーバーで共有できます。coherence-reaperdaemon-cluster-coordinatedコンフィギュレーション・オプションを使用すると、一度に1台のサーバーのみが実際のリープを実行するようにクラスタ内のリープを調整できますが、このオプションを使用することはお薦めできません。また、このオプションは、Coherence*Extendトポロジを使用しているCoherence*Webには使用できません。
セッション・リーパーは、リープ・サイクルと呼ばれる一定の期間（デフォルトは5分）にわたってすべてのセッションをスキャンするように構成されます。このリープ・サイクルの長さはcoherence-reaperdaemon-cycle-secondsオプションで指定します。セッション・リーパーは、リープ・サイクル期間内にすべての監視対象セッションをスキャンして、期限切れになったセッションをクリーンアップする必要があるため、この設定は、セッション・リーパーの動作の積極度を示すことになります。サイクルの長さが短すぎると、セッション・リーパーはリソースを余分に使用するだけで、特別な効果はもたらしません。サイクルの長さが長すぎると、期限切れになったセッションがしばらくの間クリーンアップされない可能性があります。多くの場合、期限切れになったセッションを即座にクリーンアップすることよりも、リソースの使用量を減らすことの方がはるかに多く望まれます。したがって、デフォルトの5分というサイクルは、クリーンアップの迅速性と最小限のリソース使用量という両方の点をバランスよく保つことのできる長さです。
リープ・サイクルの期間中、セッション・リーパーは期限切れのセッションをスキャンします。ほとんどの場合、セッション・リーパーはクラスタ全体のすべてのHTTPセッションをスキャンするよう構成されますが、単一層トポロジに適用できる最適化も用意されています。単一層トポロジでは、記憶域が有効でアプリケーション・サーバーも実行しているCoherenceクラスタ・メンバーによってすべてのセッションが管理される場合、セッションの記憶域はアプリケーション・サーバーと同じ場所に配置されます。したがって、各アプリケーション・サーバーでは、ローカルに格納されるセッションしかセッション・リーパーがスキャンしないという可能性もあります。この動作は、coherence-reaperdaemon-assume-localityコンフィギュレーション・オプションをtrueに設定すると有効にできます。
同じ場所に配置されたセッションのみをスキャンするか、すべてのセッションをスキャンするかにかかわらず、セッション・リーパーは次のCoherenceデータ・グリッドの高度な機能を使用して、非常に効率的な方法でセッションをスキャンします。
現在のCoherenceバージョンより、セッション・リーパーはそれぞれのセッションを実際に検査するかわりに、期限切れセッションの検索をデータ・グリッドに委譲するようになりました。これには、カスタムのValueExtractor実装が使用されます。このValueExtractorは、Coherenceバージョン3.5で導入されたBinaryEntryインタフェースを利用するため、セッションをデシリアライズしなくても、そのセッションが期限切れかどうかを判別できます。そのため、期限切れセッションの選択を他のパラレル問合せとまったく同じようにデータ・グリッドに委譲して、記憶域が有効なCoherenceメンバーで非常に効率的な方法で実行できるようになります。
パラレル問合せを使用してすべての期限切れセッションを即時に選択するかわりに、セッション・リーパーは一度に1つのメンバーのみに問合せを行います。これにより、リープ・サイクル期間全体での問合せ作業の分割が可能になります。また、期限切れセッションの問合せ時にグループ通信を行う必要もなくなります。
期限切れセッションのクリーンアップ作業はリープ・サイクル全体にわたって分割されます。これにより、期限切れセッションの選択もリープ・サイクルを通して分割され、クリーンアップ直前に期限切れセッションを選択できるようになります。したがって、同じ期限切れセッションを複数のアプリケーション・サーバーがクリーンアップしようとする可能性は低減します。セッション・リーパーは、com.tangosol.net.partition.PartitionedIteratorクラスを使用してメンバーごとに自動問合せを行います。またこの問合せは、大規模クラスタのハーモニックを回避するランダムな順序で実行されます。
記憶域が有効な各メンバーは、すべての期限切れセッションを非常に効率的にスキャンでき、リーパー・サイクルごとに各アプリケーション・サーバーで必要となるスキャンも一度だけで済みます。そのため、すぐに使用できるセッション・リーパー・コンフィギュレーションは、アプリケーション・サーバー・クラスタがわずか2台のサーバーで構成されている場合でも、数百台のサーバーで構成されている場合でも、効果的に機能します。さらに、このコンフィギュレーションは、数百の同時セッションを実行するアプリケーションや、数百万の同時セッションを実行するアプリケーションでも十分に機能します。
セッション・リーパーがアプリケーション・サーバーのスムーズな運用に影響しないよう、セッション・リーパーの作業は小さく分割され、リープ・サイクル全体にわたって分散されるようにスケジュールされます。セッション・リーパーは、スケジューリングが必要な作業量を認識する必要があるため、以前のサイクルで実行した作業量の統計を維持し、新しいリープ・サイクルの統計ほど重視されるように統計的重みづけを使用します。このようにセッション・リーパーが作業を分割する理由には、次のものがあります。
セッション・リーパーが一度に大量のCPUサイクルを消費した場合、ユーザーに対するアプリケーションの応答性が低下する可能性があります。一度に実行する作業を細分化することで、アプリケーションの応答性は維持されます。
Coherence*Webの主なパフォーマンス・イネーブラの1つは、Coherenceのニア・キャッシュ機能です。期限切れとなったセッションは、クリーンアップするために同じニア・キャッシュを介してアクセスされるため、期限切れとなるセッションが多すぎたり、期限切れにするタイミングが早すぎたりすると、アプリケーション・サーバーで使用されるはずのセッションがキャッシュから削除され、パフォーマンスの低下を招く可能性があります。
セッション・リーパーは、デフォルトのすぐに使えるコンフィギュレーションを採用した場合でも、次の方法で効率的にジョブを実行します。
できるだけ多くの作業をデータ・グリッドに委譲する。
一度に1つのメンバーにのみ作業を委譲する。
グループ通信を回避する。
デシリアライズを行わなくてもデータ・グリッドで期限切れセッションを検出できるようにする。
CPUサイクルの使用量を制限する。
パフォーマンス上の理由でCoherence*Webが依存しているニア・キャッシュのキャッシュ・スラッシングを回避する。
ここでは、セッション・リーパーのすぐに使えるコンフィギュレーションをチューニングする際の推奨事項を示します。
アプリケーションをインプロセス・トポロジでデプロイする場合は、coherence-reaperdaemon-assume-localityコンフィギュレーション・オプションをtrueに設定します。
アプリケーション・サーバーはいずれも期限切れセッションをスキャンするようになっているため、クラスタ内のアプリケーション・サーバーが10台を超えている場合は、coherence-reaperdaemon-cycle-secondsコンフィギュレーション・オプションの値を増やすことをお薦めします。アプリケーション・サーバーの数が増えるほど、サイクルは長くなる可能性があります。たとえば、サーバーが200台ある場合、妥当なリーパー・サイクルは30分といえます（この場合はcoherence-reaperdaemon-cycle-secondsコンフィギュレーション・オプションを1800に設定します）。
HttpSessionCollection.SessionDistributionControllerインタフェースで記述されるCoherence*Webセッション・ディストリビューション・コントローラを使用すると、Webアプリケーション内のHTTPセッションと属性のデフォルトのディストリビューションをオーバーライドできます。SessionDistributionControllerインタフェースの実装では、セッションと属性を次のいずれかの方法でマークできます。
local: ローカルのセッションまたは属性は、それらの作成元サーバーのヒープに格納されるため、そのサーバーからのみアクセスできます。
distributed: 分散されたセッションまたは属性は、Coherenceのグリッド内に格納されるため、他のサーバーのJVMからアクセスできます。
セッションの存続期間中であれば、どの時点でも、セッションまたはそのセッションの属性を「local」または「distributed」から遷移できます。ただし、一度分散されたセッションまたは属性は、「local」に戻すことはできません。
セッション・ディストリビューション・コントローラには、次のような使い方があります。
新しいセッションは、属性を追加するまで（たとえば、オンライン・ショッピング・カートに1つ目のアイテムを追加するまで）、「local」のままにしておくことができます。これは、セッションに意味のあるデータが含まれる場合のみ、セッションをフォルト・トレラントにする必要があるという発想です。
一部のWebフレームワークは、セッションの属性を使用してUIのレンダリング状態を格納します。一般に、このデータはシリアライズ不能なため、分散できません。セッション・ディストリビューション・コントローラを使用すると、これらの属性を「local」として維持したまま、残りのセッションの属性を分散させることができます。
セッション・ディストリビューション・コントローラは、非分散システムを分散システムに変換する場合に役立ちます。特に、すべてのセッションとすべての属性の分散コストが検討事項となっている場合は有効です。
例4-2は、HttpSessionCollection.SessionDistributionControllerインタフェースの実装例を示しています。この例では、セッションにショッピング・カートがアタッチされているかどうかがテストされます（アタッチされているセッションのみが分散されます）。次に、そのセッションに特定の属性が含まれているかどうかがテストされます。その属性が検出された場合、その属性は分散されません。
例4-2 セッション・ディストリビューション・コントローラの実装例
import com.tangosol.coherence.servlet.HttpSessionCollection; import com.tangosol.coherence.servlet.HttpSessionModel; /** * Sample implementation of SessionDistributionController */public class CustomSessionDistributionControllerimplements HttpSessionCollection.SessionDistributionController{ public void init(HttpSessionCollection collection) { } /** * Only distribute sessions that have a shopping cart. * * @param model Coherence representation of the HTTP session * * @return true if the session should be distributed */ public boolean isSessionDistributed(HttpSessionModel model) { return model.getAttribute("shopping-cart") != null; } /** * If a session is "distributed", then distribute all attributes with the * exception of the "ui-rendering" attribute. * * @param model Coherence representation of the HTTP session * @param sName name of the attribute to check * * @return true if the attribute should be distributed */ public boolean isSessionAttributeDistributed(HttpSessionModel model, String sName) { return !"ui-rendering".equals(sName); } }
SessionDistributionControllerの実装を記述したら、coherence-distributioncontroller-classコンフィギュレーション・パラメータを使用して、この実装をアプリケーションに登録できます。セッション・ディストリビューション・コントローラを使用するには、coherence-sticky-sessionsパラメータも有効にする必要があります。これらのパラメータの詳細は、付録A「Coherence*Webコンフィギュレーション・パラメータ」を参照してください。
Coherence*Webのデプロイメント・オプションの1つに、Coherence*Extendを使用して、WebコンテナのJVMをTCP/IP経由でクラスタに接続する方法があります。このコンフィギュレーションは、次のいずれかの状況が該当する場合に検討してください。
Web層JVMがDMZにあるのに、Coherenceクラスタがファイアウォールの内側にある。
Web層がUDPをサポートしていない環境に作成されている。
Web層JVMで、ガベージ・コレクションが長時間または頻繁に一時停止する。
Web層JVMが頻繁に再起動する。
このタイプのデプロイメントの参加者には、次の3種類があります。
Web層JVM: このトポロジでは、Extendクライアントとして機能します。クラスタのメンバーにはならず、クラスタ内のプロキシ・ノードに接続します。クラスタへのリクエストの発行は、そのプロキシ・ノードが代行します。
プロキシJVM: クラスタ内の記憶域が無効なメンバーとして、ExtendクライアントからのTCP/IP接続を受け入れ、管理します。クライアントからのリクエストはクラスタに送信され、応答はTCP/IP接続を通じて返送されます。
記憶域JVM: 実際のセッション・データをメモリーに格納する際に使用されます。
Coherence*Extendを使用してCoherence*Webを構成する一般的な手順は、次のとおりです。
オプティミスティック・ロック・モードを使用するようにCoherence*Webを構成します（「オプティミスティック・ロック（デフォルト）」を参照）。
プロキシJVMと記憶域JVMのキャッシュ・コンフィギュレーション・ファイルを構成します。
Web層のキャッシュ・コンフィギュレーション・ファイルを、1つ以上のプロキシJVMを指すように変更します。
次の各項では、これらの手順をさらに詳しく説明します。
オプティミスティック・ロック・モードをWebアプリケーションで使用できるようにするには、表4-3に示すCoherence*Webコンフィギュレーション・パラメータが指定の値に設定されていることを確認します。
表4-3 オプティミスティック・ロック用のCoherence*Webパラメータ設定
| パラメータ名 | 値 |
|---|---|
|
coherence-session-member-locking |
false |
|
coherence-sticky-sessions |
false |
|
coherence-preserve-attributes |
false |
これらのパラメータの詳細は、付録A「Coherence*Webコンフィギュレーション・パラメータ」を参照してください。
セッション・キャッシュ・コンフィギュレーション・ファイル（WEB-INF/classes/session-cache-config.xml）は、Coherence*Extendを使用するCoherence*Webのキャッシュ・コンフィギュレーション・ファイルの一例です。
このセッション・キャッシュ・コンフィギュレーション・ファイルは、プロキシJVMおよびサーバーJVMに使用する必要があります。このファイルにはシステム・プロパティのオーバーライドが含まれるため、同じファイルをプロキシJVMと記憶域JVMの両方に使用できます。プロキシJVMで使用する場合は、表4-4に示すシステム・プロパティを指定する必要があります。
表4-4 プロキシJVM用のシステム・プロパティ値
| システム・プロパティ名 | 値 |
|---|---|
|
tangosol.coherence.session.localstorage |
false |
|
tangosol.coherence.session.proxy |
true |
|
tangosol.coherence.session.proxy.localhost |
プロキシがバインドされるNICのホスト名またはIPアドレス |
|
tangosol.coherence.session.proxy.localport |
プロキシがバインドされるポートの一意のポート番号 |
記憶域JVMで使用する場合は、表4-5に示すシステム・プロパティを指定する必要があります。
表4-5 記憶域JVM用のシステム・プロパティ値
| システム・プロパティ名 | 値 |
|---|---|
|
tangosol.coherence.session.localstorage |
true |
|
tangosol.coherence.session.proxy |
false |
例4-3は、サーバー側のセッション・キャッシュ・コンフィギュレーション・ファイルの全内容を示しています。
例4-3 session-cache-config-server.xmlファイル
<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- -->
<!-- Server-side cache configuration descriptor for Coherence*Web over -->
<!-- Coherence*Extend (see session-cache-config-client.xml). -->
<!-- -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<cache-config>
<caching-scheme-mapping>
<!--
The clustered cache used to store Session management data.
-->
<cache-mapping>
<cache-name>session-management</cache-name>
<scheme-name>session-distributed</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store ServletContext attributes.
-->
<cache-mapping>
<cache-name>servletcontext-storage</cache-name>
<scheme-name>session-distributed</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store Session attributes.
-->
<cache-mapping>
<cache-name>session-storage</cache-name>
<scheme-name>session-distributed</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store the "overflowing" (split-out due to size)
Session attributes. Only used for the "Split" model.
-->
<cache-mapping>
<cache-name>session-overflow</cache-name>
<scheme-name>session-distributed</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store IDs of "recently departed" Sessions.
-->
<cache-mapping>
<cache-name>session-death-certificates</cache-name>
<scheme-name>session-certificate</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<!--
Distributed caching scheme used by the various Session caches.
-->
<distributed-scheme>
<scheme-name>session-distributed</scheme-name>
<scheme-ref>session-base</scheme-ref>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>
<!--
Distributed caching scheme used by the "recently departed" Session cache.
-->
<distributed-scheme>
<scheme-name>session-certificate</scheme-name>
<scheme-ref>session-base</scheme-ref>
<backing-map-scheme>
<local-scheme>
<eviction-policy>HYBRID</eviction-policy>
<high-units>4000</high-units>
<low-units>3000</low-units>
<expiry-delay>86400</expiry-delay>
</local-scheme>
</backing-map-scheme>
</distributed-scheme>
<!--
"Base" Distributed caching scheme that defines common configuration.
-->
<distributed-scheme>
<scheme-name>session-base</scheme-name>
<service-name>DistributedSessions</service-name>
<serializer>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</serializer>
<thread-count>0</thread-count>
<lease-granularity>member</lease-granularity>
<local-storage system-property="tangosol.coherence.session.localstorage">true</local-storage>
<partition-count>257</partition-count>
<backup-count>1</backup-count>
<backup-storage>
<type>on-heap</type>
</backup-storage>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<!--
Proxy scheme that Coherence*Web clients used to connect to the cluster.
-->
<proxy-scheme>
<service-name>SessionProxy</service-name>
<thread-count>10</thread-count>
<acceptor-config>
<serializer>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</serializer>
<tcp-acceptor>
<local-address>
<address system-property="tangosol.coherence.session.proxy.localhost">localhost</address>
<port system-property="tangosol.coherence.session.proxy.localport">9099</port>
<reusable>true</reusable>
</local-address>
</tcp-acceptor>
</acceptor-config>
<autostart system-property="tangosol.coherence.session.proxy">false</autostart>
</proxy-scheme>
<!--
Local caching scheme definition used by all caches that do not require an
eviction policy.
-->
<local-scheme>
<scheme-name>unlimited-local</scheme-name>
<service-name>LocalSessionCache</service-name>
</local-scheme>
</caching-schemes>
</cache-config>
例4-4に示すsession-cache-config-client.xmlファイルは、Coherence*Extendを使用するCoherence*Webのキャッシュ・コンフィギュレーション・ファイルの一例です。このキャッシュ・コンフィギュレーション・ファイルは、Web層JVMで使用する必要があります。このファイルの使用およびインストール手順は、次のとおりです。
ファイルの<remote-addresses/>セクションに、プロキシJVMのホスト名（またはIPアドレス）およびポートを追加します。一般には、ロード・バランシングとフェイルオーバーに備えて、すべてのプロキシJVMのホスト名（またはIPアドレス）とポートを追加します。
|
注意: <remote-addresses>要素には、Webコンテナの接続先となるプロキシ・サーバーがリストされています。デフォルトで、Webコンテナはランダムにアドレスを選択します（複数のアドレスが構成されていることを前提とした場合）。Webコンテナとプロキシ間の接続が切断されると、コンテナはリスト内の別のプロキシに接続します。 |
ファイル名をsession-cache-config.xmlに変更します。
このファイルをWebアプリケーションのWEB-INF/classesディレクトリに配置します。WebInstallerを使用してCoherence*Webをインストールした場合は、WebInstallerによって追加されている既存のファイルと置き換えます。
例4-4は、クライアント側のセッション・キャッシュ・コンフィギュレーション・ファイルの全内容を示しています。
例4-4 session-cache-config-client.xmlファイル
<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- -->
<!-- Client-side cache configuration descriptor for Coherence*Web over -->
<!-- Coherence*Extend (see session-cache-config-server.xml). -->
<!-- -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<cache-config>
<caching-scheme-mapping>
<!--
The clustered cache used to store Session management data.
-->
<cache-mapping>
<cache-name>session-management</cache-name>
<scheme-name>session-near</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store ServletContext attributes.
-->
<cache-mapping>
<cache-name>servletcontext-storage</cache-name>
<scheme-name>session-near</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store Session attributes.
-->
<cache-mapping>
<cache-name>session-storage</cache-name>
<scheme-name>session-near</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store the "overflowing" (split-out due to size)
Session attributes. Only used for the "Split" model.
-->
<cache-mapping>
<cache-name>session-overflow</cache-name>
<scheme-name>session-remote</scheme-name>
</cache-mapping>
<!--
The clustered cache used to store IDs of "recently departed" Sessions.
-->
<cache-mapping>
<cache-name>session-death-certificates</cache-name>
<scheme-name>session-remote</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<!--
Near caching scheme used by the Session attribute cache. The front cache
uses a Local caching scheme and the back cache uses a Remote caching
scheme.
-->
<near-scheme>
<scheme-name>session-near</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>session-front</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<remote-cache-scheme>
<scheme-ref>session-remote</scheme-ref>
</remote-cache-scheme>
</back-scheme>
<invalidation-strategy>present</invalidation-strategy>
</near-scheme>
<local-scheme>
<scheme-name>session-front</scheme-name>
<eviction-policy>HYBRID</eviction-policy>
<high-units>1000</high-units>
<low-units>750</low-units>
</local-scheme>
<remote-cache-scheme>
<scheme-name>session-remote</scheme-name>
<initiator-config>
<serializer>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</serializer>
<tcp-initiator>
<remote-addresses>
<!--
The following list of addresses should include the hostname and port
of all running proxy JVMs. This is for both load balancing and
failover of requests from the Web tier.
-->
<socket-address>
<address>localhost</address>
<port>9099</port>
</socket-address>
</remote-addresses>
</tcp-initiator>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
