ヘッダーをスキップ
Oracle Coherence*Webユーザーズ・ガイド
リリース3.4.2
B53785-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

4 Coherence*Webセッション管理機能

Coherence*Webは、作業環境の要望を満たすために様々な方法で構成できます。そのためには、デフォルトのコンフィギュレーション・オプションの一部を変更する必要がある場合があります。この章の目的は、Coherence*Webでサポートされている機能について詳しく説明し、適切なコンフィギュレーションとデプロイメントを読者が判断できるようにすることです。

4.1 セッション・モデル

セッション・モデルは、Coherence内のセッション状態をCoherence*Webでどのように物理的に表現し、保存するかを記述します。Coherence*Webは、セッション状態の柔軟なデータ管理モデルをサポートしています。セッション状態はHttpSessionModelオブジェクトで管理し、すべてのセッションのリストはHttpSessionCollectionオブジェクトで管理します。Coherence*Webは、次のようなすぐに使用できる様々なセッション・モデル実装を備えています。

図4-1 トラディショナル、モノリシック、およびスプリット・セッション・モデル

トラディショナル、モノリシック、およびスプリット・セッション・モデル
図4-1「トラディショナル、モノリシック、およびスプリット・セッション・モデル」の説明

4.1.1 トラディショナル・モデル

TraditionalHttpSessionModelTraditionalHttpSessionCollectionでは、特定のセッションのすべてのHTTPセッション・データを単一のCoherenceキャッシュ・エントリで管理しますが、HTTPセッション属性(特に、そのシリアライズとデシリアライズ)は個別に管理します。

このモデルは、HTTPセッション・オブジェクトが比較的小型で(10KB以下)、セッション属性間でオブジェクト共有の問題が発生しない用途に最適です(セッション属性間のオブジェクト共有は、1つのセッションにある複数の属性で同じオブジェクトを参照する場合に発生します。このような状況では、HTTPセッションを後でデシリアライズすると、これらの属性のシリアライズとデシリアライズが独立して実行されるので、共有オブジェクトの複数のインスタンスが発生します)。

図4-2 トラディショナル・セッション・モデル

トラディショナル・セッション・モデル
図4-2「トラディショナル・セッション・モデル」の説明

4.1.2 モノリシック・モデル

MonolithicHttpSessionModelMonolithicHttpSessionCollectionは、トラディショナル・モデルの場合と似ていますが、すべての属性を1つのオブジェクト・ストリームにまとめてシリアライズおよびデシリアライズすることで、共有オブジェクトの問題を解決している点が異なります。

そのため、モノリシック・モデルはトラディショナル・モデルよりパフォーマンスが低下することが普通です。

図4-3 モノリシック・セッション・モデル

モノリシック・セッション・モデル
図4-3「モノリシック・セッション・モデル」の説明

4.1.3 スプリット・モデル

SplitHttpSessionModelSplitHttpSessionCollectionは、セッションID、作成時刻、最終アクセス時刻などの主要なHTTPセッション・データを、他のすべての小型のセッション属性とともにトラディショナル・モデルと同じ方法で管理します。これにより、セッション・データのブロックを小型に維持できるので、高いパフォーマンスが得られます。すべての大型の属性は、独立したキャッシュ・エントリに分割して別々に管理するので、リクエストが発生するたびにクラスタ内でアクセスまたは更新を必要とするデータ量を増やさずに、大規模なHTTPセッション・オブジェクトをサポートできます。つまり、属性の更新によってネットワーク・オーバーヘッドが発生するのは、特定のリクエストで大型の属性を変更する場合のみです。したがって、一般的にスプリット・モデルでは、主要なHTTPセッション・データへのアクセスでも、またどのセッション属性へのアクセスでもネットワーク・オーバーヘッドがほとんど発生しません(これはニア・キャッシュを使用しているからです)。

図4-4 スプリット・セッション・モデル

スプリット・セッション・モデル
図4-4「スプリット・セッション・モデル」の説明

4.1.4 セッション・モデルの推奨事項

  • スプリット・モデルは、ほとんどの用途にお薦めできるセッション・モデルです。

  • トラディショナル・モデルは、HTTPセッション・オブジェクトが小型であることがわかっている用途に適しています。

  • モノリシック・モデルは、複数のセッション属性で1つの共有オブジェクトを参照し、そのオブジェクトを共有オブジェクトとして維持する必要がある場合、それら複数のセッション属性に関連する特定のクラスの問題を解決することを目的としています。

クラスタ環境におけるこれらのモデルの動作は、『Oracle Coherenceスタート・ガイド』の「クラスタ・アプリケーションのセッション管理」を参照してください。


注意:

コンフィギュレーション情報は、付録A「Coherence*Webコンフィギュレーション・パラメータ」を参照してください。

4.2 セッションとセッション属性のスコープ設定

Coherence*Webを使用すると、アプリケーションの境界を越えてセッション・データとセッション属性の両方のスコープをどのように設定するか(共有するか)についてきめ細かな制御が可能になります。

4.2.1 セッション・スコープ設定

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.comserver2.mydomain.comで実行している2つのWebアプリケーション間でセッション・データを共有する場合は、coherence-session-cookie-domainパラメータを.mydomain.comに設定する必要があります。

共有セッションに保存したオブジェクトを適切にシリアライズまたはデシリアライズするには、セッション属性に保存したすべてのオブジェクトのクラスを、セッション・データを共有するWebアプリケーションで使用できるようにする必要があります。複数のWebアプリケーションをそれぞれ別々のコンテナにデプロイしている場合は、WebコンテナまたはWebアプリケーション・クラスパスのどちらにもこれらのクラスを配置できます。一方、複数のアプリケーションを同じWebコンテナにデプロイしている場合、これらのクラスはWebコンテナ・クラスパスに配置する必要があります。この理由は、ほとんどのコンテナが別々のClassLoaderを使用してそれぞれのWebアプリケーションをロードするためです。


注意:

EARクラスタ・ノードのスコープ設定またはアプリケーション・サーバーJVMクラスタのスコープ設定を採用し、個々のWebアプリケーション間でセッション・データを共有しない高度な用途は、「Webアプリケーション間でのセッション・データ共有の禁止」を参照してください。

4.2.1.1 Webアプリケーション間でのセッション・データ共有の禁止

同じCoherenceクラスタに属する複数のJava EEアプリケーションであっても、HTTPセッション・データを共有しないようにすることが必要な場合があります。たとえば、EJB層でキャッシュ・データを共有する2つのアプリケーションHRPortalおよびInWebがあり、それぞれで使用するセッション・データは互いに別であるとします。この2つのアプリケーションにとって、1つのCoherenceクラスタに属していることは必要ですが、セッション・データについては同じクラスタ・サービスを使用しないようにする必要があります。

複数のJava EEアプリケーション間でセッション・データの共有を禁止するには、アプリケーションごとに異なる一意のセッション・キャッシュ・サービス名を指定します。

  1. 各アプリケーションのsession-cache-config.xmlファイルで、<service-name/>パラメータの記述を探します。

  2. このパラメータをアプリケーションごとに異なる一意の値に設定します。

    これによって、セッション・データについては、アプリケーションごとに別々のクラスタ・サービスを使用できるようになります。

  3. 変更した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>

4.2.1.2 セッションCookieの独立性の維持

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.comserver2.mydomain.comで実行しているとします。これらのアプリケーションがセッションCookieを共有しないようにするには、一方のアプリケーションのweb.xmlファイルでcoherence-session-cookie-domainパラメータをserver1.mydomain.comに設定し、もう一方のアプリケーションのweb.xmlファイルで同じパラメータをserver2.mydomain.comに設定します。

4.2.2 セッション属性スコープ設定

複数のWebアプリケーションでセッションを共有している場合は、セッション属性をグローバルに認識できるように(すべてのWebアプリケーションからアクセスして変更できるようにする)、または逆に個々のWebアプリケーションのみで認識できるように(他のアプリケーションのインスタンスからはアクセスできないようにする)、個々のセッション属性のスコープをアプリケーションで設定することが必要になる場面が数多くあります。

Coherence*Webでは、この動作をAttributeScopeControllerインタフェースを使用して制御できます。複数のアプリケーションでセッションを共有する場合に、このオプション・インタフェースを使用して属性を選択的にスコープ設定できます。これにより、他のアプリケーションの属性を誤って読取り、更新、削除することなく、複数のアプリケーションでアプリケーション・スコープ状態について同じ属性名を使用できます。セッションでは、アプリケーション別スコープを設定した情報のほか、セッションを共有するすべてのアプリケーションで読取り、更新、および削除できるグローバルな(スコープ設定していない)情報を保持することもできます。

すぐに使用できるこのインタフェースの実装として、ApplicationScopeControllerおよびGlobalScopeControllerの2種類があります。

4.3 クラスタ・ノード分離

Coherence*Webを使用する場合に考慮が必要なデプロイメント・オプションの1つがクラスタ・ノード分離の概念です。

このオプションでは次の点を指定します。

アプリケーションには、アプリケーション・サーバー・スコープ、EARスコープ、またはWARスコープを設定できます。この項では、これらのオプションについて説明します。これらのオプションのXMLコンフィギュレーションの詳細は、「アプリケーションのパッケージ化とクラスタ・ノードの構成」を参照してください。

4.3.1 アプリケーション・サーバー・スコープ設定クラスタ・ノード

このコンフィギュレーションでは、Coherence*Webを使用するコンテナにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。このコンフィギュレーションでは、クラスタに作成されるCoherenceノードの数が最小となります(WebコンテナJVMごとに1つ)。また、Coherenceライブラリ(coherence.jar)がコンテナのクラスパスにデプロイされるので、JVMにロードされるCoherenceクラスのコピーは1つのみです。これによって、リソースの使用が最小限に抑えられます。その一方で、すべてのアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのアプリケーションに不具合があるとすべてのアプリケーションが影響を受けます。

図4-5 アプリケーション・サーバー・スコープ設定クラスタ

アプリケーション・サーバー・スコープ設定クラスタ
図4-5「アプリケーション・サーバー・スコープ設定クラスタ」の説明

このコンフィギュレーションを使用する場合の要件は次のとおりです。

  • デプロイする各アプリケーションは、同じバージョンのCoherenceを使用し、同じクラスタに属する必要があります。

  • HTTPセッションに配置したオブジェクトのクラスは、コンテナのクラスパスに配置する必要があります。

アプリケーション・サーバー・スコープ設定クラスタ・ノードのXMLコンフィギュレーションは、「アプリケーション・サーバー・スコープ設定クラスタ・ノードのパッケージ化と構成」を参照してください。


注意:

アプリケーション・サーバー・スコープ設定クラスタ・ノードによるコンフィギュレーションは、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では絶対に使用しないでください。

このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・グループでデプロイしている状況が考えられます。このようなコンフィギュレーションでは、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他のコンフィギュレーション設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。

このような理由から、EARスコープ設定クラスタ・ノードによるコンフィギュレーションおよびWARスコープ設定クラスタ・ノードによるコンフィギュレーションの使用を強くお薦めします。どのデプロイメント・トポロジの選択が妥当か不明な場合や、この警告に該当するデプロイメントの場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによるコンフィギュレーションは選択しないでください。


4.3.2 EARスコープ設定クラスタ・ノード

このコンフィギュレーションでは、EARごとにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。このコンフィギュレーションでクラスタに作成されるCoherenceノードの数は、アプリケーション・サーバー・スコープ設定によるコンフィギュレーションの次に少ない数になります(Coherence*Webを使用するデプロイ先EARごとに1つずつ)。Coherenceライブラリ(coherence.jar)がアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーはEARごとに1つです。EARにあるすべてのWebアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのWebアプリケーションに不具合があるとEARにあるすべてのWebアプリケーションが影響を受けます。

図4-6 EARスコープ設定クラスタ

EARスコープ設定クラスタ
図4-6「EARスコープ設定クラスタ」の説明

EARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。1台のアプリケーション・サーバーにデプロイするEARを1つのみとする場合も、このオプションが最適です。

このコンフィギュレーションを使用する場合の要件は次のとおりです。

  • Coherenceライブラリ(coherence.jar)は、EARファイルの中でデプロイし、META-INF/application.xmlにJavaモジュールとして列挙する必要があります。

  • HTTPセッションに配置したオブジェクトのクラスも、Java EARモジュールとしてデプロイする必要があります。

EARスコープ設定クラスタ・ノードのXMLコンフィギュレーションは、「EARスコープ設定クラスタ・ノードのパッケージ化と構成」を参照してください。

4.3.3 WARスコープ設定クラスタ・ノード

このコンフィギュレーションでは、デプロイしたWebアプリケーションごとに専用のCoherenceノードがあります。このコンフィギュレーションでクラスタに作成されるCoherenceノードの数は最多となります(Coherence*Webを使用するデプロイ先WARごとに1つずつ)。Coherenceライブラリ(coherence.jar)がWebアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーの数はデプロイ先WARと同じ数になります。その結果、3種類の構成オプションの中で最もリソース使用率が高くなります。ただし、デプロイしたWebアプリケーションごとに専用のクラスタ・ノードがあるので、いずれかのWebアプリケーションに不具合があっても、他のWebアプリケーションは分離されているので影響を受けません。

WARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。1台のアプリケーション・サーバーにデプロイするWARを1つのみとする場合も、このオプションが最適です。

図4-7 WARスコープ設定クラスタ

WARスコープ設定クラスタ
図4-7「WARスコープ設定クラスタ」の説明

このコンフィギュレーションを使用する場合の要件は次のとおりです。

  • Coherenceライブラリ(coherence.jar)は、WARファイル(通常はWEB-INF/libにあります)の中でデプロイする必要があります。

  • HTTPセッションに配置したオブジェクトのクラスは、WARファイル(WEB-INF/libまたはWEB-INF/classesにあります)の中でデプロイする必要があります。

WARスコープ設定クラスタ・ノードのXMLコンフィギュレーションは、「WARスコープ設定クラスタ・ノードのパッケージ化と構成」を参照してください。

4.4 セッション・ロック・モード

Oracle Coherenceには、HTTPセッションへの同時アクセスを実現する次のコンフィギュレーション・オプションが用意されています。

この項で説明したパラメータの詳細は、付録A「Coherence*Webコンフィギュレーション・パラメータ」を参照してください。

4.4.1 オプティミスティック・ロック(デフォルト)

オプティミスティック・ロック・モードを使用すると、1つ以上のJVMにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了後、楽観的なアプローチで同時更新を検出して防止します。Coherence*Webで同時変更が検出されると、ConcurrentModificationExceptionがアプリケーションにスローされるので、この例外をアプリケーションで適切に処理できるように準備しておく必要があります。

このモードは、coherence-session-member-lockingパラメータをFALSEに設定して構成できます。

4.4.2 メンバー・ロック

メンバー・ロック・モードを使用すると、同じJVMにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスして変更できますが、別々のJVMにあるスレッドからは同時にアクセスできません。この動作は、リクエストの開始時点でHTTPセッションに対するメンバー・レベルのロックを取得して、リクエストの完了時点でロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Coherence開発者ガイド』の「distributed-scheme」で<lease-granularity>を参照してください。

このモードは、coherence-session-member-lockingパラメータをTRUEに設定して構成できます。

4.4.3 スレッド・ロック

スレッド・ロック・モードでは、1つのJVMにある1つのスレッドからのみセッションにアクセスし、変更できます。この動作は、リクエストの開始時点でHTTPセッションに対するメンバー・レベルのロックとスレッド・レベルのロックの両方を取得して、リクエストの完了時点で両方のロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Coherence開発者ガイド』の「distributed-scheme」で<lease-granularity>を参照してください。

このモードは、coherence-session-thread-lockingパラメータをTRUEに設定して構成できます。このパラメータをTRUEに設定するということは、coherence-session-member-lockingTRUEに設定することにもなります。

4.4.4 HTTPセッションでのロックの使用

HTTPセッションへのアクセスに対するメンバー・ロックまたはスレッド・ロックを有効にすることは、セッションへのアクセスを要求するすべてのHTTPリクエストに対するクラスタ規模のロックの取得をCoherence*Webに指定することです。デフォルトでは、ロックされたセッションにアクセスしようとするスレッドは、ロックが取得できるまでブロックされます。ロック取得のタイムアウトを有効にする場合は、コンテナの起動スクリプトでtangosol.coherence.servlet.lock.timeoutシステム・プロパティを使用して構成します(例: -tangosol.coherence.servlet.lock.timeout=30s)。

多くのWebアプリケーションには、このような厳しい同時処理要件がありません。このようなアプリケーションの場合は、オプティミスティック・ロック・モードを使用することによって、次のようなメリットが得られます。

  • HTTPリクエストのたびにクラスタ規模のロックを取得して解放することで発生するオーバーヘッドを排除できます。

  • 障害が発生したJVMや応答しないJVMから他の正常なJVMにリクエストをルーティングして負荷分散できます。クラスタ規模でセッションに適用されているロックの解放を、応答しなくなったJVMに要求する必要がありません。

4.4.5 スティッキー・セッション最適化の有効化

スティッキー・ロード・バランサの対象となっているWebアプリケーションの要件としてメンバー・ロックまたはスレッド・ロックがある場合は、HTTPセッションへのアクセスに必要なクラスタ規模のロックの取得をCoherence*Webで最適化できます。その名が示すとおり、スティッキー・ロード・バランサは、特定のセッションに対するリクエストを最初にそれを作成したJVMにルーティングしようとします。スティッキー・セッション最適化では、セッションに対するクラスタ規模のロックをそのセッションの有効期限が切れるまで保持することによって、この動作を利用しています。セッションに対するリクエストが別のJVMに転送された場合は、そのJVMからロックを保持しているJVMに対して、できるだけ早くロックを解放するように要求が発生します。この動作は、起動サービスを使用して実装します。詳細は、表B-2SessionOwnershipのエントリを参照してください。

スティッキー・セッション最適化は、coherence-sticky-sessionsパラメータをTRUEに設定すると有効になります。

4.5 デプロイメント・トポロジ

Coherence*Webでは、Coherenceで使用できるデプロイメント・トポロジのほとんどを使用できます。これには、インプロセス・トポロジ、プロセス外トポロジ(クライアント/サーバー・デプロイメント)、Coherence*Extendを介してクライアントとサーバーをブリッジするトポロジなどがあります。サポートされている主なデプロイメント・トポロジについて次で説明します。

4.5.1 プロセス外トポロジ

プロセス外デプロイメント・トポロジでは、アプリケーション・サーバー(アプリケーション・サーバー層)をキャッシュ・クライアントとして構成し(tangosol.coherence.distributed.localstorage=false)、クラスタ化データを物理的に保存および管理してキャッシュ・サーバーとして動作する専用のJVMを配置します。

このアプローチには次のようなメリットがあります。

  • セッション・データ記憶域の負荷を、アプリケーション・サーバー層からキャッシュ・サーバー層に移管できます。これによって、ヒープ使用量やガベージ・コレクション時間などを低減できます。

  • 2つの層の規模を互いに無関係に変更できます。アプリケーションの処理能力が不足している場合は、起動するアプリケーション・サーバーの数を増やすだけで済みます。セッション記憶域の容量が不足している場合は、起動するキャッシュ・サーバーの数を増やすだけです。

プロセス外トポロジは、その柔軟性によって、Oracle Coherenceのデフォルトの推奨トポロジになっています。

図4-8 プロセス外デプロイメント・トポロジ

プロセス外デプロイメント・トポロジ
図4-8「プロセス外デプロイメント・トポロジ」の説明

4.5.2 Coherence*Extendによるプロセス外トポロジ

Coherence*Extendによるプロセス外トポロジは、プロセス外デプロイメント・トポロジに似ていますが、アプリケーション・サーバー層とキャッシュ・サーバー層との通信をCoherence*Extend経由(TCP/IP)で行う点が異なります。

このアプローチには、プロセス外トポロジと同じメリットがあるほか、アプリケーション・サーバーとキャッシュ・サーバーのデプロイメントをセグメント化する機能もあります。この特性は、UDPをサポートしていないネットワーク上にアプリケーション・サーバーが存在する環境に最適です。TCPを使用してクラスタにアプリケーション・サーバーを接続した上で、独立した専用のネットワークにキャッシュ・サーバーを配置できます。

図4-9 Coherence*Extendによるプロセス外デプロイメント・トポロジ

Coherence*Extendによるプロセス外デプロイメント・トポロジ
図4-9「Coherence*Extendによるプロセス外デプロイメント・トポロジ」の説明

4.5.3 インプロセス・トポロジ

インプロセス・トポロジは、本番環境での使用にはお薦めできません。このトポロジは、主に、開発とテスト用としてサポートされています。このトポロジは、アプリケーション・サーバーを使用してセッション・データをプロセス内で保存することで、容易に起動して、スモーク・テスト、開発、およびテスト用として高速で実行できます。

図4-10 インプロセス・デプロイメント・トポロジ

インプロセス・デプロイメント・トポロジ
図4-10「インプロセス・デプロイメント・トポロジ」の説明

4.6 JMXによるアプリケーションの管理と監視


注意:

この項では、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属性の中には、次の接頭辞を使用しているものがあります。

表4-2 HttpSessionManagerMBeanから返される情報

名前 データ型 説明

CollectionClassName

String

使用中のHttpSessionCollection実装の完全修飾クラス名。HttpSessionCollectionインタフェースは、HttpSessionModelオブジェクトのコレクションの抽象モデルです。このインタフェースは、クライアントとサーバー間でセッションをどのようにやり取りするかという点にはまったく関与しません。

FactoryClassName

String

使用中のFactory実装の完全修飾クラス名。SessionHelperではSessionHelper.Factoryを使用して、サーブレット仕様の重要な部分を実装するオブジェクトを取得します。これは、アプリケーション・サーバー独自のオブジェクトのかわりにアプリケーションの前に配置できます。これによって、アプリケーション・サーバー自体の「外見上の実装」を変更できます(クラスタリングの追加など)。

LocalAttributeCacheName

String

分散されないセッション属性を保存するローカル・キャッシュの名前。この属性がNULLの場合、セッション属性のローカル記憶域は無効です。

LocalAttributeCount

Integer

セッション属性のローカル・キャッシュに保存された分散されないセッション属性の数。この属性が-1の場合、セッション属性のローカル記憶域は無効です。

LocalSessionCacheName

String

分散されないセッションを保存するローカル・キャッシュの名前。この属性がNULLの場合、セッションのローカル記憶域は無効です。

LocalSessionCount

Integer

セッションのローカル・キャッシュに保存された分散されないセッションの数。この属性が-1の場合、セッションのローカル記憶域は無効です。

OverflowAverageSize

Integer

統計を前回リセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の平均サイズ(バイト数)。この属性が-1の場合、SplitHttpSessionCollectionは使用されていません。

OverflowCacheName

String

所定のサイズより大きいことから、シリアライズしたセッション・オブジェクト自体の一部としてではなく、個別のキャッシュ・エントリとしたほうが効率的に管理できると判断される「大型の属性」を保存するクラスタ・キャッシュの名前。SplitHttpSessionCollectionが使用されていない場合は、NULLになります。

OverflowMaxSize

Integer

統計を前回リセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の最大サイズ(バイト数)。SplitHttpSessionCollectionが使用されていない場合、この属性は-1になります。

OverflowThreshold

Integer

大型の属性向けに確保されている独立した「オーバーフロー」キャッシュに属性値を格納できるようにするために、その属性値のシリアライズした形式で確保する必要がある最小長さ(バイト数)。SplitHttpSessionCollection が使用されていない場合、この属性は-1になります。

OverflowUpdates

Integer

統計を最後にリセットした時点以降、「オーバーフロー」クラスタ・キャッシュに保存されたセッション属性の更新回数。SplitHttpSessionCollectionが使用されていない場合、この属性は-1になります。

SessionAverageLifetime

Integer

統計を最後にリセットした時点以降、有効期限切れまたは明示的な無効化によって無効になったセッション・オブジェクトの平均存続期間(秒数)。

SessionAverageSize

Integer

統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの平均サイズ(バイト数)。

SessionCacheName

String

シリアライズしたセッション・オブジェクトを保存するクラスタ・キャッシュの名前。

SessionIdLength

Integer

生成されたセッションIDの長さ(文字数)。

SessionMaxSize

Integer

統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの最大サイズ(バイト数)。

SessionMinSize

Integer

統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに配置されたセッション・オブジェクトの最小サイズ(バイト数)。

SessionStickyCount

Integer

Webアプリケーションのこのインスタンスに関連付けられたセッション・オブジェクトの数。スティッキー・セッション最適化が無効になっている場合、この属性は-1になります。

SessionTimeout

Integer

セッションの存続期間(秒数)。セッションが無期限の場合、この属性は-1になります。

SessionUpdates

Integer

統計を最後にリセットした時点以降、セッション記憶域のクラスタ・キャッシュに保存されたセッション・オブジェクトの更新回数。

ServletContextCacheName

String

javax.servlet.ServletContext属性を保存するクラスタ・キャッシュの名前。ServletContextがクラスタ化されていない場合、この属性はNULLになります。

ServletContextName

String

WebアプリケーションServletContextの名前。

resetStatistics(操作)

void

セッション管理統計をリセットします。


図4-11は、JConsoleブラウザに表示されたHttpSessionManagerMBeanを示しています。

図4-11 JConsoleブラウザに表示されたHttpSessionManagerMBean

JConsoleブラウザに表示されたHttpSessionManagerMBean
図4-11「JConsoleブラウザに表示されたHttpSessionManagerMBean」の説明