| Oracle Coherence Oracle Coherence*Webユーザーズ・ガイド リリース3.6.1 B61371-02 |
|
 前 |
 次 |
Coherence*Webは、作業環境の要望を満たすために様々な方法で構成できます。そのために、一部のデフォルトの構成オプションの変更が必要になる場合があります。この章では、構成とデプロイメントについて適切な意思決定ができるように、Coherence*Webでサポートされている機能について詳しく説明します。
「セッション・モデル」では、Coherence*Webによるセッション状態の格納方法について説明します。
「セッションとセッション属性のスコープ設定」では、アプリケーション境界を越えてセッション・データとセッション属性の両方のスコープをどのように設定するか(共有するか)についてきめ細かな制御が可能になります。
「クラスタ・ノード分離」では、アプリケーション・サーバーJVM内に作成されるCoherenceノードの数とアプリケーションのクラスパスでCoherenceライブラリをデプロイする場所を決定します。
「セッション・ロック・モード」では、アプリケーションがどのようにHTTPセッションへの同時アクセスを取得するのかを決定します。
「デプロイメント・トポロジ」では、セッション・データをキャッシュ・サーバーとアプリケーション・サーバーとの間で格納および管理する方法を決定します。
「JMXによるアプリケーションの管理と監視」では、Coherence*Webを使用するWebアプリケーションに対するHTTPセッション管理属性および操作を表示する方法について説明します。
「パフォーマンス・レポートの実行」では、容量およびトラブルシューティングの問題の管理に役立つ事前構成済レポートについて説明します。
「期限切れHTTPセッションのクリーンアップ」では、期限切れHTTPセッションをクリーンアップして関連メモリーを解放する方法について説明します。
「遅延取得によるセッションへのアクセス」では、サーブレットまたはフィルタがアクセスを試みる場合にのみCoherence*Webがセッションを取得するように設定することによって、処理時間と処理能力を節約する方法について説明します。
「HTTPセッションと属性のディストリビューションのオーバーライド」では、セッションまたはその属性(あるいはその両方)をローカルのままにするか(元のサーバーのヒープに格納し、そのサーバーからのみアクセス可能にするか)、分散するか(Coherenceグリッド内に格納し、他のサーバーJVMからアクセス可能にするか)を制御する方法について説明します。
「Coherence*ExtendによるCoherence*Webの構成」では、Coherence*Extendを使用してWebコンテナJVMをクラスタに接続できるようにするためのCoherence*Webの構成方法について説明します。
「JSFおよびMyFaces用のCoherence*Webの構成」では、Java Server Faces(JSF)またはMyFacesを使用してWebアプリケーション用のユーザー・インタフェースを構築する場合のCoherence*Webの構成方法について説明します。
セッション・モデルは、Coherence内のセッション状態をCoherence*Webでどのように保存するのかを記述します。セッション・データはHttpSessionModelオブジェクトで管理し、Webアプリケーションのセッション・コレクションはHttpSessionCollectionオブジェクトで管理します。web.xmlでコレクション・タイプのみを構成する必要があります。モデルはコレクション・タイプから暗黙的に派生します。Coherence*Webは、次のようなすぐに使用できる様々なセッション・モデル実装を備えています。
トラディショナル・モデルでは、すべてのセッション状態を単一のエンティティとして保存しますが、属性は個別にシリアライズおよびデシリアライズします。
モノリシック・モデルでは、すべてのセッション状態を単一のエンティティとして保存し、すべての属性を単一の操作としてシリアライズおよびデシリアライズします。
スプリット・モデルは、トラディショナル・モデルを拡張したモデルですが、大きなセッション属性は独立した複数の物理エンティティに分離します。
|
注意: 一般的に、同じCoherenceクラスタに属するWebアプリケーションは、同じセッション・モデル・タイプを使用する必要があります。構成に一貫性がないと、デシリアライズ・エラーが発生することがあります。 |
図4-1は、3つのセッション・モデルを示しています。
TraditionalHttpSessionModelとTraditionalHttpSessionCollectionでは、特定のセッションのすべてのHTTPセッション・データを単一のCoherenceキャッシュ・エントリで管理しますが、HTTPセッション属性(特に、そのシリアライズとデシリアライズ)は個別に管理します。
このモデルは、HTTPセッション・オブジェクトが比較的小型で(10KB以下)、セッション属性間でオブジェクト共有の問題が発生しない用途に最適です (セッション属性間のオブジェクト共有は、1つのセッションにある複数の属性で同じオブジェクトを参照する場合に発生します。このような状況では、HTTPセッションを後でデシリアライズすると、これらの属性のシリアライズとデシリアライズが独立して実行されるので、共有オブジェクトの複数のインスタンスが発生します)。
MonolithicHttpSessionModelとMonolithicHttpSessionCollectionは、トラディショナル・モデルの場合と似ていますが、すべての属性を1つのオブジェクト・ストリームにシリアライズおよびデシリアライズすることで、共有オブジェクトの問題を解決している点が異なります。そのため、モノリシック・モデルはトラディショナル・モデルよりパフォーマンスが低下することがよくあります。
SplitHttpSessionModelとSplitHttpSessionCollectionは、主要なHTTPセッション・メタデータとすべての小型セッション属性を、トラディショナル・モデルと同じ方法で格納します。これにより、バイナリ・セッション・データのブロックを小型に維持できるので、高いパフォーマンスが得られます。すべての大型の属性は、独立したキャッシュ・エントリに分割して別々に管理するので、リクエストが発生するたびにクラスタ内でアクセスまたは更新を必要とするデータ量を増やさずに、大規模なHTTPセッション・オブジェクトをサポートできます。つまり、属性の更新によってネットワーク・オーバーヘッドが発生するのは、特定のリクエストで大型の属性を変更する場合のみです。したがって、一般的にスプリット・モデルでは、主要なHTTPセッション・データへのアクセスでも、またどのセッション属性へのアクセスでもネットワーク・オーバーヘッドがほとんど発生しません(これはニア・キャッシュを使用しているからです)。
次の一覧に、アプリケーションに対してどのセッション・モデルを選択するかについて推奨事項を示します。
スプリット・モデルは、ほとんどの用途にお薦めできるセッション・モデルです。
トラディショナル・モデルは、HTTPセッション・オブジェクトが小型であることがわかっている用途に適しています。
モノリシック・モデルは、複数のセッション属性で1つの共有オブジェクトを参照し、そのオブジェクトを共有オブジェクトとして維持する必要がある場合、それら複数のセッション属性に関連する特定のクラスの問題を解決することを目的としています。
クラスタ環境におけるこれらのモデルの動作は、『Oracle Coherenceスタート・ガイド』の「クラスタ・アプリケーションのセッション管理」を参照してください。
Coherence*Webを使用すると、アプリケーションの境界を越えてセッション・データとセッション属性の両方のスコープをどのように設定するか(共有するか)についてきめ細かな制御が可能になります。
Coherence*Webを使用すると、同じWebコンテナまたは別々のWebコンテナにデプロイした複数のWebアプリケーションでセッション・データを共有できます。これを実現するには、セッションCookieコンテキスト・パラメータを正しく構成して、セッション属性に保存したオブジェクトのクラスを各Webアプリケーションで使用できるようにする必要があります。
Cookieを使用してセッションIDを保存している場合(つまり、URLリライティングを使用していない場合)、セッションCookieパスには、セッション・データを共有するすべてのWebアプリケーションの共通コンテキスト・パスを設定する必要があります。たとえば、/web/HRPortalと/web/InWebのコンテキスト・パスで登録した2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-pathパラメータを/webに設定する必要があります。一方、/HRPortalと/InWebのコンテキスト・パスで2つのWebアプリケーションを登録している場合は、coherence-session-cookie-pathパラメータを「/」に設定する必要があります。
セッション・データの共有を必要とする複数のWebアプリケーションのそれぞれを、互いに別のマシンで実行している別のWebコンテナにデプロイしている場合に、これらのマシンに共通のロード・バランシングを適用していないと、セッションCookieドメインをこれらのマシンで共有しているドメインに構成することも必要です。たとえば、server1.mydomain.comとserver2.mydomain.comで実行している2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-domainコンテキスト・パラメータを.mydomain.comに設定する必要があります。
共有セッションに保存したオブジェクトを適切にシリアライズまたはデシリアライズするには、セッション属性に保存したすべてのオブジェクトのクラスを、セッション・データを共有するWebアプリケーションで使用できるようにする必要があります。
|
注意: EARクラスタ・ノードのスコープ設定またはアプリケーション・サーバーJVMクラスタのスコープ設定を採用し、かつ個々のWebアプリケーション間でセッション・データを共有しない高度な用途は、「Webアプリケーション間でのセッション・データ共有の禁止」を参照してください。 |
同じCoherenceクラスタに属する複数のJava EEアプリケーションであっても、HTTPセッション・データを共有しないようにすることが必要な場合があります。たとえば、EJB層でキャッシュ・データを共有する2つのアプリケーションHRPortalおよびInWebがあり、それぞれで使用するセッション・データは互いに別であるとします。この2つのアプリケーションにとって、1つのCoherenceクラスタに属していることは必要ですが、セッション・データについては同じクラスタ・サービスを使用しないようにする必要があります。これを実行する方法の1つは、ApplicationScopeControllerを使用して、アプリケーションの属性のスコープを定義することです。「セッション属性スコープ設定」でこの手法について説明します。もう1つの方法は、アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定することです。
アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定する手順は、次のとおりです。
アプリケーションの各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>
Coherence*Webで実行している複数のアプリケーションを操作する場合、それらに複数の異なるキャッシュ構成を設定できます。この場合、キャッシュ・サーバーのキャッシュ構成には、記憶域を有効化して実行しているか記憶域を無効化して実行しているかに関係なく、これらのキャッシュ構成の和を含める必要があります。これにより、同じキャッシュ・クラスタでそれらのアプリケーションをサポートできます。
Cookieを使用してセッションIDを保存している場合は、あるアプリケーションで作成したセッションCookieが別のアプリケーションに伝播されないようにする必要があります。これを実現するには、各アプリケーションのweb.xmlファイルで、そのアプリケーションのセッションCookieのドメインとパスを設定する必要があります。Cookieが伝播されないようにするには、2つのアプリケーションで同じコンテキスト・パスを共有しないようにします。
たとえば、2つのWebアプリケーションをそれぞれ/web/HRPortalと/web/InWebのコンテキスト・パスで登録しているとします。これらのWebアプリケーションがCookieでセッション・データを共有しないようにするには、一方のアプリケーションのCookieパスを/web/HRPortalに設定し、もう一方のアプリケーションのCookieパスを/web/InWebに設定します。
それぞれ別のマシンで実行している異なるWebコンテナに複数のアプリケーションをデプロイした場合、それらが同じドメインにならないようにCookieドメインを構成できます。
たとえば、2つのWebアプリケーションをserver1.mydomain.comとserver2.mydomain.comで実行しているとします。それらの間でセッションCookieを共有しないようにするには、一方のアプリケーションのCookieドメインをserver1.mydomain.comに設定し、もう一方のアプリケーションのCookieドメインをserver2.mydomain.comに設定します。
複数のWebアプリケーションでセッションを共有している場合は、セッション属性をグローバルに認識できるように(すべてのWebアプリケーションからアクセスして変更できるようにする)、または逆に個々のWebアプリケーションのみで認識できるように(他のアプリケーションのインスタンスからはアクセスできないようにする)、個々のセッション属性のスコープをアプリケーションで設定することが必要になる場面が数多くあります。
Coherence*Webでは、この動作はAttributeScopeControllerインタフェースを使用して制御できます。複数のアプリケーションでセッションを共有する場合に、このオプション・インタフェースを使用して属性を選択的にスコープ設定できます。これにより、他のアプリケーションの属性を誤って読取り、更新、削除することなく、複数のアプリケーションでアプリケーション・スコープ状態について同じ属性名を使用できます。セッションでは、アプリケーション別スコープを設定した情報のほか、セッションを共有するすべてのアプリケーションで読取り、更新、および削除できるグローバルな(スコープ設定していない)情報を保持することもできます。
AttributeScopeContollerインタフェースの2つの実装(ApplicationScopeControllerとGlobalScopeController)がすぐに使用できます。GlobalScopeControllerの実装は属性のスコープを設定しませんが、ApplicationScopeControllerでは、すべての属性名の先頭にアプリケーションの名前を追加することによって、すべての属性のスコープをアプリケーションに設定します。
coherence-application-nameコンテキスト・パラメータを使用して、アプリケーション(およびアプリケーションが記述されたWebモジュール)の名前を指定できます。ApplicationScopeControllerでは、アプリケーションの名前を使用して属性のスコープを設定します。このパラメータを構成しない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。詳細は、表2-1のcoherence-application-nameの説明を参照してください。
|
注意: 構成済のAttributeScopeControllerは、作成後、属性名の修飾に使用できるWebアプリケーションの名前を使用して初期化されます。coherence-application-nameコンテキスト・パラメータを使用して、Webアプリケーションの名前を構成します。 |
Coherence*Webでは、複数のアプリケーションが同じセッション・オブジェクトを共有できます。これを行うには、セッション属性がすべてのアプリケーションから参照可能である必要があります。また、WebLogic Serverで処理するURLにおいてCookieを受信できるURLを指定する必要があります。
アプリケーションでセッション属性の共有および変更ができるようにするには、web.xmlファイルのcoherence-scopecontroller-classコンテキスト・パラメータの値としてGlobalScopeController(com.tangosol.coherence.servlet.AbstractHttpSessionCollection$GlobalScopeController)を参照します。GlobalScopeControllerは、com.tangosol.coherence.servlet.HttpSessionCollection$AttributeScopeControllerインタフェースの実装であり、これによって個別のセッション属性をグローバルに参照できます。
例4-2は、web.xmlファイルで指定されたGlobalScopeControllerインタフェースを示しています。
例4-2 web.xmlで指定されたGlobalScopeController
<?xml version="1.0" encoding="UTF-8"?> <web-app> ...
<context-param>
<param-name>coherence-scopecontroller-class</param-name>
<param-value>com.tangosol.coherence.servlet. AbstractHttpSessionCollection$GlobalScopeController</param-value>
</context-param>
...
</web-app>
Coherence*Webをデプロイする方法はいくつかあります。デプロイメント・オプションについて決定するときの考慮事項の1つは、クラスタ・ノード分離です。クラスタ・ノード分離の考慮事項は次のとおりです。
アプリケーション・サーバーJVMに作成されるCoherenceノードの数
Coherenceライブラリのデプロイ先
アプリケーションには、アプリケーション・サーバー・スコープ、EARスコープ、またはWARスコープを設定できます。この項では、これらの考慮事項について説明します。これらの各オプションのXML構成の詳細は、「クラスタ・ノードの構成(WebLogic Server 10.3.3以降)」を参照してください。
この構成では、Coherence*Webを使用するコンテナにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、クラスタに作成されるCoherenceノードの数が最小となります(WebコンテナJVMごとに1つ)。また、Coherenceライブラリ(coherence.jar)がコンテナのクラスパスにデプロイされるので、JVMにロードされるCoherenceクラスのコピーは1つのみです。これによって、リソースの使用が最小限に抑えられます。その一方で、すべてのアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのアプリケーションに不具合があるとすべてのアプリケーションが影響を受けます。
この構成を使用する場合の要件は次のとおりです。
デプロイする各アプリケーションは、同じバージョンのCoherenceを使用し、同じクラスタに属する必要があります。
HTTPセッションに配置されたオブジェクトのクラスは使用可能である必要があります。
アプリケーション・サーバー・スコープ設定クラスタ・ノードのXML構成は、「アプリケーション・サーバー・スコープ設定クラスタ・ノードの構成」を参照してください。
|
注意: アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では絶対に使用しないでください。このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・グループでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。 このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択したらよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください。 |
この構成では、EARごとにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、Coherence*Webを使用するデプロイ済EARごとに1つのCoherenceノードが作成されます。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にある複数のスレッドからセッションに同時アクセスできます。この場合、最後の書込みが優先されます。
メンバー・ロック: 同じJVMにある複数のスレッドからセッションに同時にアクセスし、同時にセッションを変更できます。別々のJVMにあるスレッドからは同時にアクセスできません。
アプリケーション・ロック: 同じWebアプリケーション・インスタンスにある複数のスレッドから同時にセッションにアクセスし、同時にセッションを変更できます。別々のWebアプリケーション・インスタンスにあるスレッドからは同時にアクセスできません。
スレッド・ロック: 単一のJVMにある複数のスレッドからセッションに同時にアクセスできず、同時にセッションを変更することもできません。
|
注意: 一般的に、同じクラスタに属するWebアプリケーションは、同じロック・モードおよびスティッキー・セッション最適化設定を使用する必要があります。構成に一貫性がないと、デッドロックが発生することがあります。 |
この項で説明したパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
Coherence*WebとCoherence*Web SPIは、デフォルトでオプティミスティック・ロックを使用するように構成されています。オプティミスティック・ロック・モードを使用すると、1つ以上のJVMにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了後、楽観的なアプローチで同時更新を検出して防止します。Coherence*Webで同時変更が検出されると、ConcurrentModificationExceptionがアプリケーションにスローされるので、この例外をアプリケーションで適切に処理できるように準備しておく必要があります。例外を表示するには、コンテナの起動スクリプトでweblogic.debug.DebugHttpSessionsシステム・プロパティをtrueに設定します(例: -Dweblogic.debug.DebugHttpSessions=true)。
オプティミスティック・ロック・モードは、coherence-session-member-lockingコンテキスト・パラメータをfalseに設定して構成できます。
最後の書込みを優先するロックは、オプティミスティック・ロック・モードの一種です。これを使用すると、1つ以上のJVMにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了時に同時更新は防止されません。かわりに、最後の書込みによってセッションが変更されます。
最後の書込みを優先するロック・モードは、coherence-session-lockingパラメータをfalseに設定することによって構成できます。この値により、セッションに対して最後の更新が優先される同時変更ができます。coherence-session-app-locking、coherence-session-member-lockingまたはcoherence-session-thread-lockingのコンテキスト・パラメータをtrueに設定した場合は、この値は無視されます(論理的にtrueとされます)。デフォルトはfalseです。
メンバー・ロック・モードを使用すると、同じクラスタ・ノードにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスして変更できますが、別々の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に要求する必要がありません。
Coherence*Webは、メンバーがセッションに対してクラスタ・ロックを取得できない場合に実行される診断起動サービスを提供します。このサービスを有効にするかどうかはcoherence-session-log-threads-holding-lockコンテキスト・パラメータで設定します。このコンテキスト・パラメータをtrue(デフォルト)に設定した場合、この起動サービスによって、セッションの所有権を持つメンバーが、現在ロックを保持しているスレッドのスタック・トレースを記録するようになります。
すべてのCoherence*Webメッセージと同様に、Coherence logging-configオペレーション構成要素によって、メッセージの記録方法が制御されます。Coherenceにおけるロギングの構成方法の詳細は、『Oracle Coherence開発者ガイド』で付録「オペレーション構成の要素」のlogging-configに関する項を参照してください。
スティッキー・ロード・バランサの対象となっているWebアプリケーションの要件としてメンバー・ロック、アプリケーション・ロック、またはスレッド・ロックがある場合は、HTTPセッションへのアクセスに必要なクラスタ規模のロックの取得をCoherence*Webで最適化できます。その名が示すとおり、スティッキー・ロード・バランサは、セッションに対する各リクエストを、前回そのセッションでリクエストの転送先として使用されたものと同じアプリケーション・サーバーJVMにルーティングしようとします。これは、そのセッションを作成したアプリケーション・サーバーJVMと同じものです。スティッキー・セッション最適化では、セッションに対するクラスタ規模のロックをそのセッションの有効期限が切れるまで、または解放するよう要求されるまで保持することによって、この動作を利用しています。なんらかの理由で、スティッキー・ロード・バランサが同じセッションに対するリクエストを別のアプリケーション・サーバーJVMに送信した場合は、そのJVMから該当セッションのロックを保持しているJVMに対して、できるだけ早くロックを解放するよう要求します。詳細は、表C-2のSessionOwnershipエントリを参照してください。
スティッキー・セッション最適化は、coherence-sticky-sessionsコンテキスト・パラメータをtrueに設定すると有効になります。この設定では、メンバー、アプリケーションまたはスレッドのロックが有効になっている必要があります。
Coherence*Webでは、Coherenceで使用できるデプロイメント・トポロジのほとんどを使用できます。これには、インプロセス・トポロジ、アウトオブプロセス・トポロジ(クライアント/サーバー・デプロイメント)、Coherence*Extendを介してクライアントとサーバーをブリッジするトポロジなどがあります。サポートされている主なデプロイメント・トポロジについて次で説明します。
インプロセス: ローカル記憶域有効化とも呼ばれます。セッション・データはアプリケーション・サーバーで処理中に保存されます。
アウトオブプロセス: ローカル記憶域無効化とも呼ばれます。アプリケーション・サーバーはキャッシュ・クライアントとして構成され、専用のJVMがキャッシュ・サーバーとして動作し、クラスタ化データを物理的に保存および管理します。
Coherence*Extendによるアウトオブプロセス: アプリケーション・サーバー層とキャッシュ・サーバー層との間の通信はCoherence*Extend(TCP/IP)を介して行われます。
インプロセス・トポロジは、本番環境での使用にはお薦めできません。主に、開発用とテスト用としてサポートされています。このトポロジは、アプリケーション・サーバーを使用してセッション・データをプロセス内で保存することで、容易に起動して、スモーク・テスト、開発、およびテスト用として高速で実行できます。このトポロジでは、ローカル記憶域が有効化(tangosol.coherence.distributed.localstorage=true)されます。
アウトオブプロセス・デプロイメント・トポロジでは、アプリケーション・サーバー(アプリケーション・サーバー層)をキャッシュ・クライアントとして構成し(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 | オブジェクト名 |
|---|---|
|
|
|
表4-2は、HttpSessionManagerMBeanが提供する情報を示しています。操作を表すresetStatistics以外の名前はすべて属性を表します。
MBean属性の中には、次の接頭辞を使用しているものがあります。
LocalSession: クラスタの一部のメンバーにのみ分散されるセッションを意味します。分散元のサーバーに対して、このセッションはその存続期間中の特定の時点まで「ローカル」のままです。
LocalAttribute: クラスタの一部のメンバーにのみ分散されるセッション属性を意味します。
Overflow: 普通は、高速なフロントエンド・キャッシュから排除されたエントリを捕捉する、大容量で低速なバックエンド・キャッシュです。
表4-2 HttpSessionManagerMBeanから返される情報
| 名前 | データ型 | 説明 |
|---|---|---|
|
long |
統計をリセットした時点以降の平均リープ時間(リープ・サイクルが完了するまでの時間)でミリ秒単位。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。 |
|
|
String |
使用中の |
|
|
String |
使用中の |
|
|
long |
最後のリープ・サイクルの終了に要した時間(ミリ秒単位)。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。 |
|
|
String |
分散されないセッション属性を保存するローカル・キャッシュの名前。この属性がnullの場合、セッション属性のローカル記憶域は無効です。 |
|
|
Integer |
セッション属性のローカル・キャッシュに保存された分散されないセッション属性の数。この属性が |
|
|
String |
分散されないセッションを保存するローカル・キャッシュの名前。この属性が |
|
|
Integer |
セッションのローカル・キャッシュに保存された分散されないセッションの数。この属性が |
|
|
long |
統計をリセットした時点以降にリープ・サイクルでリープされたセッションの最大数。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。 |
|
|
java.lang.Date |
|
|
|
Integer |
統計を前回リセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の平均サイズ(バイト数)。この属性が |
|
|
String |
所定のサイズより大きいことから、シリアライズしたセッション・オブジェクト自体の一部としてではなく、個別のキャッシュ・エントリとしたほうが効率的に管理できると判断される「大型の属性」を保存するクラスタ・キャッシュの名前。 |
|
|
Integer |
統計を前回リセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の最大サイズ(バイト数)。 |
|
|
Integer |
大型の属性向けに確保されている独立した「オーバーフロー」キャッシュにシリアライズ形式の属性値を格納する必要がある場合における最小の長さ(バイト数単位)。 |
|
|
Integer |
統計を最後にリセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の更新回数。 |
|
|
long |
前回のサイクル中にリープしたセッションの数。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。 |
|
|
long |
統計をリセットした時点以降にリープされた期限切れセッションの数。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。 |
|
|
String |
|
|
|
String |
Webアプリケーション |
|
|
Integer |
統計を最後にリセットした時点以降、有効期限切れまたは明示的な無効化によって無効になったセッション・オブジェクトの平均存続期間(秒数)。 |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの平均サイズ(バイト数)。 |
|
|
String |
シリアライズしたセッション・オブジェクトを保存するクラスタ・キャッシュの名前。 |
|
|
Integer |
生成されたセッションIDの長さ(文字数)。 |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの最大サイズ(バイト数)。 |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの最小サイズ(バイト数)。 |
|
|
Integer |
Webアプリケーションのこのインスタンスに関連付けられたセッション・オブジェクトの数。スティッキー・セッション最適化が無効になっている場合、この属性は |
|
|
Integer |
セッションの存続期間(秒数)。セッションが無期限の場合、この属性は |
|
|
Integer |
統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに保存されたセッション・オブジェクトの更新回数。 |
|
|
void |
セッション管理統計をリセットします。 |
図4-11は、JConsoleブラウザに表示されたHttpSessionManagerMBeanを示しています。
図4-11 JConsoleブラウザに表示されたHttpSessionManagerMBean
Coherenceには、Reporterと呼ばれるJMXベースのレポート・ユーティリティが組み込まれています。Reporterには、管理者および開発者が容量の管理や問題のトラブルシューティングを行う際に役立つ事前構成済レポートが用意されています。これらのレポートは、Coherence*Web向けに特別に調整されています。
Webセッション記憶域レポート: クラスタのセッション・オブジェクトとデータが格納されるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。
Webセッション・オーバーフロー・レポート: Webセッション記憶域キャッシュからセッション・オブジェクトおよびデータがオーバーフローできるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。
Webレポート: クラスタに対するCoherence*Webアクティビティに関する情報を記録します。
Webサービス・レポート: Coherence*Webアプリケーションを実行するサービスに関する情報を記録します。
Coherence*Webのレポートは、バッチ・レポートの一部として実行します。これらは、report-web-group.xmlバッチ・レポートと包括的report-all.xmlバッチ・レポートの両方で定義されています。それらをカスタム・バッチ・レポートに組み込むこともできます。Coherence*Webのレポートは、デフォルト・レポート・グループ・バッチ・ファイルであるreport-group.xmlでは定義されていません。
デフォルトでは、Reporterによってreport-group.xmlバッチ・レポートが実行されます。かわりにreport-web-group.xml、report-all.xmlまたはカスタム・バッチ・レポートを実行するには、tangosol.coherence.management.report.configurationシステム・プロパティを使用します。例4-3は、プロパティを使用して、実行するレポート・グループ・バッチ・ファイルをreport-web-group.xmlに変更するコマンドラインを示しています。
例4-3 コマンドラインにおけるレポート・グループの指定
java -Dcom.sun.management.jmxremote
-Dtangosol.coherence.management=all
-Dtangosol.coherence.management.remote=true
-Dtangosol.coherence.management.report.autostart=false
-Dtangosol.coherence.management.report.distributed=false
-Dtangosol.coherence.management.report.configuration=reports/report-web-group.xml
-jar coherence.jar
report-web-group.xml、report-all.xmlおよびreport-group.xmlのレポート・グループ・バッチ・ファイルは、coherence.jarのreportsフォルダにあります。
|
注意: Reporterの構成、事前構成済レポートの実行、カスタム・レポートの作成などReporterの詳細は、『Oracle Coherence開発者ガイド』でCoherenceの管理に関する項のある章を参照してください。 |
Webセッション記憶域レポートは、セッション・オブジェクトおよびデータが格納されるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。この統計には、セッション記憶域キャッシュに対して実行された書込み、取得および削除の回数、ならびにこれらの処理の所要時間に関する情報が含まれます。
このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付が、末尾には--session-storage.txtが付きます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-session-storage.txtになります。表4-3は、Webセッション記憶域レポートの内容を示しています。
表4-3 Webセッション記憶域レポートの内容
| 列 | データ型 | 説明 |
|---|---|---|
|
|
long |
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、ファイルの統合において有用な情報になります。 |
|
|
String |
この値は常に |
|
|
long |
前回のレポート実行以降においてクラスタ全体でキャッシュに対して削除が実行されたセッションの合計数。 |
|
|
Date |
レポートが実行されたシステム時間。 |
|
|
String |
値は |
|
|
long |
前回のレポート実行以降におけるクラスタ全体でのキャッシュに対するセッション記憶域の書込み失敗の合計回数。 |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のセッション取得の合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッションを取得するために |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のセッション・ヒットの合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション記憶域に対するヒットした |
|
|
long |
前回のレポート実行以降においてクラスタ全体でキャッシュに対してキャッシュ・ミスが返されたセッション取得の合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション記憶域に対してキャッシュ・ミスとなった |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション記憶域キャッシュが削除された回数の合計。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション記憶域キャッシュを削除するための削除操作に要した時間(PrunesMillis)の合計(ミリ秒単位)。 |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のセッション更新(書込み)の合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッションを更新するために |
|
|
long |
クラスタ全体におけるセッション記憶域キャッシュのキュー・リンクの合計。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体のキャッシュに対する外部キャッシュ記憶域に書き込まれたセッションの合計数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体で外部キャッシュ記憶域を更新するための書込み操作を行うたびに要した時間(WritesMillis)の合計(ミリ秒単位)。 |
Webセッション・オーバーフロー・レポートは、セッション・オブジェクトおよびデータのオーバーフローが格納されるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。この統計には、セッション・オーバーフロー・キャッシュに対して実行された書込み、取得および削除の回数、ならびにこれらの処理の所要時間に関する情報が含まれます。
このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日付が、末尾には-cache-session-overflow.txtが付きます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-cache-session-storage.txtになります。表4-4は、Webセッション・オーバーフロー・レポートの内容を示しています。
表4-4 Webセッション・オーバーフロー・レポートの内容
| 列 | データ型 | 説明 |
|---|---|---|
|
|
long |
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、ファイルの統合において有用な情報になります。 |
|
|
String |
この値は常に |
|
|
long |
前回のレポート実行以降においてクラスタ全体でキャッシュに対して削除が実行されたセッション・オーバーフローの合計回数。 |
|
|
Date |
レポートが実行されたシステム時間。 |
|
|
String |
値は |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のキャッシュに対するセッション・オーバーフロー記憶域の書込み失敗の合計回数。 |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のセッション・オーバーフロー取得の合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション・オーバーフローを取得するために |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のセッション・オーバーフロー・ヒットの合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション・オーバーフローに対するヒットしたget()コールの所要時間(HitsMillis)の合計(ミリ秒単位)。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でキャッシュに対してキャッシュ・ミスが返されたセッション・オーバーフロー取得の合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション・オーバーフローに対してキャッシュ・ミスとなった |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション・オーバーフロー・キャッシュが削除された回数の合計。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション・オーバーフロー・キャッシュを削除するための削除操作に要した時間(PrunesMillis)の合計(ミリ秒単位)。 |
|
|
long |
前回のレポート実行以降におけるクラスタ全体のセッション・オーバーフロー(書込み)の合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体でセッション・オーバーフローを更新するために |
|
|
long |
クラスタ全体におけるセッション・オーバーフロー・キャッシュのキュー・リンク・サイズの合計。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体のキャッシュに対する外部キャッシュ記憶域に書き込まれたセッション・オーバーフローの合計回数。 |
|
|
long |
前回のレポート実行以降においてクラスタ全体で外部セッション・オーバーフロー記憶域を更新するための書込み操作を行うたびに要した時間(WritesMillis)の合計(ミリ秒単位)。 |
Webレポートは、クラスタに対するCoherence*Webアクティビティに関する情報を記録します。このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日時が、末尾には-web.txtが付きます。たとえば、2009年1月1日午前2時に作成されたファイルの名前は、2009013102-web.txtになります。表4-5は、Webレポートの内容を示しています。
表4-5 Webレポートの内容
| 列 | データ型 | 説明 |
|---|---|---|
|
|
String |
アプリケーション名。 |
|
|
long |
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、ファイルの統合において有用な情報になります。 |
|
|
long |
前回のレポート実行以降におけるオーバーフロー更新の回数。 |
|
|
long |
前回のレポート実行以降におけるセッション更新の回数。 |
|
|
long |
ノード上の属性数。 |
|
|
long |
ノード上のセッション数。 |
|
|
Integer |
ノード識別子。 |
|
|
float |
属性オーバーフローの平均サイズ。 |
|
|
long |
属性オーバーフローの最大サイズ。 |
|
|
long |
統計を最後にリセットした時点以降の属性オーバーフロー更新の合計回数。 |
|
|
Date |
レポートが実行されたシステム時間。 |
|
|
float |
セッション持続時間の平均時間(秒単位)。 |
|
|
float |
セッションの平均サイズ。 |
|
|
long |
セッションの最大サイズ。 |
|
|
long |
セッションの最小サイズ。 |
|
|
long |
ノード上のスティッキー・セッションの数。 |
|
|
long |
統計を最後にリセットした時点以降のセッション更新の回数。 |
Webサービス・レポートは、Coherence*Webアプリケーションを実行するサービスに関する情報を提供します。このレポートは、処理済のリクエスト、失敗したリクエスト、未処理のリクエスト、処理済のタスク、失敗したタスクおよび未処理のタスクに関する情報を記録します。Request CountおよびTask Countは、サービスのパフォーマンスとスループットの確認に有用です。RequestPendingCountおよびTask Backlogは、容量の問題やブロックされたプロセスの特定に有用です。Task Hung Count、Task Timeout Count、Thread Abandoned Count、Request Timeout Countは、システムで発生した実行の失敗回数を示します。
このレポートはタブ区切りのファイルで、名前の先頭にはYYYYMMDDHH形式の日時が、末尾には-web-session-service.txtが付きます。たとえば、2009年1月1日午前2時に作成されたファイルの名前は、2009013102-web-session-service.txtになります。表4-6は、Webサービス・レポートの内容を示しています。
表4-6 Webサービス・レポートの内容
| 列 | データ型 | 説明 |
|---|---|---|
|
|
Long |
関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、ファイルの統合において有用な情報になります。 |
|
|
String |
数値のノード識別子。 |
|
|
Date |
サービス情報がリモート・ノードから更新されたシステム時間。 |
|
|
Long |
前回のレポート実行以降におけるCoherence*Webアプリケーションによるリクエストの数。 |
|
|
Long |
レポート実行時点におけるCoherence*Webアプリケーションによる保留中リクエストの数。 |
|
|
Long |
レポート実行時点におけるCoherence*Webアプリケーションの保留中リクエストの待機時間。 |
|
|
Long |
前回のレポート実行以降におけるCoherence*Webアプリケーションによるリクエスト・タイムアウトの回数。 |
|
|
Date |
レポートが実行されたシステム時間。 |
|
|
String |
サービス・ファイルと情報をマージする場合にサービス名として使用される静的値( |
|
|
Long |
レポート実行時点におけるCoherence*Webアプリケーションの未処理タスクの数。 |
|
|
Long |
前回のレポート実行以降におけるCoherence*Webアプリケーションによって実行されたタスクの数。 |
|
|
Long |
前回のレポート実行以降におけるCoherence*Webアプリケーションによってハングしたタスクの数。 |
|
|
Long |
前回のレポート実行以降におけるCoherence*Webアプリケーションによるタスク・タイムアウトの数。 |
|
|
Long |
前回のレポート実行以降におけるCoherence*Webアプリケーションによって破棄されたスレッドの数。 |
Coherence*Webセッション管理モジュールの一環として、期限切れのHTTPセッションは最終的にセッション・リーパーによってクリーンアップされます。セッション・リーパーは、JVM固有のガベージ・コレクション(GC)機能に似たサービスを提供します。つまり、有効期限が切れたときに不要になったと判定されたすべてのセッションを破棄する役目を担います。
各HTTPセッションには、有効期限がいつ切れたかを判定する2つの情報が保持されます。1つ目は、そのセッションを最後に使用したアクティビティのタイムスタンプを示すLastAccessedTimeセッション・プロパティです。2つ目は、アクティビティがない状態でのセッション存続時間を指定するMaxInactiveIntervalセッション・プロパティです。一般に、このプロパティの値は30分に指定されます。MaxInactiveIntervalプロパティは、デフォルトでCoherence*Webに対して構成された値に設定されますが、セッションごとに変更することも可能です。
サーバーがHTTPリクエストを受信したときに、そのリクエストに関連付けられたHTTPセッションがある場合は、その都度セッションのLastAccessedTimeプロパティが現在の時刻に自動的に更新されます。そのセッションは、関連するリクエストが送信され続けるかぎり存続します。ただし、MaxInactiveIntervalプロパティで指定された時間の間、アクティビティがないと、そのセッションは期限切れとなります。セッションの期限切れは受動的に、すなわち時間の経過によってのみ発生します。Coherence*Webセッション・リーパーは、期限切れとなったセッションをスキャンし、見つかった場合はそれらを破棄します。
セッション・リーパーは、次の3つの基本的な質問に対応して構成します。
どのサーバーでリーパーを実行するか
どのくらいの頻度でリーパーを実行するか
リーパーを実行するときに、どのサーバー上で期限切れのセッションを検出するか
セッション・リーパーは、Coherence*Webを実行するすべてのアプリケーション・サーバーで実行されます。つまり、キャッシュ・サーバーで構成される個別のキャッシュ層を提供するようにCoherenceが構成されている場合、セッション・リーパーはそれらのキャッシュ・サーバー上では実行されません。
デフォルトでは、セッション・リーパーはすべてのアプリケーション・サーバーで同時に実行されるため、期限切れのセッションを特定してクリーンアップするためのワークロードをすべてのサーバーで共有できます。coherence-reaperdaemon-cluster-coordinatedコンテキスト・パラメータを使用すると、一度に1台のサーバーのみが実際のリープを実行するようにクラスタ内のリープを調整しますが、このオプションを使用することはお薦めできません。また、このオプションは、Coherence*Extendトポロジを使用しているCoherence*Webには使用できません。
スティッキー最適化(coherence-sticky-sessions)も有効化されている場合は、coherence-reaperdaemon-cluster-coordinatedコンテキスト・パラメータを使用しないでください。リープは一度に1台のサーバーによってのみ実行されるため、他のノードが所有するセッションはリープできません。したがって、クラスタに追加されたノードが多くなるほど、セッションのリープにかかる時間は長くなります。また、クラスタ内のノードでリープの所有権がどのように巡回するのかは制御されません。別のノードに渡される前に、1つのノードが長時間にわたってリープ・ノードとなることがあります。その間は、そのノードのセッションのみがリープされます。
セッション・リーパーは、リープ・サイクルと呼ばれる一定の期間(デフォルトは5分)にわたってすべてのセッションをスキャンするように構成されます。このリープ・サイクルの長さはcoherence-reaperdaemon-cycle-secondsコンテキスト・パラメータで指定します。この設定は、セッション・リーパーの動作のアグレッシブさを示します。サイクルの長さが短すぎると、セッション・リーパーはリソースを余分に使用するだけで、特別な効果はもたらしません。サイクルの長さが長すぎると、期限切れセッションがCoherenceキャッシュ内のヒープ領域を不要に使用することになります。多くの場合、期限切れになったセッションを即座にクリーンアップすることよりも、リソースの使用量を減らすことの方がはるかに多く望まれます。したがって、デフォルトの5分というサイクルは、クリーンアップの迅速性と最小限のリソース使用量という両方の点をバランスよく保つことのできる長さです。
リープ・サイクルの期間中、セッション・リーパーは期限切れのセッションをスキャンします。ほとんどの場合、セッション・リーパーはクラスタ全体のすべてのHTTPセッションをスキャンするよう構成されますが、単一層トポロジに適用できる最適化も用意されています。単一層トポロジでは、記憶域が有効でアプリケーション・サーバーも実行しているCoherenceクラスタ・メンバーによってすべてのセッションが管理される場合、セッションの記憶域はアプリケーション・サーバーと同じ場所に配置されます。したがって、各アプリケーション・サーバーでは、ローカルに格納されるセッションしかセッション・リーパーがスキャンしないという可能性もあります。この動作は、coherence-reaperdaemon-assume-locality構成オプションをtrueに設定すると有効にできます。
同じ場所に配置されたセッションのみをスキャンするか、すべてのセッションをスキャンするかにかかわらず、セッション・リーパーは次のCoherenceデータ・グリッドの高度な機能を使用して、非常に効率的な方法でセッションをスキャンします。
セッション・リーパーは、カスタムのValueExtractor実装を使用してデータ・グリッドに期限切れセッションの検索を委譲します。このValueExtractorは、BinaryEntryインタフェースを利用するため、セッションをデシリアライズしなくても、そのセッションが期限切れかどうかを判別できます。そのため、期限切れセッションの選択を他のパラレル問合せとまったく同じようにデータ・グリッドに委譲して、記憶域が有効なCoherenceメンバーで非常に効率的な方法で実行できるようになります。
セッション・リーパーは、com.tangosol.net.partition.PartitionedIteratorクラスを使用してメンバーごとに自動問合せを行います。またこの問合せは、大規模クラスタのハーモニックを回避するランダムな順序で実行されます。
記憶域が有効な各メンバーは、すべての期限切れセッションを非常に効率的にスキャンでき、リーパー・サイクルごとに各アプリケーション・サーバーで必要となるスキャンも一度だけですみます。そのため、すぐに使用できるセッション・リーパー構成は、1台以上のサーバーで構成されるアプリケーション・サーバー・クラスタで効果的に機能します。
セッション・リーパーは、セッションをパラレルでもシリアルでも無効化できます。デフォルトでは、セッションはパラレルに無効化されます。これにより、セッションは適時に無効化されます。ただし、同時スレッドが多数あるためにアプリケーション・サーバーJVMの負荷が高い場合は、シリアルに無効化するオプションを選択できます。リーパーがセッションをシリアルに無効化するように構成するには、coherence-reaperdaemon-parallelコンテキスト・パラメータをfalseに設定します。
セッション・リーパーがアプリケーション・サーバーのスムーズな運用に影響しないよう、セッション・リーパーの作業は小さく分割され、リープ・サイクル全体にわたって分散されるようにスケジュールされます。セッション・リーパーは、スケジューリングが必要な作業量を認識する必要があるため、以前のサイクルで実行した作業量の統計を維持し、新しいリープ・サイクルの統計ほど重視されるように統計的重みづけを使用します。このようにセッション・リーパーが作業を分割する理由には、次のものがあります。
セッション・リーパーが同時に実行して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に設定します)。
HttpSessionManagerMBeanWebは、セッション・リーパーのパフォーマンス統計として使用される属性を提供します。これらの統計には、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間が含まれます。
AverageReapDuration: 統計をリセットした時点以降における平均リープ時間(リープ・サイクルが完了するまでの所要時間)で単位はミリ秒。
MaxReapedSessions: 統計をリセットした時点以降における1回のリープ・サイクルでリープしたセッションの最大数。
これらの属性の説明は、「JMXによるアプリケーションの管理と監視」の表4-2にもあります。
これらの属性には、JConsoleなどの監視ツールでもアクセスできます。ただし、それらにアクセスする前に、Coherenceクラスタ化JMXフレームワークを設定しておく必要があります。このフレームワークの構成およびインストールを行う手順は、『Oracle Coherence開発者ガイド』でJMXでのCoherenceの管理方法に関する項を参照してください。
デフォルトでは、WebInstallerで設定されたWebアプリケーションは、サーブレットまたはフィルタがコールされるたびにセッションを取得します。サーブレットまたはフィルタで実際にセッションが必要であるかどうかに関係なく、セッションは取得されます。これにより、セッションが不要なサーブレットやフィルタを多数実行すると、時間がかかる場合や処理に負担がかかる場合があります。
この動作を防止するには、web.xmlファイルのcoherence-session-lazy-accessコンテキスト・パラメータをtrueに設定して遅延取得を有効にします。サーブレットやフィルタがアクセスを試みたときにのみ、セッションは取得されます。
HttpSessionCollection.SessionDistributionControllerインタフェースで記述されるCoherence*Webセッション・ディストリビューション・コントローラを使用すると、Webアプリケーション内のHTTPセッションと属性のデフォルトのディストリビューションをオーバーライドできます。SessionDistributionControllerインタフェースの実装では、セッションと属性を次のいずれかの方法でマークできます。
local: ローカルのセッションまたは属性(あるいはその両方)は、それらの作成元サーバーのヒープに格納されるため、そのサーバーからのみアクセスできます。
distributed: 分散されたセッションまたは属性(あるいはその両方)は、Coherenceのグリッド内に格納されるため、他のサーバーのJVMからアクセスできます。
セッションの存続期間中であればどの時点でも、セッションまたはそのセッションの属性(あるいはその両方)をlocalまたはdistributedから遷移できます。ただし、一度分散されたセッションまたは属性(あるいはその両方)は、localに戻すことはできません。
セッション・ディストリビューション・コントローラには、次のような使い方があります。
新しいセッションは、属性を追加するまで(たとえば、オンライン・ショッピング・カートに1つ目のアイテムを追加するまで)、localのままにできます。これは、セッションに意味のあるデータが含まれる場合のみ、セッションをフォルト・トレラントにする必要があるという発想です。
一部のWebフレームワークは、セッションの属性を使用してUIのレンダリング状態を格納します。一般に、このデータはシリアライズ不能なため、分散できません。セッション・ディストリビューション・コントローラを使用すると、これらの属性を■local｜local｜***□として維持したまま、残りのセッションの属性を分散させることができます。
セッション・ディストリビューション・コントローラは、非分散システムを分散システムに変換する場合に役立ちます。特に、すべてのセッションとすべての属性の分散コストが検討事項となっている場合は有効です。
例4-4は、HttpSessionCollection.SessionDistributionControllerインタフェースの実装例を示しています。この例では、セッションにショッピング・カートがアタッチされているかどうかがテストされます(アタッチされているセッションのみが分散されます)。次に、そのセッションに特定の属性が含まれているかどうかがテストされます。その属性が検出された場合、その属性は分散されません。
例4-4 セッション・ディストリビューション・コントローラの実装例
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構成パラメータを使用して、この実装をアプリケーションに登録できます。これらのパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
Coherence*Webのデプロイメント・オプションの1つに、Coherence*Extendを使用して、WebコンテナのJVMをTCP/IP経由でクラスタに接続する方法があります。この構成は、次のいずれかの状況が該当する場合に検討してください。
Web層JVMがDMZにあるのに、Coherenceクラスタがファイアウォールの内側にあります。
Web層がUDPをサポートしていない環境に作成されています。
Web層JVMで、ガベージ・コレクション(GC)が長時間または頻繁に一時停止します。
Web層JVMが頻繁に再起動します。
このタイプのデプロイメントの参加者には、次の3種類があります。
Web層JVMは、このトポロジではExtendクライアントとして機能します。クラスタのメンバーにはならず、クラスタ内のプロキシ・ノードに接続します。クラスタへのリクエストの発行は、そのプロキシ・ノードが代行します。
プロキシJVMは、クラスタ内の記憶域が無効なメンバーとして、ExtendクライアントからのTCP/IP接続を受け入れ、管理します。クライアントからのリクエストはクラスタに送信され、応答はTCP/IP接続を通じて返されます。
記憶域JVMは、実際のセッション・データをメモリーに格納する際に使用されます。
Coherence*Extendを使用してCoherence*Webを構成する一般的な手順は、次のとおりです。
オプティミスティック・ロック・モードを使用するようにCoherence*Webを構成します。「オプティミスティック・ロック」を参照してください。
プロキシJVMと記憶域JVMのキャッシュ構成ファイルを作成します。「プロキシJVMと記憶域JVMのキャッシュの構成」を参照してください。
1つ以上のプロキシJVMをポイントするようにWeb層キャッシュ構成ファイルを変更します。「Web層JVMのキャッシュの構成」を参照してください。
次の各項では、これらの手順をさらに詳しく説明します。
セッション・キャッシュ構成ファイル(WEB-INF/classes/session-cache-config.xml)は、Coherence*Extendに対してプロキシJVMおよびサーバーJVMを構成するために使用できる、Coherence*Webキャッシュ構成ファイルです。このファイルにはシステム・プロパティのオーバーライドが含まれるため、同じファイルをプロキシJVMと記憶域JVMの両方に使用できます。プロキシJVMで使用する場合は、表4-7に示すシステム・プロパティを指定します。
表4-7 プロキシJVM用のシステム・プロパティ値
| システム・プロパティ名 | 値 |
|---|---|
|
|
|
|
|
|
|
プロキシがバインドされるNICのホスト名またはIPアドレス |
|
|
プロキシがバインドされるポートの一意のポート番号 |
キャッシュ・サーバーで使用する場合は、表4-8に示すシステム・プロパティを指定します。
例4-5は、サーバー側のセッション・キャッシュ構成ファイルの全内容を示しています。
例4-5 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-6に示す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-client.xmlに変更します。
このファイルをWebアプリケーションのWEB-INF/classesディレクトリに配置します。WebInstallerを使用してCoherence*Webをインストールした場合は、WebInstallerによって追加されている既存のファイルと置き換えます。
例4-6は、クライアント側のセッション・キャッシュ構成ファイルの全内容を示しています。
例4-6 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>
Java Server Faces(JSF)は、Webアプリケーションのユーザー・インタフェースを構築できるフレームワークです。Apache Software Foundation社のMyFacesは、JSF仕様を拡張するJSFコンポーネントを提供します。MyFacesコンポーネントは、Sun JSF 1.1リファレンス実装などのように互換性のある実装と完全互換性があります。
すべてのJSFおよびMyFaces Webアプリケーションで、次のことが該当します。
JSFとMyFacesは、セッション・オブジェクトにおけるビューの状態のキャッシュを試みます。この状態データは、デフォルトではシリアライズ可能ですが、可能でない場合もあります。例:
Coherence*Webがシリアライズ不可能なクラスのために、IllegalStateExceptionをレポートした際、Webアプリケーションによってセッションに配置されたすべての属性がSerializableの場合、レンダリングされたページの非表示フィールドにビューの状態を格納するようにJSF/MyFacesを構成する必要があります。
Webアプリケーションによってセッション・オブジェクトにシリアライズ不可能なオブジェクトが書き込まれる場合、coherence-preserve-attributesコンテキスト・パラメータを有効にする必要があります。
JSFパラメータのjavax.faces.STATE_SAVING_METHODは、リクエスト間におけるビューの状態が格納される場所を特定します。デフォルトでは、状態はサーブレット・セッションに保存されます。web.xmlのcontext-param行でSTATE_SAVING_METHODパラメータをclientに設定し、レンダリングされたページの非表示フィールドにビュー全体の状態をJSFが格納するようにします。そのように設定しない場合、セッション・オブジェクトにシリアライズ不可能な状態のキャッシュをJSFで試みることがあります。
例4-7は、STATE_SAVING_METHODパラメータの設定を示しています。
例4-7 web.xmlにおけるSTATE_SAVING_METHODの設定
...
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
...
MyFacesを使用する設定済アプリケーションの場合は、次のようになります。
Coherence*Web WebInstallerでMyFacesアプリケーションをデプロイする場合(設定済アプリケーションの場合)、MyFacesのバージョンに応じて追加手順の実行が必要な場合もあります。
Coherence*Web WebInstallerを使用して、1.1.xより古いバージョンのMyFacesで構築されたWebアプリケーションをデプロイする場合、追加手順を実行する必要はありません。
Coherence*Web WebInstallerを使用して、1.2.xバージョンのMyFacesで構築されたWebアプリケーションをデプロイする場合、web.xmlにorg.apache.myfaces.DELEGATE_FACES_SERVLETコンテキスト・パラメータを追加します。このパラメータにより、デフォルトのjavax.faces.webapp.FacesServletのかわりにカスタム・サーブレットを指定できます。
例4-8は、DELEGATE_FACES_SERVLETコンテキスト・パラメータの設定を示しています。
JSFリファレンス実装(Mojarra)を使用する設定済アプリケーションの場合は、次のようになります。
Coherence*Web WebInstallerを使用して、JSF RI(Mojarra)に基づいたWebアプリケーションをデプロイする場合、web.xmlのservlet行でFaces Servletクラスを宣言する必要があります。
例4-9 web.xmlにおけるFaces Servletの宣言
...
<servlet>
<servlet-name>Faces Servlet (for loading config)</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
...
MyFacesおよびCoherence SPIを使用する非設定済アプリケーションの場合は、次のようになります。
Coherence SPIを使用して、MyFacesで構築されたWebアプリケーションをデプロイする場合、追加手順を実行する必要はありません。これは、Coherence*WebとともにMyFacesを実行する場合にお薦めする方法です。
JSFリファレンス実装(Mojarra)およびCoherence SPIを使用する非設定済アプリケーションの場合は、次のようになります。
Coherence SPIを使用して、JSF RI(Mojarra)に基づいたWebアプリケーションをデプロイする場合、追加手順を実行する必要はありません。これは、Coherence*WebとともにJSFを実行する場合にお薦めする方法です。
