注意: 特に明記する場合を除き、この章ではOracle WebLogic Serverの11gリリース1のパッチ・セット3(10.3.4)以降について説明します。 |
この章では次の項について説明します。
Coherence*Webでは、セッション状態の持続および管理が実現されます。セッション・データの格納および管理にCoherenceキャッシュを使用するのは、セッション管理モジュールです。この章では、WebLogic Server上で実行しているアプリケーションから使用できるようにCoherence*Webを設定およびデプロイする方法について説明します。
Coherence*Webは、WebLogic Serverのメモリー内HTTP状態レプリケーション・サービスにかわるものです。次のいずれかの状況に該当する場合は、Coherence*Webの使用を検討してください。
アプリケーションで使用するHTTPセッション状態オブジェクトが大きい
HTTPセッション・オブジェクト・データの格納に起因するメモリー制約がある
HTTPセッション記憶域の負荷を既存のCoherenceクラスタに分散させる必要がある
複数のエンタープライズ・アプリケーションと複数のWebモジュールにおいてセッション状態を共有する必要がある
3.7.1における新規項目: session-cache-config.xml ファイルは、coherence-web-spi.war ファイルからcoherence-web.jar ファイルに移動しました。coherence-web.jar ファイルは、coherence\lib ディレクトリにあります。 |
Coherence*Webサービス・プロバイダ・インタフェース(SPI)は、coherence-web-spi.war
ファイルで構成されています。coherence-web-spi.war
で提供される機能を使用するには、Webアプリケーションに対してcoherence.jar
クラスを使用可能にする必要があります。
Coherence*Webでは、次のデフォルト・キャッシュ構成が定義されています。
WebLogic Server向けCoherence*Web SPIは、ローカル記憶域を無効にした状態で構成します。サーバーはリクエストの処理に使用され、データのホストには使用されません。これは、WebLogic Serverを実行しているJVMとは別に、Coherenceキャッシュ・サーバーを専用のJVMで実行する必要があることを意味します。
キャッシュ・サーバーがリクエストに応答するまでのタイムアウトは30秒です。キャッシュ・サーバーへのリクエストに対して30秒以内に応答が返らない場合は、com.tangosol.net.RequestTimeoutException
例外がスローされます。
Coherence*Web SPIで使用されるCoherenceキャッシュ構成とサービスは、session-cache-config.xml
ファイルで定義され、coherence-web.jar
ファイルにあります。session-cache-config.xml
ファイルで定義されているデフォルト・キャッシュ構成とサービス構成により、大半のWebアプリケーションを実現します。
Coherence*Webには、セッションの同時アクセスを制御するためのセッション・ロック・モードがいくつかあります。Coherence*WebとCoherence*Web SPIの両方に、最後の書込みを優先するロックがデフォルトで採用されています。ロック・モードの詳細は、「セッション・ロック・モード」を参照してください。
Coherence*Web SPIは、単独ではロード・バランサをWebLogic Server層の前で実行する必要はありません。ただし、ロード・バランサによりパフォーマンスが向上します。同じセッションが同時に使用されロックが有効でない場合に必要です。デフォルトのロード・バランサでは、HTTPセッションのJVMアフィニティを適用しますが、他のロード・バランシング方法も使用できます。WebLogic Serverには、JVMセッションの持続性を維持するための様々なプロキシ・プラグインが付属しています。WebLogic Serverプロキシ・プラグインの構成に関するドキュメントは次のURLから入手できます。
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13709/load_balancing.htm
Coherence*Webにはデプロイ可能な共有ライブラリが付属しています。そのライブラリには、WebLogic ServerのHTTPセッション管理インタフェースへのネイティブ・プラグインが含まれます。次の手順は、WebLogic Server上で実行しているアプリケーションでCoherence*Webを使用するためにデプロイメントを準備する方法を示しています。
Oracle Coherenceをファイル・システムにダウンロードします。「Oracle Coherenceのダウンロード」を参照してください。
アプリケーションがCoherence*Web用に高度な構成を必要とする場合は、WARデプロイメントのweb.xml
ファイルを変更します。Webアプリケーションに対して構成可能なパラメータについては、「Coherence*Webの構成」で説明します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
(オプション)WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xml
またはweblogic-application.xml
のファイルで構成します。「セッションCookieの構成」を参照してください。
(テストの場合はオプション、本番の場合は強く推奨)WebLogic Serverを実行しているJVMとは別のJVMでキャッシュ・サーバー層を起動します。「キャッシュ・サーバーの起動」を参照してください。
デプロイメント要件に基づいて適切なパッケージ化を決定し、そのパッケージ化手順に従います。WebLogic Serverのバージョンに応じて、「クラスタ・ノードの構成」を参照してください。
Coherence*Webで必要なすべてのファイルは、coherence-web-spi.war
ファイルを含めて、Coherenceディストリビューションに付属しています。
デフォルトでは、WebLogic Server 10.3.4とともにCoherence 3.6がインストールされますCoherenceディレクトリのデフォルトの場所は、C:\Oracle\Middleware\coherence_3.6
です。WebLogic Server 10.3.4を使用している場合、Coherence 3.7をファイル・システムにダウンロードしてから保存できます。coherence-web-spi.war
やcoherence.jar
など、Coherence 3.7ディストリビューションにあるライブラリ・ファイルをアプリケーションで必ず参照してください。
同様に、WebLogic Server 10.3.3で作業する場合、Coherenceがcoherence_3.5
ディレクトリにインストールされている場合があります。再び、Coherence 3.7をファイル・システムにダウンロードしてから保存できます。coherence-web-spi.war
やcoherence.jar
など、Coherence 3.7ディストリビューションにあるライブラリ・ファイルをアプリケーションで必ず参照してください。
WebLogic Server 10.3.2以前を使用している場合は、Coherenceディストリビューションをファイル・システムにダウンロードしてください。
必要なソフトウェア・パッチの適用
CoherenceとCoherence*Webで作業する前に、一部の旧リリースのWebLogic Serverではソフトウェア・パッチの適用が必要です。表2-1に、各種バージョンのWebLogic Serverとそれらの関連パッチを示します。
表2-1 WebLogic Serverの必要なソフトウェア・パッチ
WebLogic Server 9.2 MP1 | WebLogic Server 9.2 MP3 | WebLogic Server 10.3 | WebLogic Server 11g(10.3.1以上) | |
---|---|---|---|---|
WebLogic Smart Update |
パッチID: 616G |
パッチID: LP7B |
パッチID: 6W2W |
パッチは不要 |
Smart UpdateユーティリティをWebLogic Server管理コンソールで使用するか、My Oracle Supportにアクセスすると、パッチを入手できます。
Smart Updateを使用するには、WebLogic Server管理コンソールで指示を参照してください。本番環境では、Smart Updateの本番インストールに関する注意を確認してください。
My Oracle Supportを使用するには、My Oracle Support Webサイトに移動します。
「パッチ」タブを選択してから、「単純検索」リンクをクリックし、後続の画面で適切な値(「11399293」など)のパッチ番号か名前を検索します。表示された検索結果からパッチのzipファイルをダウンロードします。Coherenceパッチを適用する手順は、パッチのzipファイルに含まれるREADME.txt
に記載されています。
Coherence*Web SPIにより、大半のWebアプリケーションに対応するデフォルト構成を実現します。表2-2に、Coherence*Webコンテキスト・パラメータの中でSPIバージョン用のデフォルトがSPI以外のバージョンとは異なるもののみを示します。表2-3は、SPIで渡された互換モード・コンテキスト・パラメータを示しています。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
コンテキスト・パラメータは、システム・プロパティとしてコマンドラインで構成することもできます。システム・プロパティは、コンテキスト・パラメータと同じ名前を持ちますが、ダッシュ(-
)がピリオド(.
)に置き換えられています。たとえば、coherence-enable-sessioncontext
コンテキスト・パラメータの値をコマンドラインで宣言するには、次のように入力します。
-Dcoherence.enable.sessioncontext=true
システム・プロパティと、同等のコンテキスト・パラメータの両方が構成されている場合、システム・プロパティの値が使用されます。
表2-2 SPIによって構成されるCoherence*Webコンテキスト・パラメータ
パラメータ名 | 説明 |
---|---|
|
Coherence*Webではこのパラメータの値を使用して、 アプリケーション名 + ! + Webモジュール名 application nameは たとえば、 このパラメータが構成されていない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。また、このパラメータが構成されておらず、 |
この設定により、セッション・リーパーでは、(たとえば、分散キャッシュ・サービスによって)このノードに保存されるセッションは、このノードで期限切れのチェックが必要なセッションのみであると仮定できます。 デフォルトは、 |
|
この値は、オプションの 有効な値は次のとおりです。
Coherence*Web SPIで設定するデフォルトは |
表2-3は、Coherence*Web SPIで具体的に渡されたcoherence-session-weblogic-compatibility-mode
コンテキスト・パラメータを示しています。
表2-3 Coherence*Web SPIによって渡されるコンテキスト・パラメータ
パラメータ名 | 説明 |
---|---|
このパラメータは、Coherence*WebのSPIバージョンによって渡されます。この値を グローバル・スコープ・コントローラが指定されていないかぎり、このパラメータではデフォルトで |
表2-4は、coherence-factory-class
コンテキスト・パラメータを示しています。デフォルト値はCoherence*Web SPIで設定されますが、変更しないでください。
Coherence*Web SPIを使用すると、WebLogic ServerによってセッションCookieが生成および解析されます。この場合、ネイティブCoherence*WebセッションCookie構成パラメータはすべて無視されます。セッションCookieを構成するには、WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xml
またはweblogic-application.xml
のファイルで使用します。これらのパラメータについては、表2-5を参照してください。
この表で「更新可能?」は、サーバー実行中にパラメータ値が変更可能かどうかを示します。「該当なし」は、対応するCoherenceセッションCookieパラメータがないことを示します。
表2-5 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キャッシュ・サーバー(データ・ノードとも呼ぶ)は、キャッシュされるデータすべての格納と管理を担います。これは、専用のJVMであっても、WebLogic Serverインスタンス内で実行されてもかまいません。Coherenceデータ・クラスタ内の上位ノード(最初のノード)は起動に数秒間かかることがあります。下位のノードで必要な起動時間はわずかです。
最初にキャッシュ・サーバーを起動するのか、WebLogic Serverインスタンスを起動するのかは、採用しているサーバー・トポロジによります。
インプロセス・トポロジ(すべて記憶域を有効化したWebLogic Serverインスタンス)を使用している場合、最初にキャッシュ・サーバーを起動しても、WebLogic Serverインスタンスを起動してもかまいません。
アウトオブプロセス・トポロジ(記憶域を無効化したWebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバー)を使用している場合は、最初にキャッシュ・サーバーを起動し、次にWebLogic Serverインスタンスを起動します。これにより、Coherenceを使用するアプリケーションの起動時間が最短(ミリ秒単位)になります。Coherenceを使用する追加Webアプリケーションはどれも上位データ・メンバーにならず、そのため、それらがWebLogic Serverの起動に与える影響は最小限になります。
このトポロジでキャッシュ・サーバーを最初に起動しないと、Coherenceでは次のようなエラー・メッセージにより応答します。
No storage-enabled nodes exist for service ...
スタンドアロン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 -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.cacheconfig=cache_configuration_file
-Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer
クラスパスのcoherence-web.jar
とcoherence.jar
を含める必要があります。cache_configuration_file
は、ファイル・システムにおけるキャッシュ構成ファイルへの絶対パスを示します。Coherence*Webの場合、これはsession-cache-config.xml
ファイルになります。キャッシュ・サーバーに対して定義されているキャッシュ構成は、同じCoherenceクラスタで実行されているアプリケーション・サーバーに対して定義されているキャッシュ構成と一致する必要があります。
さらに別なCoherenceキャッシュがCoherence*Webで実行している場合、session-cache-config.xml
ファイルに格納されているセッション構成とキャッシュ構成情報(一般的にcoherence-cache-config.xml
ファイルで定義)をマージする必要があります。キャッシュ構成とセッション構成は、WebLogic ServerとCoherenceキャッシュ・サーバーとの間で一貫している必要があります。
これらのファイルをマージする方法の詳細は、『Oracle Coherence統合ガイド』でCoherenceキャッシュとセッション情報のマージに関する項を参照してください。
前述の手順で説明したスクリプトを使用して、Coherenceデータ・ノードを1つ以上起動します。
デフォルトでは、Coherence*Webを使用可能なWebLogic Serverインスタンスは、記憶域を無効化した状態で起動します。記憶域を有効化した状態でWebLogic Serverインスタンスを起動する手順は次のとおりです。
Coherenceデータ・ノードを起動するためのスクリプトを作成します。これは、前項で説明されているスクリプトと同様にできます。
-Dtangosol.coherence.session.localstorage=true
のコマンドライン・プロパティをサーバー起動コマンドに含め、ローカル記憶域を有効にします
コマンドラインからのWebLogic Serverの操作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。
Coherence*Webで行うセッション管理は、アプリケーション・サーバー・スコープ、EARスコープまたはWARスコープを設定できます。Coherenceクラスタと同様、Coherence*Webのスコープ設定は、クラスローダーの階層におけるcoherence.jar
ファイルの位置により異なります。各スコープの詳細は、「クラスタ・ノード分離」を参照してください。
WebLogic Serverリリース10.3.3以降では、ActiveCacheと呼ばれる機能が用意されています。これによって、アプリケーションとCoherenceキャッシュとの間の対話が容易にできます。これらの機能の詳細は、ActiveCacheの使用方法ガイドを参照してください。
一部の旧リリースのWebLogic Server(リリース10.3.1以前など)では、CoherenceとCoherence*Webを使用するには、ソフトウェア・パッチが必要です。ご使用のリリースのWebLogic Serverでパッチが必要かどうかを調べるには、「必要なソフトウェア・パッチの適用」を参照してください。
次の各項では、Coherence*Webを実行するための様々なクラスタ・ノードの構成方法を説明します。
注意: アプリケーション・サーバー・スコープ設定クラスタ構成の使用は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では使用しないでください。このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・チームでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。 このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択すればよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください。 |
セッション管理のためにCoherenceクラスタにCoherence*Webを追加する場合は、次の手順に従ってください。
coherence.jar
ファイルを含めるようにWebLogic Serverのシステム・クラスパスを編集するか、JARファイルを$DOMAIN_HOME/lib
ディレクトリにコピーします。
WebLogic Server管理コンソールまたはコマンドラインを使用して、coherence-web-spi.war
ファイルを共有ライブラリとしてデプロイします。
WebアプリケーションでCoherence*Webを有効にします。
Coherence*Webを使用する予定のWebLogic Serverにデプロイした各WARファイルのweblogic.xml
に、例2-1に示すライブラリ参照コードを追加します。
EARスコープ設定クラスタ・ノードでセッション管理のためにCoherence*Webを使用する際、アプリケーションをWebLogic Server 10.3.2以前で実行する場合、次の手順に従ってください。
WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence.jar
ファイルおよびcoherence-web-spi.war
ファイルを共有ライブラリとしてデプロイします。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。
coherence.jarをWebLogic Server管理コンソールでデプロイする際にエラーが発生した場合、WLSTコマンドを使用できます。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
weblogic-application.xml
ファイルでcoherence.jar
ファイルを参照します。このファイルをEARのMETA-INF
ディレクトリに格納します。
例2-2は、weblogic-application.xml
ファイルを示しています。
weblogic.xml
ファイルでcoherence-web-spi.war
ファイルを参照します。
例2-3は、weblogic.xml
ファイルを示しています。
セッション管理のためにWARスコープ設定クラスタ・ノードでCoherence*Webを使用する場合は、次の手順に従ってください。
WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence-web-spi.war
ファイルを共有ライブラリとしてデプロイします。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。
coherence.jar
ファイルをアプリケーションに追加します。次のいずれかの方法でこれをできます。
Coherenceを使用する各モジュールのmanifest.mf
ファイルでオプション・パッケージとしてcoherence.jar
ファイルをインポートします。例2-4は、manifest.mf
ファイルを示しています。
coherence.jar
ファイルをWARファイルのWEB-INF/lib
ディレクトリにコピーします。
coherence-web-spi.war
ファイルを共有ライブラリとしてデプロイする場合、例2-5に示す行をWARファイルのWEB-INF
ディレクトリにあるweblogic.xml
ファイルに追加することによって、共有ライブラリ参照を作成することも必要です。
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セキュリティ・レイヤーでドメイン間の信頼関係を有効にすると、複数のドメインにわたって機能するようになります。
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-6に示すように、パラメータ値を感嘆符(!
)に設定します。他のアプリケーション・サーバーによって処理される際、セッション・アフィニティ接尾辞がセッションCookieから削除されます。
表2-6 セッション・アフィニティ接尾辞の削除
... <context-param> <param-name>coherence-session-affinity-token</param-name> <param-value>!</param-value> </context-param> ...
coherence-session-affinity-token
コンテキスト・パラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。