| Oracle® Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理 12c (12.2.1) E69902-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理 12c (12.2.1) E69902-02 |
|
前 |
次 |
この章では、WebLogic Serverで使用するために、Coherence*Web、セッション状態の永続性および管理モジュールを構成してデプロイする方法について説明します。Coherence*Webをこのアプリケーション・サーバーで使用可能にする機能は、Coherence*Webに含まれています。
この章では、Coherenceアプリケーションをグリッド用にパッケージ化する管理対象CoherenceサーバーおよびGrid Archive (GAR)形式の概要についても説明します。管理対象CoherenceサーバーおよびGAR形式の詳細な説明はこのドキュメントの範囲外です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server用Oracle Coherenceアプリケーションの開発』を参照してください。
この章には次の項が含まれます:
Coherence*Webでは、セッション状態の持続および管理が実現されます。セッション・データの格納および管理にCoherenceキャッシュを使用するのは、セッション管理モジュールです。Coherence*Webは、WebLogic Serverのメモリー内HTTP状態レプリケーション・サービスにかわるものです。次のいずれかの状況に該当する場合は、Coherence*Webの使用を検討してください。
アプリケーションで使用するHTTPセッション状態オブジェクトが大きい
HTTPセッション・オブジェクト・データの格納に起因するメモリー制約がある
HTTPセッション記憶域の負荷を既存のCoherenceクラスタに分散させる必要がある
複数のエンタープライズ・アプリケーションと複数のWebモジュールにおいてセッション状態を共有する必要がある
Coherence*Webを定義するクラスは、coherence-web.jarファイルに含まれています。Coherence*Webで提供される機能を使用するには、Webアプリケーションに対してcoherence.jarクラスも使用可能にする必要があります。これらのライブラリはいずれもWebLogic Serverシステム・クラスパスにあり、実行時に自動的にロードされます。coherence-web.jarは、適切なクラス・ローダーでアプリケーション・クラスをWebLogic Serverにロードします。
|
注意: WebLogic ServerとCoherenceは、Coherence*Webを使用する場合、同じバージョンである必要があります。 |
Coherence*Webで使用されるCoherenceキャッシュ構成とサービスは、default-session-cache-config.xmlファイルで定義され、このファイルはcoherence-web.jarファイル内にあります。default-session-cache-config.xmlファイルで定義されているデフォルト・キャッシュ構成とサービス構成は、ほとんどすべてのWebアプリケーションに対応可能です。
session-cache-config.xmlという名前のファイルをWebアプリケーションにパッケージ化することにより、自分専用のカスタム・セッション・キャッシュ構成を作成できます。詳細は、「カスタム・セッション・キャッシュ構成ファイルの使用方法」を参照してください。
Coherence*WebはWebLogic Serverで起動されると、最初にsession-cache-config.xmlという名前のファイルを探します。たとえば、このファイルはWARファイルのWEB-INF/classesディレクトリに置いてあるか、JARファイルにパッケージ化されてEARファイルのAPP-INF/libディレクトリに置いてある可能性があります。カスタム・セッション・キャッシュ構成XMLリソースが見つからない場合は、coherence-web.jarにパッケージ化されているdefault-session-cache-config.xmlファイルが使用されます。
Coherence*Webでは、次のデフォルト・キャッシュ構成が定義されています。
WebLogic Server向けCoherence*Webは、ローカル記憶域を無効にした状態で構成します。サーバーはリクエストの処理に使用され、データのホストには使用されません。これは、WebLogic Serverを実行しているJVMとは別に、Coherenceキャッシュ・サーバーを専用のJVMで実行する必要があることを意味します。
キャッシュ・サーバーがリクエストに応答するまでのタイムアウトは30秒です。キャッシュ・サーバーへのリクエストに対して30秒以内に応答が返らない場合は、com.tangosol.net.RequestTimeoutException例外がスローされます。
WebLogic Server上で実行されているすべてのCoherence*Web対応アプリケーションは、アプリケーション・サーバー・スコープを持ちます。この構成では、デプロイされたすべてのアプリケーションが1つのCoherenceノードに含まれます。クラスタ・ノードのスコープの詳細は、「クラスタ・ノード分離」を参照してください。
Coherence*Webには、セッションの同時アクセスを制御するためのセッション・ロック・モードがいくつかあります。両方のCoherence*Webに、最後の書込みを優先するロックがデフォルトで採用されています。ロック・モードの詳細は、「セッション・ロック・モード」を参照してください。
Coherence*Webは、単独ではロード・バランサをWebLogic Server層の前で実行する必要はありません。ただし、ロード・バランサによりパフォーマンスが向上します。同じセッションが同時に使用されロックが有効でない場合に必要です。デフォルトのロード・バランサでは、HTTPセッションのJVMアフィニティを適用しますが、他のロード・バランシング方法も使用できます。WebLogic Serverには、JVMセッションの持続性を維持するための様々なプロキシ・プラグインが付属しています。WebLogic Serverプロキシ・プラグインの構成に関するドキュメントは次のURLから入手できます。
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13709/load_balancing.htm
Oracle WebLogic ServerとCoherenceには、WebLogic Server上でホストされている他のJava EEアプリケーションと同様の利点をCoherenceアプリケーションに提供する管理対象Coherenceサーバーが定義されています。次のような利点があります。
Coherenceアプリケーションを、他のJava EEアプリケーションと同様の方法でデプロイできます。
グリッド内のCoherenceアプリケーションを、WebLogic Server管理コンソールおよびWLSTを使用して管理できます。
WebLogic構成を使用して、Coherenceクラスタを構成できます。
Coherence Grid ArchiveをEnterprise Archive (EARファイル)に統合できます。
Coherenceアプリケーションを既存のCoherenceベースの機能に統合できます。
|
注意: 単一のWebLogic Serverドメインでの複数のCoherenceクラスタの使用はお薦めしません。 |
管理対象Coherenceサーバーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server用Oracle Coherenceアプリケーションの開発』のWebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。
次の手順は、WebLogic Server上で実行しているアプリケーションでCoherence*Webを使用するためにデプロイメントを準備する方法を示しています。
WebLogic ServerとOracle Coherenceをインストールします。「WebLogic ServerとOracle Coherenceのインストール」を参照してください。
(オプション) アプリケーションにCoherence*Web用の高度な構成が必要な場合は、デプロイメントのweb.xmlファイルを変更します。Webアプリケーションに対して構成可能なパラメータについては、「Coherence*Webの構成」で説明します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
(オプション)WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xmlまたはweblogic-application.xmlのファイルで構成します。「セッションCookieの構成」を参照してください。
(テストの場合はオプション、本番の場合は強く推奨)WebLogic Serverを実行しているJVMとは別のJVMでキャッシュ・サーバー層を起動します。「キャッシュ・サーバーの起動」を参照してください。
Coherence*Webの記憶域モードを設定します。「Coherence*Webの記憶域モードの構成」を参照してください。
アプリケーションをWebLogic Serverにデプロイします。「WebLogic Serverへのアプリケーションのデプロイ」を参照してください。
WebLogic Serverは、インストーラを実行するとインストールされます。インストーラはフル・インストールを提供し、インストールするコンポーネント(ビット、サンプル、Javadocなど)を個々に選択することが可能です。インストーラでは、Oracle Universal Installer (OUI)を使用したグラフィカル・モードとサイレント・モードの両方がサポートされています。Coherenceのインストールは、WebLogic Serverインストーラのオプションです。
WebLogic Serverは常にORACLE_HOME/wlserverディレクトリにインストールされます。Coherenceは常にORACLE_HOME/coherenceディレクトリにインストールされます。
WebLogic Server and Coherenceのインストールの詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。
Coherence*Webにより、大半のWebアプリケーションに対応するデフォルト構成を実現します。表2-1で、Coherence*Webにより構成されるコンテキスト・パラメータについて説明します。表2-2で、互換性モード・コンテキスト・パラメータについて説明します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
コンテキスト・パラメータは、システム・プロパティとしてコマンド行で構成することもできます。システム・プロパティは、コンテキスト・パラメータと同じ名前を持ちますが、ダッシュ(-)がピリオド(.)に置き換えられています。たとえば、coherence-enable-sessioncontextコンテキスト・パラメータの値をコマンド行で宣言するには、次のように入力します。
-Dcoherence.enable.sessioncontext=true
システム・プロパティと、同等のコンテキスト・パラメータの両方が構成されている場合、システム・プロパティの値が使用されます。
表2-1 Coherence*Webによって構成されるコンテキスト・パラメータ
| パラメータ名 | 説明 |
|---|---|
|
|
Coherence*Webではこのパラメータの値を使用して、 アプリケーション名 + ! + Webモジュール名 application nameは たとえば、 このパラメータが構成されていない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。また、このパラメータが構成されておらず、 |
|
|
この設定により、セッション・リーパーでは、(たとえば、分散キャッシュ・サービスによって)このノードに保存されるセッションは、このノードで期限切れのチェックが必要なセッションのみであると仮定できます。 デフォルトは |
|
|
この値は、オプションの 有効な値は次のとおりです。
Coherence*Webで設定するデフォルトは |
表2-2は、Coherence*Webで具体的に渡されたcoherence-session-weblogic-compatibility-modeコンテキスト・パラメータを示しています。
表2-2 Coherence*Webによって渡されるコンテキスト・パラメータ
| パラメータ名 | 説明 |
|---|---|
|
|
このパラメータは、Coherence*Webによって渡されます。この値を グローバル・スコープ・コントローラが指定されていないかぎり、このパラメータではデフォルトで |
表2-3は、coherence-factory-classコンテキスト・パラメータを示しています。デフォルト値はCoherence*Webで設定されますが、変更しないでください。
Coherence*Webを使用すると、WebLogic ServerによってセッションCookieが生成および解析されます。この場合、ネイティブCoherence*WebセッションCookie構成パラメータはすべて無視されます。セッションCookieを構成するには、WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xmlまたはweblogic-application.xmlのファイルで使用します。これらのパラメータについては、表2-4を参照してください。
この表で「更新可能?」は、サーバー実行中にパラメータ値が変更可能かどうかを示します。「該当なし」は、対応するCoherenceセッションCookieパラメータがないことを示します。
表2-4 WebLogicによって生成されるHTTPセッションのCookieパラメータ
| セッションCookieパラメータ | 置き換えられるCoherence*Web Cookieパラメータ | 説明 |
|---|---|---|
|
|
該当なし |
Cookieファイルにあるセッション追跡Cookieを特定するコメントを指定します。 デフォルトは 更新可能?はい |
|
|
|
Cookieを有効にするドメインを指定します。たとえば、 このドメイン名では2つ以上の要素を指定する必要があります。 値を設定しない場合は、Cookieを発行したサーバーにデフォルトで設定されます。 詳細は、サーブレット仕様で「 デフォルトは 更新可能?はい |
|
|
|
セッションCookieの存続期間(秒)を設定します。この時間が経過したクライアントではセッションCookieが期限切れになります。Cookieの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』でセッションとセッション持続性の使用方法に関する項を参照してください。 デフォルト値は 更新可能?はい |
|
|
|
セッション・トラッキングのCookie名を定義します。設定しない場合は、デフォルトで デフォルトは 更新可能?はい |
|
|
|
セッション・トラッキングのCookieパスを定義します。 値を指定しない場合は、デフォルトで「 デフォルトは 更新可能?はい |
|
|
|
HTTPS接続経由でのみCookieを返すことができることをブラウザに指示します。これによって、Cookie IDが保護されます。この設定は、HTTPSを使用するWebサイトでのみ使用してください。この機能が有効な場合、HTTP経由で送信されるセッションCookieは機能しません。 この機能を使用する場合は、 WebLogic ServerによってセッションCookieが生成されます。 デフォルトは 更新可能?はい |
|
|
|
セッションCookieの使用がデフォルトで有効になり、これをお薦めしますが、このプロパティを デフォルトは 更新可能?はい |
|
|
該当なし |
HTTPセッションに対するデバッグ機能を有効にします。これは、 デフォルト値は、 更新可能?はい |
|
|
該当なし |
最新のサーブレット仕様でパス・パラメータのセッションIDをコンテナでエンコードする必要がある場合、 WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルト値は、 更新可能?はい |
|
|
該当なし |
WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルト値は 更新可能?はい |
|
|
|
セッションIDのサイズを設定します。 最小値は8バイト、最大値は Wireless Application Protocol (WAP)アプリケーションを作成している場合、WAPプロトコルではCookieがサポートされないので、URLリライティングを使用する必要があります。また、WAPデバイスの中にはURL長を128文字(属性を含む)に制限しているものがあり、その場合はURLリライティングを使用して送信できるデータの量に制限があります。属性に使用できる領域を増やすには、この属性を使用して、WebLogic Serverでランダムに生成されるセッションIDのサイズを制限します。
デフォルトは52です。 更新可能?いいえ |
|
|
該当なし |
タイムアウトしたセッションおよび無効なセッションに対してチェックを実行してから古いセッションを削除してメモリーを解放するまで、Coherence*Webが待機する時間(秒単位)を設定します。この要素を使用して、トラフィックが多いサイトで最適なパフォーマンスが得られるようにWebLogic Serverを調整します。 デフォルトは 更新可能?いいえ |
|
|
該当なし |
セッションをタイムアウトするまでCoherence*Webが待機する時間(秒単位)を設定します。 アクセスが多いサイトでは、セッションのタイムアウトを適切に設定することによってアプリケーションを調整できます。ブラウザ・クライアントにセッションを終了する機会を提供するとともに、ユーザーがサイトを離れたりその他の方法でセッションを破棄した場合に、サーバーを不要に拘束しないようにします。 この要素は、 デフォルトは 更新可能?いいえ |
|
|
該当なし |
HTTPリクエスト間のセッション・トラッキングを有効にします。 WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルトは 更新可能?いいえ |
|
|
|
URLリライティングを有効化します。これにより、ブラウザでCookieが無効化されている場合にセッションIDがURLにエンコードされてセッション・トラッキングが提供されます。URLを書き込むときには
WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルトは 更新可能?はい |
Coherenceキャッシュ・サーバーは、すべてのキャッシュ・データを格納して管理します。Coherenceは、コンテナ・サブシステムとしてWebLogic Serverに統合されます。コンテナを使用することで、Coherenceクラスタ・メンバーのライフサイクルを、管理対象サーバーのライフサイクルに合せます。つまり、管理対象サーバーJVMの開始と終了にあわせてCoherenceクラスタ・メンバーを開始および終了することになります。クラスタ・メンバーである管理対象サーバーは、管理対象Coherenceサーバーと見なされます。
Coherenceクラスタは、WebLogic Serverクラスタとは異なります。異なるクラスタリング・プロトコルを使用し、別個に構成されます。複数のWebLogic Serverクラスタを1つのCoherenceクラスタに関連付けることができ、WebLogic ServerドメインにCoherenceクラスタを1つのみ含めることができます。Coherenceクラスタ・メンバーとして構成されている管理対象サーバーは、管理対象Coherenceサーバーと見なされます。
管理対象Coherenceサーバーを明示的にCoherenceクラスタに関連付けたり、Coherenceクラスタに関連付けられているWebLogic Serverクラスタに関連付けることができます。Coherenceクラスタのメンバーであり記憶域を有効化した、WebLogic Serverによって管理されるサーバーは、キャッシュ・サーバーとして機能します。
WebLogicサーバー環境におけるCoherenceクラスタの詳細は、Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成および管理に関する項を参照してください。WebLogic Server環境におけるCoherenceアプリケーションの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
次の各項で説明するように、Coherenceキャッシュ・サーバーまたはクラスタは、WebLogic Server管理コンソールまたはコマンド行のいずれかから起動できます。
WebLogic Server管理コンソールを使用して、Coherenceクラスタのメンバーである各WebLogic Serverの記憶域を有効化できます。Coherenceセッション・キャッシュには、記憶域を有効化するための別個のフラグがあります。このフラグの詳細は、「WebLogic Server管理コンソールでのCoherenceセッション・キャッシュの有効化」を参照してください。
|
注意: 管理対象サーバーがCoherenceクラスタのメンバーでありCoherence*Webを使用している場合、セッション記憶域を有効化するには-Dcoherence.session.localstorage=trueシステム・プロパティを起動コマンドに追加します。 |
Coherenceセッション・キャッシュが自動的にWebLogic Serverクラスタで開始します。Coherenceキャッシュ・サーバーをWebLogic Server管理コンソールで操作する場合の例は、『Oracle Coherenceチュートリアル』の管理対象Coherenceサーバーによるセッションのキャッシングに関する項を参照してください。
次の手順は、CoherenceクラスタをWebLogic Server管理コンソールで起動する方法を示しています。
Coherenceクラスタを構成します。
詳細は、Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成および管理に関する項を参照してください。
Coherenceクラスタに関連付けられるWebLogic Serverおよびクラスタを構成します。
詳細は、Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成および管理に関する項を参照してください。
選択したWebLogic ServerまたはクラスタのCoherence*Webを有効化します。
詳細は、WebLogic Server管理コンソールでのCoherenceセッション・キャッシュの有効化に関する項を参照してください。
WebLogic Server管理コンソールを使用するかわりに、コマンド行からのCoherenceキャッシュ・サーバーまたはクラスタの起動が必要になる場合があります。Coherenceキャッシュ・サーバーは、コマンド行からスタンドアロン・モードまたはWebLogic Serverインスタンスの一部として起動できます。
スタンドアロンCoherenceキャッシュ・サーバーを起動するには、次の手順を実行します。
Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。記憶域が有効なキャッシュ・サーバーを作成して起動する簡単なスクリプトの例を次に示します。この例では、Sun JVMの使用を前提としています。詳細は、『Oracle Coherenceでのアプリケーションの開発』のJVMのチューニングに関する項を参照してください。
java -server -Xms512m -Xmx512m -cp <Coherence installation dir>/lib/coherence-web.jar:<Coherence installation dir>/lib/coherence.jar -Dcoherence.management.remote=true -Dcoherence.cacheconfig=session_cache_configuration_file-Dcoherence.session.localstorage=true -Dcoherence.cluster=Coherence_cluster_namecom.tangosol.net.DefaultCacheServer
クラスパスのcoherence-web.jarとcoherence.jarを含める必要があります。変数session_cache_configuration_fileは、ファイル・システムにおけるキャッシュ構成ファイルへの絶対パスを示します。Coherence*Webでは、デフォルトのセッション・キャッシュ構成ファイル名はdefault-session-cache-config.xmlです。キャッシュ・サーバーに対して定義されているキャッシュ構成は、同じCoherenceクラスタで実行されているアプリケーション・サーバーに対して定義されているキャッシュ構成と一致する必要があります。
アプリケーションで追加のCoherenceキャッシュを使用する場合は、カスタマイズしたセッション・キャッシュ構成ファイルとキャッシュ構成情報をマージする必要があります。このカスタマイズしたセッション・キャッシュ構成ファイル(通常、名前はsession-cache-config.xml)には、default-session-cache-config.xmlファイルの内容およびアプリケーションで使用されている追加のキャッシュを含める必要があります。
キャッシュ構成とセッション構成は、WebLogic ServerとCoherenceキャッシュ・サーバーとの間で一貫している必要があります。
これらのファイルをマージする方法の詳細は、『Oracle Coherenceの統合』のCoherenceキャッシュとセッション情報のマージに関する項を参照してください。
変数Coherence_cluster_nameはCoherenceクラスタの名前を表します。WebLogic Serverリリース10.3.6以降に、クラスタ名のチェック機能が追加されています。WebLogic Serverアプリケーションでクラスタ名を宣言しているため、coherence.clusterプロパティをキャッシュ・サーバーに追加する必要があります。スタンドアロン・モードで起動された場合、Coherenceサーバーはこのプロパティを渡す必要があります。そうしないと、WLSサーバーとスタンドアロン・キャッシュ・サーバー間にクラスタは形成されません。
前述の手順で説明したスクリプトを使用して、Coherenceキャッシュ・サーバーを1つ以上起動します。
デフォルトでは、Coherence*Webを使用可能なWebLogic Serverインスタンスは、記憶域を無効化した状態で起動します。記憶域を有効化した状態でWebLogic Serverインスタンスを起動する手順は次のとおりです。
Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。これは、前項で説明されているスクリプトと同様にできます。
-Dcoherence.session.localstorage=trueのコマンド行プロパティをサーバー起動コマンドに含め、ローカル記憶域を有効にします。WebLogic Serverインスタンスが、Coherence*Webが使用可能で、ローカル記憶域を有効化した状態で起動します。
Coherence*Webを使用可能なWebLogic Serverインスタンスを起動するには、このシステム・プロパティを省略します。ローカル記憶域はデフォルトでは無効化されています。
コマンド行からのWebLogic Serverの操作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド行リファレンスに関する項を参照してください。
weblogic.xmlセッション構成でpersistent-store-type属性の値としてcoherence-webを指定することにより、Coherence*Webセッション記憶域を有効にできます。この構成では、WebLogic ServerにデプロイされたWebアプリケーションに対して、アプリケーション・サーバー・レベルのクラスタ・ノードのスコープ設定が提供されます。共有ライブラリをデプロイする必要はなく、また共有ライブラリに依存する必要もありません。
Coherence*Webは、WebLogic Serverインスタンスでのセッション持続が必要なWebアプリケーションの起動時にのみ初期化されます。
例2-1は、persistent-store-type属性の値がcoherence-webであるサンプルweblogic.xmlファイルを示しています。
デフォルト・セッション・キャッシュ構成ファイルをWebアプリケーションで使用している場合は、それを他のJava EEアプリケーションのようにパッケージ化してデプロイできます。ただし、カスタム・セッション・キャッシュ構成ファイルを使用している場合は、アプリケーションをGARファイルでパッケージ化してデプロイする必要があります。
GARファイルは他のあらゆるJava EEアプリケーションと同様にデプロイされますが、Coherence層とその層に属するノードを作成する点が異なります。スタンドアロンGARまたは埋込みGARを構成できます。
スタンドアロンGARファイルおよび埋込みGARファイルの構成およびデプロイの詳細は、『Oracle Coherenceの管理』のCoherenceアプリケーションのWebLogic Serverへのデプロイに関する項および『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』のWebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。
WebLogic Serverは、ドメイン内のクラスタを表す、クラスタMBean (weblogic.management.configuration.ClusterMBean)を定義します。クラスタMBeanは、クラスタの管理に関連する複数の属性、操作およびMBeanを定義します。クラスタMBeanにより定義されるMBeanの例として、CoherenceMemberConfigMBeanとCoherenceTierMBeanがあります。
CoherenceMemberConfigMBeanとCoherenceTierMBeanはそれぞれ、クラスタまたはメンバーがCoherence*Webに対する記憶域層として機能しているかどうかを示すisCoherenceWebLocalStorageEnabled属性を定義します。この属性の定義を表2-5に示します。
表2-5 Coherence*Web用のCoherence MBean属性
| 属性 | 説明 |
|---|---|
|
isCoherenceWebLocalStorageEnabled |
この属性が この属性が デフォルト: |
WebLogic Server管理コンソールの「Coherence Webローカル記憶域有効」チェック・ボックスは、前項で説明したisCoherenceWebLocalStorageEnabled属性に対応しています。このチェック・ボックスは、クラスタがCoherence*Webの記憶域層として機能しているかどうかを示します。このチェック・ボックスに移動する手順は次のとおりです。
「ドメイン構造」ウィンドウで、「環境」→「クラスタ」を選択します。
「クラスタ」表内の定義済クラスタを選択します。
「クラスタの設定」ページで、「構成」タブ→「Coherence」タブを選択します。
図2-1に、WebLogic Server管理コンソールの「クラスタの設定」ページの「Coherence Webローカル記憶域有効」チェック・ボックスを示します。
coherence-web.jarファイルにはdefault-session-cache-config.xmlキャッシュ構成ファイルが含まれ、これはほとんどのアプリケーションに対応可能です。ただし、Coherence*ExtendまたはPush Replicationなどのテクノロジを使用している場合、またはカスタム・セッション・キャッシュ構成を使用する記憶域有効キャッシュ・サーバーとして機能するWebLogic Serverノードがある場合は、カスタム・セッション・キャッシュ構成ファイルを使用する必要があります。カスタム・セッション・キャッシュ構成ファイルを、デプロイメント用のGARファイルにパッケージ化する必要があります。
カスタム・セッション・キャッシュ構成ファイルをWebLogic Serverで使用してGARファイルにパッケージ化するには、次のWebアプリケーションの手順と、キャッシュ・サーバーとして機能しているWebLogic Serverノードの手順に従ってください。
Coherence*Webを使用しているWebアプリケーションの場合
カスタム・セッション・キャッシュ構成ファイル(名前はsession-cache-config.xml)を使用している場合は、Webアプリケーションでパッケージ化します。
WARファイルについては、セッション・キャッシュ構成ファイルをWEB-INF/classesフォルダに置きます。
EARファイルについては、セッション・キャッシュ構成ファイルをJARファイルにパッケージ化し、EARファイル内の共有ライブラリ(APP-INF/libフォルダ)に配置します。
セッション・キャッシュ構成ファイル名はカスタマイズできますが、その場合は、web.xmlファイルでcoherence-cache-configuration-pathコンテキスト・パラメータの値として新しいファイル名を指定する必要があります。
Coherence*Webアプリケーションで実行しているWebLogic Serverクラスタ・メンバーがキャッシュ・サーバーとして機能しないようにするには、WebLogic Server管理コンソールの「クラスタの設定」ページの「Coherence Webローカル記憶域有効」チェック・ボックスが選択されていないことを確認します。これにより、カスタム・セッション・キャッシュ構成ファイルが読み取られるようになります。
キャッシュ・サーバーとして機能しているWebLogic Serverノードの場合
カスタム・セッション・キャッシュ構成ファイルを使用している場合は、このファイルとcoherence-application.xmlファイルが含まれたGARファイルを作成します。GARファイルの構造は次のとおりです。
my.gar
session-cache-config.xml
META-INF
coherence-application.xml
MANIFEST.MF
GARファイルのパッケージ化要件の詳細は、『Oracle Coherenceの管理』のWebLogic Server用のCoherenceアプリケーションのパッケージ化に関する項およびOracle WebLogic Server用Oracle Coherenceアプリケーションの開発のOracle WebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。
カスタム・セッション・キャッシュ構成ファイルを作成し、session-cache-config.xmlという名前を付けます。
GARファイルをデプロイしている場合は、カスタムのsession-cache-config.xmlファイルの中のlocal-storageパラメータをtrueに設定して、すべてのキャッシュが記憶域を有効にした状態で起動するように構成します。次に例を示します。
<local-storage>true</local-storage>
|
注意: local-storageパラメータは、クラスタ・ノードをクラスタの記憶域として機能させるかどうかを指定します。WebLogic Serverでは、local-storageパラメータによって、GARファイルがデプロイされているWebLogic ServerメンバーのCoherence*Webの記憶域が有効にはなりません。 |
coherence-application.xmlファイルを作成します。ファイル内で、cache-configuration-refパラメータを使用してカスタムsession-cache-config.xmlファイルを、次の例のように参照します。
<?xml version="1.0"?>
<coherence-application>
xmlns="http://xmlns.oracle.com/weblogic/coherence-application">
<cache-configuration-ref>session-cache-config.xml</cache-configuration-ref>
</coherence-application>
記憶域が有効なCoherenceクラスタ・メンバーとして機能するWebLogic ServerクラスタにGARファイルをデプロイします。
次のいずれかの方法で、記憶域を有効にする必要があることに注意してください。
session-cache-config.xmlファイルで記憶域を有効にする(手順1aを参照)
WebLogic Server管理コンソールの「Coherence Webローカル記憶域有効」チェック・ボックスを選択するか、JVM引数coherence.session.localstorageをtrueに設定して、サーバー自体で記憶域を有効にする。
GARファイルのデプロイの詳細は、『Oracle Coherenceの管理』のWebLogic ServerドメインへのCoherenceアプリケーションのデプロイに関する項および『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』のWebLogic ServerへのCoherenceアプリケーションのデプロイに関する項を参照してください。
WebLogic ServerとCoherence*Webでは、セッション・スコープ設定とセッション・ライフサイクルは異なる方法で処理されます。これは、アプリケーションのシングル・サインオン(SSO)戦略を実装するための意思決定に影響を与えることがあります。
デフォルトでは、WebLogic Serverは、指定クライアントに対してすべてのWebアプリケーションで同じセッションIDを使用し、セッションCookieパスを「/」(スラッシュ)に設定します。これは、WebLogic Serverのデフォルトthin SSO実装要件であり、デフォルトで有効に設定されます。「/」のパスを持つセッションCookieを生成することによって、クライアントはサーバーへのすべてのリクエストで同じセッションIDを返すようになります。WebLogic Serverでは、1つのセッションIDを複数のセッション・オブジェクトにマップできます。セッションIDが同一であっても(セッション共有が有効になっていないかぎり)、各Webアプリケーションは異なるセッション・オブジェクト・インスタンスを持つことになります。
対照的に、Coherence*Webでは、1つのセッションIDが1つのセッション・インスタンスにマップされます。したがって、アプリケーションでCoherence*Webが使用される場合、複数のセッション・インスタンスを同じIDにマップする動作は、デフォルトではレプリケートされません。セッションCookieはデフォルトでは「/」にマッブされるため、1つのCoherence*WebセッションがすべてのWebアプリケーションにわたって共有されます。Coherence*Webにおけるデフォルト構成では、すべてのセッション属性が1つのWebアプリケーションにスコープ設定されます。多くの場合、この単一セッションの方法は透過的です。すべてのWebアプリケーションにわたって1つのセッションを保持することの大きな相違はセッション無効化の影響です。Coherence*Webが有効になっているが、1つのWebアプリケーションでセッションを無効化した場合、そのセッション・インスタンスを使用するすべてのWebアプリケーションでそのセッションが無効化されます。Webアプリケーションでthin SSOが使用されていない場合、セッションCookieをWebアプリケーション・パスにスコープ設定することでこの問題を回避できます。
したがって、SSOに関しては次のオプションがあります。
WebLogic Serverのセッション互換モードを有効にします。この構成は、coherence-session-weblogic-compatibility-modeパラメータで設定し、メモリー(単一サーバー、非レプリケート)、ファイル・システム持続性、JDBC持続性、Cookieベースのセッション持続性およびインメモリー・レプリケーション(クラスタ全体)といったすべてのネイティブWebLogic Serverセッション持続タイプをミラー化します。デフォルトでは、このモードが有効になります。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』でセッションとセッション持続性の使用方法に関する項を参照してください。
thin SSO機能を有効にします。クライアントは、すべてのWebアプリケーションにわたって単一セッションを使用します。したがって、セッション・ライフサイクルは、他のすべてのセッション持続タイプと一貫性がないものになります。
セッションCookieパスのスコープをWebアプリケーション・コンテキスト・パスに設定することによってthin SSO機能を無効化します。これにより、セッション・ライフサイクルは、他のすべてのセッション持続タイプと一貫したものになります。
Coherence*Webでthin SSOを有効化する利点は、Coherence*Webに対して同じCoherenceクラスタを使用するすべてのWebアプリケーションにわたって機能することです。CoherenceクラスタはWebLogic Serverクラスタから完全に独立しています。thin SSO機能は、WebLogic Serverセキュリティ・レイヤーでドメイン間の信頼関係を有効にすると、複数のドメインにわたって機能するようになります。
ユーザーが保護リソースの認証に成功すると、セッションIDはセキュリティのために変更されます。
以前のリリースのWebLogic Serverでは、新しいセッションが作成されて、古いセッションのすべてのセッション属性は新しいセッションにコピーされ、その後で古いセッションは無効化されました。これによりセッション・リスナー(登録されている場合)がトリガーされて、セッション・ライフサイクルおよびセッション属性リスナーが実行されます。
現在のリリースのWebLogic Serverは、HttpServletRequest.changeSessionIdメソッドをJava Servlet 3.1仕様から実装します。changeSessionIdメソッドの実装により、実際のセッションIDの更新が可能になります。つまり、セッション・ライフサイクル・イベントはトリガーされなくなり、実行されるリスナーもありません。ほとんどのユーザーは、アプリケーションの動作の変化には気が付きません。
HttpServletRequest.changeSessionIdメソッドの詳細は、Javaサーブレット3.1仕様およびJavadocを次のURLで参照してください。
1つのクラスタ内でCoherence*WebをWebLogic Serverとその他のアプリケーション・サーバーで実行している場合、WebLogic Serverで作成したセッションCookieは、他のサーバー上のCoherence*Webでは正しくデコードされません。これは、WebLogic Serverによって、Coherence*Webに格納されているセッションIDには含まれていないセッション・アフィニティ接尾辞が追加されるためです。Coherence*WebでセッションをCoherenceキャッシュから取得できるようにするには、他のアプリケーション・サーバーでは、WebLogicセッション・アフィニティ接尾辞をセッションCookie値から削除する必要があります。
WebLogicセッション・アフィニティ接尾辞をセッションCookie値から削除するには、他のアプリケーション・サーバーで使用されているweb.xmlファイルでcoherence-session-affinity-tokenコンテキスト・パラメータを追加します。例2-2に示すように、パラメータ値を感嘆符(!)に設定します。他のアプリケーション・サーバーによって処理される際、セッション・アフィニティ接尾辞がセッションCookieから削除されます。
例2-2 セッション・アフィニティ接尾辞の削除
... <context-param> <param-name>coherence-session-affinity-token</param-name> <param-value>!</param-value> </context-param> ...
coherence-session-affinity-tokenコンテキスト・パラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
