| Oracle Coherence*Webユーザーズ・ガイド リリース3.4.2 B53785-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種類があります。
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にあるスレッドからは同時にアクセスできません。
スレッド・ロック: 単一の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つのJVMにある1つのスレッドからのみセッションにアクセスし、変更できます。この動作は、リクエストの開始時点でHTTPセッションに対するメンバー・レベルのロックとスレッド・レベルのロックの両方を取得して、リクエストの完了時点で両方のロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Coherence開発者ガイド』の「distributed-scheme」で<lease-granularity>を参照してください。
このモードは、coherence-session-thread-lockingパラメータをTRUEに設定して構成できます。このパラメータをTRUEに設定するということは、coherence-session-member-lockingをTRUEに設定することにもなります。
HTTPセッションへのアクセスに対するメンバー・ロックまたはスレッド・ロックを有効にすることは、セッションへのアクセスを要求するすべてのHTTPリクエストに対するクラスタ規模のロックの取得をCoherence*Webに指定することです。デフォルトでは、ロックされたセッションにアクセスしようとするスレッドは、ロックが取得できるまでブロックされます。ロック取得のタイムアウトを有効にする場合は、コンテナの起動スクリプトでtangosol.coherence.servlet.lock.timeoutシステム・プロパティを使用して構成します（例: -tangosol.coherence.servlet.lock.timeout=30s）。
多くのWebアプリケーションには、このような厳しい同時処理要件がありません。このようなアプリケーションの場合は、オプティミスティック・ロック・モードを使用することによって、次のようなメリットが得られます。
HTTPリクエストのたびにクラスタ規模のロックを取得して解放することで発生するオーバーヘッドを排除できます。
障害が発生したJVMや応答しないJVMから他の正常なJVMにリクエストをルーティングして負荷分散できます。クラスタ規模でセッションに適用されているロックの解放を、応答しなくなったJVMに要求する必要がありません。
スティッキー・ロード・バランサの対象となっているWebアプリケーションの要件としてメンバー・ロックまたはスレッド・ロックがある場合は、HTTPセッションへのアクセスに必要なクラスタ規模のロックの取得をCoherence*Webで最適化できます。その名が示すとおり、スティッキー・ロード・バランサは、特定のセッションに対するリクエストを最初にそれを作成した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）で行う点が異なります。
このアプローチには、プロセス外トポロジと同じメリットがあるほか、アプリケーション・サーバーとキャッシュ・サーバーのデプロイメントをセグメント化する機能もあります。この特性は、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を示しています。
