| Oracle® Coherence Oracle Coherence*Webユーザーズ・ガイド リリース3.7.1 B65029-01 |
|
 前 |
 次 |
Coherence*Webは、作業環境の要望を満たすために様々な方法で構成できます。そのために、一部のデフォルトの構成オプションの変更が必要になる場合があります。この章では、構成とデプロイメントについて適切な意思決定ができるように、Coherence*Webでサポートされている機能について詳しく説明します。
「セッション・モデル」では、Coherence*Webによるセッション状態の格納方法について説明します。
「セッションとセッション属性のスコープ設定」では、アプリケーション境界を越えてセッション・データとセッション属性の両方のスコープをどのように設定するか(共有するか)についてきめ細かな制御が可能になります。
「クラスタ・ノード分離」では、アプリケーション・サーバーJVM内に作成されるCoherenceノードの数とアプリケーションのクラスパスでCoherenceライブラリをデプロイする場所を決定します。
「セッション・ロック・モード」では、アプリケーションがどのようにHTTPセッションへの同時アクセスを取得するのかを決定します。
「デプロイメント・トポロジ」では、セッション・データをキャッシュ・サーバーとアプリケーション・サーバーとの間で格納および管理する方法を決定します。
「遅延取得によるセッションへのアクセス」では、サーブレットまたはフィルタがアクセスを試みる場合にのみCoherence*Webがセッションを取得するように設定することによって、処理時間と処理能力を節約する方法について説明します。
「HTTPセッションと属性のディストリビューションのオーバーライド」では、セッションまたはその属性をローカルのままにするか(元のサーバーのヒープに格納し、そのサーバーからのみアクセス可能にするか)、分散するか(Coherenceグリッド内に格納し、他のサーバーJVMからアクセス可能にするか)を制御する方法について説明します。
「変更された属性値の検出」では、セッションから取得されリクエストの処理時に変更された可能性のある属性をCoherence*Webが追跡する方法について説明します。
「シリアライズ不可能な属性のローカルな保存」では、Coherence*Webがシリアライズできないセッション属性を処理する方法について説明します。
「Coherence*Webデプロイメントの保護」では、Secure Socket Layer(SSL)を有効にして、権限のないCoherence TCMPクラスタ・メンバーがHTTPセッション・キャッシュ・サーバーにアクセスできないようにする方法について説明します。
セッション・モデルは、Coherence内のセッション状態をCoherence*Webでどのように保存するのかを記述します。セッション・データはHttpSessionModelオブジェクトで管理し、Webアプリケーションのセッション・コレクションはHttpSessionCollectionオブジェクトで管理します。web.xmlファイルでコレクション・タイプのみを構成する必要があります。モデルはコレクション・タイプから暗黙的に派生します。Coherence*Webは、次のような様々なセッション・モデル実装を備えています。
トラディショナル・モデルでは、すべてのセッション状態を単一のエンティティとして保存しますが、属性は個別にシリアライズおよびデシリアライズします。
モノリシック・モデルでは、すべてのセッション状態を単一のエンティティとして保存し、すべての属性を単一の操作としてシリアライズおよびデシリアライズします。
スプリット・モデルは、トラディショナル・モデルを拡張したモデルですが、大きなセッション属性は独立した複数の物理エンティティに分離します。
|
注意: 一般的に、同じCoherenceクラスタに属するWebアプリケーションは、同じセッション・モデル・タイプを使用する必要があります。構成に一貫性がないと、デシリアライズ・エラーが発生することがあります。 |
図5-1は、3つのセッション・モデルを示しています。
トラディショナル・モデルは、TraditionalHttpSessionModelオブジェクトとTraditionalHttpSessionCollectionオブジェクトで表されます。これらは、特定のセッションのすべてのHTTPセッション・データを1つのCoherenceキャッシュ・エントリで管理しますが、各HTTPセッション属性(特にシリアライズとデシリアライズ)は個別に管理します。
このモデルは、HTTPセッション・オブジェクトが比較的小型で(10KB以下)、セッション属性間でオブジェクト共有の問題が発生しない用途に最適です。セッション属性間のオブジェクト共有は、1つのセッションにある複数の属性で同じオブジェクトを参照する場合に発生します。このような状況では、HTTPセッションを後でデシリアライズすると、これらの属性のシリアライズとデシリアライズが独立して実行されるので、共有オブジェクトの複数のインスタンスが発生します。
図5-2に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。論理表現では、セッション・データはメタデータと様々な属性で構成されます。セッション記憶域キャッシュ内の物理表現では、メタデータと属性はバイナリに変換され、これらにセッションIDが関連付けられます。セッション記憶域キャッシュでは属性は個別のエンティティとしてシリアライズされます。
モノリシック・モデルは、MonolithicHttpSessionModelオブジェクトとMonolithicHttpSessionCollectionオブジェクトで表されます。これらはトラディショナル・モデルと似ていますが、すべての属性を単一のオブジェクト・ストリームにシリアライズおよびデシシアライズすることで共有オブジェクトの問題を解決している点が異なります。そのため、モノリシック・モデルはトラディショナル・モデルよりパフォーマンスが低下することがよくあります。
図5-3に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。論理表現では、セッション・データはメタデータと様々な属性で構成されます。セッション記憶域キャッシュの物理表現では、メタデータと属性は単一のストリームにシリアライズされます。メタデータと属性にはセッションIDが関連付けられます。
スプリット・モデルは、SplitHttpSessionModelオブジェクトとSplitHttpSessionCollectionオブジェクトで表されます。これらは、主要HTTPセッション・メタデータとすべての小型セッション属性すべてを、トラディショナル・モデルと同じ方法で格納します。これによって、バイナリ・セッション・データのブロックを小型に維持できるので、高いパフォーマンスが得られます。すべての大型の属性は、独立したキャッシュ・エントリに分割して別々に管理するので、リクエストが発生するたびにクラスタ内でアクセスまたは更新を必要とするデータ量を増やさずに、大規模なHTTPセッション・オブジェクトをサポートできます。つまり、属性の更新によってネットワーク・オーバーヘッドが発生するのは、特定のリクエストで大型の属性を変更する場合のみです。したがって、一般的にスプリット・モデルでは、主要なHTTPセッション・データへのアクセスでも、またどのセッション属性へのアクセスでもネットワーク・オーバーヘッドがほとんど発生しません(これはニア・キャッシュを使用しているからです)。
図5-4に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。このモデルでは、大型のオブジェクトは独自のセッションIDを持つ個別のキャッシュ・エントリとして格納されます。
次に、アプリケーションに対してどのセッション・モデルを選択するかについて推奨事項を示します。
スプリット・モデルは、ほとんどのアプリケーションにお薦めできるセッション・モデルです。
トラディショナル・モデルは、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セッション・データを共有しないようにすることが必要な場合があります。たとえば、Enterprise JavaBeans(EJB)層でキャッシュ・データを共有する2つのアプリケーションHRPortalおよびInWebがあり、それぞれで使用するセッション・データは互いに別であるとします。この2つのアプリケーションにとって、1つのCoherenceクラスタに属していることは必要ですが、セッション・データについては同じクラスタ・サービスを使用しないようにする必要があります。これを実行する方法の1つは、ApplicationScopeControllerインタフェースを使用して、アプリケーションの属性のスコープを定義することです。「セッション属性スコープ設定」でこの手法について説明します。もう1つの方法は、アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定することです。
アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定する手順は、次のとおりです。
アプリケーションの各session-cache-config.xmlファイルで、<service-name/>要素を探します。
この要素をアプリケーションごとに異なる一意の値に設定します。
これによって、セッション・データについては、アプリケーションごとに別々のクラスタ・サービスを使用できるようになります。
変更したsession-cache-config.xmlファイルをアプリケーションに組み込みます。
例5-1は、あるHRPortalアプリケーションのsession-cache-config.xmlファイルの例です。HRPortalアプリケーションとInWebアプリケーションとの間でセッション・データを共有しないようにするには、レプリケートするスキームの<service-name>要素の名前をReplicationSessionsMiscHRPに変更します。分散スキームの<service-name>要素の名前をDistributedSessionsHRPに変更します。
例5-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インタフェースを使用して制御できます。複数のアプリケーションでセッションを共有する場合に、このオプション・インタフェースを使用して属性を選択的にスコープ設定できます。これにより、他のアプリケーションの属性を誤って読取り、更新、削除することなく、複数のアプリケーションでアプリケーション・スコープ状態について同じ属性名を使用できます。セッションでは、アプリケーション別スコープを設定した情報のほか、セッションを共有するすべてのアプリケーションで読取り、更新、および削除できるグローバルな(スコープ設定していない)情報を保持することもできます。
AttributeScopeControllerインタフェースの2つの実装(ApplicationScopeControllerとGlobalScopeController)が使用できます。GlobalScopeControllerの実装は属性のスコープを設定しませんが、ApplicationScopeControllerでは、すべての属性名の先頭にアプリケーションの名前を追加することによって、すべての属性のスコープをアプリケーションに設定します。
coherence-application-nameコンテキスト・パラメータを使用して、アプリケーション(およびアプリケーションが記述されたWebモジュール)の名前を指定します。ApplicationScopeControllerインタフェースでは、アプリケーションの名前を使用して属性のスコープを設定します。このパラメータを構成しない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。詳細は、表2-2の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インタフェースの実装であり、これによって個別のセッション属性をグローバルに参照できます。
例5-2は、web.xmlファイルで指定されたGlobalScopeControllerインタフェースを示しています。
例5-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構成の詳細は、「クラスタ・ノードの構成」を参照してください。
この構成では、Coherence*Webを使用するコンテナにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、クラスタに作成されるCoherenceノードの数が最小となります(WebコンテナJVMごとに1つ)。また、Coherenceライブラリ(coherence.jar)がコンテナのクラスパスにデプロイされるので、JVMにロードされるCoherenceクラスのコピーは1つのみです。これによって、リソースの使用が最小限に抑えられます。その一方で、すべてのアプリケーションで1つのクラスタ・ノードを使用するので、いずれかのアプリケーションに不具合があるとすべてのアプリケーションが影響を受けます。
図5-5に、クラスタ・ノード(アプリケーション・サーバー・インスタンス)が2つのアプリケーション・サーバー・スコープ設定クラスタを示します。Coherence*Webは各インスタンスのクラスパスにデプロイされているため、各インスタンスはCoherenceノードと見なすことができます。各ノードには2つのEARファイルが含まれ、それぞれのEARファイルには2つのWARファイルが含まれます。各インスタンスで実行されるすべてのアプリケーションは、同じCoherenceライブラリおよびクラスを共有します。
WebLogic Serverのアプリケーション・サーバー・スコープ設定クラスタ・ノードのXML構成要件は、「アプリケーション・サーバー・スコープ設定クラスタ・ノードの構成」を参照してください。
この構成はGlassFish Serverでは使用できません。
|
注意: アプリケーション・サーバー・スコープ設定クラスタ構成の使用は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では使用しないでください。このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・チームでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。 このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択したらよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください。 |
この構成では、EARファイルごとにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、Coherence*Webを使用するデプロイ済EARファイルごとに1つのCoherenceノードが作成されます。Coherenceライブラリ(coherence.jar)がアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーはEARファイルごとに1つです。EARファイル内のすべてのWebアプリケーションが同じクラスタ・ノードを使用するので、いずれかのWebアプリケーションに不具合があるとEARファイル内のすべてのWebアプリケーションが影響を受けます。
図5-6は、4つのEARスコープ設定クラスタ・ノードを示します。Coherence*Webは各EARファイルにデプロイされているため、各EARファイルがクラスタ・ノードとなります。各EARファイル内で実行されるすべてのアプリケーションは、同じCoherenceライブラリおよびクラスへのアクセス権を持ちます。
EARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。このオプションは、1つのアプリケーション・サーバーにデプロイするEARファイルを1つのみとする場合にも適しています。
EARスコープ設定クラスタ・ノードのXML構成要件の詳細は、次の項を参照してください。
WebLogic Serverの場合: 「EARスコープ設定クラスタ・ノードの構成」
GlassFish Serverの場合: 「EARスコープ設定クラスタ・ノードの構成」
この構成では、デプロイしたWebアプリケーションごとに専用のCoherenceノードがあります。この構成でクラスタに作成されるCoherenceノードの数は最多となります(Coherence*Webを使用するデプロイ先WARファイルごとに1つずつ)。Coherenceライブラリ(coherence.jar)がWebアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーの数はデプロイ先WARファイルと同じ数になります。その結果、3種類の構成オプションの中で最もリソース使用率が高くなります。ただし、デプロイしたWebアプリケーションごとに専用のクラスタ・ノードがあるので、いずれかのWebアプリケーションに不具合があっても、他のWebアプリケーションは分離されているので影響を受けません。
WARスコープ設定クラスタ・ノードでは、アプリケーション・サーバー・クラスパスを変更する必要がないので、デプロイメントに手間がかかりません。このオプションは、1つのアプリケーション・サーバーにデプロイするWARファイルを1つのみとする場合にも適しています。
図5-7に、アプリケーション・サーバー内のWARファイルの2つの異なる構成を示します。各WARファイルにはCoherence*Web(およびCoherence)のコピーが含まれているため、これはクラスタ・ノードと見なすことができます。
WARスコープ設定クラスタ・ノードのXML構成要件の詳細は、次の項を参照してください。
WebLogic Serverの場合: 「WARスコープ設定クラスタ・ノードの構成」
GlassFish Serverの場合: 「WARスコープ設定クラスタ・ノードの構成」
Oracle Coherenceには、HTTPセッションへの同時アクセスを実現する次の構成オプションが用意されています。
オプティミスティック・ロック: 単一のメンバーまたは複数のメンバーにある複数のスレッドからセッションに同時アクセスできます。ただし、セッションを同時に変更できません。
最後の書込みを優先するロック: オプティミスティック・ロックの一種です。これにより、単一のメンバーまたは複数のメンバーにある複数のスレッドからセッションに同時アクセスできます。この場合、最後の書込みが保存されます。これがデフォルトのロック・モードです。
メンバー・ロック: 同じメンバーにある複数のスレッドからセッションに同時にアクセスし、同時にセッションを変更できます。別々のメンバーにあるスレッドからは同時にアクセスできません。
アプリケーション・ロック: 同じWebアプリケーション・インスタンスにある複数のスレッドから同時にセッションにアクセスし、同時にセッションを変更できます。別々のWebアプリケーション・インスタンスにあるスレッドからは同時にアクセスできません。
スレッド・ロック: 単一のメンバーにある複数のスレッドからセッションに同時にアクセスできず、同時にセッションを変更することもできません。
|
注意: 一般的に、同じクラスタに属するWebアプリケーションは、同じロック・モードおよびスティッキー・セッション最適化設定を使用する必要があります。構成に一貫性がないと、デッドロックが発生することがあります。 |
この項で説明したパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
Coherence*WebとCoherence*Web SPIは、デフォルトでオプティミスティック・ロックを使用するように構成されています。オプティミスティック・ロック・モードを使用すると、1つ以上のメンバーにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了後、楽観的なアプローチで同時更新を検出して防止します。Coherence*Webで同時変更が検出されると、例外ConcurrentModificationExceptionがアプリケーションにスローされます。したがって、アプリケーションは適切にこの例外を処理できるようにしておく必要があります。例外を表示するには、コンテナの起動スクリプトでweblogic.debug.DebugHttpSessionsシステム・プロパティをtrueに設定します(例: -Dweblogic.debug.DebugHttpSessions=true)。
オプティミスティック・ロック・モードは、coherence-session-member-lockingコンテキスト・パラメータをfalseに設定して構成できます。
最後の書込みを優先するロックは、オプティミスティック・ロック・モードの一種です。これを使用すると、1つ以上のメンバーにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了時に同時更新は防止されません。かわりに、最後の書込み、つまり最終変更によってセッションが変更されます。
最後の書込みを優先するロック・モードは、coherence-session-lockingパラメータをfalseに設定することによって構成できます。この値により、セッションに対して最後の更新が適用される同時変更ができます。coherence-session-app-locking、coherence-session-member-lockingまたはcoherence-session-thread-lockingのコンテキスト・パラメータをtrueに設定した場合は、この値は無視されます(論理的にtrueとされます)。デフォルトは、falseです。
メンバー・ロック・モードを使用すると、同じクラスタ・ノードにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスして変更できますが、別々のメンバーにあるスレッドからは同時にアクセスできません。これは、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つのメンバーにある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スティッキー・セッション最適化が有効な場合は例外となります。デフォルトでは、ロックされたセッション(別のメンバーにあるスレッドでロックされたセッション)にアクセスしようとするスレッドは、ロックが取得できるまでアクセスをブロックします。ロック取得のタイムアウトを有効にする場合は、これをcoherence-session-get-lock-timeoutコンテキスト・パラメータで構成します。次に例を示します。
...
<context-param>
<param-name>coherence-session-get-lock-timeout</param-name>
<param-value>30</param-value>
</context-param>
...
多くのWebアプリケーションには、このような厳しい同時処理要件がありません。このようなアプリケーションの場合は、オプティミスティック・ロック・モードを使用することによって、次のようなメリットが得られます。
HTTPリクエストのたびにクラスタ規模のロックを取得して解放することで発生するオーバーヘッドを排除できます。
障害が発生したメンバーや応答しないメンバーからアクティブなメンバーにリクエストをルーティングして負荷分散できます。クラスタ規模でセッションに適用されているロックの解放を、応答しなくなったメンバーに要求する必要がありません。
Coherence*Webは、メンバーがセッションに対してクラスタ・ロックを取得できない場合に実行される診断起動サービスを提供します。このサービスを有効にするかどうかはcoherence-session-log-threads-holding-lockコンテキスト・パラメータで設定します。このコンテキスト・パラメータをtrue(デフォルト)に設定した場合、この起動サービスによって、セッションの所有権を持つメンバーが、現在ロックを保持しているスレッドのスタック・トレースを記録するようになります。
coherence-session-log-threads-holding-lockコンテキスト・パラメータは、coherence-sticky-sessionsコンテキスト・パラメータがtrueに設定されている場合にのみ使用可能です。このような要件があるのは、スティッキー・セッションの最適化が有効でないかぎり、Coherence Webが各セッション・アクセス・リクエストごとにクラスタ規模のロックを取得するためです。スティッキー・セッションの最適化を有効にすることにより、頻繁なロックの保持およびそれに続く多数のログ・ファイルの生成を回避できます。
すべての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)されます。
図5-8に、インプロセス・トポロジを示します。すべてのアプリケーション・サーバーが同じセッション・データ・キャッシュと通信します。
アウトオブプロセス・デプロイメント・トポロジでは、アプリケーション・サーバー(アプリケーション・サーバー層)をキャッシュ・クライアントとして構成し(tangosol.coherence.distributed.localstorage=false)、クラスタ化データを物理的に保存および管理してキャッシュ・サーバーとして動作する専用のJVMを配置します。
このアプローチには次のようなメリットがあります。
セッション・データ記憶域の負荷を、アプリケーション・サーバー層からキャッシュ・サーバー層に移管できます。これによって、ヒープ使用量やガベージ・コレクション時間などを低減できます。
アプリケーションとキャッシュ・サーバー層は、独立してスケールできます。アプリケーションの処理能力が不足している場合は、起動するアプリケーション・サーバーの数を増やすだけですみます。セッション記憶域の容量が不足している場合は、起動するキャッシュ・サーバーの数を増やすだけです。
アウトオブプロセス・トポロジは、その柔軟性によって、Oracle Coherenceのデフォルトの推奨トポロジになっています。図5-9に、アウトオブプロセス・トポロジを示します。アプリケーション層の各サーバーは、独自のニア・キャッシュを保持します。これらのニア・キャッシュは、別のキャッシュ・サーバー層で実行されるセッション・データ・キャッシュと通信します。
アプリケーションをインプロセス・トポロジからアウトオブプロセス・トポロジに容易に移行できます。このためには、アプリケーション・サーバーに加えてキャッシュ・サーバーを実行する必要があります。キャッシュ・サーバーを記憶域有効モードで起動し、これがアプリケーション・サーバーで使用しているものと同じセッションおよびキャッシュ構成ファイル(session-cache-config.xml)を参照するようにします。記憶域無効モードでアプリケーション・サーバーを起動します。詳細は、「アウトオブプロセス・トポロジへの移行」を参照してください。
Coherence*Extendは、クラスタの外部で実行されるExtendクライアント(またはプロキシ)と、1台以上のキャッシュ・サーバーでホストされているクラスタ内で実行される拡張プロキシ・サービスの2つの基本コンポーネントで構成されます。Coherence*Extendによるアウトオブプロセス・トポロジは、アウトオブプロセス・トポロジに似ていますが、アプリケーション・サーバー層とキャッシュ・サーバー層との通信をCoherence*Extend経由(TCP/IP)で行う点が異なります。このシナリオの構成手順は、「Coherence*ExtendによるCoherence*Webの構成」を参照してください。Coherence*Extendについては、『Oracle Coherenceクライアント・ガイド』を参照してください。
このアプローチには、アウトオブプロセス・トポロジと同じメリットがあるほか、アプリケーション・サーバーとキャッシュ・サーバーのデプロイメントをセグメントに分割する機能もあります。この特性は、UDPをサポートしていないネットワーク上にアプリケーション・サーバーが存在する環境に最適です。TCPを使用してクラスタにアプリケーション・サーバーを接続した上で、独立した専用のネットワークにキャッシュ・サーバーを配置できます。
図5-10に、Coherence*Extendによるアウトオブプロセス・トポロジを示します。アプリケーション・サーバー層のサーバー内のニア・キャッシュは、拡張プロキシを使用して、キャッシュ・サーバー層のセッション・データ・キャッシュと通信します。
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*Webを構成してCoherence*Extendを使用する手順は次のとおりです。
オプティミスティック・ロック・モードを使用するようにCoherence*Webを構成します(「オプティミスティック・ロック」を参照)。
プロキシおよび記憶域JVMのキャッシュ構成ファイルを構成します(「"プロキシJVMと記憶域JVMのキャッシュの構成」を参照)。
Web層キャッシュ構成ファイルが1つ以上のプロキシJVMを指定するように変更します(「Web層JVMのキャッシュの構成」を参照)。
セッション・キャッシュ構成ファイル(WEB-INF/classes/session-cache-config.xml)は、Coherence*Extendを使用するCoherence*Webのキャッシュ構成ファイルの一例です。
プロキシおよびサーバーJVMにはこのファイルを使用します。これには、同じファイルをプロキシJVMと記憶域JVMの両方に使用できるシステム・プロパティのオーバーライドが含まれます。プロキシJVMで使用する場合は、表5-1に示すシステム・プロパティを指定する必要があります。
表5-1 プロキシJVM用のシステム・プロパティ値
| システム・プロパティ名 | 値 |
|---|---|
|
|
|
|
|
|
|
プロキシがバインドされるNICのホスト名またはIPアドレス。 |
|
|
プロキシがバインドされるポートの一意のポート番号。 |
キャッシュ・サーバーで使用する場合は、表5-2に示すシステム・プロパティを指定します。
例5-3は、記憶域JVMのセッション・キャッシュ構成ファイルの全内容を示しています。
例5-3 session-cache-config-server.xmlファイル
<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- -->
<!-- Server-side cache configuration descriptor for Coherence*Web over -->
<!-- Coherence*Extend (see session-cache-config-web-tier.xml). -->
<!-- -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<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>
<instance>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</instance>
</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>
<instance>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</instance>
</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>
</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>
例5-4に示されているセッション・キャッシュ構成ファイルは、coherence-web.jarファイルにあるsession-cache-config.xmlファイルに基づいています。この例は、Coherence*Extendを使用するCoherence*Webキャッシュ構成ファイルを示しています。Web層JVMは、このキャッシュ構成ファイルを使用する必要があります。次の手順に従います。
Web層のセッション・キャッシュ構成ファイルをインストールする手順は次のとおりです。
coherence-web.jarファイルからsession-cache-config.xmlファイルを抽出します。
ファイルの<remote-addresses/>セクションに、プロキシJVMのホスト名とIPアドレス、およびポートを追加します。一般には、ロード・バランシングとフェイルオーバーに備えて、すべてのプロキシJVMのホスト名、IPアドレスおよびポートを追加します。
|
注意: <remote-addresses>要素には、Webコンテナの接続先となるプロキシ・サーバーがリストされています。デフォルトでは、Webコンテナはランダムにアドレスを選択します(複数のアドレスが構成されている場合)。Webコンテナとプロキシ間の接続が切断されると、コンテナはリスト内の別のプロキシに接続します。 |
ファイル名をsession-cache-config-web-tier.xmlに変更します。
このファイルをWebアプリケーションのWEB-INF/classesディレクトリに配置します。WebInstallerを使用してCoherence*Webをインストールした場合は、WebInstallerによって追加されている既存のファイルと置き換えます。
例5-4は、クライアント側のセッション・キャッシュ構成ファイルの全内容を示しています。
例5-4 session-cache-config-web-tier.xmlファイル
<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- -->
<!-- Client-side cache configuration descriptor for Coherence*Web over -->
<!-- Coherence*Extend (see session-cache-config-server.xml). -->
<!-- -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<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>
<instance>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</instance>
</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>
デフォルトでは、WebInstallerで設定されたWebアプリケーションは、サーブレットまたはフィルタがコールされるたびにセッションを取得します。サーブレットまたはフィルタで実際にセッションが必要であるかどうかに関係なく、セッションは取得されます。これにより、セッションが不要なサーブレットやフィルタを多数実行すると、時間がかかる場合や処理に負担がかかる場合があります。
この動作を防止するには、web.xmlファイルのcoherence-session-lazy-accessコンテキスト・パラメータをtrueに設定して遅延取得を有効にします。サーブレットやフィルタがアクセスを試みたときにのみ、セッションは取得されます。
HttpSessionCollection.SessionDistributionControllerインタフェースで記述されるCoherence*Webセッション・ディストリビューション・コントローラを使用すると、Webアプリケーション内のHTTPセッションと属性のデフォルトのディストリビューションをオーバーライドできます。coherence-distributioncontroller-classコンテキスト・パラメータを設定してデフォルトのディストリビューションをオーバーライドします(「セッション・ディストリビューション・コントローラの実装の登録」を参照)。コンテキスト・パラメータの値は、SessionDistributionControllerインタフェースの実装を示します。
SessionDistributionControllerインタフェースの実装では、セッションまたは属性を次のいずれかの方法で特定できます。
distributed: 分散されたセッションまたは属性は、Coherenceデータ・グリッド内に格納されるため、他のサーバーのJVMからアクセスできます。すべてのセッション(およびその属性)が分散管理されます。これがデフォルトの動作で、SessionDistributionControllerインタフェースのcom.tangosol.coherence.servlet.AbstractHttpSessionCollection$DistributedController実装により指定されます。
local: ローカルのセッションまたは属性は、それらの作成元サーバーのヒープに格納されるため、そのサーバーからのみアクセスできます。com.tangosol.coherence.servlet.AbstractHttpSessionCollection$LocalControllerクラスによりこの動作が指定されます。これは本番環境にはお薦めしませんが、ローカルのみの実装と完全な分散実装でのスケーラブル・パフォーマンスの違いをテストする場合に役立つことがあります。
hybrid: これは、すべてのセッションおよびシリアライズ可能な属性が分散管理されるdistributedに似ています。ただし、distributedとは異なり、Serializableインタフェースを実装していないセッション属性は、localのままとなります。com.tangosol.coherence.servlet.AbstractHttpSessionCollection$HybridControllerクラスによりこの動作が指定されます。
セッションの存続期間中であればどの時点でも、セッションまたはそのセッションの属性をlocalまたはdistributedから変更できます。ただし、一度分散されたセッションまたは属性は、localに戻すことはできません。
セッション・ディストリビューション・コントローラには、次のような使い方があります。
新しいセッションは、属性を追加するまで(たとえば、オンライン・ショッピング・カートに1つ目のアイテムを追加するまで)、localのままにできます。これは、セッションに意味のあるデータが含まれる場合のみ、セッションをフォルト・トレラントにする必要があるという発想です。
一部のWebフレームワークは、セッションの属性を使用してUIのレンダリング状態を格納します。一般に、このデータはシリアライズ不能なため、分散できません。セッション・ディストリビューション・コントローラを使用すると、これらの属性をlocalとして維持したまま、残りのセッションの属性を分散させることができます。
セッション・ディストリビューション・コントローラは、非分散システムを分散システムに変換する場合に役立ちます。特に、すべてのセッションとすべての属性の分散コストが検討事項となっている場合は有効です。
例5-5は、HttpSessionCollection.SessionDistributionControllerインタフェースの実装例を示しています。この例では、セッションにショッピング・カートがアタッチされているかどうかがテストされます(アタッチされているセッションのみが分散されます)。次に、そのセッションに特定の属性が含まれているかどうかがテストされます。その属性が検出された場合、その属性は分散されません。
例5-5 セッション・ディストリビューション・コントローラの実装例
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が追跡を行います。これを行うには、最初のシリアライズされたバイナリ・フォームの属性がセッションから取得されたときに、これをキャッシュします。リクエストの処理の最後に、Coherence*Webは現在の属性のバイナリ値と「古い」バージョンのバイナリを比較します。値が一致しない場合、現在の値がキャッシュに書き込まれます。アプリケーションで該当するsetを行わずにセッション属性を変更することはないことがわかっている場合は、coherence-enable-suspect-attributesコンテキスト・パラメータをfalseに設定する必要があります。これにより、メモリー使用率およびニア・キャッシュの最適化が改善されます。
デフォルトでは、Coherence*Webはすべてのセッション属性のシリアライズを試みます。シリアライズできないセッション属性を処理している場合、coherence-preserve-attributesパラメータをtrueに設定することにより、これらをローカルに保存できます。このパラメータでは、セッションのシリアライズ不可属性を取得するためにロード・バランサが必要です。
クライアント(アプリケーション・サーバー)が失敗した場合、属性は失われます。アプリケーションは、この状態から復旧できる必要があります。
このパラメータのデフォルトはfalseです。GlassFishにActiveCacheを使用している場合、GlassFish Serverではローカル・セッションが使用できる必要があるため、この値はtrueに設定します。
coherence-preserve-attributesパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
許可されていないCoherence TCMPクラスタ・メンバーによるHTTPセッション・キャッシュ・サーバーへのアクセスを防止するため、CoherenceではSecure Socket Layer(SSL)実装を提供します。この実装は、クラスタ・ノード間のTCMP通信やCoherence*Extendクライアントとプロキシ間のTCP通信の保護に使用できます。Coherenceでは、SSL 3.0プロトコルの次のバージョンのTransport Layer Security(TLS)1.0プロトコルを使用できます。しかし、SSLの方が広く認識されている用語であるため、SSLという用語を使用します。
ここでは、Coherence環境でのSSLの使用方法の概要のみを説明します。詳細および構成のサンプルは、Oracle Coherenceセキュリティ・ガイドのSSLを使用した通信の保護に関する項を参照してください。
SSLを使用したTCMP通信の保護
Coherenceクラスタは、TCMPでSSLを使用するように構成できます。Coherenceでは、一方向と双方向の両方の認証を使用できます。通常、双方向の認証を使用する方が一方向の認証よりも多く、クラスタ環境では一方向の認証は双方向の認証ほど使用されません。さらに、TCMPではpeer-to-peerプロトコルであることを認識する必要があります。peer-to-peerプロトコルは、通常、多くのクラスタ・ノードを相互に接続したままであることが想定される信頼できる環境で動作します。管理およびパフォーマンスに関してSSLが受ける可能性のある影響について、慎重に考慮する必要があります。
この構成では、ピア信頼に基づく双方向通信のSSL接続を可能にする事前定義済のそのまま使用できるSSLソケット・プロバイダを使用することも、独自のSSLソケット・プロバイダを定義することもできます。
SSLを使用した拡張クライアント通信の保護
Extendクライアントと拡張プロキシの間の通信は、SSLを使用して保護できます。SSLには、クライアント側とクラスタ側の両方での構成が必要です。クラスタ側では、プロキシ・サービス用のSSLソケット・プロバイダを定義することにより、SSLをクラスタ側キャッシュ構成ファイルに構成します。SSLソケット・プロバイダは、すべてのプロキシ・サービス用にも、個々のプロキシ・サービス用にも定義できます。
クライアント側では、リモート・キャッシュ・スキーム用、また必要に応じてリモート起動スキーム用のSSLソケット・プロバイダを定義することにより、SSLをクライアント側キャッシュ構成ファイルに構成します。クラスタ側と同様に、SSLソケット・プロバイダは、すべてのリモート・サービス用にも、個々のリモート・サービス用にも定義できます。
