Oracle® Fusion Middleware

Oracle Coherence*WebでのHTTPセッション・マネージメントの管理

12c (12.1.2)

B70746-02(原本部品番号:E26051-02)

2013年11月

WebLogic ServerやGlassFish Serverなどの各種アプリケーション・サーバー上で、クラスタ環境内でセッション状態を管理するためのHTTPセッション管理モジュールであるCoherence*Webの構成、デプロイメントおよび使用方法について説明する、開発者および管理者向けのドキュメント。

Oracle Fusion Middleware Oracle Coherence*WebでのHTTPセッション・マネージメントの管理, 12c (12.1.2)

B70746-02

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

原本著者:  Tom Pfaeffle

原本協力著者:  Torkel Dominique、James Kirsch、Pyounguk Cho

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.1.2)の新機能と変更された機能

- 12c (12.1.2)に関するこのドキュメントにおけるその他の大きな変更

1 Coherence*Webの概要

- 1.1 Coherence*Webの理解

- 1.2 サポートされているWebコンテナ

- 1.3 インストールとデプロイメントの指針

- 1.3.1 クラスタ・ノード分離の選択

- 1.3.2 ロック・モードの選択

- 1.3.3 セッションとセッション属性のスコープ設定方法の選択

- 1.3.4 期限切れHTTPセッションをいつクリーンアップするかの選択

- 1.3.5 インストール方法の選択

2 WebLogic ServerでのCoherence*Webの使用方法

- 2.1 Coherence*Webの概要

- 2.2 Coherence Containerの概要

- 2.3 Coherence*Webの構成とデプロイ: 主な手順

- 2.3.1 WebLogic ServerとOracle Coherenceのインストール

- 2.3.2 Coherence*Webの構成

- 2.3.3 セッションCookieの構成

- 2.3.4 キャッシュ・サーバーの起動

- 2.3.4.1 WebLogic Server管理コンソールからのCoherenceキャッシュ・サーバーの起動

- 2.3.4.2 コマンドラインからのCoherenceキャッシュ・サーバーの起動

- 2.3.5 Coherence*Webの記憶域モードの構成

- 2.3.6 WebLogic Serverへのアプリケーションのデプロイ

- 2.4 Coherence*Web用のCoherence MBean属性

- 2.4.1 WebLogic Server管理コンソールでのCoherenceセッション・キャッシュの有効化

- 2.5 カスタム・セッション・キャッシュ構成ファイルの使用方法

- 2.6 セッションCookieパスのスコープ設定

- 2.7 セッションIDの更新

- 2.8 その他のアプリケーション・サーバーとのCoherence*Webセッションの共有

- 2.9 WebLogic ServerとCoherence: 互換性

3 GlassFish ServerでのCoherence*Webの使用方法

- 3.1 GlassFish Serverの概要

- 3.2 ActiveCache for GlassFishの概要

- 3.3 GlassFish ServerでのCoherence*Webの構成とデプロイ: 主な手順

- 3.3.1 Oracle Coherenceのダウンロード

- 3.3.2 セッション持続タイプの設定

- 3.3.3 デフォルトのCoherence*Webキャッシュ構成またはクラスタ構成のオーバーライド

- 3.3.4 ActiveCache for GlassFishとセッション・キャッシュ・ファイルをアプリケーションにコピーする方法

- 3.3.5 Webアプリケーションを配布可能にする方法

- 3.3.6 Coherence*Webの構成

- 3.3.7 キャッシュ・サーバーの起動

- 3.3.8 クラスタ・ノードの構成

- 3.3.8.1 EARスコープ設定クラスタ・ノードの構成

- 3.3.8.2 WARスコープ設定クラスタ・ノードの構成

4 他のアプリケーション・サーバーにおけるCoherence*Webの使用方法

- 4.1 WebInstallerによるCoherence*Webのインストール

- 4.1.1 アプリケーション・サーバー固有のインストール手順

- 4.1.1.1 Oracle WebLogic Server 10.nへのインストール

- 4.1.1.2 Caucho Resin 3.1.nへのインストール

- 4.1.2 Coherence*Webセッション管理モジュールをインストールする一般的な手順

- 4.1.2.1 インプロセスのアプリケーションのデプロイと実行

- 4.1.2.2 アウトオブプロセスのアプリケーションのデプロイと実行

- 4.1.2.3 アウトオブプロセス・トポロジへの移行

- 4.1.2.4 Coherence*Extendによるアウトオブプロセスのアプリケーションのデプロイと実行

- 4.1.3 Apache Tomcatサーバーに対するスティッキー・セッションの有効化

- 4.1.4 IBM WebSphere 7.nサーバーに対するURLセッションIDのデコード

- 4.2 Coherence*Web WebInstaller Antタスク

- 4.2.1 Coherence*Web WebInstaller Antタスクの使用方法

- 4.2.2 WebInstaller Antタスクの構成

- 4.2.3 WebInstaller Antタスクの例

- 4.3 HTTPセッション管理のテスト

- 4.4 Coherence*Web WebInstallerによるJava EEアプリケーションの設定

- 4.5 Java EEセキュリティを使用しているアプリケーションへのCoherence*Webのインストール

- 4.6 クロスサイト・スクリプティング攻撃の防止

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

- 5.1 セッション・モデル

- 5.1.1 モノリシック・モデル

- 5.1.2 トラディショナル・モデル

- 5.1.3 スプリット・モデル

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

- 5.1.5 セッション・モデルの構成

- 5.1.6 クラスタ環境でのデータの共有

- 5.1.7 スケーラビリティとパフォーマンス

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

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

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

- 5.2.1.2 複数のキャッシュ構成の操作

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

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

- 5.2.2.1 複数のアプリケーション間におけるセッション情報の共有

- 5.3 クラスタ・ノード分離

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

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

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

- 5.4 セッション・ロック・モード

- 5.4.1 オプティミスティック・ロック

- 5.4.2 最後の書込みを優先するロック

- 5.4.3 メンバー・ロック

- 5.4.4 アプリケーション・ロック

- 5.4.5 スレッド・ロック

- 5.4.6 HTTPセッションでのロックのトラブルシューティング

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

- 5.5 デプロイメント・トポロジ

- 5.5.1 インプロセス・トポロジ

- 5.5.2 アウトオブプロセス・トポロジ

- 5.5.2.1 インプロセス・トポロジからアウトオブプロセス・トポロジへの移行

- 5.5.3 Coherence*Extendによるアウトオブプロセス・トポロジ

- 5.5.4 Coherence*ExtendによるCoherence*Webの構成

- 5.5.4.1 プロキシJVMと記憶域JVMのキャッシュの構成

- 5.5.4.2 Web層JVMのキャッシュの構成

- 5.6 遅延取得によるセッションへのアクセス

- 5.7 HTTPセッションと属性のディストリビューションのオーバーライド

- 5.7.1 セッション・ディストリビューション・コントローラの実装

- 5.7.2 セッション・ディストリビューション・コントローラの実装の登録

- 5.8 変更された属性値の検出

- 5.9 シリアライズ不可能な属性のローカルな保存

- 5.10 Coherence*Webデプロイメントの保護

- 5.11 セッション・キャッシュ構成ファイル名のカスタマイズ

- 5.12 Coherence*Webのロギングの構成

- 5.13 同一のセッション・インスタンスへの同時アクセス

6 アプリケーションの監視

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

- 6.1.1 WebLogic Serverでのアプリケーションの管理および監視

- 6.2 パフォーマンス・レポートの実行

- 6.2.1 Webセッション記憶域レポート

- 6.2.2 Webセッション・オーバーフロー・レポート

- 6.2.3 Webレポート

- 6.2.4 Webサービス・レポート

7 期限切れHTTPセッションのクリーンアップ

- 7.1 セッション・リーパーの理解

- 7.2 セッション・リーパーの構成

- 7.3 セッション・リーパー・パフォーマンス統計の取得

- 7.4 セッション・リーパーのセッション無効化の例外の理解

8 ColdFusionアプリケーションの操作

- 8.1 ColdFusionアプリケーションのためのCoherence*Web SPIの構成

- 8.2 ColdFusionアプリケーションのためのCoherence*Web(非SPI)の構成

9 JSFおよびMyFacesアプリケーションの操作

- 9.1 すべてのJSFおよびMyFaces Webアプリケーションに対する構成

- 9.2 MyFacesを使用する設定済アプリケーションに対する構成

- 9.3 Mojarraを使用する設定済アプリケーションに対する構成

- 9.4 MyFacesおよびCoherence SPIを使用する非設定済アプリケーションに対する構成

- 9.5 MojarraおよびCoherence SPIを使用する非設定済アプリケーションに対する構成

10 WebLogic PortalでのCoherence*Webの使用方法

- 10.1 必要なパッチのダウンロード(オプション)

- 10.2 WebLogic PortalでのCoherence*Webの使用方法: 主な手順

- 10.2.1 キャッシュ・サーバーの起動

- 10.2.2 セッション構成の変更(オプション)

- 10.2.3 P13N(パーソナライゼーション)キャッシュ・プロバイダの有効化(オプション)

- 10.2.4 Coherence JARファイルの配置

- 10.2.5 ポータル・アプリケーションでのSPIの参照

- 10.2.6 Coherence*Webセッションの有効化

- 10.2.7 アプリケーションの作成およびデプロイ

- 10.3 WebLogic PortalでのCoherenceキャッシュ・プロバイダの使用方法

- 10.3.1 アウトオブプロセス・トポロジのCoherenceキャッシュ・プロバイダのデプロイ

A Coherence*Webコンテキスト・パラメータ

B キャパシティ・プランニング

C セッション・キャッシュ構成ファイル

D ニア・キャッシュのないセッション・キャッシュ構成ファイル

E OVAB用Oracle Coherence*Web拡張機能

- E.1 サポートされるバージョン

- E.2 Oracle Coherence*Webのイントロスペクション・パラメータ

- E.3 参照システムの前提条件

- E.4 要件

- E.4.1 デプロイメント・モデルの要件

- E.4.2 カスタム・クラスタ構成ファイルを手動更新するための要件

- E.5 結果のアーティファクト・タイプ

- E.6 接続

- E.7 接続プロパティ

- E.8 Oracle Coherence*Webアプライアンスのプロパティ

- E.9 サポートされるテンプレート・タイプ

F WebLogic PortalおよびOracle Coherenceのためのキャッシュ構成

例一覧

- 2-1 weblogic.xmlのCoherence Webの記憶域モード

- 2-2 セッション・アフィニティ接尾辞の削除

- 3-1 Coherence*Web用のglassfish-web.xmlファイルの構成

- 3-2 glassfish-web.xmlファイルにおける持続タイプの設定

- 4-1 Coherence*Web WebInstaller用のタスク・インポート文

- 5-1 セッション・モデルの構成

- 5-2 アプリケーション間でセッション・データを共有しないようにするための構成

- 5-3 web.xmlで指定されたGlobalScopeController

- 5-4 default-session-cache-config-server.xmlファイル

- 5-5 default-session-cache-config-web-tier.xmlファイル

- 5-6 セッション・ディストリビューション・コントローラの実装例

- 5-7 web.xmlファイルのキャッシュ・デリゲータの構成

- 6-1 コマンドラインにおけるレポート・グループの指定

- 9-1 web.xmlファイルのSTATE_SAVING_METHODの設定

- 9-2 web.xmlファイルのDELEGATE_FACES_SERVLETの設定

- 9-3 web.xmlファイルにおけるFaces Servletの宣言

- C-1 default-session-cache-config.xmlファイルの内容

- D-1 ニア・キャッシュ構成のないsession-cache-config.xmlファイル

- F-1 WebLogic Portal管理対象サーバーのキャッシュ構成

図一覧

- 2-1 「Coherence Webローカル記憶域有効」チェック・ボックス

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

- 5-2 モノリシック・セッション・モデル

- 5-3 トラディショナル・セッション・モデル

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

- 5-5 セッション・サイズに応じたパフォーマンス

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

- 5-7 EARスコープ設定クラスタ

- 5-8 WARスコープ設定クラスタ

- 5-9 インプロセス・デプロイメント・トポロジ

- 5-10 アウトオブプロセス・デプロイメント・トポロジ

- 5-11 Coherence*Extendによるアウトオブプロセス・デプロイメント・トポロジ

- 6-1 JConsole監視ツールに表示されたHttpSessionManager

- 10-1 Oracle Smart Updateにログインするためのダイアログ・ボックス

- 10-2 Oracle Smart Updateのブラウザ

- 10-3 WebLogic Portalのアウトオブプロセス・デプロイメント・トポロジ

表一覧

- 1-1 Coherence*Webを使用できるWebコンテナ

- 2-1 以前のバージョンのWebLogic Serverに必要なソフトウェア・パッチ

- 2-2 Coherence*Webによって構成されるコンテキスト・パラメータ

- 2-3 Coherence*Webによって渡されるコンテキスト・パラメータ

- 2-4 変更してはいけないコンテキスト・パラメータ値

- 2-5 WebLogicによって生成されるHTTPセッションのCookieパラメータ

- 2-6 Coherence*Web用のCoherence MBean属性

- 2-7 スタンドアロンのWebLogic Serverの各バージョンとCoherenceとの互換性

- 2-8 JRFとともに配布されるWebLogic Serverの各バージョンとCoherenceとの互換性

- 3-1 ActiveCache for GlassFishに用意されているデフォルトのコンテキスト・パラメータ値

- 3-2 GlassFish Serverで有効ではないCoherence*Webコンテキスト・パラメータ

- 3-3 glassfish-web.xmlの有効なGlassFishセッション構成パラメータ

- 3-4 glassfish.web.xmlのCoherence*Webで有効ではないGlassFishコンテキスト・パラメータ

- 4-1 Coherence*Webのコンテキスト・パラメータ設定の例

- 4-2 Coherence*Web WebInstaller Antタスクの属性

- 4-3 ロード・バランサのコマンドライン・オプション

- 5-1 coherence-session-locking-modeコンテキスト・パラメータ値の一覧

- 5-2 プロキシJVM用のシステム・プロパティ値

- 5-3 記憶域JVM用のシステム・プロパティ値

- 6-1 HttpSessionManagerMBeanのオブジェクト名

- 6-2 HttpSessionManagerから返される情報

- 6-3 WebLogicHttpSessionManagerMBeanのオブジェクト名

- 6-4 WebLogicHttpSessionManager MBeanから返される情報

- 6-5 Webセッション記憶域レポートの内容

- 6-6 Webセッション・オーバーフロー・レポートの内容

- 6-7 Webレポートの内容

- 6-8 Webサービス・レポートの内容

- 10-1 WebLogic Serverと必要なCoherenceパッチ・リリース・レベル

- A-1 Coherence*Webのコンテキスト・パラメータ

- C-1 default-session-cache-config.xmlで使用するキャッシュ関連の値

- C-2 default-session-cache-config.xmlで使用するサービス関連の値

- E-1 Oracle Coherence*Webアプライアンスのシステム・プロパティ

- E-2 Oracle Coherence*Webアプライアンスのユーザー・プロパティ

はじめに

このガイドでは、HTTPセッション管理モジュールであるOracle Coherence*Web (Coherence*Web)をGlassFish Server、WebLogic Serverおよび他のアプリケーション・サーバーにデプロイする方法について説明します。また、構成可能な様々なセッション管理機能についても説明します。

このガイドでは、Coherence*WebとWebLogic Portalを統合して、Oracle Coherenceキャッシュに基づくセッション状態管理を実現する方法についても説明します。

対象読者

このガイドは、クラスタ環境でセッション状態の管理を目指すアプリケーション開発者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

オラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、 http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info または http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、次のOracle Coherenceドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』

- 『Oracle Fusion Middleware Oracle Coherenceリモート・クライアントの開発』

- 『Oracle Fusion Middleware Oracle Coherenceチュートリアル』

- 『Oracle Fusion Middleware Oracle Coherenceの統合』

- 『Oracle Fusion Middleware Oracle Coherenceのマネージメント』

- 『Oracle Fusion Middleware Oracle Coherenceの管理』

- 『Oracle Fusion Middleware Oracle Coherenceの保護』

- Oracle Fusion Middleware Oracle Coherence Java APIリファレンス

- Oracle Fusion Middleware Oracle Coherence .NET APIリファレンス

- Oracle Fusion Middleware Oracle Coherence C++ APIリファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次の各トピックでは、Oracle Coherenceの新機能と変更された機能およびこのガイドに記載される他の重要な変更について紹介し、追加情報へのリンクを示します。このドキュメントは、旧名『Oracle Coherence*Webユーザーズ・ガイド』の新版です。

12c (12.1.2)の新機能と変更された機能

Oracle Coherence 12c (12.1.2)には、このドキュメントにおける次の新機能と変更された機能が装備されています。

- CoherenceコンテナをWebLogic Serverで実行しているアプリケーションで使用できます。CoherenceコンテナはCoherenceアプリケーションに、WebLogic Server上でホストされている他のJava EEアプリケーションと同様の利点を提供します。詳細は、第2章「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。『Oracle Fusion Middleware Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』も参照してください。

- coherence-web.jarおよびcoherence.jarファイルは、WebLogic Serverシステム・クラスパスに表示されるようになりました。つまり、coherence.jarまたはcoherence-web.jarファイルをWebアプリケーションのクラスパスに含める必要はありません。詳細は、「Coherence*Webの概要」を参照してください。

- Coherence*Webで使用されるCoherenceキャッシュ構成とサービスは、現在はdefault-session-cache-config.xmlファイルで定義され、このファイルはcoherence-web.jarファイル内にあります。session-cache-config.xmlという名前のファイルをWebアプリケーションにパッケージ化することにより、自分専用のカスタム・セッション・キャッシュ構成を作成できます。詳細は、「カスタム・セッション・キャッシュ構成ファイルの使用方法」を参照してください。

12c (12.1.2)に関するこのドキュメントにおけるその他の大きな変更

このガイドは、12c (12.1.2)でいくつかの点が更新されました。次の表に、追加または変更された項を示します。

- サポートされているWebコンテナのリストに、Apache Tomcat 7.xを追加しました。「サポートされているWebコンテナ」を参照してください。

- セッションIDがCoherence *Webで更新される方法に関する情報を追加しました。「セッションIDの更新」を参照してください。

- WebLogicセッション・アフィニティ接尾辞をセッションCookieから削除してCoherence*Webセッションを他のアプリケーション・サーバーと共有できるようにする方法に関する情報を追加しました。「その他のアプリケーション・サーバーとのCoherence*Webセッションの共有」を参照してください。

- スタンドアロンのWebLogic Serverの各バージョンとCoherenceとの互換性を示す表を追加しました。「WebLogic ServerとCoherence: 互換性」を参照してください。

- セッション・キャッシュ構成ファイルのデフォルト名の変更方法に関する情報を追加しました。「セッション・キャッシュ構成ファイル名のカスタマイズ」を参照してください。

- Coherence*Webを使用したロギングの使用方法に関する情報を追加しました。「Coherence*Webのロギングの構成」を参照してください。

- キャッシュ・デリゲータを使用して、セッション・インスタンスの保存および取得に分散キャッシュが使用される前にローカル・キャッシュが使用されるようにする方法、に情報を追加しました。「同一のセッション・インスタンスへの同時アクセス」を参照してください。

- Coherence*WebをOracle Portalで使用するための手順を修正しました。第10章「WebLogic PortalでのCoherence*Webの使用方法」を参照してください。

- Oracle Virtual Assembly Builder (OVAB)用のCoherence*Web拡張機能の使用方法に関する情報を追加しました。付録E「OVAB用Oracle Coherence*Web拡張機能」を参照してください。

1 Coherence*Webの概要

この章では、クラスタ環境でのセッション状態の管理にCoherence*Webを使用することの利点について説明します。ここでは、Coherence*Webを使用できるコンテナを列挙し、インストールおよびデプロイメント・ロードマップを示します。インストール、デプロイメントおよび機能の詳細は、これ以降の章を参照してください。

この章には次の項が含まれます:

- Coherence*Webの理解

- サポートされているWebコンテナ

- インストールとデプロイメントの指針

1.1 Coherence*Webの理解

Coherence*Webは、クラスタ環境におけるセッション状態の管理に特化したHTTPセッション管理モジュールです。Coherence*WebはOracle Coherence (Coherence)を基本として構築されており、その特徴は次のとおりです。

- Coherenceデータ・グリッドのデータのスケーラビリティ、可用性、信頼性およびパフォーマンスをメモリー内のセッション管理と記憶域にもたらします。

- プラガブル・ポリシーにより、セッションとセッション属性のスコープをきめ細かく構成できます(「セッションとセッション属性のスコープ設定」を参照)。

- Oracle GlassFish Server、Oracle WebLogic Server、IBM WebSphere、Tomcatなど、広く使用されているアプリケーション・サーバーにデプロイできます(「サポートされているWebコンテナ」を参照)。

- Oracle WebLogic Portal(第10章「WebLogic PortalでのCoherence*Webの使用方法」を参照)などの多数のポータル・コンテナにデプロイできます。

- セッション・データをJava EEアプリケーション・サーバー外部で保存可能にすることによって、アプリケーション・サーバーのヒープ領域を解放し、セッション・データを失わずにサーバーを再起動できるようにします(「デプロイメント・トポロジ」を参照)。

- 様々なWebアプリケーション、ドメインおよび異機種アプリケーション・サーバーにわたってセッションの共有と管理を可能にします(「セッションとセッション属性のスコープ設定」を参照)。

- クラスタでセッション状態をシリアライズとデシリアライズする方法を定義する高度なセッション・モデル(モノリシック、トラディショナルおよびスプリット)で使用できます(「セッション・モデル」を参照)。

1.2 サポートされているWebコンテナ

Oracle WebLogic Server 9.2.1、9.2.3、10.3.1およびそれ以降においてCoherence*Webセッション管理モジュールをインストールする場合は、Coherence*Webサービス・プロバイダ・インタフェース(SPI)ベースのインストール方法を使用できます。管理モジュールをWebLogic Server 10.3.4にインストールする手順については、『Oracle Coherence*Web用Oracle Coherenceユーザーズ・ガイド』を参照してください。

WebLogic Server 12c (12.1.2)では、Coherence*Webが製品に統合されています。インストールの必要はありません。詳細は、第2章「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。

サード・パーティ製アプリケーション・サーバーおよびいくつかのレガシー・バージョンのOracle WebLogic Server (9.2.1、9.2.3、10.3、10.3.1)の場合、Coherence*Webでは汎用インストーラ(WebInstaller)が用意されています。これによりWebアプリケーションが透過的に設定されます。第4章「他のアプリケーション・サーバーにおけるCoherence*Webの使用方法」で、WebInstallerを使用してこれらのサーバーにCoherence*Webをインストールする方法について説明します。

表1-1は、Coherence*Webセッション管理モジュールでサポートされているWebコンテナを示しています。また、Coherence*Webをインストールする際に必要な情報へのリンクも示しています。Oracle WebLogic Server 10.3.4を除くすべてのWebコンテナには、一般的なインストール手順が共通に適用されます。Webコンテナの中には、この一般的なインストール手順を開始する前に、そのコンテナ固有の追加手順を実行しなければならないものがわずかにあります。Caucho Resin、WebLogic 10.nなどがこのようなコンテナに該当します。

注意:

サーバー・タイプの別名の列に示す値は、Coherence*Web WebInstallerによるインストールでのみ使用します。この値は、-serverコマンドライン・オプションを使用してWebInstallerに渡します。

表1-1 Coherence*Webを使用できるWebコンテナ

アプリケーション・サーバー

サーバー・タイプの別名

インストール手順の参照先

Apache Tomcat 5.5.n

Tomcat/5.5.x

「Coherence*Webセッション管理モジュールをインストールする一般的な手順」および「Apache Tomcatサーバーに対するスティッキー・セッションの有効化」

Apache Tomcat 6.0.n

Tomcat/6.0.x

「Coherence*Webセッション管理モジュールをインストールする一般的な手順」および「Apache Tomcatサーバーに対するスティッキー・セッションの有効化」

Apache Tomcat 7.n

Tomcat/7.x

「Coherence*Webセッション管理モジュールをインストールする一般的な手順」および「Apache Tomcatサーバーに対するスティッキー・セッションの有効化」

この機能は、パッチ・リリースの一部として追加されました。パッチに追加された機能の詳細は、『Oracle Coherenceリリース・ノート』を参照してください。

Caucho Resin 3.1.n

Resin/3.1.x

Caucho Resin 3.1.nへのインストール

IBM WebSphere 5.n

WebSphere/5.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

IBM WebSphere 6.n

WebSphere/6.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

IBM WebSphere 7.n

WebSphere/7.x

「Coherence*Webセッション管理モジュールをインストールする一般的な手順」および「IBM WebSphere 7.nサーバーに対するURLセッションIDのデコード」

IBM WebSphere 8.n

WebSphere/8.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

IBM WebSphere 8.5

WebSphere/8.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

JBoss Application Server

GenericまたはJetty/5.1.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

Jetty 5.1.n

Jetty/5.1.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

Jetty 6.1.n

Generic

Coherence*Webセッション管理モジュールをインストールする一般的な手順

Oracle GlassFish 3.n

なし

第3章「GlassFish ServerでのCoherence*Webの使用方法」

Oracle OC4J 10.1.2.n

Oracle/10.1.2.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

Oracle OC4J 10.1.3.n

Oracle/10.1.3.x

Coherence*Webセッション管理モジュールをインストールする一般的な手順

Oracle WebLogic 9.2 MP1とMP3
Oracle WebLogic 10.3

WebLogic/9.x

WebLogic/10.x

WebInstallerとSPIベースのインストールの詳細は、第2章「WebLogic ServerでのCoherence*Webの使用方法」と第4章「他のアプリケーション・サーバーにおけるCoherence*Webの使用方法」を参照してください。

Oracle WebLogic 10.n

WebLogic/10.x

WebInstallerインストールの詳細は、「Oracle WebLogic Server 10.nへのインストール」を参照してください。

Sun Application Server 8.n

Generic

Coherence*Webセッション管理モジュールをインストールする一般的な手順

Sun GlassFish 2.n

Generic

Coherence*Webセッション管理モジュールをインストールする一般的な手順

1.3 インストールとデプロイメントの指針

Coherence*Webを構成してデプロイする前にデプロイメント決定を行う必要があります。Coherence*Webは、様々なアプリケーション・サーバー上でサポートされています。使用するアプリケーション・サーバーに関係なく、パッケージ化での考慮事項、セッション・モデル、セッション・ロック・モード、デプロイメント・トポロジなどの特定の要件を満たすためにCoherence*Webの構成オプションの変更が必要になることがあります。

1.3.1 クラスタ・ノード分離の選択

クラスタ・ノード分離とは、各アプリケーション・サーバーJVM内に作成されるCoherenceノードのスコープを意味します。いくつかの分離モードがサポートされています。

たとえば、同じ1つのクラスタ(または1つのCoherenceノード)を使用する必要があるコンテナに複数のアプリケーションをデプロイするモード、単一のクラスタを使用する単一のEARファイルにパッケージ化した複数のWebアプリケーションを使用するモード、独立したセッション・データを保持したままで専用のCoherenceクラスタにデプロイする必要のあるWebアプリケーションを使用するモードなどが考えられます。これらの選択肢、およびデプロイメントで構成が必要なディスクリプタと要素については、「クラスタ・ノード分離」で説明します。

1.3.2 ロック・モードの選択

ロック・モードとは、複数のWebコンテナ・スレッドから同時にアクセスが発生したときのHTTPセッションの動作を指します。Coherence*Webには、様々なセッション・ロック・オプションが用意されています。たとえば、クラスタ内の複数のノードから1つのHTTPセッションに同時にアクセスすることや、1つのHTTPセッションに同時にアクセスできるスレッドの数を1つにのみ制限することが可能です。また、同じWebアプリケーション・インスタンスへの複数のスレッドからのアクセスを許可する一方で、異なるWebアプリケーション・インスタンスにあるスレッドからの同時アクセスを禁止することもできます。これらの選択肢、およびデプロイメントで構成が必要なディスクリプタと要素については、「セッション・ロック・モード」で説明します。

1.3.3 セッションとセッション属性のスコープ設定方法の選択

セッションとセッション属性のスコープ設定とは、アプリケーション境界を越えてセッション・データとセッション属性の両方の有効範囲を詳細に設定(共有)する操作を指します。Coherence*Webでは、Webアプリケーション間でセッションを共有したり、アプリケーション間で共有するセッション属性を制限することができます。これらの選択肢、およびデプロイメントで構成が必要なディスクリプタと要素については、「セッションとセッション属性のスコープ設定」で説明します。

1.3.4 期限切れHTTPセッションをいつクリーンアップするかの選択

Coherence*Webには、期限切れのセッションを無効にするセッション・リーパーが用意されています。セッション・リーパーの詳細は、第7章「期限切れHTTPセッションのクリーンアップ」を参照してください。

1.3.5 インストール方法の選択

実行するインストール手順は、アプリケーション・サーバーによって異なります。「サポートされているWebコンテナ」では、アプリケーション・サーバーとそのサーバーに応じたCoherence*Webのインストール手順が一覧に記載されています。

最新リリースのWebLogic Server (12c (12.1.2)など)を使用している場合、CoherenceおよびCoherence*WebはWebLogic Server製品とともにインストールされます。Coherence*Webを別個にインストールする必要はありません。第2章「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。

Coherence*Webを古いリリースのWebLogic Server (WebLogic Server 11gR1以前など)にインストールしている場合は、次のURLの『Oracle Coherence*Web用Coherenceユーザーズ・ガイド』に記載されているネイティブのWebLogic Server SPIベースのインストール手順を使用してください。

http://docs.oracle.com/cd/E24290_01/coh.371/e22620/toc.htm

その他のアプリケーション・サーバーの場合、汎用Java EE WebInstallerを使用します。詳細は、第4章「他のアプリケーション・サーバーにおけるCoherence*Webの使用方法」を参照してください。

WebLogic PortalへのCoherence*Webのインストールは、WebLogic Serverからは全面的に独立した操作です。つまり、Coherence*WebをWebLogic Portalにインストールするために、WebLogic ServerにもCoherence*Webのインストールが必要になることはありません。第10章「WebLogic PortalでのCoherence*Webの使用方法」を参照してください。

2 WebLogic ServerでのCoherence*Webの使用方法

この章では、WebLogic Serverで使用するために、Coherence*Web、セッション状態の永続性および管理モジュールを構成してデプロイする方法について説明します。Coherence*Webをこのアプリケーション・サーバーで使用可能にする機能は、Coherence*Webに含まれています。

この章では、Coherenceアプリケーションをグリッド用にパッケージ化するためのCoherence ContainerおよびGrid Archive (GAR)形式についても概説します。Coherence ContainerおよびGAR形式の詳細な説明はこのドキュメントの範囲外です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server用Oracle Coherenceアプリケーションの開発』を参照してください。

この章には次の項が含まれます:

- Coherence*Webの概要

- Coherence Containerの概要

- Coherence*Webの構成とデプロイ: 主な手順

- Coherence*Web用のCoherence MBean属性

- セッションCookieパスのスコープ設定

- セッションIDの更新

- その他のアプリケーション・サーバーとのCoherence*Webセッションの共有

- WebLogic ServerとCoherence: 互換性

Coherence*Webでは、セッション状態の持続および管理が実現されます。セッション・データの格納および管理にCoherenceキャッシュを使用するのは、セッション管理モジュールです。Coherence*Webは、WebLogic Serverのメモリー内HTTP状態レプリケーション・サービスにかわるものです。次のいずれかの状況に該当する場合は、Coherence*Webの使用を検討してください。

- アプリケーションで使用するHTTPセッション状態オブジェクトが大きい

- HTTPセッション・オブジェクト・データの格納に起因するメモリー制約がある

- HTTPセッション記憶域の負荷を既存のCoherenceクラスタに分散させる必要がある

- 複数のエンタープライズ・アプリケーションと複数のWebモジュールにおいてセッション状態を共有する必要がある

2.1 Coherence*Webの概要

Coherence*Webを定義するクラスは、coherence-web.jarファイルに含まれています。Coherence*Webで提供される機能を使用するには、Webアプリケーションに対してcoherence.jarクラスも使用可能にする必要があります。どちらのファイルもcoherence\libディレクトリにあります。

注意:

Coherence 12c (12.1.2)ディストリビューションでは、coherence-web-spi.warファイルもcoherence\libディレクトリに含まれます。このファイルは、以前のバージョンのWebLogic Serverとの後方互換性のためにのみ提供されています。WebLogic Server 12c (12.1.2)以降を使用している場合は、このファイルを操作または参照する必要はありません。coherence-web-spi.warファイルをWebLogic Server 12c (12.1.2)以降にデプロイしようとしても無視されます。

WebLogic Server 12c (12.1.2)以降では、coherence-web.jarおよびcoherence.jarファイルはWebLogic Serverシステム・クラスパスに表示されます。coherence-web.jarは、適切なクラス・ローダーでアプリケーション・クラスをWebLogic Serverにロードします。つまり、coherence.jarまたはcoherence-web.jarファイルを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の12c (12.1.2)リリースで実行されているすべての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

2.2 Coherence Containerの概要

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アプリケーションをActiveCacheなどの既存のCoherenceベースの機能に統合できます。

注意:

デプロイされたアプリケーションでCoherenceデータ・キャッシュを簡単に使用し、セッション管理のためにCoherence*Webをシームレスに統合するためのWebLogic Serverの機能の集合であるActiveCacheは、12c (12.1.2)以降、非推奨となっています。これは、以前のバージョンのWebLogic Server上で実行されるように開発されたアプリケーションでは引き続き使用できます。詳細は、『Oracle Fusion Middleware ActiveCacheの使用』を参照してください。

Coherenceコンテナの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server用Oracle Coherenceアプリケーションの開発』のWebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。

2.3 Coherence*Webの構成とデプロイ: 主な手順

次の手順は、WebLogic Server上で実行しているアプリケーションでCoherence*Webを使用するためにデプロイメントを準備する方法を示しています。

1. WebLogic ServerとOracle Coherenceをインストールします。「WebLogic ServerとOracle Coherenceのインストール」を参照してください。

2. (オプション) アプリケーションにCoherence*Web用の高度な構成が必要な場合は、デプロイメントのweb.xmlファイルを変更します。Webアプリケーションに対して構成可能なパラメータについては、「Coherence*Webの構成」で説明します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

3. (オプション)WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xmlまたはweblogic-application.xmlのファイルで構成します。「セッションCookieの構成」を参照してください。

4. (テストの場合はオプション、本番の場合は強く推奨)WebLogic Serverを実行しているJVMとは別のJVMでキャッシュ・サーバー層を起動します。「キャッシュ・サーバーの起動」を参照してください。

5. Coherence*Webの記憶域モードを設定します。「Coherence*Webの記憶域モードの構成」を参照してください。

6. アプリケーションをWebLogic Serverにデプロイします。「WebLogic Serverへのアプリケーションのデプロイ」を参照してください。

2.3.1 WebLogic ServerとOracle Coherenceのインストール

WebLogic Serverには、次のインストール・オプションがあります。

- wls_version.jarはフル・インストールを提供し、インストールするコンポーネント(ビット、サンプル、Javadoc)を個々に選択することが可能です。インストーラでは、Oracle Universal Installer (OUI)を使用したグラフィカル・モードとサイレント・モードの両方がサポートされています。サイレント・モードでは、グラフィカル・インタフェースを使用せずにWebLogic ServerとCoherenceをインストールでき、リモート・インストールまたはスクリプトの一部としてインストールを組み込んでいる場合に適しています。

- wls_quick_version.jarは、ビットをサイレント・インストールします。クイック・インストールでは、オプションなしでサイレント・インストールが実行されます。

- wls_quick_supp_version.jarは、サンプルおよびJavadocファイルをサイレント・インストールします。

次のように、javaコマンドを使用して、ターゲット・コンピュータ上でインストーラを実行します。

java -jar wls_version.jar

WebLogic Serverは常にORACLE_HOME/wlserverディレクトリにインストールされます。Coherenceは常にORACLE_HOME/coherenceディレクトリにインストールされます。

WebLogic Serverのインストール手順の詳細は、『Oracle WebLogic Serverのインストール』を参照してください。

以前のバージョンのWebLogic Serverへの必要なソフトウェア・パッチの適用

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

パッチ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サイトに移動します。

https://support.oracle.com/

「パッチ」タブを選択してから、「単純検索」リンクをクリックし、後続の画面で適切な値(「11399293」など)のパッチ番号か名前を検索します。表示された検索結果からパッチのzipファイルをダウンロードします。Coherenceパッチを適用する手順は、パッチのzipファイルに含まれるREADME.txtに記載されています。

Coherence*Webを古いリリースのWebLogic Server (WebLogic Server 11gR1以前など)にインストールする場合の詳細は、次のURLの『Oracle Coherence*Web用Coherenceユーザーズ・ガイド』に記載されているネイティブのWebLogic Server SPIベースのインストール手順を参照してください。

http://docs.oracle.com/cd/E24290_01/coh.371/e22620/toc.htm

2.3.2 Coherence*Webの構成

Coherence*Webにより、大半のWebアプリケーションに対応するデフォルト構成を実現します。表2-2で、Coherence*Webにより構成されるコンテキスト・パラメータについて説明します。表2-3で、互換性モード・コンテキスト・パラメータについて説明します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

コンテキスト・パラメータは、システム・プロパティとしてコマンドラインで構成することもできます。システム・プロパティは、コンテキスト・パラメータと同じ名前を持ちますが、ダッシュ(-)がピリオド(.)に置き換えられています。たとえば、coherence-enable-sessioncontextコンテキスト・パラメータの値をコマンドラインで宣言するには、次のように入力します。

-Dcoherence.enable.sessioncontext=true

システム・プロパティと、同等のコンテキスト・パラメータの両方が構成されている場合、システム・プロパティの値が使用されます。

表2-2 Coherence*Webによって構成されるコンテキスト・パラメータ

パラメータ名

説明

coherence-application-name

Coherence*Webではこのパラメータの値を使用して、ApplicationScopeControllerインタフェースを使用して属性のスコープを設定するアプリケーションの名前を判別します。このパラメータの値は、次の形式で指定する必要があります。

アプリケーション名 + ! + Webモジュール名

application nameはApplicationScopeControllerインタフェースを使用するアプリケーションの名前であり、Web module nameはそれが記述されているWebモジュールの名前です。

たとえば、test.earというEARファイルと、このEARファイル内で定義されたapp1というWebモジュールがある場合、coherence-application-nameパラメータのデフォルト値はtest!app1となります。

このパラメータが構成されていない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。また、このパラメータが構成されておらず、ApplicationScopeControllerインタフェースが構成されている場合、アプリケーション名が構成されていなかったことを示す警告が記録されます。詳細は、「セッション属性スコープ設定」を参照してください。

coherence-reaperdaemon-assume-locality

この設定により、セッション・リーパーでは、(たとえば、分散キャッシュ・サービスによって)このノードに保存されるセッションは、このノードで期限切れのチェックが必要なセッションのみであると仮定できます。

デフォルトはfalseです。

coherence-scopecontroller-class

この値は、オプションのcom.tangosol.coherence.servlet.HttpSessionCollection$AttributeScopeControllerインタフェース実装のクラス名を指定します。

有効な値は次のとおりです。

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeController (デフォルト)

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$GlobalScopeController

Coherence*Webで設定するデフォルトはcom.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeControllerです。

表2-3は、Coherence*Webで具体的に渡されたcoherence-session-weblogic-compatibility-modeコンテキスト・パラメータを示しています。

表2-3 Coherence*Webによって渡されるコンテキスト・パラメータ

パラメータ名

説明

coherence-session-weblogic-compatibility-mode

このパラメータは、Coherence*Webによって渡されます。この値をtrueに設定した場合、各Webアプリケーションで、単一のセッションID (Cookieのパスを「/」に設定)が、固有のCoherence*Webセッション・インスタンスにマップされます。falseに設定した場合は、標準の動作が適用されます。つまり、単一のセッションIDが、WebLogic ServerのCoherence*Webを使用して単一のセッション・インスタンスにマップされます。WebLogicにおけるその他のすべてのセッション持続メカニズムでは、各Webアプリケーションで単一のセッションIDを使用して、様々なセッション・インスタンスを参照します。

グローバル・スコープ・コントローラが指定されていないかぎり、このパラメータではデフォルトでtrueに設定されます。コントローラが指定されていると、パラメータのデフォルト値はfalseになります。

表2-4は、coherence-factory-classコンテキスト・パラメータを示しています。デフォルト値はCoherence*Webで設定されますが、変更しないでください。

表2-4 変更してはいけないコンテキスト・パラメータ値

パラメータ名

説明

coherence-factory-class

SessionHelper.Factoryファクトリ・クラスを実装するクラスの完全修飾クラス名。Coherence*Webにより、デフォルト値はweblogic.servlet.internal.session.WebLogicSPIFactoryに設定されます。この値は変更しないでください。

2.3.3 セッションCookieの構成

Coherence*Webを使用すると、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-comment

該当なし

Cookieファイルにあるセッション追跡Cookieを特定するコメントを指定します。

デフォルトはnullです。

更新可能?はい

cookie-domain

coherence-session-cookie-domain

Cookieを有効にするドメインを指定します。たとえば、cookie-domainを.mydomain.comに設定した場合は、*.mydomain.comドメインにあるすべてのサーバーにCookieが返されます。

このドメイン名では2つ以上の要素を指定する必要があります。*.comや*.netと指定した名前は無効です。

値を設定しない場合は、Cookieを発行したサーバーにデフォルトで設定されます。

詳細は、サーブレット仕様で「Cookie.setDomain()」を参照してください。

デフォルトはnullです。

更新可能?はい

cookie-max-age-secs

coherence-session-max-age

セッションCookieの存続期間(秒)を設定します。この時間が経過したクライアントではセッションCookieが期限切れになります。Cookieの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』でセッションとセッション持続性の使用方法に関する項を参照してください。

デフォルト値は-1(無制限)です。

更新可能?はい

cookie-name

coherence-session-cookie-name

セッション・トラッキングのCookie名を定義します。設定しない場合は、デフォルトでJSESSIONIDに設定されます。これは、アプリケーションに固有の名前に設定できます。

デフォルトはJSESSIONIDです。

更新可能?はい

cookie-path

coherence-session-cookie-path

セッション・トラッキングのCookieパスを定義します。

値を指定しない場合は、デフォルトで「/」(スラッシュ)に設定され、WebLogic Serverで指定するすべてのURLにブラウザからCookieが送信されます。このパスによる対応範囲を狭くすることで、ブラウザからのCookie送信先となるリクエストURLを制限できます。

デフォルトはnullです。

更新可能?はい

cookie-secure

coherence-session-cookie-secure

HTTPS接続経由でのみCookieを返すことができることをブラウザに指示します。これによって、Cookie IDが保護されます。この設定は、HTTPSを使用するWebサイトでのみ使用してください。この機能が有効な場合、HTTP経由で送信されるセッションCookieは機能しません。

この機能を使用する場合は、url-rewriting-enabled要素を無効にしてください。

WebLogic ServerによってセッションCookieが生成されます。

デフォルトはfalseです。

更新可能?はい

cookies-enabled

coherence-session-cookies-enabled

セッションCookieの使用がデフォルトで有効になり、これをお薦めしますが、このプロパティをfalseに設定してCookieを無効にすることもできます。テスト時はこのオプションを無効にしてもかまいません。

デフォルトはtrueです。

更新可能?はい

debug-enabled

該当なし

HTTPセッションに対するデバッグ機能を有効にします。これは、HttpSessionDebugロギングおよびWebLogic Serverトレース・ロガーを有効にすることによってサポートされます。

デフォルト値は、falseです。

更新可能?はい

encode-session-id-in-query-params

該当なし

最新のサーブレット仕様でパス・パラメータのセッションIDをコンテナでエンコードする必要がある場合、trueに設定します。Webサーバーの中には、パス・パラメータを適切に処理しないものがあります。そのような場合は、encode-session-id-in-query-params要素をtrueに設定する必要があります。

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルト値は、falseです。

更新可能?はい

http-proxy-caching-of-cookies

該当なし

falseに設定すると、プロキシ・キャッシュにCookieがキャッシュされていないことを示す「Cache-control: no-cache=set-cookie」というヘッダーおよびレスポンスがWebLogic Serverによって追加されます。

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルト値はtrueです。

更新可能?はい

id-length

coherence-session-id-length

セッションIDのサイズを設定します。

最小値は8バイト、最大値はInteger.MAX_VALUEです。

Wireless Application Protocol (WAP)アプリケーションを作成している場合、WAPプロトコルではCookieがサポートされないので、URLリライティングを使用する必要があります。また、WAPデバイスの中にはURL長を128文字(属性を含む)に制限しているものがあり、その場合はURLリライティングを使用して送信できるデータの量に制限があります。属性に使用できる領域を増やすには、この属性を使用して、WebLogic Serverでランダムに生成されるセッションIDのサイズを制限します。

WAPEnabled属性を設定することで、長さを52文字固定に制限し、特殊文字の使用を禁止することもできます。詳細は、WebLogic Server用のWebアプリケーションの開発のURLリライティングとワイヤレス・アクセス・プロトコルに関する項を参照してください。

デフォルトは52です。

更新可能?いいえ

invalidation-interval-secs

該当なし

タイムアウトしたセッションおよび無効なセッションに対してチェックを実行してから古いセッションを削除してメモリーを解放するまで、Coherence*Webが待機する時間(秒単位)を設定します。この要素を使用して、トラフィックが多いサイトで最適なパフォーマンスが得られるようにWebLogic Serverを調整します。

デフォルトは60です。

更新可能?いいえ

timeout-secs

該当なし

セッションをタイムアウトするまでCoherence*Webが待機する時間(秒単位)を設定します。

アクセスが多いサイトでは、セッションのタイムアウトを適切に設定することによってアプリケーションを調整できます。ブラウザ・クライアントにセッションを終了する機会を提供するとともに、ユーザーがサイトを離れたりその他の方法でセッションを破棄した場合に、サーバーを不要に拘束しないようにします。

この要素は、web.xmlのsession-timeout要素(分単位で定義)によってオーバーライドできます。

デフォルトは3600秒です。

更新可能?いいえ

tracking-enabled

該当なし

HTTPリクエスト間のセッション・トラッキングを有効にします。

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルトはtrueです。

更新可能?いいえ

url-rewriting-enabled

coherence-session-urlencode-enabled

URLリライティングを有効化します。これにより、ブラウザでCookieが無効化されている場合にセッションIDがURLにエンコードされてセッション・トラッキングが提供されます。URLを書き込むときにはencodeURLまたはencodeRedirectedURLのメソッドが使用されます。詳細は、次を参照してください。

http://www.jguru.com/faq/view.jsp?EID=1045

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルトはtrueです。

更新可能?はい

2.3.4 キャッシュ・サーバーの起動

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キャッシュ・サーバーの起動

- コマンドラインからのCoherenceキャッシュ・サーバーの起動

2.3.4.1 WebLogic Server管理コンソールからのCoherenceキャッシュ・サーバーの起動

WebLogic Server管理コンソールを使用して、Coherenceクラスタのメンバーである各WebLogic Serverの記憶域を有効化できます。Coherenceセッション・キャッシュには、記憶域を有効化するための別個のフラグがあります。このフラグの詳細は、「WebLogic Server管理コンソールでのCoherenceセッション・キャッシュの有効化」を参照してください。

注意:

管理対象サーバーがCoherenceクラスタのメンバーでありCoherence*Webを使用している場合、セッション記憶域を有効化するには-Dtangosol.coherence.session.localstorage=trueシステム・プロパティを起動コマンドに追加します。

Coherenceセッション・キャッシュが自動的にWebLogic Serverクラスタで開始します。Coherenceキャッシュ・サーバーをWebLogic Server管理コンソールで操作する場合の例は、『Oracle Fusion Middleware Oracle Coherenceチュートリアル』のCoherenceコンテナおよびWebLogic Serverによるセッションのキャッシングに関する項を参照してください。

次の手順は、CoherenceクラスタをWebLogic Server管理コンソールで起動する方法を示しています。

1. Coherenceクラスタを構成します。
詳細は、Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成および管理に関する項を参照してください。

2. Coherenceクラスタに関連付けられるWebLogic Serverおよびクラスタを構成します。
詳細は、Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成および管理に関する項を参照してください。

3. 選択したWebLogic ServerまたはクラスタのCoherence*Webを有効化します。
詳細は、WebLogic Server管理コンソールでのCoherenceセッション・キャッシュの有効化に関する項を参照してください。

2.3.4.2 コマンドラインからのCoherenceキャッシュ・サーバーの起動

WebLogic Server管理コンソールを使用するかわりに、コマンドラインからのCoherenceキャッシュ・サーバーまたはクラスタの起動が必要になる場合があります。Coherenceキャッシュ・サーバーは、コマンドラインからスタンドアロン・モードまたはWebLogic Serverインスタンスの一部として起動できます。

- スタンドアロンCoherenceキャッシュ・サーバーの起動方法

- 記憶域を有効化したWebLogic Serverインスタンスまたは記憶域を無効化したWebLogic Serverインスタンスを起動するには:

2.3.4.2.1 スタンドアロンCoherenceキャッシュ・サーバーの起動方法

スタンドアロンCoherenceキャッシュ・サーバーを起動するには、次の手順を実行します。

1. Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。記憶域が有効なキャッシュ・サーバーを作成して起動する簡単なスクリプトの例を次に示します。この例では、Sun JVMの使用を前提としています。詳細は、『Oracle Fusion Middleware 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=session_cache_configuration_file
-Dtangosol.coherence.session.localstorage=true -Dtangosol.coherence.cluster=Coherence_cluster_name com.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 Fusion Middleware Oracle Coherence統合ガイド』のCoherenceキャッシュとセッション情報のマージに関する項を参照してください。

変数Coherence_cluster_nameはCoherenceクラスタの名前を表します。WebLogic Serverリリース10.3.6以降に、クラスタ名のチェック機能が追加されています。クラスタ名をWebLogic Serverアプリケーションで宣言しているため、tangosol.coherence.clusterプロパティをキャッシュ・サーバーに追加する必要があります。スタンドアロン・モードで起動された場合、Coherenceサーバーはこのプロパティを渡す必要があります。そうしないと、WLSサーバーとスタンドアロン・キャッシュ・サーバー間にクラスタは形成されません。

2. 前述の手順で説明したスクリプトを使用して、Coherenceキャッシュ・サーバーを1つ以上起動します。

2.3.4.2.2 記憶域を有効化したWebLogic Serverインスタンスまたは記憶域を無効化したWebLogic Serverインスタンスの起動方法

デフォルトでは、Coherence*Webを使用可能なWebLogic Serverインスタンスは、記憶域を無効化した状態で起動します。記憶域を有効化した状態でWebLogic Serverインスタンスを起動する手順は次のとおりです。

1. Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。これは、前項で説明されているスクリプトと同様にできます。

2. -Dtangosol.coherence.session.localstorage=trueのコマンドライン・プロパティをサーバー起動コマンドに含め、ローカル記憶域を有効にしますWebLogic Serverインスタンスが、Coherence*Webが使用可能で、ローカル記憶域を有効化した状態で起動します。
Coherence*Webを使用可能なWebLogic Serverインスタンスを起動するには、このシステム・プロパティを省略します。ローカル記憶域はデフォルトでは無効化されています。

コマンドラインからのWebLogic Serverの操作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。

2.3.5 Coherence*Webの記憶域モードの構成

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ファイルを示しています。

例2-1 weblogic.xmlのCoherence Webの記憶域モード

<weblogic-web-app>
...
<session-descriptor>
<persistent-store-type>coherence-web</persistent-store-type>
</session-descriptor>
...
</weblogic-web-app>

2.3.6 WebLogic Serverへのアプリケーションのデプロイ

デフォルト・セッション・キャッシュ構成ファイルをWebアプリケーションで使用している場合は、それを他のJava EEアプリケーションのようにパッケージ化してデプロイできます。ただし、カスタム・セッション・キャッシュ構成ファイルを使用している場合は、アプリケーションをGARファイルでパッケージ化してデプロイする必要があります。

GARファイルは他のあらゆるJava EEアプリケーションと同様にデプロイされますが、Coherence層とその層に属するノードを作成する点が異なります。スタンドアロンGARまたは埋込みGARを構成できます。

スタンドアロンGARファイルおよび埋込みGARの構成およびデプロイの詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』のWebLogic ServerへのCoherenceアプリケーションのデプロイに関する項およびOracle WebLogic Server用Oracle Coherenceアプリケーションの開発のWebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。

2.4 Coherence*Web用のCoherence MBean属性

WebLogic Serverは、ドメイン内のクラスタを表す、クラスタMBean (weblogic.management.configuration.ClusterMBean)を定義します。クラスタMBeanは、クラスタの管理に関連する複数の属性、操作およびMBeanを定義します。クラスタMBeanにより定義されるMBeanの例として、CoherenceMemberConfigMBeanとCoherenceTierMBeanがあります。

CoherenceMemberConfigMBeanとCoherenceTierMBeanはそれぞれ、クラスタまたはメンバーがCoherence*Webに対する記憶域層として機能しているかどうかを示すisCoherenceWebLocalStorageEnabled属性を定義します。この属性の定義を表2-6に示します。

表2-6 Coherence*Web用のCoherence MBean属性

属性

説明

isCoherenceWebLocalStorageEnabled

この属性がCoherenceTierMBeanでtrueに設定されている場合、クラスタがCoherence*Webに対する記憶域層として機能していることを示します。Coherence*Webキャッシュ・サービスは、サーバーの起動時に記憶域が有効な状態で起動します。Coherence*Web対応のアプリケーションのデプロイ時には、ドメイン内にこの属性が有効になっている稼動中のWebLogicクラスタが存在する必要があります。

この属性がCoherenceMemberConfigMBeanでtrueに設定されている場合、このノードがCoherence*Webに対する記憶域ノードとして機能していることを示します。Coherence*Webキャッシュ・サービスは、サーバーの起動時に記憶域が有効な状態で起動します。Coherence*Web対応のアプリケーションのデプロイ時には、ドメイン内にこの属性が有効になっている稼動中のWebLogicクラスタが存在する必要があります。

デフォルト: false

2.4.1 WebLogic Server管理コンソールでのCoherenceセッション・キャッシュの有効化

WebLogic Server管理コンソールの「Coherence Webローカル記憶域有効」チェック・ボックスは、前項で説明したisCoherenceWebLocalStorageEnabled属性に対応しています。このチェック・ボックスは、クラスタがCoherence*Webの記憶域層として機能しているかどうかを示します。このチェック・ボックスに移動する手順は次のとおりです。

1. 「ドメイン構造」ウィンドウで、「環境」→「クラスタ」を選択します。

2. 「クラスタ」表内の定義済クラスタを選択します。

3. 「クラスタの設定」ページで、「構成」タブ→「Coherence」タブを選択します。

図2-1に、WebLogic Server管理コンソールの「クラスタの設定」ページの「Coherence Webローカル記憶域有効」チェック・ボックスを示します。

図2-1 「Coherence Webローカル記憶域有効」チェック・ボックス

2.5 カスタム・セッション・キャッシュ構成ファイルの使用方法

coherence-web.jarファイルにはdefault-session-cache-config.xmlキャッシュ構成ファイルが含まれ、これはほとんどのアプリケーションに対応可能です。ただし、Coherence*ExtendまたはPush Replicationなどのテクノロジを使用している場合、またはカスタム・セッション・キャッシュ構成を使用する記憶域有効キャッシュ・サーバーとして機能するWebLogic Serverノードがある場合は、カスタム・セッション・キャッシュ構成ファイルを使用する必要があります。カスタム・セッション・キャッシュ構成ファイルを、デプロイメント用のGARファイルにパッケージ化する必要があります。

カスタム・セッション・キャッシュ構成ファイルをWebLogic Serverで使用してGARファイルにパッケージ化するには、次のWebアプリケーションの手順と、キャッシュ・サーバーとして機能しているWebLogic Serverノードの手順に従ってください。

Coherence*Webを使用しているWebアプリケーションの場合

1. カスタム・セッション・キャッシュ構成ファイル(名前はsession-cache-config.xml)を使用している場合は、Webアプリケーションでパッケージ化します。

- WARファイルについては、セッション・キャッシュ構成ファイルをWEB-INF/classesフォルダに置きます。

- EARファイルについては、セッション・キャッシュ構成ファイルをJARファイルにパッケージ化し、EARファイル内の共有ライブラリ(APP-INF/libフォルダ)に配置します。

セッション・キャッシュ構成ファイル名はカスタマイズできますが、その場合は、web.xmlファイルでcoherence-cache-configuration-pathコンテキスト・パラメータの値として新しいファイル名を指定する必要があります。

2. Coherence*Webアプリケーションで実行しているWebLogic Serverクラスタ・メンバーがキャッシュ・サーバーとして機能しないようにするには、WebLogic Server管理コンソールの「クラスタの設定」ページの「Coherence Webローカル記憶域有効」チェック・ボックスが選択されていないことを確認します。これにより、カスタム・セッション・キャッシュ構成ファイルが読み取られるようになります。

キャッシュ・サーバーとして機能しているWebLogic Serverノードの場合

1. カスタム・セッション・キャッシュ構成ファイルを使用している場合は、このファイルとcoherence-application.xmlファイルが含まれたGARファイルを作成します。GARファイルの構造は次のとおりです。

my.gar
session-cache-config.xml
META-INF
coherence-application.xml
MANIFEST.MF

GARファイルのパッケージ化要件の詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』のWebLogic Server用のCoherenceアプリケーションのパッケージ化に関する項およびOracle WebLogic Server用Oracle Coherenceアプリケーションの開発のOracle WebLogic Server用のCoherenceアプリケーションの作成に関する項を参照してください。

1. カスタム・セッション・キャッシュ構成ファイルを作成し、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の記憶域が有効にはなりません。

2. 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>

2. 記憶域が有効なCoherenceクラスタ・メンバーとして機能するWebLogic ServerクラスタにGARファイルをデプロイします。
次のいずれかの方法で、記憶域を有効にする必要があることに注意してください。

- session-cache-config.xmlファイルで記憶域を有効にする(手順1aを参照)

- WebLogic Server管理コンソールの「Coherence Webローカル記憶域有効」チェック・ボックスを選択するか、JVM引数tangosol.coherence.session.localstorageをtrueに設定して、サーバー自体で記憶域を有効にする

GARファイルのデプロイの詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』のWebLogic ServerドメインへのCoherenceアプリケーションのデプロイに関する項およびOracle WebLogic Server用Oracle Coherenceアプリケーションの開発のWebLogic ServerへのCoherenceアプリケーションのデプロイに関する項を参照してください。

2.6 セッションCookieパスのスコープ設定

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セキュリティ・レイヤーでドメイン間の信頼関係を有効にすると、複数のドメインにわたって機能するようになります。

2.7 セッションIDの更新

ユーザーが保護リソースの認証に成功すると、セッションIDはセキュリティのために変更されます。

以前のリリースのWebLogic Serverでは、新しいセッションが作成されて、古いセッションのすべてのセッション属性は新しいセッションにコピーされ、その後で古いセッションは無効化されました。これによりセッション・リスナー(登録されている場合)がトリガーされて、セッション・ライフサイクルおよびセッション属性リスナーが実行されます。

現在のリリースのWebLogic Serverは、HttpServletRequest.changeSessionIdメソッドをJava Servlet 3.1仕様から実装します。changeSessionIdメソッドの実装により、実際のセッションIDの更新が可能になります。つまり、セッション・ライフサイクル・イベントはトリガーされなくなり、実行されるリスナーもありません。ほとんどのユーザーは、アプリケーションの動作の変化には気が付きません。

HttpServletRequest.changeSessionIdメソッドの詳細は、Javaサーブレット3.1仕様およびJavadocを次のURLで参照してください。

http://jcp.org/en/jsr/detail?id=340

2.8 その他のアプリケーション・サーバーとのCoherence*Webセッションの共有

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コンテキスト・パラメータ」を参照してください。

2.9 WebLogic ServerとCoherence: 互換性

表2-7に、スタンドアロンのWebLogic Serverの各バージョンとCoherenceとの互換性を示します。

表2-7 スタンドアロンのWebLogic Serverの各バージョンとCoherenceとの互換性

スタンドアロンのWebLogic Serverのバージョン

WebLogic ServerにバンドルされているCoherenceのバージョン

一般的な使用でサポートされているCoherenceのバージョン

Coherence*Webに対してサポートされているCoherenceのバージョン

依存関係インジェクションおよび管理統合に対してサポートされているCoherenceのバージョン

WebLogic Server 10.3.4

3.6

3.5以降をサポート、3.6または3.7.1をお薦めします

3.5以降をサポート、3.6または3.7.1をお薦めします

3.6, 3.7.1

WebLogic Server 10.3.5

3.6

3.5以降をサポート、3.6または3.7.1をお薦めします

3.5以降をサポート、3.6または3.7.1をお薦めします

3.6, 3.7.1

WebLogic Server 10.3.6

3.7.1

3.5以降をサポート、3.7.1をお薦めします

3.5以降をサポート、3.7.1をお薦めします

3.7.1

WebLogic Server 12.1.1

3.7.1

3.5以降をサポート、3.7.1をお薦めします

3.5以降をサポート、3.7.1をお薦めします

3.7.1

WebLogic Server 12.1.2

12.1.2

12.1.2をサポート

12.1.2をサポート

12.1.2

表2-8に、Java Required Files (JRF)とともに配布されるWebLogic Serverの各バージョンとCoherenceとの互換性を示します。

表2-8 JRFとともに配布されるWebLogic Serverの各バージョンとCoherenceとの互換性

WebLogic ServerとJRFのバージョン

WebLogic ServerにバンドルされているCoherenceのバージョン

一般的な使用でサポートされているCoherenceのバージョン

Coherence*Webに対してサポートされているCoherenceのバージョン

WebLogic Server 10.3.4/Fusion Middleware 11.1.1.4

3.6

JRFバージョンと一致する必要があります

JRFバージョンと一致する必要があります

WebLogic Server 10.3.5/Fusion Middleware 11.1.1.5

3.6

JRFバージョンと一致する必要があります

JRFバージョンと一致する必要があります

WebLogic Server 10.3.6/Fusion Middleware 11.1.1.6

3.7.1

JRFバージョンと一致する必要があります

JRFバージョンと一致する必要があります

WebLogic Server 12.1.1

3.7.1

JRFバージョンと一致する必要があります

JRFバージョンと一致する必要があります

WebLogic Server 12.1.2

12.1.2

JRFバージョンと一致する必要があります

JRFバージョンと一致する必要があります

3 GlassFish ServerでのCoherence*Webの使用方法

この章では、GlassFish Serverで使用するために、Coherence*Web、セッション状態の永続性および管理モジュールを構成してデプロイする方法について説明します。Coherence*Webをこのアプリケーション・サーバーで使用可能にする機能は、ActiveCache for GlassFishに含まれています。

この章には次の項が含まれます:

- GlassFish Serverの概要

- ActiveCache for GlassFishの概要

- GlassFish ServerでのCoherence*Webの構成とデプロイ: 主な手順

3.1 GlassFish Serverの概要

Oracle GlassFish Serverは、軽量型で、柔軟性と拡張可能性に優れたJava EE 6プラットフォームを提供します。これにより、フットプリントが小さく、完全に装備されたJava EEアプリケーション・サーバーが実現されます。このアプリケーション・サーバーは、商用デプロイメント用に完全にサポートされており、スタンドアロン製品として利用できます。Oracle GlassFish Serverは、軽量型インフラストラクチャおよびJava Enterprise Editionの最新の実装を必要とするアプリケーションに最適です。この章では、GlassFish Server上で実行しているアプリケーションからCoherence*Webを使用できるように設定およびデプロイする方法について説明します。

3.2 ActiveCache for GlassFishの概要

Oracle CoherenceとOracle GlassFish Serverの現在のリリースでは、ActiveCache for GlassFishと呼ばれるCoherence*Web機能が提供されています。ActiveCache for GlassFishを使用すると、Oracle GlassFish ServerにデプロイされたWebアプリケーションでCoherence*Web機能を利用できます。旧リリースでは、セッション記憶域にCoherence*Webを使用するには、Coherence*Web WebInstallerでアプリケーションを事前処理する必要がありました。ActiveCache for GlassFishを使用することにより、GlassFish 3.1アプリケーションでは、WebInstallerの事前処理手順は不要になります。

ActiveCache for GlassFish機能は、coherence\libフォルダにあるcoherence-web.jarファイルで提供されます。ActiveCache for GlassFishで使用されるCoherenceキャッシュの構成とサービスは、default-session-cache-config.xmlファイルに定義されており、このファイルはcoherence-web.jarファイル内にあります。default-session-cache-config.xmlファイルで定義されているデフォルト・キャッシュ構成とサービス構成は、ほとんどすべてのWebアプリケーションに対応可能です。

Coherence*WebではCoherenceキャッシュを使用してセッション・データを格納するので、coherence.jarファイルはWebアプリケーションのクラス・ローダーからも使用できる必要があります。EARスコープ設定やWARスコープ設定のクラスタ・ノードでActiveCache for GlassFishを実行するように構成する方法の詳細は、「クラスタ・ノードの構成」を参照してください。

デフォルトでは、GlassFish Server上で稼働するCoherenceノードは、記憶域を無効化した状態で構成されます。Webアプリケーションを動作させるには、別のCoherenceキャッシュ・サーバーが稼働している必要があります。

Coherence*Webには、セッションの同時アクセスを制御するためのセッション・ロック・モードがいくつかあります。ActiveCache for GlassFishでは、最後の書込みを優先するロックがデフォルトで採用されます。これにより、単一のJVMまたは複数のJVMにある複数のスレッドからセッションに同時アクセスできます。ただし、セッションを同時に変更できません。ロック・モードの詳細は、「セッション・ロック・モード」を参照してください。

スプリット・セッション・モデル(SplitHttpSessionModel)では、小さなセッション属性が単一のキャッシュ・エントリとして格納され、大きな属性が個別のキャッシュ・エントリとして格納されますが、これは、ActiveCache for GlassFishで使用されるデフォルトのセッション・モデルです。詳細は、「セッション・モデル」を参照してください。

セッション・データをCoherenceデータ・グリッドに格納することで、GlassFish Serverでヒープ領域を利用できるようになります。セッション・データをGlassFish Serverの外部に格納することにより、セッション・データを失わずにWebアプリケーションとサーバーを再起動できます。また、これによって別々のWebアプリケーションでセッションを共有できます。EARスコープ設定かWARスコープ設定のクラスタ・ノードにあるGlassFish Server上でCoherence*Webを実行できます。アプリケーション・サーバー・スコープはサポートされていません。

3.3 GlassFish ServerでのCoherence*Webの構成とデプロイ: 主な手順

次の手順は、GlassFish Server上で実行しているアプリケーションでCoherence*Webを使用するためにデプロイメントを準備する方法を示しています。

1. Oracle Coherenceをファイル・システムにダウンロードします。「Oracle Coherenceのダウンロード」を参照してください。

2. glassfish-web.xmlファイルでWebアプリケーションのセッション持続タイプをcoherence-webに設定します。「セッション持続タイプの設定」を参照してください。

3. (オプション)デフォルトのCoherence*Webキャッシュ構成やクラスタ構成をオーバーライドする必要がある場合、default-session-cache-config.xmlファイルを編集します。「デフォルトのCoherence*Webキャッシュ構成またはクラスタ構成のオーバーライド」を参照してください。

4. coherence-web.jarファイルをWebアプリケーションで利用できるようにします。「ActiveCache for GlassFishとセッション・キャッシュ・ファイルをアプリケーションにコピーする方法」を参照してください。

5. web.xmlファイルを編集して、Webアプリケーションをサーバー・クラスタで利用できるようにします。「Webアプリケーションを配布可能にする方法」を参照してください。

6. (オプション)アプリケーションがCoherence*Web用に高度な構成を必要とする場合は、WARデプロイメントのweb.xmlファイルを編集します。「Coherence*Webの構成」を参照してください。

7. (テストの場合はオプション、本番の場合は強く推奨)GlassFish Serverを実行しているJVMとは別のJVMでキャッシュ・サーバー層を起動します。「キャッシュ・サーバーの起動」を参照してください。

8. アプリケーションをパッケージ化します。GlassFish ServerにおけるEARスコープ設定やWARスコープ設定のクラスタ・ノードに対してCoherence*Webを構成できます。「クラスタ・ノードの構成」を参照してください。

3.3.1 Oracle Coherenceのダウンロード

Coherence*Webをサポートしているすべてのファイルは、ActiveCache for GlassFishを含めて、Coherenceディストリビューションに付属しています。最新リリースのOracle Coherenceは次のURLで入手できます。

http://www.oracle.com/technetwork/middleware/coherence/overview/index.html

3.3.2 セッション持続タイプの設定

WebアプリケーションのWEB-INFディレクトリのglassfish-web.xmlファイルを作成するか編集します。Webアプリケーションのセッション持続タイプをcoherence-webに設定します。次に例を示します。

例3-1 Coherence*Web用のglassfish-web.xmlファイルの構成

<glassfish-web-app>
<session-config>
<session-manager persistence-type="coherence-web" />
</session-config>
</glassfish-web-app>

3.3.3 デフォルトのCoherence*Webキャッシュ構成またはクラスタ構成のオーバーライド

default-session-cache-config.xmlファイルには、Coherence*WebがHTTPセッション管理を実装するために使用するセッション・キャッシュとサービスのデフォルト定義が記述されています。coherence-web.jarファイルに含まれるdefault-session-cache-config.xmlファイルは、ほとんどのWebアプリケーションに対応可能です。必要に応じて、独自のカスタム・セッション・キャッシュ構成ファイルとtangosol-coherence-override.xmlファイルを使用して、別のキャッシュ構成とクラスタ構成を指定できます。このファイルは、WebアプリケーションのWEB-INF/classesディレクトリに配置する必要があります。

カスタム・セッション・キャッシュ構成ファイル名の指定方法の詳細は、「セッション・キャッシュ構成ファイル名のカスタマイズ」を参照してください。

3.3.4 ActiveCache for GlassFishとセッション・キャッシュ・ファイルをアプリケーションにコピーする方法

coherence-web.jarファイルは、ActiveCache for GlassFishの機能を提供します。GlassFish Serverで実行するアプリケーションからcoherence-web.jarファイルを利用できるようにする必要があります。

GlassFish Server上にデプロイする各Webアプリケーションの/WEB-INF/lib/ディレクトリにcoherence-web.jarファイルをコピーします。

3.3.5 Webアプリケーションを配布可能にする方法

Webアプリケーションを、サーバー・クラスタなどの分散環境で実行できるように構成する必要があります。<distributable/>要素をWebアプリケーションのweb.xmlデプロイメント・ディスクリプタに追加します。<distributable/>要素は、ルート<web-app>要素の子です。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。

3.3.6 Coherence*Webの構成

ActiveCache for GlassFishには、ほとんどのWebアプリケーションに対応するデフォルトのCoherence*Web構成が用意されています。web.xmlファイルの<context-param>要素を使用してCoherence*Web構成を定義します。web.xmlファイルに<context-params>要素を追加するか編集することで、デフォルト値をオーバーライドできます。

注意:

Webアプリケーション起動後にCoherence*Web構成を変更した場合、Webアプリケーションを再起動する必要があります。動的に更新可能な構成オプションはCoherence*Webにありません。

表3-1に、ActiveCache for GlassFishでCoherence*Web用に用意されているデフォルト値を示します。これらのパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

表3-1 ActiveCache for GlassFishに用意されているデフォルトのコンテキスト・パラメータ値

パラメータ名

説明およびデフォルト値

coherence-application-name

デフォルトは、「ServletContextパス+ServletContext名」です。

Webアプリケーション名を表すための、一貫性のある、一意の文字列です。

coherence-cluster-owned

デフォルトはfalseです。

Webアプリケーション起動時にすべてのCoherenceノードが起動するため、Webアプリケーション停止時にもCoherenceノードを停止する必要があります。

coherence-reaperdaemon-assume-locality

デフォルトはfalseです。

セッションはスタンドアロンのキャッシュ・サーバーに格納できます。

coherence-scopecontroller-class

デフォルトはcom.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeControllerです。

coherence-session-locking

デフォルトはfalseです。

セッション・ロックは、デフォルトでは無効になっています。この構成により最後の書込みを優先するポリシーが有効になります。

coherence-session-locking-mode

デフォルトはnoneです。

セッション・ロックは、デフォルトでは無効になっています。この構成により最後の書込みを優先するポリシーが有効になります。

coherence-sessioncollection-class

デフォルトはcom.tangosol.coherence.servlet.SplitHttpSessionCollectionです。

SplitHttpSessionCollectionは、推奨されるデフォルト・モデルです。

GlassFish ServerでセッションCookieの生成と解析が行われるため、セッションCookieを構成するCoherence*Webコンテキスト・パラメータは使用されません。サーブレットのコンテキストをクラスタ化できるようにCoherence*Webを構成できる場合でも、ActiveCache for GlassFishではこの機能はサポートされません。

ActiveCache for GlassFishで使用する際に有効でないCoherence*Webコンテキスト・パラメータを表3-2に示します。これらのコンテキスト・パラメータが存在する場合、ActiveCache for GlassFishで警告ログが返されます。これらのパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

表3-2 GlassFish Serverで有効ではないCoherence*Webコンテキスト・パラメータ

パラメータ名

有効ではない理由

coherence-distributioncontroller-class

GlassFish Server用の値は、com.tangosol.coherence.servlet.glassfish31.GlassFishHybridControllerです。

coherence-preserve-attributes

GlassFish Serverは、セッションでシリアライズ不可能なユーザー・データをキャッシュします。

coherence-session-cookie-domain

GlassFish ServerによりセッションCookieの生成と解析が行われるため、このパラメータは有効ではありません。

coherence-session-cookie-max-age

GlassFish ServerによりセッションCookieの生成と解析が行われるため、このパラメータは有効ではありません。

coherence-session-cookie-name

GlassFish ServerによりセッションCookieの生成と解析が行われるため、このパラメータは有効ではありません。

coherence-session-cookie-path

GlassFish ServerによりセッションCookieの生成と解析が行われるため、このパラメータは有効ではありません。

coherence-session-cookies-enabled

GlassFish ServerによりセッションCookieの生成と解析が行われ、URLがセッションIDでエンコードされるため、このパラメータは有効ではありません。

coherence-eventlisteners

web.xmlに登録されているセッション・イベント・リスナーがActiveCache for GlassFishで自動的に登録されるため、このパラメータは有効ではありません。

coherence-servletcontext-clustered

ActiveCache for GlassFishのクラスタ化されたServletContextがCoherence*Webでサポートされていないため、このパラメータは有効ではありません。

coherence-session-id-length

GlassFish ServerによりセッションCookieの生成と解析が行われるため、このパラメータは有効ではありません。

coherence-session-urldecode-bycontainer

GlassFish ServerによりセッションCookieの生成と解析、およびURLのエンコードとデコードが行われるため、このパラメータは有効ではありません。

coherence-session-urlencode-enabled

GlassFish ServerによりセッションCookieの生成と解析が行われ、URLがセッションIDでエンコードされるため、このパラメータは有効ではありません。

coherence-session-urlencode-name

GlassFish ServerによりセッションCookieの生成と解析が行われ、URLがセッションIDでエンコードされるため、このパラメータは有効ではありません。

表3-3に、glassfish-web.xmlファイルの有効なセッション構成パラメータを示します。GlassFishによりセッションCookieが作成され、URLがサーブレットでエンコードされるため、これらは有効です。

表3-3 glassfish-web.xmlの有効なGlassFishセッション構成パラメータ

パラメータ名

有効である理由

session-config/cookie-properties/cookieComment

GlassFishによってセッションCookieが生成されます。

session-config/cookie-properties/cookieMaxAgeSeconds

GlassFishによってセッションCookieが生成されます。

session-config/cookie-properties/cookiePath

GlassFishによってセッションCookieが生成されます。

session-config/cookie-properties/cookieSecure

GlassFishによってセッションCookieが生成されます。

session-config/cookie-properties/cookieDomain

GlassFishによってセッションCookieが生成されます。

session-config/session-properties/enableCookies

GlassFish ServerによってセッションCookieが生成されます。

session-config/session-properties/enableURLRewriting

GlassFish ServerによってセッションCookieが生成されます。

session-config/session-manager/persistence-type

このパラメータをcoherence-webに設定して、Coherence*Webを有効にする必要があります。

session-config/session-manager/manager-properties/reap-interval-in-seconds

この値には、coherence-reaperdaemon-cycle-seconds Coherence*Web構成パラメータを設定します。GlassFish Serverのデフォルトは60秒です

session-config/session-properties/timeoutSeconds

この値には、coherence-session-expire-seconds Coherence*Web構成パラメータを設定します。web.xmlファイルにある同等パラメータがオーバーライドされます。

ActiveCache for GlassFishを使用する際にglassfish-web.xmlファイルで有効でない構成パラメータを表3-4に示します。これらのパラメータがglassfish-web.xmlファイルで構成されている場合は、無視されます。

表3-4 glassfish.web.xmlのCoherence*Webで有効ではないGlassFishコンテキスト・パラメータ

パラメータ名

有効ではない理由

session-config/session-manager/manager-properties/maxSessions

Coherence*Webによりセッション管理が制御されます。セッションを複数のアプリケーションで共有できるため、特定のアプリケーションに対してセッションの数は計算できません。

session-config/session-manager/manager-properties/ persistenceFrequency

Coherence*Webでは必ずセッション・データがリクエストの最後においてキャッシュにフラッシュされますが、非同期で行われる場合があります。

session-config/session-manager/manager-properties/sessionFilename

このパラメータは、fileセッション持続タイプにのみ関連します。

session-config/session-manager/store-properties/ directory

このパラメータは、fileセッション持続タイプにのみ関連します。

session-config/session-manager/store-properties/ persistenceScope

このパラメータは、GlassFish Server native replicatedセッション持続タイプにのみ関連します。

3.3.7 キャッシュ・サーバーの起動

Coherenceキャッシュ・サーバーは、すべてのキャッシュ・データを格納して管理します。これは、専用のJVM(アウトオブプロセス)内でも、GlassFish Serverインスタンス内(インプロセス)でも実行できます。Coherenceデータ・クラスタ内の上位ノード(最初のノード)は起動に数秒間かかることがあります。下位のノードで必要な起動時間は最小限です。

アウトオブプロセス・トポロジ(記憶域を無効化したGlassFish ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバー)を使用している場合は、最初にキャッシュ・サーバーを起動し、次にGlassFish Serverインスタンスを起動します。これにより、Coherenceを使用するアプリケーションの起動時間はわずか(ミリ秒単位)になります。Coherenceを使用する追加Webアプリケーションはどれも上位データ・メンバーにならず、そのため、それらがGlassFish Serverの起動に与える影響は最小限になります。

スタンドアロンCoherenceキャッシュ・サーバーの起動方法

1. Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。
キャッシュ・サーバーを起動するスクリプトの例を次に示します。この例では、Sun JVMの使用を前提としています。詳細は、『Oracle Fusion Middleware 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=default-session-cache-config.xml
-Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer

クラスパスのcoherence-web.jarとcoherence.jarを含める必要があります。Coherence*Webの場合、default-session-cache-config.xmlファイルをキャッシュ構成ファイルとして使用します。これは、「ActiveCache for GlassFishとセッション・キャッシュ・ファイルをアプリケーションにコピーする方法」で入手したファイルです。キャッシュ・サーバーに対して定義されているキャッシュ構成は、同じCoherenceクラスタで実行されているアプリケーション・サーバーに対して定義されているキャッシュ構成と一致する必要があります。

Coherence*Webで追加のCoherenceキャッシュを実行している場合は、default-session-cache-config.xmlファイルに格納されているセッション構成とキャッシュ構成情報(一般的にcoherence-cache-config.xmlファイルで定義)をマージする必要があります。キャッシュ構成とセッション構成は、GlassFish ServerとCoherenceキャッシュ・サーバーで一貫している必要があります。

これらのファイルをマージする方法の詳細は、『Oracle Fusion Middleware Oracle Coherence統合ガイド』のCoherenceキャッシュとセッション情報のマージに関する項を参照してください。

2. 前述の手順で説明したスクリプトを使用して、Coherenceキャッシュ・サーバーを1つ以上起動します。

記憶域を有効化したGlassFish Serverインスタンスまたは記憶域を無効化したGlassFish Serverインスタンスを起動する手順は次のとおりです。

デフォルトでは、Coherence*Webを使用可能なGlassFish Serverインスタンスは、記憶域を無効化した状態で起動します。

記憶域を有効化した状態でGlassFish Serverインスタンスを起動する方法は数種類あります。その一つとして、サーバー起動コマンドにコマンド・ライン・プロパティの-Dtangosol.coherence.session.localstorage=trueを含める方法があります。

別の方法としては、default-session-cache-config.xmlファイルでlocal-storage要素をtrueに設定することです。次に例を示します。

...
<local-storage>true</local-storage>
...

3.3.8 クラスタ・ノードの構成

GlassFish Serverでは、EARスコープ設定やWARスコープ設定のクラスタ・ノードに対してのみCoherence*Webを構成できます。GlassFish Serverクラス・ローダーの動作仕様により、アプリケーション・サーバー・スコープ設定のクラスタ・ノードは構成できません。アプリケーション・サーバー・スコープ設定、EARスコープ設定またはWARスコープ設定のクラスタ・ノードの詳細は、「クラスタ・ノード分離」を参照してください。

3.3.8.1 EARスコープ設定クラスタ・ノードの構成

Coherence*WebをEARスコープ設定クラスタ・ノードで使用する手順は次のとおりです。

1. EARファイルの各WARにあるWEB-INF/libディレクトリにcoherence.jarとcoherence-web.jarのファイルをコピーします。

2. 例3-2に示すように、glassfish-web.xmlファイルでセッション持続タイプをcoherence-webに設定します。

例3-2 glassfish-web.xmlファイルにおける持続タイプの設定

<glassfish-web-app>
...
<session-config>
<session-manager persistence-type="coherence-web"/>
</session-config>
...
</glassfish-web-app>

3. EARファイルの各WARファイルにある/WEB-INF/classes/ディレクトリに、セッション・キャッシュ構成ファイルdefault-session-cache-config.xmlをコピーします。

3.3.8.2 WARスコープ設定クラスタ・ノードの構成

Coherence*WebをWARスコープ設定のクラスタ・ノードで使用する手順は次のとおりです。

1. GlassFish Server上にデプロイする各Webアプリケーションの/WEB-INF/lib/ディレクトリに coherence.jarとcoherence-web.jarのファイルをコピーします。

2. glassfish-web.xmlファイルでセッション持続タイプをcoherence-webに設定します。例3-2を参照してください。

3. GlassFish Serverにデプロイする各Webアプリケーションの/WEB-INF/classes/ディレクトリに、セッション・キャッシュ構成ファイルdefault-session-cache-config.xmlをコピーします。

このパッケージ化は、デプロイした各WARファイルでCoherenceノードがクラスタに作成されることを意味します。複数のWARファイルをEARファイルにパッケージ化する場合、各WARファイルでCoherenceノードがクラスタに作成されます。

4 他のアプリケーション・サーバーにおけるCoherence*Webの使用方法

この章では、様々なアプリケーション・サーバーで使用するために、Coherence*Web、セッション状態の永続性および管理モジュールを構成してデプロイする方法について説明します。Coherence*Webをこれらのアプリケーション・サーバーで使用可能にする機能は、自動化されたCoherence*Web WebInstallerを実行することにより提供されます。

準備:

「サポートされているWebコンテナ」を参照して、アプリケーション・サーバー固有のインストール手順を実行する必要があるかどうかを確認してください。

WebLogic Server上でCoherence*Webをデプロイするには、次の方法があります。

- この章で説明するWebInstallerによる方法。

- WebLogic Server 11gR1以降では、SPIベースのインストールによる方法。第2章「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。

- GlassFish ServerにおけるSPIベースのインストールを使用する方法。第3章「GlassFish ServerでのCoherence*Webの使用方法」を参照してください。

この章では、Coherence*Web WebInstallerを使用して、Java EEアプリケーション向けのCoherence*Webを様々なアプリケーション・サーバーにインストールする手順について説明します。

この章には次の項が含まれます:

- WebInstallerによるCoherence*Webのインストール

- Coherence*Web WebInstaller Antタスク

- HTTPセッション管理のテスト

- Coherence*Web Web WebInstallerによるJava EEアプリケーションの設定

- Java EEセキュリティを使用しているアプリケーションへのCoherence*Webのインストール

- クロスサイト・スクリプティング攻撃の防止

4.1 WebInstallerによるCoherence*Webのインストール

Coherence*Webは、様々なWebコンテナのJava EEアプリケーションに対して有効化できます。これを行うには、アプリケーションをデプロイする前に、自動化したCoherence*Web WebInstallerを使用して、デプロイの準備が整ったアプリケーションを実行する必要があります。この自動化したインストーラによって、アプリケーションのデプロイメント準備が完了します。インスペクトとインストールの2段階でインストール・プロセスが実行されます。これらの各段階でのインストーラの動作は、「Coherence*Web WebInstallerによるJava EEアプリケーションの設定」を参照してください。

このインストーラは、JavaコマンドラインまたはAntタスクから実行できます。次の各項では、Javaコマンドラインから実行する方法について説明します。Antタスク・ベースのインストールについては、「Coherence*Web WebInstaller Antタスク」を参照してください。

4.1.1 アプリケーション・サーバー固有のインストール手順

「サポートされているWebコンテナ」の説明にあるすべてのWebコンテナは、WebInstallerで同じ一般的なインストール手順を使用してインストールできます。この手順の詳細は「Coherence*Webセッション管理モジュールをインストールする一般的な手順」を参照してください。

Webコンテナの中には、この一般的なインストール手順を開始する前に、そのコンテナ固有の追加手順を実行しなければならないものがわずかにあります。Caucho Resin、WebLogic 10.nなどがこのようなコンテナに該当します。次の各項で、アプリケーション・サーバー固有のインストール手順について説明しています。

- Oracle WebLogic Server 10.nへのインストール

- Caucho Resin 3.1.nへのインストール

4.1.1.1 Oracle WebLogic Server 10.nへのインストール

Coherence*Webセッション管理モジュールをOracle WebLogic Serverリリース10からリリース10.2にインストールするには、次の手順を実行します。

1. coherence-web.jarファイルをcoherence/libディレクトリから入手します。

2. サーバー・クラスタで実行する予定のWebLogic Server 10.nをインストールするたびに、次のコマンドを使用してライブラリを更新します。

java -cp coherence.jar;coherence-web.jar com.tangosol.coherence.servlet.WebPluginInstaller <wls-home-path> -install

3. 「Coherence*Webセッション管理モジュールをインストールする一般的な手順」の説明にある手順に従ってインストールを完了します。サーバー・タイプとして「WebLogic/10.x」を指定します。

4.1.1.2 Caucho Resin 3.1.nへのインストール

Coherence*Webセッション管理モジュールをCaucho Resin 3.1.nサーバーにインストールするには、次の手順を実行します。

1. coherence-web.jarファイルをcoherence/libディレクトリから入手します。

2. サーバー・クラスタで実行する予定のCaucho Resinをインストールするたびに、次のコマンドを使用してライブラリを更新します。

java -cp coherence.jar;coherence-web.jar
com.tangosol.coherence.servlet.WebPluginInstaller <resin-home-path> -install

3. 「Coherence*Webセッション管理モジュールをインストールする一般的な手順」の説明にある手順に従ってインストールを完了します。サーバー・タイプとして「Resin/3.1.x」を指定します。

4.1.2 Coherence*Webセッション管理モジュールをインストールする一般的な手順

「サポートされているWebコンテナ」に記載したどのWebコンテナにJava EEアプリケーション用のCoherence*Webをインストールする場合でも、次の手順を実行してください。

Java EE用のCoherence*WebをApache Tomcatサーバーにインストールしている場合の手順の詳細は、「Apache Tomcatサーバーに対するスティッキー・セッションの有効化」も参照してください。

Java EE用のCoherence*WebをIBM WebSphereサーバーにインストールしている場合の手順の詳細は、「IBM WebSphere 7.nサーバーに対するURLセッションIDのデコード」も参照してください。

デプロイするJava EEアプリケーション用のCoherence*Webをインストールするには:

1. アプリケーション・ディレクトリ、EARファイルおよびWARファイルを他のプロセスで使用もアクセスもしていないことを確認します。

2. 現在のディレクトリをCoherenceのライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib、Unixの場合は$COHERENCE_HOME/lib)。

3. Javaコマンドを実行できるようにパスを構成していることを確認します。

4. 次のコマンドを実行してアプリケーションのインスペクト手順を完了します。次のコマンドラインで、<app-path>にはアプリケーションへのフル・パスを指定し、<server-type>には、使用しているサーバーの名前を表1-1から選択して指定します。

java -jar webInstaller.jar <app-path> -inspect -server:<server-type>

アプリケーションを配置したディレクトリに、Java EEアプリケーション用のcoherence-web.xml構成ディスクリプタ・ファイルが作成されます(すでに存在している場合はそれが更新されます)。この構成ディスクリプタ・ファイルには、アプリケーション用としてインストーラ推奨のデフォルトのCoherence*Web設定が収められています。

5. 必要に応じて、各自の要件に基づいてCoherence*Web設定を見直し、変更してください。
coherence-web.xmlディスクリプタ・ファイルを編集することで、Coherence*Web設定を変更できます。変更可能なCoherence*Web設定は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。context-paramパラメータのサブ要素であるparam-nameおよびparam-valueを使用して、必要な機能を有効にします。表4-1に、様々な設定の例を示します。

表4-1 Coherence*Webのコンテキスト・パラメータ設定の例

パラメータ

名前

説明

coherence-servletcontext-clustered

true

すべてのServletContext(グローバル)属性をクラスタ化し、そのクラスタにあるサーバーがこれらの属性に同じ値を持ち、これらの属性が変更されたときはサーブレット仕様で指定されたイベントを受け取るようにします。

coherence-enable-sessioncontext

true

アプリケーションで使用すると、そのアプリケーションに存在するすべてのセッションを列挙したり、そのいずれかを取得して調査または操作したりできます。

coherence-session-id-length

32

SecureRandomアルゴリズムを使用して生成したHttpSession IDを長くできます。この長さは任意の値にできますが、実際は、CookieまたはURLに適した長さにする必要があります(セッションIDの管理方法に依存)。これを長くすると、セッションが意図的にハイジャックされる危険性を低くできます。

coherence-session-urlencode-enabled

true

デフォルトでは、HttpSession IDはCookieで管理されます。アプリケーションでURLのエンコードがサポートされている場合、このオプションにより有効になります。

6. 次のコマンドで、<app-path>をアプリケーションへのフル・パスに置き換えて実行すると、Coherence*Webアプリケーションのインストール手順が実行します。

java -jar webInstaller.jar <app-path> -install

このインストーラでは、有効なcoherence-web.xml構成ディスクリプタ・ファイルをアプリケーションと同じディレクトリに配置する必要があります。このコマンドにより、アプリケーション・アーカイブ・ファイルのWEB-INF\classesディレクトリにdefault-session-cache-config.xmlファイルが作成されます。このファイルには、セッション構成情報とキャッシュ構成情報が格納されます。

7. 更新済のアプリケーションをデプロイし、Coherenceディストリビューションに付随している軽量型ロード・バランサを使用して、すべてが仕様どおりに機能することを確認します。この軽量型ロード・バランサは、WebLogic Serverに付随しているロード・バランサとは対照的に、本番向けのユーティリティではありません。

Coherenceでサポートしているデプロイメント・トポロジであれば任意のトポロジで、アプリケーションをデプロイして実行できます。サポートしているデプロイメント・トポロジには、Coherence*Extendによるアウトオブプロセスとインプロセスがあります。これらのトポロジにおいてアプリケーションのデプロイと実行を行う方法の詳細は、次の各項を参照してください。トポロジ自体の詳細は、「デプロイメント・トポロジ」を参照してください。

4.1.2.1 インプロセスのアプリケーションのデプロイと実行

Coherence*Webはアプリケーション・サーバーでインプロセス状態で実行できます。これは、セッション・データがアプリケーション・サーバーで格納される場所です。このトポロジの詳細は、「インプロセス・トポロジ」を参照してください。

アプリケーション・サーバーの場合:

1. 記憶域を有効化した状態でアプリケーション・サーバーを起動します。システム・プロパティのtangosol.coherence.session.localstorage=trueをアプリケーション・サーバー起動スクリプトのJavaオプションに追加します。

2. coherence.jarとcoherence-web.jarのファイルを共有ライブラリとしてデプロイします。

3. アプリケーションをデプロイして実行します。

4.1.2.2 アウトオブプロセスのアプリケーションのデプロイと実行

アウトオブプロセス・デプロイメント・トポロジでは、スタンドアロンのキャッシュ・サーバーでセッション・データを格納し、アプリケーション・サーバーはキャッシュ・クライアントとして構成されます。このトポロジの詳細は、「アウトオブプロセス・トポロジ」を参照してください。

キャッシュ・サーバーとアプリケーション・サーバーは、同じキャッシュ構成とセッション構成を使用する必要があります。この構成は、Coherence*Web WebInstallerによりdefault-session-cache-config.xmlファイルに生成されます。WebInstallerにより、設定済アプリケーションのWEB-INF\classesディレクトリにファイルが生成されます。

キャッシュ・サーバーの場合:

1. tangosol.coherence.cacheconfigシステム・プロパティをキャッシュ・サーバー起動スクリプトに追加して、構成ファイルを探します。また、システム・プロパティのtangosol.coherence.session.localstorage=trueを含めて、キャッシュ・サーバーの記憶域を有効にする必要があります。

2. coherence.jarとcoherence-web.jarのファイルをキャッシュ・サーバー起動スクリプトのクラスパスに追加します。
次の例は、サンプル起動スクリプトです。

java -server -Xms512m -Xmx512m
-cp <Coherence installation dir>/lib/coherence.jar:<Coherence installation dir>/lib/coherence-web.jar -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.cacheconfig=default-session-cache-config.xml
-Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer

アプリケーション・サーバーの場合(キャッシュ・クライアント):

1. coherence.jarとcoherence-web.jarのファイルを共有ライブラリとしてデプロイします。

2. 設定済アプリケーションのWEB-INF\classesディレクトリにdefault-session-cache-config.xmlファイルが存在する必要があります。
デフォルトでは、ファイルではローカル記憶域が無効になるように指定します(不明な場合、ファイルを調べてlocal-storage要素がfalseに設定されていることを確認するか、システム・プロパティのtangosol.coherence.session.localstorage=falseを起動スクリプトに追加できます)。

3. アプリケーションをサーバーにデプロイします。

4.1.2.3 アウトオブプロセス・トポロジへの移行

インプロセスのCoherence*Webでアプリケーションの実行とテストを行っている場合、簡単にアウトオブプロセス・トポロジに移行できます。単純に、キャッシュ・サーバーとアプリケーション・サーバーを設定します。詳細は、「アウトオブプロセスのアプリケーションのデプロイと実行」を参照してください。

4.1.2.4 Coherence*Extendによるアウトオブプロセスのアプリケーションのデプロイと実行

Coherence*Extendによるアウトオブプロセス・トポロジは、アウトオブプロセス・トポロジに似ていますが、アプリケーション・サーバー層とキャッシュ・サーバー層との通信をCoherence*Extend経由(TCP/IP)で行う点が異なります。Coherence*Extendは、クラスタの外部で実行されるExtendクライアント(またはプロキシ)と、1台以上のキャッシュ・サーバーでホストされているクラスタ内で実行される拡張プロキシ・サービスの2つの基本コンポーネントで構成されます。このトポロジの詳細は、「"Coherence*Extendによるアウトオブプロセス・トポロジ"」を参照してください。

これらのデプロイメントの参加者には、次の3種類があります。

- キャッシュ・サーバー(記憶域サーバー)は、実際のセッション・データをメモリーに格納する際に使用されます。

- Web(アプリケーション)サーバーは、このトポロジにおけるExtendクライアントです。クラスタのメンバーにはならず、クラスタ内のプロキシ・ノードに接続します。クラスタへのリクエストの発行は、そのプロキシ・ノードが代行します。

- プロキシ・サーバーは、クラスタ内の記憶域が無効なメンバーとして、ExtendクライアントからのTCP/IP接続を受け入れ、管理します。クライアントからのリクエストはクラスタに送信され、応答はTCP/IP接続を通じて返送されます。

キャッシュ・サーバーの場合:

「アウトオブプロセスのアプリケーションのデプロイと実行」でキャッシュ・サーバーを構成する手順に従ってください。また、キャッシュ・サーバーのdefault-session-cache-config.xmlファイルをコピーしてから編集し、システム・プロパティのtangosol.coherence.session.proxy=falseとtangosol.coherence.session.localstorage=trueを追加します。

これらのコンテキスト・パラメータを含むdefault-session-cache-config.xmlファイルの例と詳細は、「プロキシJVMと記憶域JVMのキャッシュの構成」を参照してください。

Web層(アプリケーション)サーバーの場合:

「アウトオブプロセスのアプリケーションのデプロイと実行」でアプリケーション・サーバーを構成する手順に従ってください。また、次の手順を完了します。

1. オプティミスティック・ロック・モードを使用するようにCoherence*Webを構成していることを確認します。オプティミスティック・ロックは、Coherence*Webにおけるデフォルトのロック・メカニズムです(「"オプティミスティック・ロック"」を参照)。

2. アプリケーション・サーバーのdefault-session-cache-config.xmlファイルをコピーしてから編集し、プロキシJVMのホスト名、IPアドレスおよびポートを追加します。このためには、<remote-addresses>セクションをファイルに追加します。一般には、ロード・バランシングとフェイルオーバーに備えて、すべてのプロキシJVMのホスト名、IPアドレスおよびポートを追加します。

<remote-addresses>セクションを含むdefault-session-cache-config.xmlファイルの例と詳細は、「Web層JVMのキャッシュの構成」を参照してください。

プロキシ・サーバーの場合:

若干変更することで、プロキシ・サーバーではキャッシュ・サーバーおよびアプリケーション・サーバーと同じキャッシュ構成およびセッション構成を使用できます。default-session-cache-config.xmlファイルを編集して、これらのシステム・プロパティを追加します。

- tangosol.coherence.session.localstorage=falseにより、ローカル記憶域を無効にします。

- tangosol.coherence.session.proxy=trueは、プロキシ・サービスが使用されていることを示します。

- tangosol.coherence.session.proxy.localhostは、プロキシがバインドされるNICのホスト名またはIPアドレスを示します。

- tangosol.coherence.session.proxy.localportは、プロキシがバインドされるポートの一意のポート番号を示します。

これらのコンテキスト・パラメータを含むdefault-session-cache-config.xmlファイルの例と詳細は、「プロキシJVMと記憶域JVMのキャッシュの構成」を参照してください。

4.1.3 Apache Tomcatサーバーに対するスティッキー・セッションの有効化

Apache Tomcatサーバーにスティッキー・セッションを採用するには、サーバーのserver.xmlファイルにjvmRoute属性を構成する必要があります。この属性の詳細は、次のURLを参照してください。

http://tomcat.apache.org/connectors-doc/reference/workers.html

4.1.4 IBM WebSphere 7.nサーバーに対するURLセッションIDのデコード

coherence-session-urldecode-bycontainerコンテキスト・パラメータをtrueに設定すると、コンテナでURLをデコードできます。Java EE用のCoherence*WebをIBM WebSphereアプリケーション・サーバーのリリース7.nにインストールしている場合は、このコンテキスト・パラメータをfalseに設定する必要があります。WebSphereアプリケーション・サーバーのかわりに、Coherence*WebによってセッションIDのデコードが処理されます。

Coherence*Web WebInstallerをWebSphere 7.nアプリケーション・サーバー・タイプに対して実行する場合、このパラメータは、ユーザーが明示的にtrueに設定しないかぎり、自動的にfalseに設定されます。

4.2 Coherence*Web WebInstaller Antタスク

Coherence*Web WebInstaller Antタスクを使用すると、既存のAntビルド・ファイルからインストーラを実行できます。

この項の内容は次のとおりです。

- Coherence*Web WebInstaller Antタスクの使用方法

- WebInstaller Antタスクの構成

- WebInstaller Antタスクの例

4.2.1 Coherence*Web WebInstaller Antタスクの使用方法

Coherence*Web WebInstaller Antタスクを使用するには、例4-1に示すタスク・インポート文をAntビルド・ファイルに追加します。この例で、${coherence.home}はCoherenceをインストールした環境のルート・ディレクトリを指しています。

例4-1 Coherence*Web WebInstaller用のタスク・インポート文

<taskdef name="cwi" classname="com.tangosol.coherence.misc.CoherenceWebAntTask">
<classpath>
<pathelement location="${coherence.home}/lib/webInstaller.jar"/>
</classpath>
</taskdef>

次の手順は、AntビルドからJava EEアプリケーションにCoherence*Webをインストールするための基本的なプロセスを示しています。

1. いつものようにJava EEアプリケーションをビルドします。

2. operations属性をinspectに設定して、Coherence*Web Antタスクを実行します。

3. 生成されたCoherence*Web XMLディスクリプタ・ファイルを必要に応じて変更します。

4. operations属性をinstallに設定して、Coherence*Web Antタスクを実行します。

反復手順のある開発作業の実行

アプリケーションで反復手順のある開発作業(JavaServer Pages (JSP)、サーブレット、静的リソースなどの変更)を実行する場合は、次のインストール・プロセスを使用します。

1. operations属性をuninstallに、failonerror属性をfalseに、descriptor属性を「Coherence*Web WebInstaller Antタスクの使用方法」の手順2で以前生成したCoherence*Web XMLディスクリプタ・ファイルの場所にそれぞれ設定して、Coherence*Web Antタスクを実行します。

2. いつものようにJava EEアプリケーションをビルドします。

3. operations属性をinspectに、install属性とdescriptor属性を「Coherence*Web WebInstaller Antタスクの使用方法」の手順2で以前生成したCoherence*Web XMLディスクリプタ・ファイルの場所にそれぞれ設定して、Coherence*Web Antタスクを実行します。

Java EEアプリケーションのCoherence*Web構成設定の変更

Coherence*Webを使用するJava EEアプリケーションのCoherence*Web構成設定を変更する必要がある場合、次の手順を使用します。

1. operations属性をuninstallに、descriptor属性をJava EEアプリケーションのCoherence*Web XMLディスクリプタ・ファイルの場所にそれぞれ設定して、Coherence*Web Antタスクを実行します。

2. Coherence*Web XMLディスクリプタ・ファイルで、必要な構成パラメータを変更します。

3. operations属性をinstallに、descriptor属性を「Coherence*Web WebInstaller Antタスクの使用方法」の手順2で変更したCoherence*Web XMLディスクリプタ・ファイルの場所にそれぞれ設定して、Coherence*Web Antタスクを実行します。

4.2.2 WebInstaller Antタスクの構成

表4-2は、Coherence*Web WebInstaller Antタスクで使用可能な属性を示しています。

表4-2 Coherence*Web WebInstaller Antタスクの属性

属性

説明

必須?

app

目的のJava EEアプリケーションへのパス。WARファイル、EARファイル、展開したWARディレクトリ、または展開したEARディレクトリのいずれかへのパスを指定できます。

operations属性をversion以外の値に設定した場合は、はい。

backup

元の目的のJava EEアプリケーションのバックアップを保存するディレクトリへのパス。この属性は、デフォルトでJava EEアプリケーションのインストール先ディレクトリに設定されます。

いいえ

descriptor

Coherence*Web XMLディスクリプタ・ファイルへのパス。この属性は、デフォルトで目的のJava EEアプリケーションのインストール先ディレクトリにあるcoherence-web.xmlファイルに設定されます。

いいえ

failonerror

0以外のステータスでCoherence*Webインストーラが終了した場合はAntビルドを停止します。デフォルトはtrueです。

いいえ

nowarn

警告メッセージを表示しません。この属性の値はtrueまたはfalseのいずれかです。デフォルトはfalseです。

いいえ

operations

実行する操作をカンマまたはスペースで区切って指定します。指定できる操作は、inspect、install、uninstall、およびversionです。

はい

server

目的のJava EEアプリケーション・サーバーの別名。

いいえ

touch

Coherence*Webインストーラによって変更されたJSPとTLDにtouchコマンドを実行します。この属性に指定できる値は、true、false、またはM/d/y h:mmです。デフォルトはfalseです。

いいえ

verbose

詳細出力を表示します。この属性の値はtrueまたはfalseのいずれかです。デフォルトはfalseです。

いいえ

4.2.3 WebInstaller Antタスクの例

次に、WebInstaller Antタスクのコマンド例を示します。

- myWebApp.war Webアプリケーションをインスペクトして、現在の作業ディレクトリでmy-coherence-web.xmlという名前のCoherence*Web XMLディスクリプタ・ファイルを作成します。

<cwi app="myWebApp.war" operations="inspect" descriptor="my-coherence-web.xml"/>

- 現在の作業ディレクトリにあるmy-coherence-web.xmlという名前のCoherence*Web XMLディスクリプタ・ファイルを使用して、myWebApp.war WebアプリケーションにCoherence*Webをインストールします。

<cwi app="myWebApp.war" operations="install" descriptor="my-coherence-web.xml"/>

- myWebApp.war WebアプリケーションからCoherence*Webをアンインストールします。

<cwi app="myWebApp.war" operations="uninstall">

- /dev/myWebApp/srcディレクトリにあるmy-coherence-web.xmlという名前のCoherence*Web XMLディスクリプタ・ファイルを使用して、/dev/myWebApp/buildディレクトリに配置したmyWebApp.war WebアプリケーションにCoherence*Webをインストールし、元のWebアプリケーションのバックアップを/dev/myWebApp/workディレクトリに配置します。

<cwi app="/dev/myWebApp/build/myWebApp.war" operations="install" descriptor="/dev/myWebApp/src/my-coherence-web.xml" backup="/dev/myWebApp/work"/>

- /dev/myWebApp/buildディレクトリにあるcoherence-web.xmlという名前のCoherence*Web XMLディスクリプタ・ファイルを使用して、/dev/myWebApp/buildディレクトリに配置したmyWebApp.war WebアプリケーションにCoherence*Webをインストールします。Webアプリケーションがまだインスペクトされていない(つまり、/dev/myWebApp/build/coherence-web.xmlが存在しない)場合は、Coherence*Webをインストールする前にWebアプリケーションをインスペクトします。

<cwi app="/dev/myWebApp/build/myWebApp.war" operations="inspect,install"/>

- /dev/myWebApp/srcディレクトリにあるmy-coherence-web.xmlという名前のCoherence*Web XMLディスクリプタ・ファイルを使用して、/dev/myWebApp/buildディレクトリに配置したmyWebApp.war WebアプリケーションにCoherence*Webを再インストールします。

<cwi app="/dev/myWebApp/build/myWebApp.war" operations="uninstall,install" descriptor="/dev/myWebApp/src/my-coherence-web.xml"/>

4.3 HTTPセッション管理のテスト

Coherenceには、ソフトウェアによる軽量なロード・バランサが付属しています。このソフトウェアはテスト以外の目的には使用できません。このロード・バランサは、セッション管理などの機能テストではきわめて効果的で、たいへん使いやすいソフトウェアです。次の手順に従い、HTTPセッション管理を軽量型ロード・バランサでテストします。

1. それぞれがIPアドレスとポートの一意な組合せでアプリケーションを実行する複数のアプリケーション・サーバー・プロセスを、1台以上のサーバー・マシン上で開始します。

2. コマンド(またはシェル)ウィンドウを開きます。

3. 現在のディレクトリをCoherenceのライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib、Unixの場合は$COHERENCE_HOME/lib)。

4. Javaコマンドを実行できるようにパスを構成していることを確認します。

5. 次のコマンドラインを使用してソフトウェア・ロード・バランサを起動します(これらの各コマンドラインによって、デフォルトのHTTPポート80でアプリケーションが使用可能になります)。
たとえば、2つのアプリケーション・サーバー・インスタンスを7001ポートと7002ポートに持つ1台のマシンでローカルにロード・バランシングをテストするには、次のように入力します。

java -jar coherence-loadbalancer.jar localhost:80 localhost:7001 localhost:7002

server1、server2およびserver3に対して7001ポートで負荷を分散するserver1でローカルにロード・バランサを実行するには、次のように入力します。

java -jar coherence-loadbalancer.jar server1:80 server1:7001 server2:7001 server3:7001

前述のコマンドラインを実行すると、これまでhttp://server1:7001/my.jspをURLとしていたアプリケーションに、http://server1:80/my.jspまたはhttp://server1/my.jspのみを指定してアクセスできるようになります。

注意:

アプリケーションで使用されるアドレスが、相対リダイレクトまたはロード・バランサのアドレスのいずれかであることを確認してください。

表4-3は、ロード・バランサのコマンドライン・オプションを示しています。

表4-3 ロード・バランサのコマンドライン・オプション

オプション

説明

backlog

TCP/IP受入れバックログ・オプションを指定の値に設定します(例: -backlog=64)。

random

ランダム・ロード・バランシング・アルゴリズムの使用を指定します(デフォルト)。

roundrobin

ラウンドロビン・ロード・バランシング・アルゴリズムの使用を指定します。

threads

指定の数のリクエスト・スレッドやレスポンス・スレッドのペアを使用します(そのため、新しいデーモン・スレッドの総数は指定した値の2倍になります)(例: -threads=64)。

4.4 Coherence*Web WebInstallerによるJava EEアプリケーションの設定

インスペクトの手順では、Coherence*Web WebInstallerによって次のタスクが実行されます。

1. アプリケーションと目的のWebコンテナに関する基本的な情報、および目的のWebコンテナに適したデフォルトのCoherence*Web構成コンテキスト・パラメータを記述したテンプレートであるcoherence-web.xml構成ファイルを生成します。使用可能なすべてのパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
WebInstallerではサーブレット・コンテナを設定して、記憶域を無効化した状態で起動します(つまり、tangosol.coherence.session.localstorageをfalseに設定します)。

既存のcoherence-web.xml構成ファイルが存在する場合(たとえば、過去にCoherence*Web WebInstallerを実行したことがある場合)は、既存のファイルにあるコンテキスト・パラメータは生成したテンプレートにあるパラメータにマージされます。

2. 目的のJava EEアプリケーションにある各WebアプリケーションからJSPを列挙して、各JSPに関する情報をcoherence-web.xml構成ファイルに追加します。

3. 目的のJava EEアプリケーションにある各WebアプリケーションからTLDを列挙して、各TLDに関する情報をcoherence-web.xml構成ファイルに追加します。

インストールの手順では、Coherence*Web WebInstallerによって次のタスクが実行されます。

1. アンインストールの手順で復元できるように、元のJava EEアプリケーションのバックアップを作成します。

2. インスペクトの手順1で生成したCoherence*Web構成コンテキスト・パラメータを、目的のJava EEアプリケーションに含まれる各Webアプリケーションのweb.xmlディスクリプタ・ファイルに追加します。

3. 各Webアプリケーションから、アプリケーション固有のServletContextListener、ServletContextAttributeListener、ServletRequestListener、ServletRequestAttributeListener、HttpSessionListener、およびHttpSessionAttributeListenerの各クラス(TLDによって登録されたものを含む)を登録解除します。

4. Coherence*Web ServletContextListenerクラスを各web.xmlディスクリプタ・ファイルに登録します。実行時に、Coherence*Web ServletContextListenerクラスによって、各アプリケーション固有のServletContextListenerリスナーに各ServletContextEventイベントが伝播します。

5. Coherence*Web ServletContextAttributeListenerリスナーを各web.xmlディスクリプタ・ファイルに登録します。実行時に、Coherence*Web ServletContextAttributeListenerによって、各アプリケーション固有のServletContextAttributeListenerリスナーに各ServletContextAttributeEventイベントが伝播します。

6. 各web.xmlディスクリプタ・ファイルで宣言した各アプリケーション固有のServletをCoherence*Web SessionServletでラップします。実行時に、各Coherence*Web SessionServletからラップされたServletに権限が委譲されます。

7. インスペクト手順2で列挙した各JSPに次のディレクティブを追加します。

<%@ page extends="com.tangosol.coherence.servlet.api22.JspServlet" %>

アンインストールの手順では、Coherence*Web WebInstallerによって、設定済のJava EEアプリケーションがインストール・プロセスの手順(1)で作成した元のバージョンのバックアップに置き換えられます。

4.5 Java EEセキュリティを使用しているアプリケーションへのCoherence*Webのインストール

注意:

Coherence*WebのネイティブなWebLogic Server SPI実装には、この項の内容は該当しません。これは、Java EEセキュリティを使用しているアプリケーションに、WebInstallerを使用してCoherence*Webをインストールする場合にのみ該当します。SPI実装を使用する手順は、第2章「WebLogic ServerでのCoherence*Webの使用方法」を参照してください。

Java EEセキュリティを使用しているアプリケーションにCoherence*Webをインストールするには、インストールで次の手順を別途実行してください。

1. Coherence*WebセッションCookieを有効にします。
詳細は、表A-1のcoherence-session-cookies-enabled構成要素を参照してください。

2. Coherence*WebセッションCookieの名前を、目的のWebコンテナで使用していない名前に変更します。
デフォルトでは、JSESSIONIDがほとんどのコンテナでセッションCookie名として使用されるため、Coherence*WebセッションCookie名としてはCSESSIONIDをお薦めします。詳細は、表A-1のcoherence-session-cookie-name構成要素を参照してください。

3. 目的のWebコンテナに対するセッション・レプリケーションを有効にします。
セッション・レプリケーションが有効になっていない場合、またはコンテナでセッション・レプリケーションの形態がサポートされていない場合は、フェイルオーバーの際にWebアプリケーションに対する再認証を実行する必要があります。セッション・レプリケーションの有効化に関する手順は、Webコンテナのドキュメントを参照してください。

この構成によって、指定の認証済ユーザーに次の2つのセッションが関連付けられます。

- Webアプリケーションで作成したすべてのセッション・データを含むCoherence*Webセッション

- 認証中にWebコンテナによって作成され、ユーザーの特定に必要な情報のみを保存したセッション

4.6 クロスサイト・スクリプティング攻撃の防止

coherence-session-cookie-httponlyコンテキスト・パラメータを使用して、HttpOnly属性をセッションCookieに追加します。HttpOnly属性は、CookieにJavaScriptなどのクライアント側のスクリプトがアクセスできないようにするため、クロスサイト・スクリプティングといった攻撃を防止するために使用します。すべてのブラウザがこの機能をサポートしているわけではありません。このコンテキスト・パラメータは、設定済アプリケーションの場合のみ使用可能です。

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

この章では、Coherence*Webの機能(セッション・モデル、セッション・スコープ設定、セッション・ロック、デプロイメント・トポロジ、ロギングなど)について説明します。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*Webのロギングの構成」では、Coherence*Webに対してサポートされているロギングのタイプを説明します。

- 「同一のセッション・インスタンスへの同時アクセス」では、キャッシュ・デリゲータを使用して、セッション・インスタンスの保存および取得に分散キャッシュが使用される前にローカル・キャッシュが使用されるようにする方法を説明します。

5.1 セッション・モデル

セッション・モデルは、Coherence内のセッション状態をCoherence*Webでどのように保存するのかを記述します。セッション・データはHttpSessionModelオブジェクトで管理し、Webアプリケーションのセッション・コレクションはHttpSessionCollectionオブジェクトで管理します。web.xmlファイルでコレクション・タイプのみを構成する必要があります。モデルはコレクション・タイプから暗黙的に派生します。Coherence*Webは、次のような様々なセッション・モデル実装を備えています。

- モノリシック・モデルでは、すべてのセッション状態を単一のエンティティとして保存し、すべての属性を単一の操作としてシリアライズおよびデシリアライズします。

- トラディショナル・モデルでは、すべてのセッション状態を単一のエンティティとして保存しますが、属性は個別にシリアライズおよびデシリアライズします。

- スプリット・モデルは、トラディショナル・モデルを拡張したモデルですが、大きなセッション属性は独立した複数の物理エンティティに分離します。

この項では、セッション・モデルについて詳しく説明します。

- 「セッション・モデルの推奨事項」では、アプリケーションに対してどのセッション・モデルを選択するかについての推奨事項を示します。

- 「セッション・モデルの構成」では、システム・プロパティまたはコンテキスト・パラメータを使用してセッション・モデルを変更する方法について説明します。

- 「クラスタ環境でのデータの共有」では、JVM間およびJVM内でデータがどのように共有されるかについて説明します。

- 「スケーラビリティとパフォーマンス」では、スケーラビリティおよびパフォーマンスへのセッション・モデルの影響について説明します。

注意:

一般的に、同じCoherenceクラスタに属するWebアプリケーションは、同じセッション・モデル・タイプを使用する必要があります。構成に一貫性がないと、デシリアライズ・エラーが発生することがあります。

図5-1は、3つのセッション・モデルを示しています。

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

5.1.1 モノリシック・モデル

モノリシック・モデルは、MonolithicHttpSessionModelオブジェクトとMonolithicHttpSessionCollectionオブジェクトで表されます。これらはトラディショナル・モデルと似ていますが、すべての属性を単一のオブジェクト・ストリームにシリアライズおよびデシシアライズすることで共有オブジェクトの問題を解決している点が異なります。そのため、モノリシック・モデルはトラディショナル・モデルよりパフォーマンスが低下することがよくあります。

図5-2に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。論理表現では、セッション・データはメタデータと様々な属性で構成されます。セッション記憶域キャッシュの物理表現では、メタデータと属性は単一のストリームにシリアライズされます。メタデータと属性にはセッションIDが関連付けられます。

図5-2 モノリシック・セッション・モデル

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

トラディショナル・モデルは、TraditionalHttpSessionModelオブジェクトとTraditionalHttpSessionCollectionオブジェクトで表されます。TraditionalHttpSessionCollectionオブジェクトはHTTPセッション・オブジェクトを単一のキャッシュに格納しますが、各属性を個別にシリアライズします。

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

図5-3に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。論理表現では、セッション・データはメタデータと様々な属性で構成されます。セッション記憶域キャッシュ内の物理表現では、メタデータと属性はバイナリに変換され、これらにセッションIDが関連付けられます。属性は、単一のバイナリBLOBとして(モノリシック・モデルのように)ではなく、個々にシリアライズされることに注意してください。

図5-3 トラディショナル・セッション・モデル

5.1.3 スプリット・モデル

スプリット・モデルは、SplitHttpSessionModelオブジェクトとSplitHttpSessionCollectionオブジェクトで表されます。SplitHttpSessionCollectionはCoherence*Webで使用されるデフォルトです。

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

図5-4に、データの論理表現とセッション記憶域キャッシュにおけるその物理表現の関係を示します。このモデルでは、大型のオブジェクトは独自のセッションIDを持つ個別のキャッシュ・エントリとして格納されます。

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

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

次に、アプリケーションに対してどのセッション・モデルを選択するかについて推奨事項を示します。

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

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

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

注意:

セッション・モデルの構成に使用するパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

5.1.5 セッション・モデルの構成

デフォルトではCoherence*Webは、大型の属性が独立したキャッシュ・エントリに分割され、個々に管理されるスプリット・セッション・モデルを使用します。Coherence*Webにより使用されるセッション・モデルは、-Dcoherence.sessioncollection.classシステム・プロパティを構成するか、Webアプリケーションのweb.xmlファイル内の同等のcoherence-sessioncollection-classコンテキスト・パラメータを設定することにより変更できます。コンテキスト・パラメータ(またはシステム・プロパティ)の値として、HttpSessionCollection実装の完全修飾クラス名を使用します。

- com.tangosol.coherence.servlet.SplitHttpSessionCollection (デフォルト)は、スプリット・モデルを構成します。

- com.tangosol.coherence.servlet.MonolithicHttpSessionCollectionは、モノリシック・モデルを構成します。

- com.tangosol.coherence.servlet.TraditionalHttpSessionCollectionは、トラディショナル・モデルを構成します。

例5-1は、モノリシック・モデルを構成するためのweb.xmlエントリを示しています。

例5-1 セッション・モデルの構成

...
<context-param>
<param-name>coherence-sessioncollection-class</param-name>
<param-value>com.tangosol.coherence.servlet.MonolithicHttpSessionCollection</param-value>
</context-param>
...

5.1.6 クラスタ環境でのデータの共有

クラスタ化によって、アプリケーションのスケーラビリティと可用性を高めることができます。Coherence*Webなどのクラスタ化ソリューションは開発者の多くの問題を解決しますが、開発を成功させるためには、基礎となるテクノロジの制限とその対処方法を認識する必要があります。開発者は、プラットフォームが提供する機能とユーザーの要求内容を把握することによって、これら2つの間のギャップを埋めることができます。

セッション属性を複数のJVM間で処理する場合は、属性をシリアライズ可能にする必要があります。これはクラスタ化では必須です。セッション属性の一部のフィールドを非クラスタ化することもできます。その場合、対象のフィールドを一時フィールドとして宣言します。それによって、セッション属性のすべてのフィールドをシリアライズ可能にする必要はなくなりますが、このような属性はバックアップ・サーバーに完全にレプリケートされません。アプリケーションの開発時にこのアプローチを採用する場合は、属性フィールドが失われても、アプリケーションで一貫性のある動作が可能なことを入念に確認する必要があります。一般に、このアプローチを採用すると、すべてのセッション属性をシリアライズ可能オブジェクトに単純に変換する場合よりも、作業が難しくなります。しかし、セッション内でユーザー固有のデータが大量にキャッシュされる場合は、このパターンが役立つことがあります。

Java EEサーブレットの仕様(バージョン2.2、2.3および2.4)では、サーブレットのコンテキストをクラスタ内で共有しないように規定しています。サーブレットのコンテキストをシングルトン・データ構造として使用している非クラスタ化アプリケーションでは、クラスタ環境への移行時に移植の問題が発生します。

クラスタ環境で発生する、より複雑な問題として、オブジェクトの共有の問題があります。クラスタ化されていないアプリケーションでは、2つのセッション属性が共通オブジェクトを参照している場合、その共通オブジェクトに対する変更は両方のセッション属性の一部として参照可能です。しかし、クラスタ化されたアプリケーションでは、多くの場合、これと異なります。ほとんどのセッション管理の実装では、計算リソースを無駄に使用しないために、必要に応じて個別にセッション属性のシリアライズとデシリアライズが実行されます。Coherence*Webは、(トラディショナルおよびスプリット・セッション・モデルにおいて)通常、この方法で動作します。共通オブジェクトを参照する2つのセッション属性を個別にデシリアライズする場合、共有されている共通オブジェクトは2回インスタンス化されます。共有されているオブジェクトの動作に依存する、容易に修正できないアプリケーション向けに、Coherence*Webは、セッション・オブジェクト全体を単一操作としてシリアライズおよびデシリアライズするモノリスティック・セッション・モデルのオプションを備えています。これによって、もともとクラスタ化を考慮して設計されていないアプリケーションに対する互換性が確保されます。

多くのプロジェクトが、複数のWebアプリケーション間でのセッション・データの共有を必要とします。この場合の課題は、通常、Webアプリケーションごとに固有のクラス・ローダーがあることです。それが原因で、Webアプリケーション間でのオブジェクトの共有が難しくなります。回避策として使用できる一般的な方法が2つありますが、それぞれ固有のトレードオフがあります。

- 共通クラスをJava CLASSPATHに配置することによって、共通クラスのインスタンスを複数のアプリケーションで共有できます。ただし、この場合、構成が通常より若干複雑になります。

- Coherence*Webを使用して、クラス・ローダーの境界間でセッション・データを共有します。各Webアプリケーションは、たとえ同じJVM内で実行されていても、独立したクラスタ・メンバーとして扱われます。このアプローチでは、Webアプリケーション間が疎結合されます(シリアライズ・クラスが共通のシリアル・バージョンUIDを共有していることが前提となります)。ただし、この場合、クラスタ・メンバー間の転送のためにオブジェクトをシリアライズ/デシリアライズする必要があるため、パフォーマンスに影響します。

5.1.7 スケーラビリティとパフォーマンス

クラスタ環境への移行時には、セッション・サイズが重要な考慮事項になります。メモリー使用量は、アプリケーションがクラスタ化されるかどうかにかかわらず影響要因となりますが、クラスタ化アプリケーションの場合はさらに、セッションが大規模な場合のCPU使用率とネットワーク負荷の増加についても考慮する必要があります。メモリー内セッションを使用する非クラスタ化アプリケーションではセッション状態のシリアライズ/デシリアライズは必要ありませんが、クラスタ化アプリケーションではセッション状態の更新時に毎回シリアライズ/デシリアライズを実行する必要があります。セッション状態のシリアライズと、その後のネットワークを介した転送は、アプリケーションのパフォーマンスに影響を及ぼす重要な要因になります。このような理由などから、サーバーでは、通常、セッション・サイズを2、3KB以下に制限する必要があります。

Coherence*Webのトラディショナル・セッション・モデルとモノリシック・セッション・モデルでは制限要因が共通していますが、スプリット・セッション・モデルは大規模なHTTPセッションを効率よくサポートするように明示的に設計されています。単一のクラスタ化されたキャッシュ・エントリを使用して小さいセッション属性のすべてを格納することによって、セッションまたはその比較的小さい属性に対するアクセスや更新時にネットワーク通信量が最小化されます。各属性を個別にデシリアライズすることによって、CPU使用率も最小化されます。Coherence*Webは、比較的大きいセッション属性を独立したクラスタ化キャッシュ・エントリに分離します。そのため、アプリケーションでそのような大きいセッション属性に関連するコストが発生するのは、対象の属性へのアクセスまたは属性の更新が実際に実行されたときのみに限定されます。また、Coherence*WebではCoherenceのデータ管理機能が活用されるため、ニア・キャッシング、NIOバッファ・キャッシング、ディスクベースのオーバーフローなど、基礎となるすべての機能をセッション属性管理に利用できます。

図5-5は、セッション・サイズに応じたパフォーマンスを示しています。各セッションは、10個の10文字の文字列と0 - 4個の10,000文字の文字列で構成されています。各HTTPリクエストでは、小さい属性1つと、大きい属性1つ(セッション内に大きい属性が存在する場合)が読み取られ、リクエストの50%でこれらの属性が更新されます。2つのサーバーから成るクラスタで、テストが実行されました。トラディショナル・モデルとモノリシック・モデルのパフォーマンスはだいたい同じである点に注目してください。文字列のシリアライズ/デシリアライズでは最小限のCPUリソースしか消費されないため、実際に使用された属性のみのデシリアライズによるパフォーマンスの向上はほとんどありません。スプリット・モデルによるパフォーマンスの向上率は、セッション・サイズが1MB(大きな文字列100個)に達するまでに37:1を超えます。特筆すべき点として、クラスタ環境では、基本的なデータにしかアクセスしないアプリケーション・リクエストについては、スケーラビリティとパフォーマンスの向上の可能性があります。これは、セッションを妥当なサイズに抑える必要がある理由の1つとなっています。

図5-5 セッション・サイズに応じたパフォーマンス

もう1つの最適化方法は、セッション属性クラスでの一時データ・メンバーの使用です。Javaのシリアライズ・ルーチンは、一時フィールドを無視するため、セッション属性がクラスタ化されているか、単一のクラスタ・メンバーに分離されているかを制御するための非常に便利な手段になります。これは、データが他のデータソースから遅延ロードされる(したがって、サーバーのフェイルオーバー・プロセスでは再計算される)場合や、絶対的な信頼性を必要としないシナリオで役立ちます。セッション状態の一部が失われてもアプリケーションに支障がなく、ユーザーへの影響がゼロ(または許容範囲内)の場合は、パフォーマンス上のメリットを考慮する価値がある場合があります。同様に、スケールの大きいアプリケーションでは、セッションの喪失をセッションのタイムアウトとして処理し、ユーザーにアプリケーションへの再ログインを要求することもめずらしくありません(これには、アプリケーション・セッションの状態に関するユーザーの期待を適切に設定するという暗黙的なメリットがあります)。

スティッキー・ロード・バランシングは重要な役割を果たします。なぜなら、セッションの状態はクラスタ全体でグローバルに参照可能なわけではないためです。スケールの大きいクラスタでは、ユーザー・リクエストは、通常、一連のステートレス・ロード・バランサを介してアプリケーション層に入り、これらのバランサによって、Microsoft IISやApache HTTP Serverなどの一連のスティッキー・ロード・バランサに(ある程度ランダムに)再分配されます。これらのスティッキー・ロード・バランサは、リクエストのHTTPヘッダーを解析して、そのリクエストを処理しているサーバー・インスタンスを(セッションCookieに指定されたサーバーIDに基づいて)判別するという、より集中的な計算を必要とする処理を行います。なんらかの理由でリクエストが誤ってルーティングされた場合、セッションの整合性が失われます。たとえば、一部のロード・バランサでは、大量(64KB超など)のPOSTデータを含むリクエストのHTTPヘッダーが解析されず、このようなリクエストが適切なサーバー・インスタンスにルーティングされないことがあります。ルーティング障害のその他の原因として、セッションCookie内のサーバーIDの破損や形式の誤りなどがあります。これらの問題のほとんどは、ロード・バランサを適切に選択するとともに、可能な場合はアプリケーションの設計で耐久力を組み込むこと(たとえば、大きなPOSTリクエストではいずれもセッション状態に対するアクセスや変更を行わないなど)によって対処できます。

スティッキー・ロード・バランシングはCoherence*Webのパフォーマンスを促進しますが、必須ではありません。Coherence*WebはCoherenceデータ管理プラットフォームを基盤としているため、すべてのセッション・データがクラスタ全体でグローバルに参照可能です。Coherence*Webの標準的なデプロイメントでは、セッション・データがニア・キャッシュ・トポロジに配置されます。このトポロジでは、パーティション化されたキャッシュの使用により、膨大なデータがスケーラビリティとフォルト・トレランスのある方法で管理されるとともに、各アプリケーション・サーバーJVMのローカル・キャッシュによって、よく使用されるセッション状態へのアクセスが迅速化されます。スティッキー・ロード・バランサはCoherence*Web使用時に必須というわけではありませんが、このバランサの使用によって2つの重要なメリットが得られます。ニア・キャッシュ・テクノロジが使用されるため、ユーザー・リクエストが常に同じサーバーにルーティングされるのであれば、セッション属性への読取りアクセスが迅速化されます。なぜなら、ローカル・キャッシュを使用することで、コストのかかるセッション属性のデシリアライズとネットワーク転送が不要になるためです。また、スティッキー・ロード・バランシングによって、Coherenceで並行性をローカルで管理できるようになります。ユーザー・リクエストが別のサーバーにリバランスされるときにのみ、セッション・ロックが転送されます。

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

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

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

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アプリケーション間でのセッション・データ共有の禁止」を参照してください。

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

同じCoherenceクラスタに属する複数のJava EEアプリケーションであっても、HTTPセッション・データを共有しないようにすることが必要な場合があります。たとえば、Enterprise JavaBeans (EJB)層でキャッシュ・データを共有する2つのアプリケーションHRPortalおよびInWebがあり、それぞれで使用するセッション・データは互いに別であるとします。この2つのアプリケーションにとって、1つのCoherenceクラスタに属していることは必要ですが、セッション・データについては同じクラスタ・サービスを使用しないようにする必要があります。これを実行する方法の1つは、ApplicationScopeControllerインタフェースを使用して、アプリケーションの属性のスコープを定義することです。「セッション属性スコープ設定」でこの手法について説明します。もう1つの方法は、アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定することです。

アプリケーションごとに固有のセッション・キャッシュ・サービス名を指定する手順は、次のとおりです。

1. アプリケーションの各default-session-cache-config.xmlファイルで、<service-name/>要素を探します。

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

3. 変更したdefault-session-cache-config.xmlファイルをアプリケーションに組み込みます。

例5-2は、あるHRPortalアプリケーションのdefault-session-cache-config.xmlファイルの例です。HRPortalアプリケーションとInWebアプリケーションとの間でセッション・データを共有しないようにするには、レプリケートするスキームの<service-name>要素の名前をReplicationSessionsMiscHRPに変更します。分散スキームの<service-name>要素の名前をDistributedSessionsHRPに変更します。

例5-2 アプリケーション間でセッション・データを共有しないようにするための構成

<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>

5.2.1.2 複数のキャッシュ構成の操作

Coherence*Webで実行している複数のアプリケーションを操作する場合、それらに複数の異なるキャッシュ構成を設定できます。この場合、キャッシュ・サーバーのキャッシュ構成には、記憶域を有効化して実行しているか記憶域を無効化して実行しているかに関係なく、これらのキャッシュ構成の和を含める必要があります。これにより、同じキャッシュ・クラスタでそれらのアプリケーションをサポートできます。

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

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に設定します。

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

複数の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アプリケーションの名前を構成します。

5.2.2.1 複数のアプリケーション間におけるセッション情報の共有

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-3は、web.xmlファイルで指定されたGlobalScopeControllerインタフェースを示しています。

例5-3 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>

5.3 クラスタ・ノード分離

Coherence*Webをデプロイする方法はいくつかあります。デプロイメント・オプションについて決定するときの考慮事項の1つは、クラスタ・ノード分離です。クラスタ・ノード分離の考慮事項は次のとおりです。

- アプリケーション・サーバーJVMに作成されるCoherenceノードの数

- Coherenceライブラリのデプロイ先

アプリケーションには、アプリケーション・サーバー・スコープ、EARスコープ、またはWARスコープを設定できます。この項では、これらの考慮事項について説明します。これらの各オプションに対するXML構成の詳細は、「Coherence*Webの記憶域モードの構成」を参照してください。

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

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

図5-6に、クラスタ・ノード(アプリケーション・サーバー・インスタンス)が2つのアプリケーション・サーバー・スコープ設定クラスタを示します。Coherence*Webは各インスタンスのクラスパスにデプロイされているため、各インスタンスはCoherenceノードと見なすことができます。各ノードには2つのEARファイルが含まれ、それぞれのEARファイルには2つのWARファイルが含まれます。各インスタンスで実行されるすべてのアプリケーションは、同じCoherenceライブラリおよびクラスを共有します。

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

WebLogic Serverでは、すべてのCoherence*Web対応アプリケーションがアプリケーション・サーバー・スコープを持ちます。WebLogic Serverのアプリケーション・サーバー・スコープ設定クラスタ・ノードのXML構成要件の詳細は、「Coherence*Webの記憶域モードの構成」を参照してください。

すべてのCoherence*Web対応アプリケーションがアプリケーション・サーバー・スコープを持ちます。アプリケーション・サーバー・スコープはGlassFish Serverでは使用できません。

注意:

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

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

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

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

この構成では、EARファイルごとにデプロイしたすべてのアプリケーションが1つのCoherenceノードに属します。この構成では、Coherence*Webを使用するデプロイ済EARファイルごとに1つのCoherenceノードが作成されます。Coherenceライブラリ(coherence.jar)がアプリケーションのクラスパスにデプロイされるので、ロードされるCoherenceクラスのコピーはEARファイルごとに1つです。EARファイル内のすべてのWebアプリケーションが同じクラスタ・ノードを使用するので、いずれかのWebアプリケーションに不具合があるとEARファイル内のすべてのWebアプリケーションが影響を受けます。

図5-7は、4つのEARスコープ設定クラスタ・ノードを示します。Coherence*Webは各EARファイルにデプロイされているため、各EARファイルがクラスタ・ノードとなります。各EARファイル内で実行されるすべてのアプリケーションは、同じCoherenceライブラリおよびクラスへのアクセス権を持ちます。

図5-7 EARスコープ設定クラスタ

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

EARスコープ設定クラスタ・ノードのXML構成要件の詳細は、「EARスコープ設定クラスタ・ノードの構成」を参照してください。

注意:

この構成は、WebLogic Serverプラットフォームで実行されているCoherence*Webアプリケーションでは使用できません。WebLogic Serverプラットフォームで実行されているアプリケーションに対して可能なのは、アプリケーション・サーバー・スコープ設定のみです。

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

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

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

図5-8に、アプリケーション・サーバー内のWARファイルの2つの異なる構成を示します。各WARファイルにはCoherence*Web(およびCoherence)のコピーが含まれているため、これはクラスタ・ノードと見なすことができます。

図5-8 WARスコープ設定クラスタ

WARスコープ設定クラスタ・ノードのXML構成要件の詳細は、「WARスコープ設定クラスタ・ノードの構成」を参照してください。

注意:

この構成は、WebLogic Serverプラットフォームで実行されているCoherence*Webアプリケーションでは使用できません。WebLogic Serverプラットフォームで実行されているアプリケーションに対して可能なのは、アプリケーション・サーバー・スコープ設定のみです。

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

Oracle Coherenceには、HTTPセッションへの同時アクセスを実現する次の構成オプションが用意されています。

- オプティミスティック・ロック: 単一のメンバーまたは複数のメンバーにある複数のスレッドからセッションに同時アクセスできます。ただし、セッションを同時に変更できません。

- 最後の書込みを優先するロック: オプティミスティック・ロックの一種です。これにより、単一のメンバーまたは複数のメンバーにある複数のスレッドからセッションに同時アクセスできます。この場合、最後の書込みが保存されます。これはデフォルトのロック・モードです。

- メンバー・ロック: 同じメンバーにある複数のスレッドからセッションに同時にアクセスし、同時にセッションを変更できます。別々のメンバーにあるスレッドからは同時にアクセスできません。

- アプリケーション・ロック: 同じWebアプリケーション・インスタンスにある複数のスレッドから同時にセッションにアクセスし、同時にセッションを変更できます。別々のWebアプリケーション・インスタンスにあるスレッドからは同時にアクセスできません。

- スレッド・ロック: 単一のメンバーにある複数のスレッドからセッションに同時にアクセスできず、同時にセッションを変更することもできません。

注意:

一般的に、同じクラスタに属するWebアプリケーションは、同じロック・モードおよびスティッキー・セッション最適化設定を使用する必要があります。構成に一貫性がないと、デッドロックが発生することがあります。

Webアプリケーションが使用するセッション・ロッキング・モードを指定するには、coherence-session-locking-modeコンテキスト・パラメータを設定します。表5-1は、コンテキスト・パラメータの値と、それによって指定されるセッション・ロッキング・モードを示しています。coherence-session-locking-modeコンテキスト・パラメータの詳細は、次の項と、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

表5-1 coherence-session-locking-modeコンテキスト・パラメータ値の一覧

ロック・モード

coherence-session-locking-modeの値

オプティミスティック・ロック

optimistic

最後の書込みを優先するロック

none

メンバー・ロック

member

アプリケーション・ロック

app

スレッド・ロック

thread

5.4.1 オプティミスティック・ロック

オプティミスティック・ロック・モードを使用すると、1つ以上のメンバーにある複数のWebコンテナ・スレッドから1つの同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了後、楽観的なアプローチで同時更新を検出して防止します。ConcurrentModificationException例外のスローはセッションがキャッシュにフラッシュされたときに行われ、これはサーブレット・リクエストが処理を終了した後になります。例外を表示するには、コンテナの起動スクリプトでweblogic.debug.DebugHttpSessionsシステム・プロパティをtrueに設定します(例: -Dweblogic.debug.DebugHttpSessions=true)。

オプティミスティック・ロック・モードは、coherence-session-locking-modeパラメータをoptimisticに設定することにより構成できます。

5.4.2 最後の書込みを優先するロック

Coherence*WebとCoherence*Web SPIは、デフォルトで最後の書込みを優先するロックを使用するように構成されています。最後の書込みを優先するロックは、オプティミスティック・ロック・モードの一種です。これを使用すると、1つ以上のメンバーにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスできます。この設定では明示的なロックは使用されず、セッションを変更するHTTPリクエストの完了時に同時更新は防止されません。かわりに、最後の書込み、つまり最終変更によってセッションが変更されます。

最後の書き込みを優先するロック・モードは、coherence-session-locking-modeパラメータをnoneに設定することにより構成できます。この値により、セッションに対して最後の更新が適用される同時変更ができます。

5.4.3 メンバー・ロック

メンバー・ロック・モードを使用すると、同じクラスタ・ノードにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスして変更できますが、別々のメンバーにあるスレッドからは同時にアクセスできません。これは、HTTPセッションを取得したときに、そのセッションのメンバー・レベルのロックを取得することによって実現されます。ロックはHTTPリクエストの完了時に解放されます。メンバー・レベルのロックの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のdistributed-schemeに関する項で<lease-granularityを参照してください。

メンバー・ロック・モードは、coherence-session-locking-modeパラメータをmemberに設定することにより構成できます。

5.4.4 アプリケーション・ロック

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

アプリケーション・ロック・モードは、coherence-session-locking-modeパラメータをappに設定することにより構成できます。

5.4.5 スレッド・ロック

スレッド・ロック・モードでは、一度に1つのメンバーにある1つのスレッドからのみセッションにアクセスし、変更できます。この動作は、セッションの取得時点でHTTPセッションに対するメンバー・レベルのロック、アプリケーション・レベルのロックおよびスレッド・レベルのロックを取得して、リクエストの完了時点でそれらの3つすべてのロックを解放することによって実現します。メンバー・レベルのロックの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のdistributed-schemeに関する項で<lease-granularityを参照してください。

スレッド・ロック・モードは、coherence-session-locking-modeパラメータをthreadに設定することにより構成できます。

5.4.6 HTTPセッションでのロックのトラブルシューティング

HTTPセッション・アクセスに対してメンバー、アプリケーションまたはスレッドのロックを有効にすることは、セッションへのアクセスを必要とする各HTTPリクエストに対して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 Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のオペレーション構成要素に関する項にあるlogging-configの説明を参照してください。

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

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

スティッキー・セッション最適化は、coherence-sticky-sessionsコンテキスト・パラメータをtrueに設定すると有効になります。この設定では、メンバー、アプリケーションまたはスレッドのロックが有効になっている必要があります。

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

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

- インプロセス・トポロジ: ローカル記憶域有効化とも呼ばれます。セッション・データはアプリケーション・サーバーで処理中に保存されます。

- アウトオブプロセス・トポロジ: ローカル記憶域無効化とも呼ばれます。アプリケーション・サーバーはキャッシュ・クライアントとして構成され、専用のJVMがキャッシュ・サーバーとして動作し、クラスタ化データを物理的に保存および管理します。

- Coherence*Extendによるアウトオブプロセス・トポロジ: アプリケーション・サーバー層とキャッシュ・サーバー層との間の通信はCoherence*Extend (TCP/IP)を介して行われます。

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

インプロセス・トポロジは、本番環境での使用にはお薦めできません。主に、開発用とテスト用としてサポートされています。このトポロジは、アプリケーション・サーバーを使用してセッション・データをプロセス内で保存することで、容易に起動して、スモーク・テスト、開発、およびテスト用として高速で実行できます。このトポロジでは、ローカル記憶域が有効化(tangosol.coherence.distributed.localstorage=true)されます。

図5-9に、インプロセス・トポロジを示します。すべてのアプリケーション・サーバーが同じセッション・データ・キャッシュと通信します。

図5-9 インプロセス・デプロイメント・トポロジ

5.5.2 アウトオブプロセス・トポロジ

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

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

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

- アプリケーションとキャッシュ・サーバー層は、独立してスケールできます。アプリケーションの処理能力が不足している場合は、起動するアプリケーション・サーバーの数を増やすだけですみます。セッション記憶域の容量が不足している場合は、起動するキャッシュ・サーバーの数を増やすだけです。

アウトオブプロセス・トポロジは、その柔軟性によって、Oracle Coherenceのデフォルトの推奨トポロジになっています。図5-10に、アウトオブプロセス・トポロジを示します。アプリケーション層の各サーバーは、独自のニア・キャッシュを保持します。これらのニア・キャッシュは、別のキャッシュ・サーバー層で実行されるセッション・データ・キャッシュと通信します。

図5-10 アウトオブプロセス・デプロイメント・トポロジ

5.5.2.1 インプロセス・トポロジからアウトオブプロセス・トポロジへの移行

アプリケーションをインプロセス・トポロジからアウトオブプロセス・トポロジに容易に移行できます。このためには、アプリケーション・サーバーに加えてキャッシュ・サーバーを実行する必要があります。キャッシュ・サーバーを記憶域有効モードで起動し、これがアプリケーション・サーバーで使用しているものと同じセッションおよびキャッシュ構成ファイル(default-session-cache-config.xml)を参照するようにします。記憶域無効モードでアプリケーション・サーバーを起動します。詳細は、「アウトオブプロセス・トポロジへの移行」を参照してください。

5.5.3 Coherence*Extendによるアウトオブプロセス・トポロジ

Coherence*Extendは、クラスタの外部で実行されるExtendクライアント(またはプロキシ)と、1台以上のキャッシュ・サーバーでホストされているクラスタ内で実行される拡張プロキシ・サービスの2つの基本コンポーネントで構成されます。Coherence*Extendによるアウトオブプロセス・トポロジは、アウトオブプロセス・トポロジに似ていますが、アプリケーション・サーバー層とキャッシュ・サーバー層との通信をCoherence*Extend経由(TCP/IP)で行う点が異なります。このシナリオの構成手順は、「Coherence*ExtendによるCoherence*Webの構成」を参照してください。Coherence*Extendの詳細は、『Oracle Fusion Middleware Oracle Coherenceリモート・クライアントの開発』を参照してください。

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

図5-11に、Coherence*Extendによるアウトオブプロセス・トポロジを示します。アプリケーション・サーバー層のサーバー内のニア・キャッシュは、拡張プロキシを使用して、キャッシュ・サーバー層のセッション・データ・キャッシュと通信します。

図5-11 Coherence*Extendによるアウトオブプロセス・デプロイメント・トポロジ

5.5.4 Coherence*ExtendによるCoherence*Webの構成

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を使用する手順は次のとおりです。

1. オプティミスティック・ロック・モードを使用するようにCoherence*Webを構成します(「オプティミスティック・ロック」を参照)。

2. プロキシおよび記憶域JVMのキャッシュ構成ファイルを構成します(「"プロキシJVMと記憶域JVMのキャッシュの構成」を参照)。

3. Web層キャッシュ構成ファイルが1つ以上のプロキシJVMを指定するように変更します(「Web層JVMのキャッシュの構成」を参照)。

5.5.4.1 プロキシJVMと記憶域JVMのキャッシュの構成

セッション・キャッシュ構成ファイル(WEB-INF/classes/default-session-cache-config.xml)は、Coherence*Extendを使用するCoherence*Webセッションのキャッシュ構成ファイルの例です。

プロキシおよびサーバーJVMにはこのファイルを使用します。これには、同じファイルをプロキシJVMと記憶域JVMの両方に使用できるシステム・プロパティのオーバーライドが含まれます。プロキシJVMで使用する場合は、表5-2に示すシステム・プロパティを指定する必要があります。

注意:

WebLogic Serverプラットフォームのアプリケーションを記述しており、カスタマイズしたセッション・キャッシュ構成ファイルを使用している場合は、この構成ファイルをデプロイメントのためのGARファイルにパッケージ化する必要があります。詳細は、カスタム・セッション・キャッシュ構成ファイルの使用方法に関する項を参照してください。

GARファイルのパッケージ化要件の詳細は、『Oracle Fusion Middleware Oracle Coherenceの管理』のWebLogic Server用のCoherenceアプリケーションのパッケージ化に関する項および『Oracle WebLogic Server用Oracle Coherenceアプリケーションの開発』のOracle WebLogic Server用のCoherenceアプリケーションの作成に関する項も参照してください。

表5-2 プロキシJVM用のシステム・プロパティ値

システム・プロパティ名

値

tangosol.coherence.session.localstorage

false

tangosol.coherence.session.proxy

true

tangosol.coherence.session.proxy.localhost

プロキシがバインドされるNICのホスト名またはIPアドレス。

tangosol.coherence.session.proxy.localport

プロキシがバインドされるポートの一意のポート番号。

キャッシュ・サーバーで使用する場合は、表5-3に示すシステム・プロパティを指定します。

表5-3 記憶域JVM用のシステム・プロパティ値

システム・プロパティ名

値

tangosol.coherence.session.localstorage

true

tangosol.coherence.session.proxy

false

例5-4は、記憶域JVMのセッション・キャッシュ構成ファイルの全内容を示しています。

例5-4 default-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 default-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>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.5.4.2 Web層JVMのキャッシュの構成

例5-5に示されているセッション・キャッシュ構成ファイルは、coherence-web.jarファイルにあるdefault-session-cache-config.xmlファイルに基づいています。この例は、Coherence*Extendを使用するCoherence*Webキャッシュ構成ファイルを示しています。Web層JVMは、このキャッシュ構成ファイルを使用する必要があります。次の手順に従います。

Web層のセッション・キャッシュ構成ファイルをインストールする手順は次のとおりです。

1. coherence-web.jarファイルからdefault-session-cache-config.xmlファイルを抽出します。

2. ファイルの<remote-addresses/>セクションに、プロキシJVMのホスト名とIPアドレス、およびポートを追加します。一般には、ロード・バランシングとフェイルオーバーに備えて、すべてのプロキシJVMのホスト名、IPアドレスおよびポートを追加します。

注意:

<remote-addresses>要素には、Webコンテナの接続先となるプロキシ・サーバーがリストされています。デフォルトでは、Webコンテナはランダムにアドレスを選択します(複数のアドレスが構成されている場合)。Webコンテナとプロキシ間の接続が切断されると、コンテナはリスト内の別のプロキシに接続します。

3. ファイル名をdefault-session-cache-config-web-tier.xmlに変更します。

4. このファイルをWebアプリケーションのWEB-INF/classesディレクトリに配置します。WebInstallerを使用してCoherence*Webをインストールした場合は、WebInstallerによって追加されている既存のファイルと置き換えます。

例5-5は、クライアント側のセッション・キャッシュ構成ファイルの全内容を示しています。

例5-5 default-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 default-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>

5.6 遅延取得によるセッションへのアクセス

デフォルトでは、WebInstallerで設定されたWebアプリケーションは、サーブレットまたはフィルタがコールされるたびにセッションを取得します。サーブレットまたはフィルタで実際にセッションが必要であるかどうかに関係なく、セッションは取得されます。これにより、セッションが不要なサーブレットやフィルタを多数実行すると、時間がかかる場合や処理に負担がかかる場合があります。

この動作を防止するには、web.xmlファイルのcoherence-session-lazy-accessコンテキスト・パラメータをtrueに設定して遅延取得を有効にします。サーブレットやフィルタがアクセスを試みたときにのみ、セッションは取得されます。

5.7 HTTPセッションと属性のディストリビューションのオーバーライド

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のレンダリング状態を格納します。一般に、このデータはシリアライズ不能なため、分散できません。セッション・ディストリビューション・コントローラを使用すると、これらの属性を「ローカル」として維持したまま、残りのセッションの属性を分散させることができます。

- セッション・ディストリビューション・コントローラは、非分散システムを分散システムに変換する場合に役立ちます。特に、すべてのセッションとすべての属性の分散コストが検討事項となっている場合は有効です。

5.7.1 セッション・ディストリビューション・コントローラの実装

例5-6は、HttpSessionCollection.SessionDistributionControllerインタフェースの実装例を示しています。この例では、セッションにショッピング・カートがアタッチされているかどうかがテストされます(アタッチされているセッションのみが分散されます)。次に、そのセッションに特定の属性が含まれているかどうかがテストされます。その属性が検出された場合、その属性は分散されません。

例5-6 セッション・ディストリビューション・コントローラの実装例

import com.tangosol.coherence.servlet.HttpSessionCollection;
import com.tangosol.coherence.servlet.HttpSessionModel;

/**
* Sample implementation of SessionDistributionController
*/
public class CustomSessionDistributionController
implements 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);
}
}

5.7.2 セッション・ディストリビューション・コントローラの実装の登録

SessionDistributionControllerの実装を記述したら、coherence-distributioncontroller-classコンテキスト・パラメータを使用して、この実装をアプリケーションに登録できます。このパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

5.8 変更された属性値の検出

デフォルトでは、セッションから取得された属性がリクエストの処理中に変更された場合にCoherence*Webが追跡を行います。これを行うには、最初のシリアライズされたバイナリ・フォームの属性がセッションから取得されたときに、これをキャッシュします。リクエストの処理の最後に、Coherence*Webは現在の属性のバイナリ値と「古い」バージョンのバイナリを比較します。値が一致しない場合、現在の値がキャッシュに書き込まれます。アプリケーションで該当するsetを行わずにセッション属性を変更することはないことがわかっている場合は、coherence-enable-suspect-attributesコンテキスト・パラメータをfalseに設定する必要があります。これにより、メモリー使用率およびニア・キャッシュの最適化が改善されます。

5.9 シリアライズ不可能な属性のローカルな保存

デフォルトでは、Coherence*Webはすべてのセッション属性のシリアライズを試みます。シリアライズできないセッション属性を処理している場合、coherence-preserve-attributesパラメータをtrueに設定することにより、これらをローカルに保存できます。このパラメータでは、セッションのシリアライズ不可属性を取得するためにロード・バランサが必要です。

クライアント(アプリケーション・サーバー)が失敗した場合、属性は失われます。アプリケーションは、この状態から復旧できる必要があります。

このパラメータのデフォルトはfalseです。GlassFishにActiveCacheを使用している場合、GlassFish Serverではローカル・セッションが使用できる必要があるため、この値はtrueに設定します。

coherence-preserve-attributesパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

5.10 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 Fusion Middleware 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ソケット・プロバイダは、すべてのリモート・サービス用にも、個々のリモート・サービス用にも定義できます。

5.11 セッション・キャッシュ構成ファイル名のカスタマイズ

デフォルトでは、Coherence*Webはdefault-session-cache-config.xmlファイル内の情報を使用して、Coherence*Web内でセッション・キャッシュを構成します。web.xmlファイル内のcoherence-cache-configuration-pathコンテキスト・パラメータを指定することにより、別のファイルを使用するようにCoherence*Webに指示できます。次に例を示します。

...
<context-param>
<param-name>coherence-cache-configuration-path</param-name>
<param-value>my-default-session-cache-config-name.xml</param-value>
</context-param>
...

5.12 Coherence*Webのロギングの構成

Coherence*Webでは、Coherenceにより提供されるロギング・フレームワークを使用します。Coherenceは、独自のロギング・フレームワークを持ち、一般的なアプリケーションのロギング環境を提供するlog4j、slf4jおよびJavaロギングの使用もサポートします。システムの重要な部分への影響を軽減するために、Coherenceでのロギングは優先度の低い専用のスレッドで実行されます。ロギングは事前構成されており、必要に応じてデフォルト設定を変更する必要があります。詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のロギングの構成に関する項を参照してください。

Coherence*Webのロギング・レベルは、コンテキスト・パラメータ/システム・プロパティcoherence-session-logger-levelを使用して設定することもできます。これは、JDKロギングを使用するかわりにCoherence*Webのロギング・レベルを設定する方法です。このパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

警告:

JDKロギング・フレームワークを使用するアプリケーションでは、CoherenceもJDKロギングを使用するように構成できます。ただし、ログ・レベルをFINESTに設定すると、ログ・レベル内のセッションIDを公開できることに注意してください。

5.13 同一のセッション・インスタンスへの同時アクセス

この機能は、パッチ・リリースの一部として追加されました。パッチに追加された機能の詳細は、『Oracle Coherenceリリース・ノート』を参照してください。

キャッシュ・デリゲータ・クラスは、分散キャッシュ内のデータ操作(取得、配置および削除)を担当するクラスです。web.xmlファイルの<coherence-cache-delegator-class>コンテキスト・パラメータを使用して、このデータ操作を担当するクラス名を指定します。

このコンテキスト・パラメータで可能な値は、com.tangosol.coherence.servlet.LocalSessionCacheDelegatorクラスなどです。このクラスは、セッション・インスタンスの保存および取得に分散キャッシュが使用される前に、ローカル・キャッシュが使用される必要があることを示しています。このデリゲータは、同一のセッション・インスタンスへの同時アクセスが必要なアプリケーションで有用です。

注意:

PeopleSoftアプリケーションを使用する場合は、この機能を有効にする必要があります。

LocalSessionCacheDelegatorキャッシュ・デリゲータを有効にするには、web.xmlで次の項目を構成する必要があります。

- coherence-cache-delegator-classコンテキスト・パラメータの値をcom.tangosol.coherence.servlet.LocalSessionCacheDelegatorに設定する。

- coherence-preserve-attributesコンテキスト・パラメータをtrueに設定して、シリアライズされていないオブジェクトのセッション・オブジェクトへの保存を許可します。

- coherence-distributioncontroller-classコンテキスト・パラメータの値をcom.tangosol.coherence.servlet.AbstractHttpSessionCollection$HybridControllerに設定します。この値を設定することで、すべてのセッションおよびシリアライズ可能な属性が強制的に分散管理されます。Serializableインタフェースを実装していないすべてのセッション属性は、ローカルのままとなります。このコンテキスト・パラメータを使用するには、coherence-sticky-sessions最適化も有効にする必要があることに注意してください。

例5-7に、web.xmlファイルのキャッシュ・デリゲータの構成例を示します。

例5-7 web.xmlファイルのキャッシュ・デリゲータの構成

...
<context-param>
<param-name>coherence-cache-delegator-class</param-name>
<param-value>com.tangosol.coherence.servlet.LocalSessionCacheDelegator
</param-value>
</context-param>
<context-param>
<param-name>coherence-preserve-attributes</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>coherence-distributioncontroller-class</param-name>
<param-value>com.tangosol.coherence.servlet.AbstractHttpSessionCollection$HybridController</param-value>
</context-param>
...

また、LocalSessionCacheDelegatorをキャッシュ・デリゲータとして使用する場合は、session-cache-config.xmlファイルのニア・キャッシュを構成しないでください。これは、ローカル・セッション・インスタンスが使用されるためです。付録D「ニア・キャッシュのないセッション・キャッシュ構成ファイル」には、ニア・キャッシュ構成を省略したsession-cache-config.xmlファイルの例が示されています。

6 アプリケーションの監視

この章では、提供されているJMX MBeanを使用して、システム上のCoherence*Webのヘルス状態およびパフォーマンスを監視する方法について説明します。また、管理者および開発者が容量の管理や問題のトラブルシューティングを行う際に役立つ複数の事前構成済レポートを提供するJMXベースのレポート・ユーティリティであるReporterの実行方法についても説明します。

この章には次の項が含まれます:

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

- パフォーマンス・レポートの実行

注意:

この項では、Coherence*Web JMXの管理と監視を有効にするために、Coherenceクラスタ化JMXフレームワークがすでに設定されているものとします。このフレームワークを設定するには、『Oracle Fusion Middleware Oracle Coherenceのマネージメント』のJMXを使用してCoherenceを管理する方法に関する項にある構成およびインストールの手順を参照してください。

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

HTTPセッション管理でCoherence*Webを使用しているWebアプリケーションの管理属性および操作は、HttpSessionManagerMBean MBean (com.tangosol.coherence.servlet.management.HttpSessionManagerMBean)から表示できます。

設定中に、Coherence*WebのWebアプリケーションごとにHttpSessionManagerクラスのインスタンスが1つ登録されます。MBean属性の値を表示するには、JConsoleなどの監視ツールを使用できます。このMBeanは、該当のWebアプリケーションを終了すると登録解除されます。

表6-1は、登録のためにMBeanによって使用されるオブジェクト名を示しています。

表6-1 HttpSessionManagerMBeanのオブジェクト名

マネージドBean

オブジェクト名

HttpSessionManager

type=HttpSessionManager, nodeId=cluster node id, appId=web application id

表6-2は、HttpSessionManagerが提供する情報を示しています。操作を表すresetStatistics以外の名前はすべて属性を表します。

MBean属性の中には、次の接頭辞を使用しているものがあります。

- LocalSession: クラスタの一部のメンバーにのみ分散されるセッションを意味します。分散元のサーバーに対して、このセッションはその存続期間中の特定の時点までローカルのままです。

- LocalAttribute: クラスタの一部のメンバーにのみ分散されるセッション属性を意味します。

- Overflow: スプリット・セッション・モデルを使用するときに大型のセッション属性を格納するキャッシュです。

表6-2 HttpSessionManagerから返される情報

属性名

データ
型

説明

AverageReapDuration

long

統計をリセットした時点以降の平均リープ時間(リープ・サイクルが完了するまでの時間)でミリ秒単位。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。

CollectionClassName

String

使用中のHttpSessionCollection実装の完全修飾クラス名。HttpSessionCollectionインタフェースは、HttpSessionModelオブジェクトのコレクションの抽象モデルです。クライアントとサーバー間のセッションの通信方法により、インタフェースはまったく影響を受けません。

FactoryClassName

String

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

LastReapDuration

long

最後のリープ・サイクルの終了に要した時間(ミリ秒単位)。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。

LocalAttributeCacheName

String

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

LocalAttributeCount

Integer

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

LocalSessionCacheName

String

非分散セッションを格納するローカル・キャッシュの名前。この属性がnull値の場合、ローカル・セッション記憶域は無効です。

LocalSessionCount

Integer

ローカル・セッション・キャッシュに格納された非分散セッションの名前。属性値が-1の場合、ローカル・セッション記憶域は無効です。

MaxReapedSessions

long

統計をリセットした時点以降にリープ・サイクルでリープされたセッションの最大数。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。

NextReapCycle

java.lang.Date

java.lang.Dateデータ型で表現した次のリープ・サイクルの時間。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。

OverflowAverageSize

Integer

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

OverflowCacheName

String

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

OverflowMaxSize

Integer

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

OverflowThreshold

Integer

大型の属性向けに確保されている独立したオーバーフロー・キャッシュにシリアライズ形式の属性値を格納する必要がある場合における最小の長さ(バイト数単位)。SplitHttpSessionCollectionモデルが使用されていない場合、属性値は-1となります。

OverflowUpdates

Integer

統計が最後にリセットされてから、オーバーフロー・クラスタ・キャッシュに保存されたセッション属性の更新回数。SplitHttpSessionCollectionモデルが使用されていない場合、属性値は-1となります。

ReapedSessions

long

前回のサイクル中にリープしたセッションの数。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。

ReapedSessionsTotal

long

統計をリセットした時点以降にリープされた期限切れセッションの数。「セッション・リーパー・パフォーマンス統計の取得」を参照してください。

ServletContextCacheName

String

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

ServletContextName

String

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

SessionAverageLifetime

Integer

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

SessionAverageSize

Integer

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

SessionCacheName

String

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

SessionIdLength

Integer

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

SessionMaxSize

Integer

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

SessionMinSize

Integer

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

SessionStickyCount

Integer

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

SessionTimeout

Integer

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

SessionUpdates

Integer

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

resetStatistics (操作)

void

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

図6-1に、JConsole監視ツールに表示されたHttpSessionManager MBeanの属性を示します。

図6-1 JConsole監視ツールに表示されたHttpSessionManager

6.1.1 WebLogic Serverでのアプリケーションの管理および監視

WebLogic Serverでは、HTTPセッション管理にCoherence*Webを使用するWebアプリケーションの管理属性および操作を、WebLogicHttpSessionManagerMBean MBean (com.tangosol.coherence.servlet.management.WebLogicHttpSessionManagerMBean)を介して表示できます。

表6-3は、登録のためにMBeanによって使用されるオブジェクト名を示しています。

表6-3 WebLogicHttpSessionManagerMBeanのオブジェクト名

マネージドBean

オブジェクト名

WebLogicHttpSessionManager

type=WebLogicHttpSessionManager, nodeId=cluster node id, appId=web application id

WebLogicHttpSessionManagerクラスはHttpSessionManagerクラスを拡張します。WebLogicHttpSessionManagerクラスは、表6-2で説明されている情報以外に表6-4にリストされている情報も返します。Enterprise Managerはこの情報を使用してCoherence*Webインスタンスをサーバーに関連付けます。

表6-4 WebLogicHttpSessionManager MBeanから返される情報

属性名

データ
型

説明

ApplicationId

String

WebLogic WebアプリケーションID。

ApplicationName

String

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

ApplicationVersion

String

このWebアプリケーションのバージョン。

DomainName

String

アプリケーションがデプロイされるWebLogicドメインの名前。

IsEar

Boolean

WebアプリケーションがEARファイルのモジュールである場合、trueとなります。

IsListenAddressEnabled

Boolean

HTTPポートがこのサーバーで使用可能な場合、trueとなります。

IsSSLListenPortEnabled

Boolean

HTTPSポートがこのサーバーで使用可能な場合、trueとなります。

ListenAddress

String

サーバーがリスニングするアドレス。

ListenPort

Integer

このサーバーがHTTPリクエストのリスニングを行うポート。

ServerName

String

アプリケーションがデプロイされるWebLogic Serverの名前。

SSLListenPort

Integer

このサーバーがHTTPSリクエストのリスニングを行うポート。

6.2 パフォーマンス・レポートの実行

注意:

Reporterの構成、事前構成済レポートの実行、カスタム・レポートの作成などReporterの詳細は、『Oracle Fusion Middleware Oracle Coherenceのマネージメント』のJMXレポートの使用方法に関する部分の章を参照してください。

Coherenceには、Reporterと呼ばれるJMXベースのレポート・ユーティリティが組み込まれています。Reporterには、管理者および開発者が容量の管理や問題のトラブルシューティングを行う際に役立つ事前構成済レポートが用意されています。これらのレポートは、Coherence*Web向けに特別に調整されています。

- Webセッション記憶域レポート: クラスタのセッション・オブジェクトとデータが格納されるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。

- Webセッション・オーバーフロー・レポート: Webセッション記憶域キャッシュからセッション・オブジェクトおよびデータがオーバーフローできるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。

- Webレポート: クラスタに対するCoherence*Webアクティビティに関する情報を記録します。

- Webサービス・レポート: Coherence*Webアプリケーションを実行するサービスに関する情報を記録します。

Coherence*Webのレポートは、バッチ・レポートの一部として実行します。これらは、report-web-group.xmlバッチ・レポートと包括的report-all.xmlバッチ・レポートの両方で定義されています。それらをカスタム・バッチ・レポートに組み込むこともできます。Coherence*Webのレポートは、デフォルト・レポート・グループ・バッチ・ファイルであるreport-group.xmlでは定義されていません。

デフォルトでは、Reporterによってreport-group.xmlバッチ・レポートが実行されます。かわりにreport-web-group.xml、report-all.xmlまたはカスタム・バッチ・レポートを実行するには、tangosol.coherence.management.report.configurationシステム・プロパティを使用します。例6-1は、プロパティを使用して、実行するレポート・グループ・バッチ・ファイルをreport-web-group.xmlに変更するコマンドラインを示しています。

例6-1 コマンドラインにおけるレポート・グループの指定

java -Dcom.sun.management.jmxremote
-Dtangosol.coherence.management=all
-Dtangosol.coherence.management.remote=true
-Dtangosol.coherence.management.report.autostart=false
-Dtangosol.coherence.management.report.distributed=false
-Dtangosol.coherence.management.report.configuration=reports/report-web-group.xml
-jar coherence.jar

report-web-group.xml、report-all.xmlおよびreport-group.xmlのレポート・グループ・バッチ・ファイルは、coherence.jarファイルのreportsフォルダにあります。

6.2.1 Webセッション記憶域レポート

Webセッション記憶域レポートは、セッション・オブジェクトおよびデータが格納されるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。この統計には、セッション記憶域キャッシュに対して実行された書込み、取得および削除の操作回数、ならびにこれらの処理の所要時間に関する情報が含まれます。

このレポートはタブ区切りのファイルで、名前の先頭はYYYYMMDDHH形式の日付で、-session-storage.txtが付加されます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-session-storage.txtになります。表6-5は、Webセッション記憶域レポートの内容を示しています。

表6-5 Webセッション記憶域レポートの内容

列タイトル

データ
型

説明

Batch Counter

long

関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、ファイルの統合において有用な情報になります。

Cache Name

String

常にsession-storageです。これは、キャッシュ使用率レポートとの一貫性を確保するために使用されます。

Evictions

long

前回のレポート作成以降においてクラスタ全体でキャッシュに対して削除が実行されたセッションの合計数。

Report Time

Date

レポートが作成されたシステム時間。

Tier

String

値はfrontまたはbackです。キャッシュがフロント層(ローカル・キャッシュ)とバック層(リモート・キャッシュ)のどちらに配置されているのかを示します。

TotalFailures

long

前回のレポート作成以降におけるクラスタ全体でのキャッシュに対するセッション記憶域の書込み失敗の合計回数。

TotalGets

long

前回のレポート作成以降におけるクラスタ全体でのセッションの取得操作の合計回数。

TotalGetsMillis

long

前回のレポート作成以降においてクラスタ全体でセッションを取得するためにget()コールするたびに要した時間(GetsMillis)の合計(ミリ秒単位)。

TotalHits

long

前回のレポート作成以降におけるクラスタ全体のセッション・ヒットの合計回数。

TotalHitsMillis

long

前回のレポート作成以降においてクラスタ全体でセッション記憶域に対するヒットしたget()コールの所要時間(HitsMillis)の合計(ミリ秒単位)。

TotalMisses

long

前回のレポート作成以降におけるクラスタ全体でのキャッシュ・ミスを返すセッションの取得操作の合計回数。

TotalMissesMillis

long

前回のレポート作成以降においてクラスタ全体でセッション記憶域に対するミスしたget()コールの所要時間(MissesMillis)の合計(ミリ秒単位)。

TotalPrunes

long

前回のレポート作成以降においてクラスタ全体でセッション記憶域キャッシュが削除された回数の合計。

TotalPrunesMillis

long

前回のレポート作成以降においてクラスタ全体でセッション記憶域キャッシュを削除するための削除操作に要した時間(PrunesMillis)の合計(ミリ秒単位)。

TotalPuts

long

前回のレポート作成以降におけるクラスタ全体でのセッションの更新(書込み操作)の合計回数。

TotalPutsMillis

long

前回のレポート作成以降においてクラスタ全体でセッションを更新するためにput()コールするたびに要した時間(PutsMillis)の合計(ミリ秒単位)。

TotalQueue

long

クラスタ全体におけるセッション記憶域キャッシュのキュー・リンクの合計。

TotalWrites

long

前回のレポート作成以降においてクラスタ全体のキャッシュに対する外部キャッシュ記憶域に書き込まれたセッションの合計数。

TotalWritesMillis

long

前回のレポート作成以降においてクラスタ全体で外部キャッシュ記憶域を更新するための書込み操作を行うたびに要した時間(WritesMillis)の合計(ミリ秒単位)。

6.2.2 Webセッション・オーバーフロー・レポート

Webセッション・オーバーフロー・レポートは、セッション・オブジェクトおよびデータのオーバーフローが格納されるキャッシュとクラスタとの間のアクティビティに関する統計を記録します。この統計には、セッション・オーバーフロー・キャッシュに対して実行された書込み、取得および削除の操作回数、ならびにこれらの処理の所要時間に関する情報が含まれます。

このレポートはタブ区切りのファイルで、名前の先頭はYYYYMMDDHH形式の日付で、-cache-session-overflow.txtが付加されます。たとえば、2010年1月31日午後1時に作成されたファイルの名前は、2010013113-cache-session-storage.txtになります。表6-6は、Webセッション・オーバーフロー・レポートの内容を示しています。

表6-6 Webセッション・オーバーフロー・レポートの内容

列タイトル

データ
型

説明

Batch Counter

long

関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、 ファイルの統合において有用な情報になります。

Cache Name

String

常にsession-overflowです。これは、キャッシュ使用率レポートとの一貫性を確保するために使用されます。

Evictions

long

前回のレポート作成以降においてクラスタ全体でキャッシュに対して削除が実行されたセッション・オーバーフローの合計回数。

Report Time

Date

レポートが実行されたシステム時間。

Tier

String

値はfrontまたはbackです。キャッシュがフロント層(ローカル・キャッシュ)とバック層(リモート・キャッシュ)のどちらに配置されているのかを示します。

TotalFailures

long

前回のレポート作成以降におけるクラスタ全体のキャッシュに対するセッション・オーバーフロー記憶域の書込み失敗の合計回数。

TotalGets

long

前回のレポート作成以降におけるクラスタ全体でのセッション・オーバーフローの取得操作の合計回数。

TotalGetsMillis

long

前回のレポート作成以降においてクラスタ全体でセッション・オーバーフローを取得するためにget()コールするたびに要した時間(GetsMillis)の合計(ミリ秒単位)。

TotalHits

long

前回のレポート作成以降におけるクラスタ全体のセッション・オーバーフロー・ヒットの合計回数。

TotalHitsMillis

long

前回のレポート作成以降においてクラスタ全体でセッション・オーバーフローに対するヒットしたget()コールの所要時間(HitsMillis)の合計(ミリ秒単位)。

TotalMisses

long

前回のレポート作成以降におけるクラスタ全体でのキャッシュ・ミスを返すセッション・オーバーフローの取得操作の合計回数。

TotalMissesMillis

long

前回のレポート作成以降においてクラスタ全体でセッション・オーバーフローに対するミスしたget()コールの所要時間(MissesMillis)の合計(ミリ秒単位)。

TotalPrunes

long

前回のレポート作成以降においてクラスタ全体でセッション・オーバーフロー・キャッシュが削除された回数の合計。

TotalPrunesMillis

long

前回のレポート作成以降においてクラスタ全体でセッション・オーバーフロー・キャッシュを削除するための削除操作に要した時間(PrunesMillis)の合計(ミリ秒単位)。

TotalPuts

long

前回のレポート作成以降におけるクラスタ全体でのセッション・オーバーフロー(書込み操作)の合計回数。

TotalPutsMillis

long

前回のレポート作成以降においてクラスタ全体でセッション・オーバーフローを更新するためにput()コールするたびに要した時間(PutsMillis)の合計(ミリ秒単位)。

TotalQueue

long

クラスタ全体におけるセッション・オーバーフロー・キャッシュのキュー・リンク・サイズの合計。

TotalWrites

long

前回のレポート作成以降においてクラスタ全体のキャッシュに対する外部キャッシュ記憶域に書き込まれたセッション・オーバーフローの合計回数。

TotalWritesMillis

long

前回のレポート作成以降においてクラスタ全体で外部セッション・オーバーフロー記憶域を更新するための書込み操作を行うたびに要した時間(WritesMillis)の合計(ミリ秒単位)。

6.2.3 Webレポート

Webレポートは、クラスタに対するCoherence*Webアクティビティに関する情報を記録します。このレポートはタブ区切りのファイルで、名前の先頭はYYYYMMDDHH形式の日付と時間で、-web.txtが付加されます。たとえば、2009年1月1日午前2時に作成されたファイルの名前は、2009013102-web.txtになります。表6-7は、Webレポートの内容を示しています。

表6-7 Webレポートの内容

列

データ
型

説明

Application

String

アプリケーション名。

Batch Counter

long

関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、 ファイルの統合において有用な情報になります。

Current Overflow Updates

long

前回のレポート作成以降におけるオーバーフロー更新の回数。

Current Session Updates

long

前回のレポート作成以降におけるセッション更新の回数。

LocalAttributeCount

long

ノード上の属性数。

LocalSessionCount

long

ノード上のセッション数。

Node Id

integer

ノード識別子。

OverflowAvgSize

float

属性オーバーフローの平均サイズ。

OverflowMaxSize

long

属性オーバーフローの最大サイズ。

OverflowUpdates

long

統計を最後にリセットした時点以降の属性オーバーフロー更新の合計回数。

Report Time

Date

レポートが作成されたシステム時間。

SessionAverageLifetime

float

セッションがアクティブである平均時間(秒単位)。

SessionAverageSize

float

セッションの平均サイズ。

SessionMaxSize

long

セッションの最大サイズ。

SessionMinSize

long

セッションの最小サイズ。

SessionStickyCount

long

ノード上のスティッキー・セッションの数。

SessionUpdateCount

long

統計を最後にリセットした時点以降のセッション更新の回数。

6.2.4 Webサービス・レポート

Webサービス・レポートは、 Coherence*Webアプリケーションを実行するサービスに関する情報を提供します。このレポートは、処理済のリクエスト、失敗したリクエスト、未処理のリクエスト、処理済のタスク、失敗したタスクおよび未処理のタスクに関する情報を記録します。Request CountおよびTask Countは、サービスのパフォーマンスとスループットの確認に有用です。RequestPendingCountおよびTask Backlogは、容量の問題やブロックされたプロセスの特定に有用です。Task Hung Count、Task Timeout Count、Thread Abandoned Count、Request Timeout Countは、システムで発生した実行の失敗回数を示します。

このレポートはタブ区切りのファイルで、名前の先頭はYYYYMMDDHH形式の日付と時間で、-web-session-service.txtが付加されます。たとえば、2009年1月1日午前2時に作成されたファイルの名前は、2009013102-web-session-service.txtになります。表6-8は、Webサービス・レポートの内容を示しています。

表6-8 Webサービス・レポートの内容

列タイトル

データ
型

説明

Batch Counter

Long

関連ファイルの情報の統合に役立つ順次カウンタ。この値は、Reporterを再起動する場合や、ノード全体での一貫性がない場合にリセットされますが、 ファイルの統合において有用な情報になります。

Node Id

String

数値のノード識別子。

Refresh Time

Date

サービス情報がリモート・ノードから更新されたシステム時間。

Request Count

Long

前回のレポート作成以降におけるCoherence*Webアプリケーションによるリクエストの数。

RequestPendingCount

Long

レポート実行時点におけるCoherence*Webアプリケーションによる保留中リクエストの数。

RequestPendingDuration

Long

レポート実行時点におけるCoherence*Webアプリケーションの保留中リクエストの待機時間。

Request Timeout Count

Long

前回のレポート作成以降におけるCoherence*Webアプリケーションによるリクエスト・タイムアウトの数。

Report Time

Date

レポートが実行されたシステム時間。

Service

String

サービス・ファイルと情報をマージする場合にサービス名として使用される静的値(DistributedSessions)。

Task Backlog

Long

レポート作成時点におけるCoherence*Webアプリケーションの未処理タスクの数。

Task Count

Long

前回のレポート作成以降におけるCoherence*Webアプリケーションによって実行されたタスクの数。

Task Hung Count

Long

前回のレポート作成以降におけるCoherence*Webアプリケーションによってハングしたタスクの数。

Task Timeout Count

Long

前回のレポート作成以降におけるCoherence*Webアプリケーションによるタスク・タイムアウトの数。

Thread Abandoned Count

Long

前回のレポート作成以降におけるCoherence*Webアプリケーションによって破棄されたスレッドの数。

7 期限切れHTTPセッションのクリーンアップ

この章では、セッション・リーパーの構成および使用方法について説明します。セッション・リーパーは、セッションのタイムアウト時に使用されていないと判断されたセッションを破棄します。

この章には次の項が含まれます:

- セッション・リーパーの理解

- セッション・リーパーの構成

- セッション・リーパー・パフォーマンス統計の取得

- セッション・リーパーのセッション無効化の例外の理解

Coherence*Webセッション管理モジュールの一環として、期限切れのHTTPセッションは最終的にセッション・リーパーによってクリーンアップされます。セッション・リーパーは、JVMのガベージ・コレクション(GC)機能に似たサービスを提供します。つまり、セッションのタイムアウト時に使用されていないと判断されたセッションを破棄する役目を担います。

各HTTPセッションには、有効期限がいつ切れたかを判定する2つの情報が保持されます。1つ目は、そのセッションを最後に使用したアクティビティのタイムスタンプを示すLastAccessedTimeセッション・プロパティです。2つ目は、アクティビティがない状態でのセッション存続時間を指定するMaxInactiveIntervalセッション・プロパティです。一般に、このプロパティの値は30分に指定されます。MaxInactiveIntervalプロパティは、デフォルトでCoherence*Webに対して構成された値に設定されますが、セッションごとに変更することも可能です。

サーバーがHTTPリクエストを受信したときに、そのリクエストに関連付けられたHTTPセッションがある場合は、その都度セッションのLastAccessedTimeプロパティが現在の時刻に自動的に更新されます。そのセッションは、関連するリクエストが送信され続けるかぎり存続します。ただし、MaxInactiveIntervalプロパティで指定された時間の間、アクティビティがないと、そのセッションは期限切れとなります。セッションの期限切れは受動的に、すなわち時間の経過によってのみ発生します。Coherence*Webセッション・リーパーは、期限切れとなったセッションをスキャンし、見つかった場合はそれらを破棄します。

7.1 セッション・リーパーの理解

セッション・リーパーは、次の3つの基本的な質問に対応して構成します。

- どのサーバーでリーパーを実行するか

- どのくらいの頻度でリーパーを実行するか

- リーパーを実行するときに、どのサーバー上で期限切れのセッションを検出するか

セッション・リーパーは、Coherence*Webを実行するすべてのアプリケーション・サーバーで実行されます。つまり、キャッシュ・サーバーで構成される個別のキャッシュ層を提供するようにCoherenceが構成されている場合、セッション・リーパーはそれらのキャッシュ・サーバー上では実行されません。

デフォルトでは、セッション・リーパーはすべてのアプリケーション・サーバーで同時に実行されるため、期限切れのセッションを特定してクリーンアップするためのワークロードをすべてのサーバーで共有できます。coherence-reaperdaemon-cluster-coordinatedコンテキスト・パラメータを使用すると、一度に1台のサーバーのみが実際のリープを実行するようにクラスタ内のリープを調整しますが、このオプションを使用することはお薦めできません。また、このオプションは、Coherence*Extendトポロジを使用しているCoherence*Webには使用できません。

スティッキー最適化(coherence-sticky-sessions)も有効化されている場合は、coherence-reaperdaemon-cluster-coordinatedコンテキスト・パラメータを使用しないでください。リープは一度に1台のサーバーによってのみ実行されるため、他のノードが所有するセッションはリープできません。したがって、クラスタに追加されたノードが多くなるほど、セッションのリープにかかる時間は長くなります。また、クラスタ内のノードでリープの所有権がどのように巡回するのかは制御されません。別のノードに渡される前に、1つのノードが長時間にわたってリープ・ノードとなることがあります。その間は、そのノードのセッションのみがリープされます。

セッション・リーパーは、リープ・サイクルと呼ばれる一定の期間(デフォルトは5分)にわたってすべてのセッションをスキャンするように構成されます。このリープ・サイクルの長さはcoherence-reaperdaemon-cycle-secondsコンテキスト・パラメータで指定します。この設定は、セッション・リーパーの動作の積極性を示します。サイクルの長さが短すぎると、セッション・リーパーはリソースを余分に使用するだけで、特別な効果はもたらしません。サイクルの長さが長すぎると、期限切れセッションがCoherenceキャッシュ内のヒープ領域を不要に使用することになります。多くの場合、期限切れになったセッションを即座にクリーンアップすることよりも、リソースの使用量を減らすことの方がはるかに多く望まれます。したがって、デフォルトの5分というサイクルは、クリーンアップの迅速性と最小限のリソース使用量という両方の点をバランスよく保つことのできる長さです。

リープ・サイクルの期間中、セッション・リーパーは期限切れのセッションをスキャンします。ほとんどの場合、セッション・リーパーはクラスタ全体のすべてのHTTPセッションをスキャンするよう構成されますが、単一層トポロジに適用できる最適化も用意されています。単一層トポロジでは、記憶域が有効でアプリケーション・サーバーも実行しているCoherenceクラスタ・メンバーによってすべてのセッションが管理される場合、セッションの記憶域はアプリケーション・サーバーと同じ場所に配置されます。したがって、各アプリケーション・サーバーでは、ローカルに格納されるセッションしかセッション・リーパーがスキャンしないという可能性もあります。この動作は、coherence-reaperdaemon-assume-locality構成オプションをtrueに設定すると有効にできます。

同じ場所に配置されたセッションのみをスキャンするか、すべてのセッションをスキャンするかにかかわらず、セッション・リーパーは次のCoherenceデータ・グリッドの高度な機能を使用して、非常に効率的な方法でセッションをスキャンします。

- セッション・リーパーは、カスタムのValueExtractor実装を使用してデータ・グリッドに期限切れセッションの検索を委譲します。このValueExtractorは、BinaryEntryインタフェースを利用するため、セッションをデシリアライズしなくても、そのセッションが期限切れかどうかを判別できます。そのため、期限切れセッションの選択を他のパラレル問合せとまったく同じようにデータ・グリッドに委譲して、記憶域が有効なCoherenceメンバーで非常に効率的な方法で実行できるようになります。

- セッション・リーパーは、com.tangosol.net.partition.PartitionedIteratorクラスを使用してメンバーごとに自動問合せを行います。またこの問合せは、大規模クラスタのハーモニックを回避するランダムな順序で実行されます。

記憶域が有効な各メンバーは、すべての期限切れセッションを非常に効率的にスキャンでき、リーパー・サイクルごとに各アプリケーション・サーバーで必要となるスキャンも一度のみですみます。そのため、デフォルトのセッション・リーパー構成は、1台以上のサーバーで構成されるアプリケーション・サーバー・クラスタで効果的に機能します。

セッション・リーパーは、セッションをパラレルでもシリアルでも無効化できます。デフォルトでは、セッションはパラレルに無効化されます。これにより、セッションは適時に無効化されます。ただし、同時スレッドが多数あるためにアプリケーション・サーバーJVMのシステム負荷が高い場合は、シリアルに無効化するオプションを選択できます。リーパーがセッションをシリアルに無効化するように構成するには、coherence-reaperdaemon-parallelコンテキスト・パラメータをfalseに設定します。

Coherence*Webはワーク・マネージャを使用して、パラレル・リープを実行するスレッドを取得します。WebLogic Serverはデフォルトのワーク・マネージャ、wm/CoherenceWorkManagerを定義し、これの使用を試みることになります。ワーク・マネージャがその名前で定義されていない場合は、Coherenceで実装されているデフォルトのワーク・マネージャを使用します。

セッション・リーパーがアプリケーション・サーバーのスムーズな運用に影響しないよう、セッション・リーパーの作業は小さく分割され、リープ・サイクル全体にわたって分散されるようにスケジュールされます。セッション・リーパーは、スケジューリングが必要な作業量を認識する必要があるため、以前のサイクルで実行した作業量の統計を維持し、新しいリープ・サイクルの統計ほど重視されるように統計的重みづけを使用します。このようにセッション・リーパーが作業を分割する理由には、次のものがあります。

- セッション・リーパーが同時に実行してCPU使用率が高くなると、ユーザーに対するアプリケーションの応答性が低下する可能性があります。一度に実行する作業を細分化することで、アプリケーションの応答性は維持されます。

- Coherence*Webの主なパフォーマンス・イネーブラの1つは、Coherenceのニア・キャッシュ機能です。期限切れとなったセッションは、クリーンアップするために同じニア・キャッシュを介してアクセスされるため、期限切れとなるセッションが多すぎたり、期限切れにするタイミングが早すぎたりすると、アプリケーション・サーバーで使用されるはずのセッションがキャッシュから削除され、パフォーマンスの低下を招く可能性があります。

セッション・リーパーは、デフォルトの構成を採用した場合でも、次の方法で効率的にジョブを実行します。

- できるだけ多くの作業をデータ・グリッドに委譲します。

- 一度に1つのメンバーにのみ作業を委譲します。

- デシリアライズを行わずにデータ・グリッドで期限切れセッションを検出できるようにします。

- CPUサイクルの使用量を制限します。

- パフォーマンス上の理由でCoherence*Webが依存しているニア・キャッシュのキャッシュ・スラッシングを回避します。

7.2 セッション・リーパーの構成

ここでは、セッション・リーパーのデフォルト構成をチューニングする際の推奨事項を示します。

- アプリケーションをインプロセス・トポロジでデプロイする場合は、coherence-reaperdaemon-assume-locality構成オプションをtrueに設定します。

- アプリケーション・サーバーはいずれも期限切れセッションをスキャンするようになっているため、クラスタ内のアプリケーション・サーバーが10台を超えている場合は、coherence-reaperdaemon-cycle-seconds構成オプションの値を増やすことをお薦めします。アプリケーション・サーバーの数が増えるほど、サイクルは長くなる可能性があります。たとえば、サーバーが200台ある場合、妥当なリーパー・サイクルは30分といえます(この場合はcoherence-reaperdaemon-cycle-seconds構成オプションを1800に設定します)。

7.3 セッション・リーパー・パフォーマンス統計の取得

HttpSessionManagerMBeanWebは、セッション・リーパーのパフォーマンス統計として使用される属性を提供します。これらの統計には、次のリストに示すように、リープ・サイクルの平均継続時間、リープしたセッションの数、次のリープ・サイクルまでの時間が含まれます。

- AverageReapDuration: 統計をリセットした時点以降における平均リープ時間(リープ・サイクルが完了するまでの所要時間)で単位はミリ秒。

- LastReapDuration: 前回のリープ・サイクルが完了するまでの所要時間(ミリ秒単位)。

- MaxReapedSessions: 統計をリセットした時点以降における1回のリープ・サイクルでリープしたセッションの最大数。

- NextReapCycle: java.lang.Dateデータ型で表現した次のリープ・サイクルの時間。

- ReapedSessions: 前回のサイクル中にリープしたセッションの数。

- ReapedSessionsTotal: 統計をリセットした時点以降にリープされた期限切れセッションの数。

これらの属性の説明は、「JMXによるアプリケーションの管理と監視」の表6-2にもあります。

これらの属性には、JConsoleなどの監視ツールでもアクセスできます。ただし、それらにアクセスする前に、Coherenceクラスタ化JMXフレームワークを設定しておく必要があります。フレームワークの構成およびインストール手順については、『Oracle Fusion Middleware Oracle Coherenceのマネージメント』のJMXを使用してCoherenceを管理する方法に関する項を参照してください。

7.4 セッション・リーパーのセッション無効化の例外の理解

各Coherence*Webインスタンスには、セッション・キャッシュ内のすべてのセッションを定期的に繰り返し、期限切れのセッションをチェックするセッション・リーパーがあります。複数のWebアプリケーションでCoherence*Webを使用している場合は、1つのWebアプリケーションのリーパーが、別のアプリケーションで使用されるセッションを無効にできます。期限切れのセッションをリープしているWebアプリケーションに登録されているセッション・リスナーが実行されます。

セッション属性リスナーは、無効化の際にセッション属性値の取得を試みます。セッション属性が元のWebアプリケーションにのみ存在するクラスに依存している場合、セッション・リーパーでClassNotFound例外がスローされ、記録されます。これらの例外によって、Webアプリケーションまたはアプリケーション・サーバーの障害が発生することはありません。

Coherence*Webは、これらの例外を記録するかどうかを制御するコンテキスト・パラメータcoherence-session-log-invalidation-exceptionsを提供します。デフォルト値はtrueで、例外が記録されます。これらの例外を記録しない場合は、このコンテキスト・パラメータをfalseに設定します。

8 ColdFusionアプリケーションの操作

この章では、ColdFusionアプリケーションで使用するために、Coherence*Webを構成する方法について説明します。ColdFusionは、単純なHTMLページのデータベースへの接続をより容易にするために設計された高速アプリケーション開発プラットフォームです。アプリケーション・サーバーで実行しているCoherence*WebのバージョンがSPIであるか非SPIであるかに関係なく、ColdFusionアプリケーションはセッション管理にCoherence*Webを使用できます。

この章には次の項が含まれます:

- ColdFusionアプリケーションのためのCoherence*Web SPIの構成

- ColdFusionアプリケーションのためのCoherence*Web(非SPI)の構成

8.1 ColdFusionアプリケーションのためのCoherence*Web SPIの構成

WebLogic ServerでColdFusionアプリケーションを実行している場合は、セッション管理にCoherence*Webを使用できます。WebLogic Server上で実行されているColdFusionアプリケーションに対してCoherence*WebのSPIバージョンを有効にする手順は次のとおりです。

1. ColdFusionインストーラで、ColdFusionのWARバージョンを作成します。

2. ColdFusion用にWebLogic Serverを構成するために提供されている手順に従います。

3. WebLogic Serverへの展開ディレクトリ・デプロイメント用のディレクトリにWARファイルを抽出します。

4. 展開されたColdFusion WARファイルの/WEB-INFディレクトリにweblogic.xmlファイルを作成します。Coherence SPIを<library-ref>属性として指定します。

<?xml version="1.0"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
<library-ref>
<library-name>coherence-web-spi</library-name>
</library-ref>
</weblogic-web-app>

5. coherence.jarファイルを展開されたアプリケーションのWEB-INF/libディレクトリにコピーします。

6. cfusion.jarファイルをWEB-INF/cfusion/libディレクトリからWEB-INF/ディレクトリにコピーします。

7. WebLogic Serverインスタンスを起動します。Coherence*Web SPIをWebLogic Serverにデプロイします。SPIは、Coherenceディストリビューションのcoherence\lib\coherence-web-spi.warにあります。

8. ColdFusionアプリケーションをWebLogic Serverインスタンスにデプロイします。

9. Java EEセッション管理を使用するようにColdFusion MXを構成します。

1. 次のURLにあるColdFusion管理ページにアクセスします。

http://<host>:<port>/coldfusion-context-root/CFIDE/administrator.

2. 「Server Sessions」の下にある「Memory Variables」を選択し、「Use Java EE session variables」チェック・ボックスを選択します。

10. 展開したColdFusion WARファイルの下にColdFusionアプリケーションを追加します。
アプリケーションには、sessionmanagement="Yes"と指定したApplication.cfmファイルが必要ですが、ColdFusion構成を使用してセッションを構成しないでください(そのようにしないと例外がスローされます)。Application.cfmファイルには次の行が含まれている必要があります。

<cfapplication sessionmanagement="Yes">

8.2 ColdFusionアプリケーションのためのCoherence*Web(非SPI)の構成

注意:

この項の説明は、Coherence*WebのSPIバージョンを使用しないアプリケーション・サーバーのみを対象としています。

アプリケーション・サーバーに対してCoherence*Webの非SPIバージョンを有効にする手順は次のとおりです。

1. ColdFusionインストーラで、ColdFusionのWARバージョンを作成します。

2. ColdFusion用にJava EEコンテナを構成するために指定された手順に従います。
アプリケーション・サーバーとしてCaucho Resinを実行する場合、Coherence*Web WebInstallerをそのコンテナで実行します。詳細は、「Caucho Resin 3.1.nへのインストール」を参照してください。

3. Coherence*Web WebInstallerを使用して生成されたcfusion.warファイルを設定します。
Java EEアプリケーション用にCoherence*Webをインストールするための追加手順は、「Coherence*Webセッション管理モジュールをインストールする一般的な手順」を参照してください。

4. cfusion.warファイルをWebコンテナにデプロイします。

5. Java EEセッション管理を使用するようにColdFusion MXを構成します。

1. 次のURLにあるColdFusion管理ページにアクセスします。

http://<host>:<port>/coldfusion-context-root/CFIDE/administrator

2. 「Server Sessions」の下にある「Memory Variables」を選択し、「Use J2EE session variables」チェック・ボックスを選択します。

6. ColdFusionアプリケーションを追加します。
アプリケーションには、sessionmanagement="Yes"と指定したApplication.cfmファイルが必要ですが、ColdFusion構成を使用してセッションを構成しないでください(そのようにしないと例外がスローされます)。Application.cfmファイルには次の行が含まれている必要があります。

<cfapplication sessionmanagement="Yes">

9 JSFおよびMyFacesアプリケーションの操作

この章では、JavaServer Faces (JSF)およびMyFacesアプリケーションで使用するために、Coherence*Webを構成する方法について説明します。JSFは、Webアプリケーションのユーザー・インタフェースを構築できるフレームワークです。Apache Software Foundation社のMyFacesは、JSF仕様を拡張するJSFコンポーネントを提供します。MyFacesコンポーネントは、JSF 1.1リファレンス実装などのように互換性のある実装と完全互換性があります。

この章には次の項が含まれます:

- すべてのJSFおよびMyFaces Webアプリケーションに対する構成

- MyFacesを使用する設定済アプリケーションに対する構成

- Mojarraを使用する設定済アプリケーションに対する構成

- MyFacesおよびCoherence SPIを使用する非設定済アプリケーションに対する構成

- MojarraおよびCoherence SPIを使用する非設定済アプリケーションに対する構成

9.1 すべてのJSFおよびMyFaces Webアプリケーションに対する構成

JSFとMyFacesは、セッション・オブジェクトにおけるビューの状態のキャッシュを試みます。この状態データは、デフォルトではシリアライズ可能ですが、可能でない場合もあります。次に例を示します。

- Coherence*Webがシリアライズ不可能なクラスのために、IllegalStateExceptionをレポートした際、Webアプリケーションによってセッションに配置されたすべての属性がシリアライズ可能な場合、レンダリングされたページの非表示フィールドにビューの状態を格納するようにJSF/MyFacesを構成する必要があります。

- Webアプリケーションによってセッション・オブジェクトにシリアライズ不可能なオブジェクトが書き込まれる場合、coherence-preserve-attributesコンテキスト・パラメータをtrueに設定する必要があります。

JSFパラメータのjavax.faces.STATE_SAVING_METHODは、リクエスト間におけるビューの状態が格納される場所を特定します。デフォルトでは、状態はサーブレット・セッションに保存されます。web.xmlファイルのcontext-param行でSTATE_SAVING_METHODパラメータをclientに設定し、レンダリングされたページの非表示フィールドにビュー全体の状態をJSFが格納するようにします。そのように設定しない場合、セッション・オブジェクトにシリアライズ不可能な状態のキャッシュをJSFで試みることがあります。

例9-1は、web.xmlファイルのSTATE_SAVING_METHODパラメータの設定を示しています。

例9-1 web.xmlファイルのSTATE_SAVING_METHODの設定

...
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
...

9.2 MyFacesを使用する設定済アプリケーションに対する構成

Coherence*Web WebInstallerでMyFacesアプリケーションをデプロイする場合(設定済アプリケーションの場合)、MyFacesのバージョンに応じて追加手順の実行が必要な場合もあります。

- Coherence*Web WebInstallerを使用して、1.1.nより古いバージョンのMyFacesで構築されたWebアプリケーションをデプロイする場合、追加手順を実行する必要はありません。

- Coherence*Web WebInstallerを使用して、1.2.xバージョンのMyFacesで構築されたWebアプリケーションをデプロイする場合、web.xmlファイルにorg.apache.myfaces.DELEGATE_FACES_SERVLETコンテキスト・パラメータを追加します。このパラメータにより、デフォルトのjavax.faces.webapp.FacesServletのかわりにカスタム・サーブレットを指定できます。
例9-2は、web.xmlファイルのDELEGATE_FACES_SERVLETコンテキスト・パラメータの設定を示しています。

例9-2 web.xmlファイルのDELEGATE_FACES_SERVLETの設定

...
<context-param>
<param-name>org.apache.myfaces.DELEGATE_FACES_SERVLET</param-name>
<param-value>com.tangosol.coherence.servlet.api23.ServletWrapper</param-value>
</context-param>
...

9.3 Mojarraを使用する設定済アプリケーションに対する構成

Coherence*Web WebInstallerを使用してJSFリファレンス実装(Mojarra)に基づくWebアプリケーションをデプロイしている場合、web.xmlファイルのservlet行でFacesServletクラスを宣言する必要があります。

例9-3 web.xmlファイルにおけるFaces Servletの宣言

...
<servlet>
<servlet-name>Faces Servlet (for loading config)</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
...

9.4 MyFacesおよびCoherence SPIを使用する非設定済アプリケーションに対する構成

Coherence SPIを使用して、MyFacesで構築されたWebアプリケーションをデプロイする場合、追加手順を実行する必要はありません。これは、Coherence*WebとともにMyFacesを実行する場合にお薦めする方法です。

9.5 MojarraおよびCoherence SPIを使用する非設定済アプリケーションに対する構成

Coherence SPIを使用して、JSFリファレンス実装(Mojarra)に基づくWebアプリケーションをデプロイする場合は、何も実行する必要はありません。これは、Coherence*WebとともにJSFを実行する場合にお薦めする方法です。

10 WebLogic PortalでのCoherence*Webの使用方法

この章では、Coherence*WebをWebLogic Portal環境で使用してCoherenceに基づくセッション状態管理を実現する方法を説明します。Coherence*Webを使用すると、クラスタ環境でより高度なデプロイメント・モデル、セッション・モデル、およびロック・モードが可能になります。これらの機能の詳細は、第5章「Coherence*Webセッション管理機能」を参照してください。

この章には次の項が含まれます:

- 必要なパッチのダウンロード(オプション)

- WebLogic PortalでのCoherence*Webの使用方法: 主な手順

- WebLogic PortalでのCoherenceキャッシュ・プロバイダの使用方法

10.1 必要なパッチのダウンロード(オプション)

注意:

Oracle WebLogic Serverリリース10.3.1以降では、パッチは不要です。リリース10.3.1以降を使用している場合、この項はスキップできます。

WebLogic Server 10.3以前を使用している場合、適切なソフトウェア・パッチを、Coherence*Webを使用するWebアプリケーションをホストしているすべてのWebLogic Serverインスタンスに適用します。表10-1は、WebLogic Serverの各バージョンに対応するパッチとCoherenceリリース・レベルを示しています。

表10-1 WebLogic Serverと必要なCoherenceパッチ・リリース・レベル

WebLogic Server 9.2 MP1

WebLogic Server 10.3

WebLogic Server 10.3.1以降

WebLogic Smart Update

パッチID: AJQB

パッチID: 6W2W

パッチは不要です。

パッチはMy Oracle SupportのWebサイト、またはWebLogic ServerのSmart Updateユーティリティを使用してダウンロードできます。

My Oracle Supportからダウンロードする手順は次のとおりです。

1. 次のMy Oracle SupportのWebサイトにアクセスし、パッチを探します。
http://support.oracle.com/

2. 「パッチ」タブを選択し、「単純検索」リンクをクリックします。後続の画面で、適切な値(たとえば、11399293)を使用してパッチ番号/名前の検索を実行します。

3. 表示された検索結果からパッチのzipファイルをダウンロードします。

4. パッチのzipファイルに含まれるREADME.txtを開き、Coherenceパッチの適用手順を確認します。

Smart Updateを使用してダウンロードする手順は次のとおりです。

1. Smart UpdateのガイドでSmart Updateを使用してWebLogic Serverのパッチをインストールする手順を確認してください。
本番環境では、Smart Updateの本番インストールを確認することをお薦めします。

Smart Updateのガイドは次のURLで入手できます。

http://download.oracle.com/docs/cd/E14759_01/doc.32/e14143/toc.htm

2. 「スタート」→「すべてのプログラム」→「Oracle WebLogic」→「Smart Update」を選択し、ログイン・ダイアログ・ボックスを開きます。各自のサポートIDとパスワードを使用してログインします。

図10-1 Oracle Smart Updateにログインするためのダイアログ・ボックス

3. お使いのWebLogic Serverのリリースに対応するパッチをダウンロードし、適用します。図10-2は、Oracle Smart Updateのブラウザを示しています。

図10-2 Oracle Smart Updateのブラウザ

10.2 WebLogic PortalでのCoherence*Webの使用方法: 主な手順

WebLogic PortalでCoherence*Webを使用するには、次の手順を実行します。

1. キャッシュ・サーバーの起動

2. セッション構成の変更(オプション)

3. P13N(パーソナライゼーション)キャッシュ・プロバイダの有効化(オプション)

4. Coherence JARファイルの配置

5. ポータル・アプリケーションでのSPIの参照

6. Coherence*Webセッションの有効化

7. アプリケーションの作成およびデプロイ

10.2.1 キャッシュ・サーバーの起動

キャッシュ・サーバーJVMは、キャッシュしたすべてのデータ(この場合はHTTPセッション状態)の保存と管理専用のCoherence JVMです。WebLogic ServerまたはWebLogic PortalのJVMを起動する前に、1つ以上のキャッシュ・サーバーJVMを起動しておく必要があります。キャッシュ・サーバーを起動するには、次の手順を実行します。

1. キャッシュ・サーバーJVMを起動するためのスクリプトを作成します。Coherence*Webで使用する記憶域対応キャッシュ・サーバーを起動するスクリプトの例を次に示します。特定のJVMのチューニングの詳細は、『Oracle Fusion Middleware Oracle Coherenceでのアプリケーションの開発』のJVMチューニングに関する項を参照してください。

java -server -Xms512m -Xmx512m -cp <Coherence installation dir>/lib/coherence.jar:<Coherence installation dir>/lib/coherence-web-spi.war -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.cacheconfig=C:\Coherence1212\coherence\default-session-cache-config.xml -Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer

このコマンドは、default-session-cache-config.xmlファイルをcoherence-web.jarファイルから抽出してC:\Coherence1212\coherence\ディレクトリに保存していることを前提としています。

2. 前述の手順で説明したスクリプトを使用して、キャッシュ・サーバーJVMを1つ以上起動します。

10.2.2 セッション構成の変更(オプション)

Coherence*Webのキャッシュ・トポロジをカスタマイズするには、(必要に応じて) default-session-cache-config.xmlファイルを変更します。ファイルをsession-cache-config.xmlという名前で保存します。

default-session-cache-config.xmlファイルのデフォルト構成の説明については、付録C「セッション・キャッシュ構成ファイル」を参照してください。

10.2.3 P13N(パーソナライゼーション)キャッシュ・プロバイダの有効化(オプション)

Coherence P13N (パーソナライゼーション)キャッシュ・プロバイダを使用する場合、coherence-wlp.jarファイルをポータル・エンタープライズ・アプリケーションのAPP-INF\libディレクトリにコピーします。

P13N CacheProvider SPI実装およびWeb Services for Remote Portlets (WSRP)フェデレーテッド・ポータルの詳細は、『Oracle Fusion Middleware Oracle Coherenceの統合』を参照してください。

Coherence P13Nキャッシュをデフォルトのキャッシュ・プロバイダとして使用する場合は、ポータル・エンタープライズ・アプリケーションのMETA-INF\p13n-cache-config.xmlファイルで、最初の<cache>要素の前に次の行を追加します。

<default-provider-id>com.tangosol.coherence.weblogic</default-provider-id>

10.2.4 Coherence JARファイルの配置

ポータル・エンタープライズ・アプリケーションのAPP-INF\libディレクトリにcoherence.jarファイルをコピーします。

10.2.5 ポータル・アプリケーションでのSPIの参照

ポータルWebアプリケーションのWEB-INF\weblogic.xmlファイルで、次のようにライブラリ・リファレンス(library-ref)を使用してcoherence-web-spi.warファイルを参照します。

<wls:library-ref>
<wls:library-name>coherence-web-spi</wls:library-name>
</wls:library-ref>

10.2.6 Coherence*Webセッションの有効化

Coherence*Webセッションを有効にするには、ポータルWebアプリケーションのWEB-INF\web.xmlファイルで、アプリケーション・パラメータcoherence-web-sessions-enabledをtrueに設定します。

<context-param>
<param-name>coherence-web-sessions-enabled</param-name>
<param-value>true</param-value>
</context-param>

10.2.7 アプリケーションの作成およびデプロイ

1. ポータル・ドメインで、coherence-web-spi.warファイルをライブラリとしてクラスタにデプロイします。

2. アプリケーションのEARファイルを作成します。

3. ポータル・ドメインで、アプリケーションのEARファイルをクラスタにデプロイします。

10.3 WebLogic PortalでのCoherenceキャッシュ・プロバイダの使用方法

WebLogic Portalで実行するエンタープライズ・アプリケーションにキャッシュ・サービスを提供するように、Coherenceキャッシュ・プロバイダを構成できます。このためには、キャッシュ・プロバイダとWebLogicポータル・サーバーをアウトオブプロセス・デプロイメント・トポロジで実行するように設定する必要があります。

アウトオブプロセス・トポロジでは、WebLogicポータル・サーバー(つまりWebLogic Portalサーバー層)はローカル記憶域が無効なキャッシュ・クライアントとして構成され(つまり、tangosol.coherence.weblogic.localstorage、tangosol.coherence.distributed.localstorageおよびtangosol.coherence.session.localstorageシステム・プロパティをfalseに設定)、クラスタ化データを物理的に保存および管理してキャッシュ・サーバーとして動作する専用のJVMを配置します。

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

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

- WebLogic Portalとキャッシュ・サーバー層は、独立してスケールできます。アプリケーションの処理能力が不足している場合は、起動するWebLogic Portalサーバーの数を増やします。セッション記憶域の容量が不足している場合は、起動するキャッシュ・サーバーの数を増やします。

アウトオブプロセス・トポロジは、その柔軟性によって、Oracle Coherenceのデフォルトの推奨トポロジになっています。図10-3に、アウトオブプロセス・トポロジを示します。ポータル層の各WebLogic Portalサーバーが、それぞれのニア・キャッシュを管理します。これらのニア・キャッシュは、別のキャッシュ・サーバー層で実行されるセッション・データ・キャッシュと通信します。

このトポロジの構成手順については、「アウトオブプロセス・トポロジのCoherenceキャッシュ・プロバイダのデプロイ」を参照してください。

図10-3 WebLogic Portalのアウトオブプロセス・デプロイメント・トポロジ

10.3.1 アウトオブプロセス・トポロジのCoherenceキャッシュ・プロバイダのデプロイ

1. セッション・キャッシュとポータル・キャッシュの構成ファイルを取得します。

- coherence-web.jarファイルからdefault-session-cache-config.xmlファイルを抽出します。

- coherence-wlp.jarファイルからportal-cache-config.xmlファイルを抽出します。

2. default-session-cache-config.xmlファイルとportal-cache-config.xmlファイルの内容をマージし、Coherenceグリッド・ノードのセットがセッションおよびP13Nキャッシュの両方のタイプのオブジェクトをサポートできるようにします。
このファイルのコピーが2セット必要となります。1つはCoherenceキャッシュ・サーバー用、もう1つはWebLogic Portal管理対象サーバー用です。この2つのファイルの内容は、ポータル・キャッシュ・セクションとセッション・キャッシュ・セクションのlocal-storageプロパティの値以外、すべて同じです。

付録Fの例F-1「WebLogic PortalおよびOracle Coherenceのキャッシュ構成」には、WebLogic Portal管理対象サーバーで使用可能な、マージされた構成ファイルが示されています。セッション・キャッシュとポータル・キャッシュのlocal-storage値はfalseに設定されます。Coherenceキャッシュ・サーバーの構成ファイルは、セッション・キャッシュ構成セクションとポータル・キャッシュ構成セクションのlocal-storageシステム・プロパティの値をtrueに設定する必要があることを除き、例F-1と同様にできます。

3. WebLogic Portal管理対象サーバーのマージされた構成ファイルを、そのサーバーのキャッシュ構成ファイルとして使用します。WebLogic Portal管理対象サーバーで実行されるアプリケーションごとに、そのアプリケーションのAPP-INF/classesディレクトリにこのファイルをコピーします。

4. Coherenceキャッシュのマージされた構成ファイルをCoherenceグリッドJVMのキャッシュ構成として設定します。たとえばキャッシュ構成ファイルを配置する次のシステム・プロパティで、portal-session-cache-config.xmlはマージされたファイルを表します。

-Dtangosol.coherence.cacheconfig=D:\Coherence1212\coherence\temp\portal-session-cache-config.xml

5. WebLogic Portal管理対象サーバーに対してローカル記憶域を無効にするシステム・プロパティを追加します。たとえば、次のプロパティをCoherenceキャッシュ・サーバーの起動スクリプトに追加できます。

-Dtangosol.coherence.weblogic.localstorage=false -Dtangosol.coherence.distributed.localstorage=false -Dtangosol.coherence.session.localstorage=false

6. EARファイルのAPP-INF/libディレクトリにcoherence.jarとcoherence-wlp.jarファイルをコピーします。
デプロイ手順は、「WebLogic PortalでのCoherence*Webの使用方法: 主な手順」を参照してください。

7. WebLogic Portal管理対象サーバーを起動します。

A Coherence*Webコンテキスト・パラメータ

この付録では、Coherence*Webコンテキスト・パラメータについて説明します。このパラメータは、web.xmlファイルで構成することも、システム・プロパティとしてコマンドラインで入力することもできます。システム・プロパティは、コンテキスト・パラメータと同じ名前を持ちますが、ダッシュ(-)がピリオド(.)に置き換えられています。

たとえば、コンテキスト・パラメータのcoherence-enable-sessioncontextは、コマンドラインで次のように宣言できます。

-Dcoherence.enable.sessioncontext=true

システム・プロパティと、同等のコンテキスト・パラメータの両方が構成されている場合、システム・プロパティの値が使用されます。

表A-1で、Coherence*Webのコンテキスト・パラメータについて説明します。

表A-1 Coherence*Webのコンテキスト・パラメータ

パラメータ名

説明

coherence-application-name

Coherence*Webではこのパラメータの値を使用して、ApplicationScopeControllerインタフェースを使用して属性のスコープを設定するアプリケーションの名前を判別します。このパラメータの値は、次の形式で指定する必要があります。

アプリケーション名 + ! + Webモジュール名

application nameはApplicationScopeControllerインタフェースを使用するアプリケーションの名前であり、Web module nameはそれが記述されているWebモジュールの名前です。

たとえば、test.earというEARファイルと、このEARファイル内で定義されたapp1というWebモジュールがある場合、coherence-application-nameパラメータのデフォルト値はtest!app1となります。

このパラメータが構成されていない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。また、このパラメータが構成されておらず、ApplicationScopeControllerインタフェースが構成されている場合、アプリケーション名が構成されていなかったことを示す警告が記録されます。詳細は、「セッション属性スコープ設定」を参照してください。

coherence-attribute-overflow-threshold

スプリット・モデルの場合、「セッション・モデル」の説明のとおり、大型の属性向けに確保されている独立したオーバーフロー・キャッシュに格納するためにシリアライズ形式の属性値で必要な最小長(バイト数単位)をこの値で指定します。

値を指定しない場合、このパラメータはデフォルトで1024に設定されます。

coherence-cache-configuration-path

セッション・キャッシュ情報を取得するために、デフォルトのdefault-session-cache-config.xmlファイルを使用するかわりに、Coherence*Webが使用する必要があるファイルの名前を指定します。「セッション・キャッシュ構成ファイル名のカスタマイズ」を参照してください。

coherence-cache-delegator-class

分散キャッシュ内のデータ操作(取得、配置および削除)を担当するキャッシュ・デリゲータ・クラスを指定します。次の値が有効です。

- com.tangosol.coherence.servlet.LocalSessionCacheDelegator—このクラスは、セッション・インスタンスの保存および取得に分散キャッシュが使用される前に、ローカル・キャッシュが使用される必要があることを示しています。詳細は、「同一のセッション・インスタンスへの同時アクセス」を参照してください。

coherence-cluster-owned

trueの場合は、Webアプリケーションを終了すると自動的にCoherenceノードが終了します。この場合は、WARスコープ設定クラスタ・ノードによるデプロイメント・モデルを使用する必要があります。詳細は、「WARスコープ設定クラスタ・ノード」を参照してください。

falseの場合は、WebアプリケーションがCoherenceノードを終了する必要があります(Javadoc内のcom.tangosol.net.CacheFactory.shutdown()を参照)。クラスタ・ノードをスコープ設定したデプロイメント・モデルのこの状況での使用、およびアプリケーションがCoherenceノードを終了する環境とその終了処理に伴う副作用を慎重に検討する必要があります。クラスタ・ノードのスコープ設定の詳細は、「クラスタ・ノード分離」を参照してください。

注意: WebInstallerを使用している場合は、trueを指定すると、Java EEアプリケーションにある各WebアプリケーションのWEB-INF/libディレクトリにCoherenceライブラリを配置できます。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

coherence-configuration-consistency

trueの場合、Coherence*Webは起動時に構成チェックを実行し、Web層にあるすべてのノードで同じCoherence*Web構成であるかどうかを判別します。特定ノードの構成に一貫性がない場合、起動に失敗します(それにより、アプリケーションが起動しなくなります)。

falseの場合(チェックが実行されず)に構成に一貫性がないと、セッション・データの管理においてクラスタ・メンバーが一貫性のない動作をすることがあります。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

coherence-contextless-session-retain-millis

現在のリクエスト・コンテキストとは関係がないセッションにアクセスしているときに、そのセッションに対するロックを保持する時間を指定します(ミリ秒単位)。現在のリクエスト・コンテキストからセッションが暗黙的に指定されるのは、現在のスレッドでサーブレット・リクエストが処理されており、そのセッションに関連付けられている場合のみです。セッション・オブジェクトに対するその他のすべてのアクセスはコンテキスト外となります。たとえば、任意のセッションへの参照をSessionContextオブジェクトから取得する場合(該当のオプションが有効になっている場合)や、セッションを直接管理するためのセッション・オブジェクト参照を保持するコードがアプリケーションに記述されている場合です。セッションへのアクセスにはそのセッションの所有権が必要なので、セッション・オブジェクトに対するコンテキスト外アクセスでは、コール元にかわって自動的に所有権を取得できます。この所有権はこのオプションで指定した時間だけ保持できるので、セッションのコールごとに所有権の取得と解放が繰り返される、時間のかかる操作を省略できます。有効な時間は10から10000ミリ秒(1/100から10秒)です。

値を指定しない場合、このパラメータはデフォルトで200に設定されます。

coherence-distributioncontroller-class

この値は、com.tangosol.coherence.servlet.HttpSessionCollection$SessionDistributionControllerインタフェース実装のクラス名を指定します。

有効な値は次のとおりです。

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$DistributedController: すべてのセッション(およびそれらの属性)の分散管理を実施するSessionDistributionControllerインタフェースの実装。これがデフォルトの動作ですが、このような実装により、 HttpSessionControllerの使用による生のオーバーヘッドを測定できます。

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$HybridController: すべてのセッションおよびシリアライズ可能な属性の分散管理を実施するSessionDistributionControllerインタフェースの実装。Serializableインタフェースを実装していないすべてのセッション属性は、ローカルのままとなります。

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$LocalController: すべてのセッション(およびそれらの属性)のローカルな管理を実施するSessionDistributionControllerインタフェースの実装。これは本番環境には有用ではありませんが、ローカルのみの実装と完全な分散実装でのスケーラブル・パフォーマンスの違いをテストする場合に役立つことがあります。

coherence-enable-sessioncontext

trueに設定した場合は、アプリケーションでセッション・コンテキストのセッションを繰り返すことができます。この処理は、サーブレット仕様では推奨されていません。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-eventlisteners

Webコンテナからイベントを受信する必要があるアプリケーション・クラス名のカンマ区切りリストです。このリストは、web.xmlファイルのlistener要素で宣言したアプリケーション・リスナーから得られます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-enable-suspect-attributes

trueに設定した場合、Coherence*Webはセッション関連のいずれかの属性値が変更されていないか検出を試みます。可変(シンプル・チェックで判別される)でありgetメソッドによってアクセスできる属性は、変更された可能性があると見なされます。可変オブジェクトは、アプリケーション・コードによって変更された可能性があり、再度シリアライズしてキャッシュに戻す必要があります。詳細は、「変更された属性値の検出」を参照してください。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

coherence-factory-class

SessionHelper.Factoryファクトリ・クラスを実装するクラスの完全修飾名です。

デフォルトでcom.tangosol.coherence.servlet.apinn.DefaultFactoryに設定されます。ここで、nnは、22、23、24、25のいずれかで、それぞれ、サーブレット2.2、2.3、2.4、2.5コンテナに対応します。

coherence-local-session-cachename

この名前は、coherence-distributioncontroller-classパラメータを指定した場合に、分散されないセッションを保存するローカル・キャッシュの名前をオーバーライドします。

値を指定しない場合、このパラメータはデフォルトでlocal-session-storageに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-local-attribute-cachename

この名前は、coherence-distributioncontroller-classパラメータを指定した場合またはcoherence-preserve-attributesパラメータにtrueを指定した場合に、分散されないセッションを保存するローカル・キャッシュの名前をオーバーライドします。

値を指定しない場合、このパラメータはデフォルトでlocal-attribute-storageに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-preserve-attributes

この値をtrueに設定した場合は、シリアライズ不可能な属性をローカルな属性として維持する指定となります。このパラメータでは、セッションのシリアライズ不可属性を取得するためにロード・バランサが必要です。

クライアント(アプリケーション・サーバー)が失敗すると、これらの属性は失われます。アプリケーションは、この状態から復旧できる必要があります。

GlassFish Serverではローカル・セッションを使用可能にする必要があるため、GlassFishにActiveCacheを使用している場合は、この値をtrueに設定します。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

coherence-reaperdaemon-assume-locality

この設定により、セッション・リーパーでは、(たとえば、分散キャッシュ・サービスによって)このノードに保存されるセッションは、このノードで期限切れのチェックが必要なセッションのみであると仮定できます。リーパーを実行していないノードでセッションの記憶域キャッシュを管理している場合は、この値をfalseに設定する必要があります。たとえば、セッションの記憶域キャッシュの管理にキャッシュ・サーバーを使用している場合がこれに該当します

キャッシュ・サーバーを使用している場合は、スプリット・モデルを選択し、全体をそのキャッシュ・サーバーで管理している独立した分散キャッシュ・サービスでセッションのオーバーフロー記憶域を実行します。セッションの記憶域キャッシュ自体は、全体をアプリケーション・サーバーJVMで管理している分散キャッシュ・サービスに残します。これによって、このローカル性を前提とした機能を活用できます。セッション・リーパーの詳細は、第7章「期限切れHTTPセッションのクリーンアップ」を参照してください。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

coherence-reaperdaemon-cluster-coordinated

trueに設定した場合、セッション・リーバーは、指定したリープ・サイクル中に1台のサーバーのみでリープを実行し、クラスタで管理しているすべてのセッションをそのサーバーで確認するように、クラスタ内のリープを調整します。セッション・リーパーの詳細は、第7章「期限切れHTTPセッションのクリーンアップ」を参照してください。

スティッキー最適化(coherence-sticky-sessions)も有効化されている場合は、このオプションを使用しないでください。詳細は、「セッション・リーパーの理解」を参照してください。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

coherence-reaperdaemon-cycle-seconds

リープ処理の間でデーモンが待機する秒数です。セッション・タイムアウト間隔の長い本番クラスタの場合、これは問題なく大きな値に設定できます。テストで、特にセッション・タイムアウト間隔が短い場合には、もっと小さな値に設定できます。設定値が小さすぎると、ネットワーク・トラフィックの増加や処理に費やすサイクルの増加が発生します。小さい設定値が効果的なのは、期限切れのセッションをアプリケーションで迅速に無効にする必要がある場合のみです。セッション・リーパーの詳細は、第7章「期限切れHTTPセッションのクリーンアップ」を参照してください。

値を指定しない場合、このパラメータはデフォルトで300に設定されます。

coherence-reaperdaemon-parallel

trueに設定した場合、セッション・リーパーは期限切れセッションをパラレルに無効化します。falseに設定した場合、期限切れセッションはシリアルに無効化されます。「セッション・リーパーの理解」を参照してください。

デフォルトはtrueです。

coherence-reaperdaemon-priority

セッションのリーパー・デーモンの優先度です。詳細は、第7章「期限切れHTTPセッションのクリーンアップ」およびjava.lang.Threadクラスのソースを参照してください。

値を指定しない場合、このパラメータはデフォルトで5に設定されます。

coherence-reaperdaemon-sweep-modulo

Coherenceリリース3.5以降、このパラメータは非推奨です。

coherence-scopecontroller-class

この値は、オプションのcom.tangosol.coherence.servlet.HttpSessionCollection$AttributeScopeControllerインタフェース実装のクラス名を指定します。詳細は、「セッション属性スコープ設定」を参照してください。

有効な値は次のとおりです。

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeController

- com.tangosol.coherence.servlet.AbstractHttpSessionCollection$GlobalScopeController

GlassFishのCoherence*Web SPIおよびActiveCacheのデフォルト値は、com.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeControllerです。

Coherence*Web WebInstallerについては、デフォルト値は宣言されていません。

coherence-servletcontext-clustered

この値は、ServletContextの属性をクラスタ化するかどうかを指定し、trueまたはfalseのいずれかとなります。trueの場合は、シリアライズ可能なすべてのServletContext属性値がすべてのクラスタ・ノード間で共有されます。

値を指定しない場合は、デフォルトでfalseに設定されます。この主な理由は、ServletContext属性はJVMに対してローカルであり、クラスタ化しないことがサーブレット仕様で規定されているためです。

WebLogic SPIで使用した場合、このコンテキスト・パラメータは無効です。

coherence-servletcontext-cachename

サーブレット・コンテキストをクラスタ化している場合にサーブレットのコンテキスト・データを保持するために使用するCoherenceキャッシュの名前を指定します。Coherence*Web SPIで使用した場合、このパラメータはキャッシュ名の定義に使用できますが、そのキャッシュは使用されません。

値を指定しない場合、このパラメータはデフォルトでservletcontext-storageに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-session-affinity-token

セッション・アフィニティ接尾辞トークンを指定の値で構成します。たとえばセッション・アフィニティ接尾辞をabcdに設定するには、Webアプリケーションのweb.xmlファイルに次のコードを追加します。

<context-param>
<param-name>coherence-session-affinity-token</param-name>
<param-value>abcd</param-value>
</context-param>

トークンからセッション・アフィニティ接尾辞を分割するには、パラメータ値として感嘆符(!)を入力します。詳細は、「その他のアプリケーション・サーバーとのCoherence*Webセッションの共有」を参照してください。

coherence-session-app-locking

この値をtrueに設定した場合は、別々のアプリケーションにある2つのスレッドで1つの同じセッションに対するリクエストを同時に処理することはできなくなります。trueに設定した場合、アプリケーション・ロックは暗黙的にメンバー・ロックになるので、coherence-session-member-lockingパラメータの値が無視されます。値をfalseに設定すると、スレッド・ロックとの互換性がなくなります。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

この表のcoherence-session-member-locking、coherence-session-lockingおよびcoherence-session-thread-lockingのパラメータの説明および「セッション・ロック・モード」も参照してください。

coherence-session-cachename

この名前は、セッションを保存するクラスタ・キャッシュの名前をオーバーライドします。

値を指定しない場合、このパラメータはデフォルトでsession-storageに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-session-cookie-domain

「Request for Comments 2109: HTTP State Management Mechanism」(RFC 2109)で定義されているセッションCookieのドメインを指定します。デフォルトでは、セッション管理実装によって明示的に設定されているドメインはありません。詳細は、「セッションとセッション属性のスコープ設定」を参照してください。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-cookie-httponly

HttpOnly属性をセッションCookieに追加します。すべてのブラウザがこの機能をサポートしているわけではありません。このコンテキスト・パラメータは設定済アプリケーションでのみ使用できます。詳細は、「クロスサイト・スクリプティング攻撃の防止」を参照してください。

coherence-session-cookie-name

セッションCookieの名前を指定します。

指定しない場合、このパラメータはデフォルトでJSESSIONIDに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-cookie-path

RFC 2109で定義されているセッションCookieのパスを指定します。デフォルトでは、セッション管理実装によって明示的に設定されているパスはありません。詳細は、「セッションとセッション属性のスコープ設定」を参照してください。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-cookie-max-age

RFC 2109で定義されているセッションCookieの最長有効期間(秒)を指定します。-1を指定すると、クライアント上ではCookieが維持されません。正の値を指定すると、最長でその秒数、Cookieがクライアント上で維持されます。0は指定できません。

値を指定しない場合、このパラメータはデフォルトで-1に設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-cookie-secure

trueに設定すると、Secure Socket Layer (SSL)接続を介したWebクライアントからのみセッションCookieが送信されます。値を指定しない場合は、デフォルトでfalseに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-cookies-enabled

値を指定しない場合、このパラメータはデフォルトでtrueに設定され、セッションのCookieが有効になります。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-deathcert-cachename

この名前は、最近終了したセッションのIDを保存するクラスタ・キャッシュの名前をオーバーライドします。

値を指定しない場合、このパラメータはデフォルトでsession-death-certificatesに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-session-expire-seconds

この値は、セッションの有効期限をオーバーライドします。単位は秒です。-1に設定した場合は、セッションが無期限になります。詳細は、第7章「期限切れHTTPセッションのクリーンアップ」を参照してください。

値を指定しない場合、このパラメータはデフォルトで1800に設定されます。

coherence-session-get-lock-timeout

Coherence*Webのロック取得のタイムアウトを構成します。詳細は、「HTTPセッションでのロックのトラブルシューティング」を参照してください。

coherence-session-id-length

生成されるセッションIDの文字数です。推奨の絶対最小長は8です。

値を指定しない場合、このパラメータはデフォルトで12に設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-lazy-access

セッションの遅延取得を有効化します。セッションは、サーブレットまたはフィルタがアクセスを試みたときにのみ取得されます。これは、設定済Webアプリケーションにのみ関係します。Coherence*Web SPIを使用する場合は関係ありません。「遅延取得によるセッションへのアクセス」を参照してください。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

coherence-session-locking

falseの場合、セッションに対して最後の更新が保存される同時変更が可能です。coherence-session-app-locking、coherence-session-member-lockingまたはcoherence-session-thread-lockingをtrueに設定した場合は、この値は無視されます(論理的にtrueとされます)。「オプティミスティック・ロック」と「最後の書込みを優先するロック」を参照してください。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

この表のcoherence-session-app-locking、coherence-session-member-lockingおよびcoherence-session-thread-lockingも参照してください。

coherence-session-locking-mode

このコンテキスト・パラメータの値は、HTTPセッションへの同時アクセスを制御するロック・モードを決定します。

- none: 単一のメンバーまたは複数のメンバーにある複数のスレッドからのセッションへの同時アクセスを許可します。この場合、最後の書込みが保存されます。これはデフォルトのロック・モードです。「最後の書込みを優先するロック」を参照してください。

- optimistic: 1つ以上のメンバーにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスすることを許可します。「オプティミスティック・ロック」を参照してください。

- app: 別々のアプリケーションにある2つのスレッドで同じセッションに対するリクエストを同時に処理することを禁止します。このパラメータをappに設定した場合、アプリケーション・ロックは暗黙的にメンバー・ロックになるので、coherence-session-member-lockingパラメータの値が無視されます。値をfalseに設定すると、スレッド・ロックとの互換性がなくなります。「アプリケーション・ロック」を参照してください。

- member: 同じクラスタ・ノードにある複数のWebコンテナ・スレッドから同じセッションに同時にアクセスして変更することを許可しますが、別々のメンバーにあるスレッドからの同時アクセスは禁止します。「メンバー・ロック」を参照してください。

- thread: 同じJVMにある2つのスレッドで同じセッションに対するリクエストを同時に処理することを禁止します。trueに設定した場合、スレッド・ロックは暗黙的にメンバー・ロックになるので、coherence-session-member-lockingパラメータの値が無視されます。「スレッド・ロック」を参照してください。

たとえば、web.xmlでcoherence-session-locking-modeコンテキスト・パラメータをアプリケーション・ロックに設定するには、次のように指定します。

<context-param>
<param-name>coherence-session-locking-mode</param-name>
<param-value>app</param-value>
</context-param>

coherence-session-log-invalidation-exceptions

セッションの無効化中、セッション・リーパーでClassNotFound例外が多数スローされ、記録される場合があります。このコンテキスト・パラメータがfalseに設定されている場合、この例外は抑制されます。trueに設定されている場合、この例外は記録されます。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

セッション無効化および、セッション・リーパーの動作中に発生する可能性のあるClassNotFound例外の原因の詳細は、「セッション・リーパーのセッション無効化の例外の理解」を参照してください。

coherence-session-log-threads-holding-lock

trueの場合、メンバーがセッションに対してクラスタ・ロックを取得できないときに、診断起動サービスが実行されます。この起動サービスによって、セッションの所有権を持つメンバーが、ロックを現在保持しているスレッドのスタック・トレースを記録します。coherence-session-log-threads-holding-lockコンテキスト・パラメータは、coherence-sticky-sessionsコンテキスト・パラメータがtrueに設定されている場合にのみ使用可能です。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

詳細は、「HTTPセッションでのロックのトラブルシューティング」を参照してください。

coherence-session-logger-level

Coherence*Webのロギング・レベルをJDKロギングのかわりに設定する方法。このパラメータの有効な値は、JDKロギングの値(SEVERE、WARNING、INFO、CONFIG、FINE、FINER (デフォルト)、およびFINEST)と同じです。詳細は、「Coherence*Webのロギングの構成」を参照してください。

java.util.loggingについてはJavadocも参照してください。

http://docs.oracle.com/javase/1.4.2/docs/api/java/util/logging/Level.html

coherence-session-management-cachename

この名前は、セッション管理実装の管理情報と構成情報を保存するクラスタ・キャッシュの名前をオーバーライドします。通常は、レプリケート・キャッシュとして構成する必要があります。

値を指定しない場合、このパラメータはデフォルトでsession-managementに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-session-member-locking

この値をtrueに設定した場合は、別々のメンバーにある2つのスレッドで1つの同じセッションに対するリクエストを同時に処理することはできなくなります。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

この表のcoherence-session-thread-locking、coherence-session-lockingおよびcoherence-session-app-lockingも参照してください。

coherence.session.optimizeModifiedSessions

このJVMシステム・プロパティをtrueに設定した場合、最後の書込みを優先するロックを使用するアプリケーションでパフォーマンスを向上できるニア・キャッシュ最適化が有効になります。

値を指定しない場合、この値はデフォルトでfalseに設定されます。

このパラメータは、システム・プロパティとしてコマンドラインでのみ設定できます。

coherence-session-overflow-cachename

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

値を指定しない場合、このパラメータはデフォルトでsession-overflowに設定されます。このパラメータの詳細は、付録C「セッション・キャッシュ構成ファイル」を参照してください。

coherence-session-strict-spec

falseに設定した場合、実装はサーブレット仕様に従う必要がありません。実装では、特定の種類の例外が無視され、アプリケーションは終了しません。属性の設定、取得および削除、またはセッションの無効化によって、セッション・リスナーへのコールバックは生成されません。コール元のアプリケーションにクラスが存在しないために属性をデシリアライズできない場合、ClassNotFound例外がコール元に伝播されません。

trueに設定した場合、実装はサーブレット仕様に厳密に準拠します。ClassNotFound例外はアプリケーションによって処理される必要があり、属性値の取得に失敗した場合でもセッション・リスナー・イベントが送信されます。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

coherence-session-thread-locking

この値をtrueに設定した場合は、同じJVMにある2つのスレッドで1つの同じセッションに対するリクエストを同時に処理することはできなくなります。trueに設定した場合、スレッド・ロックは暗黙的にメンバー・ロックになるので、coherence-session-member-lockingパラメータの値が無視されます。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

この表のcoherence-session-app-locking、coherence-session-locking、coherence-session-member-lockingパラメータの説明、および「セッション・ロック・モード」を参照してください。

coherence-session-urldecode-bycontainer

trueに設定した場合は、コンテナのURLセッションIDのデコードが使用されます。coherence-session-urlencode-nameがオーバーライドされている場合は、この値をfalseに設定する必要があります。コンテナによっては、この値をfalseに設定しても機能しない場合があります。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-urlencode-bycontainer

trueに設定した場合は、コンテナのURLセッションIDのエンコードが使用されます。この値をtrueに設定すると、事前に指定したcoherence-session-urlencode-nameの設定と矛盾する場合があります。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-urlencode-enabled

trueに設定した場合は、セッションIDのURLエンコードが有効になります。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-urlencode-name

URLにセッションIDをエンコードするパラメータ名です。コンテナによっては、この値をオーバーライドできない場合があります。

指定しない場合、このパラメータはデフォルトでjsessionidに設定されます。

WebLogic SPI実装でこのコンテキスト・パラメータを使用した場合は、Coherence*Webの動作を制御できません。

coherence-session-weblogic-compatibility-mode

trueに設定した場合、各Webアプリケーションで単一セッションID (Cookieのパスを「/」に設定)は、固有のCoherence*Webセッション・インスタンスにマップされます。falseの場合、標準の動作が適用されます。つまり、WebLogic ServerのCoherence*Web SPIを使用して単一セッションIDが単一セッション・インスタンスにマップされます。WebLogic Serverにおけるその他のすべてのセッション持続メカニズムでは、各Webアプリケーションで単一のセッションIDを使用して、様々なセッション・インスタンスを参照します。

値を指定しない場合、このパラメータはデフォルトでtrueに設定されます。例外は、アプリケーションがグローバル・スコープ・コントローラを使用するように構成されている場合です。その場合は、デフォルトでfalseに設定されます。

「セッションCookieパスのスコープ設定」を参照してください。

coherence-sessioncollection-class

使用するHttpSessionCollection実装の完全修飾クラス名です。使用可能な値は次のとおりです。

- com.tangosol.coherence.servlet.MonolithicHttpSessionCollection

- com.tangosol.coherence.servlet.SplitHttpSessionCollection (デフォルト)

- com.tangosol.coherence.servlet.TraditionalHttpSessionCollection

このパラメータは、値の指定が必須です。「セッション・モデルの構成」を参照してください。

coherence-shutdown-delay-seconds

アプリケーションが停止したという最後の通知をServletContextListenerイベント(サーブレット2.3以降)またはServletオブジェクトとFilterオブジェクトの破棄によって受け取ってからシャットダウンするまでにセッション管理実装が待機する時間が、この値で決まります。この値は秒単位で表します。0を指定すると同期シャットダウンになり、正の値を指定すると非同期シャットダウンになります。

一部のサーバーでは非同期シャットダウンができないため、値を指定しない場合、このパラメータはデフォルトで0に設定されます。

coherence-sticky-sessions

この値をtrueに設定した場合は、スティッキー・セッション最適化が使用されます。この設定は、スティッキー・ロード・バランサを使用している場合にのみ有効にする必要があります。この機能には、メンバー、アプリケーションまたはスレッドのロックが有効になっている必要があります。「スティッキー・セッション最適化の有効化」を参照してください。

この表のcoherence-session-thread-locking、coherence-session-member-lockingおよびcoherence-session-app-lockingも参照してください。

値を指定しない場合、このパラメータはデフォルトでfalseに設定されます。

coherence-web-sessions-enabled

WebLogic PortalアプリケーションでCoherence*Webセッションを有効にします。詳細は、「Coherence*Webセッションの有効化」を参照してください。

B キャパシティ・プランニング

この付録は、アプリケーションで必要とされるキャッシュ・サーバーの台数の見積りを支援します。記載されている式は、合理的な見積もりの算出にのみ役立つものであり、キャッシュ索引、キャッシュ・サーバー・ヒープに存在する可能性のある非アプリケーション・オブジェクト、フェイルオーバー・ヘッドルームなどの影響は考慮されていません。

必要となるキャッシュ・サーバーの台数を算出するには、最初にアプリケーションのヒープ要件とキャッシュ・サーバーの使用可能な確保領域を計算する必要があります。

1. アプリケーションの合計ヒープ要件を計算します。
アプリケーションに必要なキャッシュ・サーバーの台数を決定する場合、最初にアプリケーションの合計ヒープ要件を決定します。合計ヒープ要件は、実行予定のセッションの数に、セッションごとにキャッシュされるオブジェクトの平均数を乗算してから、キャッシュされるオブジェクトごとの平均バイト数を乗算して計算できます。通常、キャッシュ・エントリごとにバックアップ・コピーを1つ作成するため、合計を2倍します。式として表すと、次のようになります。

Total_Heap_Requirement = 2 * (Number_of_Sessions) * (Average_Number_of_Cached_Objects per Session) * (Average_Number_of_Bytes per Cached_Object)

Total_Heap_Requirementの単位はバイトです。Average_Number_of_Bytes per Cached_Objectは、プライマリ・コピーのシリアライズしたバイト・ストリームのバイト数を意味します。この式は、シリアライズされていないオブジェクト・サイズには対応していません。バックアップ・コピーに必要な領域は別に計算されます。

2. キャッシュ・サーバーJVMで使用可能な確保領域を計算します。
使用可能な確保領域は、最大ヒープ・サイズ割当てと他のユーザー指定のJVMヒープ・サイズ設定パラメータによって変わります。使用可能な確保領域のもう1つの係数は、記憶域に使用可能なヒープの比率です。通常、記憶域に使用可能なヒープの最大比率として66%が使用されますが、システムによってはこの数値が低すぎる場合もあります。これを変数にします。

Percent_of_Heap_Available_for_Storage = 0.66

Available_Tenured_Generation = (Maximum_Heap_Size) * (Percent_of_Heap_Available_for_Storage)

3. 必要なキャッシュ・サーバーの台数を計算します。
必要なキャッシュ・サーバーの台数を計算するには、使用可能な確保領域で合計ヒープ要件を除算します。

Number_of_Cache_Servers = (Total_Heap_Requirement / Available_Tenured_Generation)

C セッション・キャッシュ構成ファイル

この付録では、セッション・キャッシュ構成ファイルdefault-session-cache-config.xmlの内容について説明します。Coherence*Webでは、このファイルで定義したキャッシュとサービスを使用してHTTPセッション管理を実装します。このファイルは、設定済のWebアプリケーションまたは共有しているWebLogic Coherence*Web SPIライブラリのWEB-INF/classesディレクトリにデプロイされます。表C-1は、default-session-cache-config.xmlファイルで使用するキャッシュ関連デフォルト値を示しています。

表C-1 default-session-cache-config.xmlで使用するキャッシュ関連の値

値

説明

local-attribute-storage

このローカル・キャッシュには、分散配置しない属性を保存します。これには、次のような状況が考えられます。

- coherence-distributioncontroller-classを構成済の場合。ローカル・セッションの属性をこのキャッシュに保存します。

- 分散セッションに対してシリアライズ不可能な属性を設定している場合。coherence-preserve-attributesをtrueに設定した場合は、シリアライズ不可能な属性がこのキャッシュに配置されます。このパラメータの詳細は、表A-1を参照してください。

local-session-storage

構成済のcoherence-distributioncontroller-classパラメータが存在する場合、それによってローカルと見なされたセッション・モデルをこのローカル・キャッシュに保存します。このパラメータの詳細は、表A-1を参照してください。

servletcontext-storage

ServletContext属性のクラスタリング(表A-1のcoherence-servletcontext-clusteredパラメータを参照)が有効になっている場合(デフォルトでは無効)、ServletContext属性はこのキャッシュに保存されます。read-mostly属性が少数存在することを想定して、このキャッシュはデフォルトでレプリケートされます。

session-death-certificates

最近使用されたセッションIDが再利用されないように、最近有効期限が切れたセッションIDがこのキャッシュに保存されます。デフォルトでは、記憶域ノードごとに最大4000個のセッションIDを保持できます。これらのセッションIDは、保存した時点から24時間後に削除されます。このキャッシュは分散キャッシュとして構成されます。

session-management

このキャッシュには、セッション管理実装の内部的な構成情報と管理情報を保存します。この情報は、更新頻度が低いことから、このキャッシュはデフォルトでレプリケートしたキャッシュになります。

session-overflow

coherence-sessioncollection-classパラメータ(表A-1を参照)をcom.tangosol.coherence.servlet.SplitHttpSessionCollectionに設定している場合は、このキャッシュに大型のセッション属性が保存されます。デフォルトでは、1Kを超えるサイズのセッション属性がこのキャッシュに保存されます。このキャッシュは分散キャッシュとして構成されます。

session-storage

このキャッシュには、セッション・モデルを保存します。このキャッシュは、分散キャッシュをバック・キャッシュとするニア・キャッシュにデフォルトでマップされます。これは、セッションのサブセットにはコンテナによるアクセスと変更が何回も発生することを想定しているからです(スティッキー・セッションのロード・バランシングが構成されている場合)。詳細は、「セッション・モデル」を参照してください。

表C-2は、default-session-cache-config.xmlファイルで使用するサービス関連値を示しています。

表C-2 default-session-cache-config.xmlで使用するサービス関連の値

値

説明

DistributedSessions

この分散サービスは、次のキャッシュで使用します。

- session-storage

- session-overflow

- session-death-certificates

これらのキャッシュのデータをJVMで保存および管理するかどうかを、tangosol.coherence.session.localstorageシステム・プロパティで制御します。大半の状況では、WebコンテナのJVMについてこのシステム・プロパティをfalseに設定する必要があります。詳細は、「デプロイメント・トポロジ」を参照してください。

ReplicatedSessionsMisc

このレプリケートしたサービスは、session-managementキャッシュとservletcontext-storageキャッシュで使用します。

SessionOwnership

この起動サービスは、スティッキー・セッションの最適化機能で使用します(coherence-sticky-sessionsをtrueに設定している場合)。

例C-1は、default-session-cache-config.xmlファイルの内容を示しています。表C-1と表C-2で説明したキャッシュ関連およびサービス関連の値はboldフォントで表示されています。

例C-1 default-session-cache-config.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">
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!--                                                                       -->
<!--      Cache configuration descriptor for Coherence*Web                 -->
<!--                                                                       -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<caching-scheme-mapping>
<!--
The clustered cache used to store Session management data.
-->
<cache-mapping>
<cache-name>session-management</cache-name>
<scheme-name>replicated</scheme-name>
</cache-mapping>

<!--
The clustered cache used to store ServletContext attributes.
-->
<cache-mapping>
<cache-name>servletcontext-storage</cache-name>
<scheme-name>replicated</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-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>

<!--
The local cache used to store Sessions that are not yet distributed (if
there is a distribution controller).
-->
<cache-mapping>
<cache-name>local-session-storage</cache-name>
<scheme-name>unlimited-local</scheme-name>
</cache-mapping>

<!--
The local cache used to store Session attributes that are not distributed
(if there is a distribution controller or attributes are allowed to become
local when serialization fails).
-->
<cache-mapping>
<cache-name>local-attribute-storage</cache-name>
<scheme-name>unlimited-local</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<!--
Replicated caching scheme used by the Session management and ServletContext
attribute caches.
-->
<replicated-scheme>
<scheme-name>replicated</scheme-name>
<service-name>ReplicatedSessionsMisc</service-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
<request-timeout>30s</request-timeout>
<autostart>true</autostart>
</replicated-scheme>

<!--
Near caching scheme used by the Session attribute cache. The front cache
uses a Local caching scheme and the back cache uses a Distributed 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>
<distributed-scheme>
<scheme-ref>session-distributed</scheme-ref>
</distributed-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>

<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>
<!-- for disk overflow use this backing scheme instead:
<overflow-scheme>
<scheme-ref>session-paging</scheme-ref>
</overflow-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>
<thread-count>0</thread-count>
<lease-granularity>member</lease-granularity>
<local-storage>false</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>
<request-timeout>30s</request-timeout>
<autostart>true</autostart>
</distributed-scheme>

<!--
Disk-based Session attribute overflow caching scheme.
-->
<overflow-scheme>
<scheme-name>session-paging</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>session-front</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<external-scheme>
<bdb-store-manager/>
</external-scheme>
</back-scheme>
</overflow-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>

<!--
Clustered invocation service that manages sticky session ownership.
-->
<invocation-scheme>
<service-name>SessionOwnership</service-name>
<request-timeout>30s</request-timeout>
</invocation-scheme>
</caching-schemes>
</cache-config>

D ニア・キャッシュのないセッション・キャッシュ構成ファイル

この付録では、ニア・キャッシュ構成を含まないセッション・キャッシュ構成ファイル(session-cache-config.xml)のサンプルを示します。ローカル・セッション・インスタンスを使用している場合は、通常ニア・キャッシュ構成を省略します。「同一のセッション・インスタンスへの同時アクセス」では、ニア・キャッシュのかわりにローカル・セッション・インスタンスを使用するユース・ケースについて説明しています。

例D-1 ニア・キャッシュ構成のないsession-cache-config.xmlファイル

<?xml version="1.0"?>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!--                                                                       -->
<!--      Cache configuration descriptor for Coherence*Web                 -->
<!--                                                                       -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<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">

<caching-scheme-mapping>
<!--
The clustered cache used to store Session management data.
-->
<cache-mapping>
<cache-name>session-management</cache-name>
<scheme-name>replicated</scheme-name>
</cache-mapping>

<!--
The clustered cache used to store ServletContext attributes.
-->
<cache-mapping>
<cache-name>servletcontext-storage</cache-name>
<scheme-name>replicated</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-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>

<!--
The local cache used to store Sessions that are not yet distributed (if
there is a distribution controller).
-->
<cache-mapping>
<cache-name>local-session-storage</cache-name>
<scheme-name>unlimited-local</scheme-name>
</cache-mapping>

<!--
The local cache used to store Session attributes that are not distributed
(if there is a distribution controller or attributes are allowed to become
local when serialization fails).
-->
<cache-mapping>
<cache-name>local-attribute-storage</cache-name>
<scheme-name>unlimited-local</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<!--
Replicated caching scheme used by the Session management and ServletContext
attribute caches.
-->
<replicated-scheme>
<scheme-name>replicated</scheme-name>
<service-name>ReplicatedSessionsMisc</service-name>
<request-timeout>30s</request-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</replicated-scheme>

<!--
Near caching scheme used by the Session attribute cache. The front cache
uses a Local caching scheme and the back cache uses a Distributed 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>
<distributed-scheme>
<scheme-ref>session-distributed</scheme-ref>
</distributed-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>

<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>
<!-- for disk overflow use this backing scheme instead:
<overflow-scheme>
<scheme-ref>session-paging</scheme-ref>
</overflow-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>
<thread-count>0</thread-count>
<lease-granularity>member</lease-granularity>
<local-storage system-property="tangosol.coherence.session.localstorage">false</local-storage>
<partition-count>257</partition-count>
<backup-count>1</backup-count>
<backup-storage>
<type>on-heap</type>
</backup-storage>
<request-timeout>30s</request-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<!--
Disk-based Session attribute overflow caching scheme.
-->
<overflow-scheme>
<scheme-name>session-paging</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>session-front</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<external-scheme>
<bdb-store-manager/>
</external-scheme>
</back-scheme>
</overflow-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>

<!--
Clustered invocation service that manages sticky session ownership.
-->
<invocation-scheme>
<service-name>SessionOwnership</service-name>
<request-timeout>30s</request-timeout>
</invocation-scheme>
</caching-schemes>
</cache-config>

E OVAB用Oracle Coherence*Web拡張機能

この付録では、インストールしたOracleコンポーネントを仮想化し、これらのコンポーネントを変更して、ご使用の環境にデプロイするためのツール、Oracle Virtual Assembly Builder用のCoherence*Web拡張機能について説明します。Oracle Virtual Assembly Builderを使用して、ソフトウェア・アプライアンスと呼ばれるアーティファクト内の既存のソフトウェア・コンポーネントの構成を取得します。その後、アプライアンスをグループ化して、その関係をソフトウェア・アセンブリと呼ばれるアーティファクトに定義できます。アセンブリは、完全な複数層アプリケーション・トポロジを記述するブループリントを提供します。

Coherence*Web用のOracle Coherence*Webイントロスペクション拡張機能は、WebLogic Serverイントロスペクタの機能を拡張します。これは、WebLogicドメインの一部として構成されたCoherenceキャッシュ・クラスタおよびサーバーの構成を調べます。

この付録の内容は、次のとおりです。

- サポートされるバージョン

- Oracle Coherence*Webのイントロスペクション・パラメータ

- 参照システムの前提条件

- 要件

- 結果のアーティファクト・タイプ

- ワイヤリング

- 接続プロパティ

- Oracle Coherence*Webアプライアンスのプロパティ

- サポートされるテンプレート・タイプ

E.1 サポートされるバージョン

このプラグイン拡張機能は、Oracle WebLogic Server 11gR1リリース11.1.1.4.0 (Coherence 3.6を含む)と連携して機能します。

E.2 Oracle Coherence*Webのイントロスペクション・パラメータ

Oracle WebLogic Serverで必要とするもの以外に必要な追加のパラメータはありません。WebLogic Serverに必要なパラメータについては、『Oracle WebLogic Serverサーバー環境の管理』でOracle Virtual Assembly Builder用のイントロスペクション・プラグインの使用方法に関する項を参照してください。

E.3 参照システムの前提条件

Oracle WebLogic Serverで定義するもの以外に追加の前提条件はありません。WebLogic Serverに必要な前提条件については、『Oracle WebLogic Serverサーバー環境の管理』でOracle Virtual Assembly Builder用のイントロスペクション・プラグインの使用方法に関する項を参照してください。

E.4 要件

Oracle Coherence*Webには、次の要件があります。

注意:

この項で説明するCoherence*Webの要件に加え、WebLogic Serverのすべての要件も満たす必要があります。WebLogic Serverの要件については、『Oracle WebLogic Serverサーバー環境の管理』でOracle Virtual Assembly Builder用のイントロスペクション・プラグインの使用方法に関する項を参照してください。

E.4.1 デプロイメント・モデルの要件

このプラグイン拡張機能では、プロセス外デプロイメント・モデルをOracle Coherence*Webに使用する必要があります。Oracle Coherence*Webでは、ストレージ対応のキャッシュ・サーバーがOracle WebLogic Server内で実行されるのではなく、別個のプロセスとして実行されます。アウトオブプロセス・デプロイメント・モデルの詳細は、「アウトオブプロセス・トポロジ」を参照してください。

E.4.2 カスタム・クラスタ構成ファイルを手動更新するための要件

プラグイン拡張機能は、WebLogic Server管理コンソールおよびWebLogic Server MBean (WLSTを含む)で定義されたOracle Coherence*Web構成を調査します。tangosol-coherence-override.xmlなどのカスタム・クラスタ構成ファイルの調査および変更は実行しません。カスタム・クラスタ構成ファイルはデプロイされる環境に渡されますが、その環境を反映するようにそれらのファイルは構成変更されません。

デプロイ後、必ずカスタム・クラスタ構成ファイルに適切な構成変更を手動で行ってください。

E.5 結果のアーティファクト・タイプ

このプラグイン拡張機能は、イントロスペクトされたWebLogicドメインに定義されているCoherenceクラスタごとに、新しいアプライアンスをOracle WebLogic Server原子性アセンブリ内に作成します。

E.6 接続

Coherenceクラスタ・アプライアンスに対して接続は実行できません。各クラスタ・アプライアンスには、ドメインの管理サーバーへの固定の事前定義済接続があり、リハイドレーション時にクラスタの構成を変更するために使用されます。

E.7 接続プロパティ

なし。

E.8 Oracle Coherence*Webアプライアンスのプロパティ

各Oracle Coherence*Webクラスタ・アプライアンスには、次のシステム・プロパティおよびユーザー・プロパティがあります。

表E-1では、Oracle Coherence*Webクラスタ・アプライアンスのシステム・プロパティについて説明します。

表E-1 Oracle Coherence*Webアプライアンスのシステム・プロパティ

名前

型

必須

デフォルト

説明

cache-servers

String

省略可

なし

クラスタに属するキャッシュ・サーバーのリスト。

targets

String

省略可

なし

クラスタに属するWebLogic Server管理対象サーバーのリスト。

<cacheserver>.node-manager-type

String

省略可

なし

前述のリストのキャッシュ・サーバーごとに、ノード・マネージャ・タイプを示すプロパティがあります。

well-known-addresses

String

省略可

なし

クラスタに定義されたwell-known-addressesのリスト。well-known-addressがこのクラスタに定義されていない(つまり、マルチキャストを使用している)場合、このプロパティはありません。

<wellknownaddress>.server

String

省略可

なし

前述のリストのwell-known-addressesごとに、Well Knownアドレスが(一致するリスニング・アドレスおよびポート情報に基づいて)マップされるキャッシュ・サーバーを示すプロパティがあります。

表E-2では、Oracle Coherence*Webクラスタ・アプライアンスのユーザー・プロパティについて説明します。

表E-2 Oracle Coherence*Webアプライアンスのユーザー・プロパティ

名前

型

必須

デフォルト

説明

<cacheserver>.node-manager-port

String

省略可

なし

クラスタ内のキャッシュ・サーバーごとに、ノード・マネージャ・ポートがリストされ、ユーザーはこれを変更できます。

<cacheserver>.unicast-listen-port

String

省略可

なし

クラスタ内のキャッシュ・サーバーごとに、そのサーバーのユニキャスト・リスニング・ポートがリストされ、ユーザーはこれを変更できます。

multicast-listen-address

String

省略可

なし

クラスタ全体のマルチキャスト・リスニング・アドレス。1つ以上のwell-known-addressesがリストされる(つまり、クラスタではクラスタの検出にユニキャストを使用している)場合、このマルチキャスト・プロパティはありません。

multicast-listen-port

String

省略可

なし

クラスタ全体のマルチキャスト・リスニング・ポート。1つ以上のwell-known-addressesがリストされる(つまり、クラスタではクラスタの検出にユニキャストを使用している)場合、このマルチキャスト・プロパティはありません。

unicast-listen-port

String

省略可

なし

クラスタのデフォルト・ユニキャスト・リスニング・ポート。この値は、ユニキャスト・リスニング・ポートが定義されていないキャッシュ・サーバーと、クラスタに加わるWebLogic Server管理対象サーバーで使用されます。

<wellknownaddress>.server

String

true

なし

定義されたWell Knownアドレスのいずれかをキャッシュ・サーバーと(一致するリスニング・アドレスおよびポート情報に基づいて)相互に関連付けることができない場合、そのアドレスがここにリストされ、ユーザーがWell Knownアドレスとして使用されるキャッシュ・サーバー名を指定します。このプロパティは必須です。つまり、アプライアンスのプロパティとして指定するか、デプロイメント・プランを介して指定する必要があります。

E.9 サポートされるテンプレート・タイプ

サポートされるテンプレート・タイプは、Oracle Enterprise Linux (OEL)です。

F WebLogic PortalおよびOracle Coherenceのためのキャッシュ構成

この付録は、WebLogic Portalの管理対象Coherenceキャッシュ・サーバーに対するサンプル構成を提供します。Coherenceキャッシュ・プロバイダをアウトオブプロセス・トポロジにデプロイしている場合、WebLogic Portalの管理対象サーバー(つまり、WebLogic Portalサーバー層)は、ローカル記憶域が無効のキャッシュ・クライアントとして構成されます。Coherenceキャッシュは、キャッシュ・サーバーとして動作し、物理的にポータルおよびセッション・データを格納し管理する専用のJVMとして機能します。「WebLogic PortalでのCoherenceキャッシュ・プロバイダの使用方法」を参照してください。

このトポロジでは、セッションおよびキャッシュ構成がマージされたファイルのコピーが2つ必要です。1つはローカル記憶域が無効なWebLogic Portal管理対象サーバー用、もう1つはローカル記憶域が有効なCoherenceキャッシュ・サーバー用です。

例F-1に、WebLogic Portal管理対象サーバーのキャッシュ構成ファイルを示します。この構成により、WebLogic Portal管理対象サーバーはセッション・データをCoherenceキャッシュ・サーバーに格納できます。この構成ファイルは、default-session-cache-config.xmlのセッション・キャッシュ構成とportal-cache-config.xmlのポータル・キャッシュ構成を結合しています。

Coherenceキャッシュ・サーバーの構成ファイルは、セッション・キャッシュ構成セクションとポータル・キャッシュ構成セクションのlocal-storageシステム・プロパティの値をtrueに設定する必要があることを除き、例F-1と同様にできます。詳細は、「アウトオブプロセス・トポロジのCoherenceキャッシュ・プロバイダのデプロイ」を参照してください。

例F-1 WebLogic Portal管理対象サーバーのキャッシュ構成

<?xml version="1.0"?>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!--                                                                       -->
<!--        Coherence BEA WebLogic Portal CacheProvider:                   -->
<!--                  Cache Configuration Descriptor                       -->
<!--                                                                       -->
<!--       (See http://e-docs.bea.com/wlp/docs81/perftune/apenB.html)      -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<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">

<caching-scheme-mapping>

<cache-mapping>
<!--
Cache:
adServiceCache

Use:
Used to store the results of searches for content rendered in a
placeholder (ads). Used by the AdHelper to increase the speed of ad
queries.

Key:
An ad query (java.lang.String).

Value:
An array of com.bea.p13n.content.Content objects.
-->
<cache-name>adServiceCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>32</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>5m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
binaryCache.[repository name]

Use:
Used to cache binary property values for the BEA Repository.

Key:
Node ID + property ID (java.lang.String).

Value:
A byte array associated with the binary property.
-->
<cache-name>binaryCache.*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>256</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
CategoryCache

Use:
Used to cache the root com.beasys.commerce.ebusiness.catalog.Category,
the total number of categories in the product catalog (java.lang.Integer)
and the com.beasys.commerce.ebusiness.catalog.service.category.CategoryInfo
for each category.

Key:
The key for the root Category and the total number of categories is a
java.lang.String. The key for a given CategoryInfo object is a
com.beasys.commerce.ebusiness.catalog.CategoryKey.

Value:
The value for the root Category is a com.beasys.commerce.ebusiness.catalog.Category.
The value for the total number of categories is a java.lang.Integer.
The value for the category info objects is a
com.beasys.commerce.ebusiness.catalog.service.category.CategoryInfo.
-->
<cache-name>CategoryCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1000</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
CategoryTreeCache

Use:
Used to cache portlet category trees.

Key:
A webapp name.

Value:
A CategoryTree object.
-->
<cache-name>CategoryTreeCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
communitiesEntityPropertyCache

Use:
Used to cache community membership capability information for users
accessing communities.

Key:
A composite key of community definition ID and user name.

Value:
A java.util.Map of community membership capabilities.
-->
<cache-name>communitiesEntityPropertyCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
communitiesMemberActiveCache

Use:
Used to cache information about active status for community members.

Key:
A user name.

Value:
A java.lang.String representing the user's community member record
active status.
-->
<cache-name>communitiesMemberActiveCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
complexProducerPortletHandleToIdCache

Use:
Used to cache the primary instance ID of portlets.

Key:
A remote portlet handle.

Value:
A remote portlet primary instance ID.
-->
<cache-name>complexProducerPortletHandleToIdCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1000</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
complexProducerPortletIdToDefinitionLabel

Use:
Used to cache the definition label of portlets.

Key:
A remote portlet primary instance ID.

Value:
A remote portlet definition label.
-->
<cache-name>complexProducerPortletIdToDefinitionLabel:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1000</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
credentialEntryCache

Use:
Used to cache credential vault entries with encrypted credential.

Key:
A com.bea.p13n.security.management.credentials.internal.CredentialEntryLocator.

Value:
A com.bea.p13n.security.management.credentials.CredentialEntry.
-->
<cache-name>credentialEntryCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
documentContentCache

Use:
Used to cache the document bytes for the DocumentManager. It is not
used by the content repositories.

Notes:
Deprecated cache.
-->
<cache-name>documentContentCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
documentIdCache

Use:
Used to caches the results of document searches (ids only) for the
DocumentManager. It is not used by the content repositories.

Notes:
Deprecated cache.
-->
<cache-name>documentIdCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
documentContentCache

Use:
Used to cache the results of document searches for the DocumentManager.
It is not used by the content repositories.

Notes:
Deprecated cache.
-->
<cache-name>documentMetadataCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
discountAssocCache

Use:
Used to cache computed discount associations (applicable to individual
customers or to customer segments).

Key:
A com.beasys.commerce.ebusiness.customer.CustomerPk.

Value:
A com.bea.commerce.ebusiness.discount.association.DiscountAssociation.
-->
<cache-name>discountAssocCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1h</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
discountCache

Use:
Used to cache computed discount definitions (applicable to individual
customers or to customer segments).

Key:
A com.bea.commerce.ebusiness.discount.mgmt.QualificationDiscountId.

Value:
A java.util.Set of
com.bea.commerce.ebusiness.discount.mgmt.QualificationDiscountDef
objects.
-->
<cache-name>discountCache:*</cache-name>
<scheme-name>portal-partitioned</scheme-name>
<init-params>
<init-param>
<param-name>back-size-limit</param-name>
<param-value>10</param-value>
</init-param>
<init-param>
<param-name>back-expiry</param-name>
<param-value>5m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
entityIdCache

Use:
Used to cache the numeric ids for entity property locators.

Key:
A com.bea.p13n.property.PropertyLocator.

Value:
An entity ID (java.lang.Long).
-->
<cache-name>entityIdCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
entityPropertyCache

Use:
Used to caches property values for users and groups.

Key:
A com.bea.p13n.property.PropertyLocator.

Value:
A com.bea.p13n.property.EntityPropertyCache.
-->
<cache-name>entityPropertyCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>10m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
globalDiscountAssocCache

Use:
Used to cache computed global discount associations. This is the set of
discount associations that is applicable to all users.

Key:
A com.beasys.commerce.ebusiness.customer.CustomerPk.

Value:
A com.bea.commerce.ebusiness.discount.association.DiscountAssociation.
-->
<cache-name>globalDiscountAssocCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1h</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
globalDiscountCache

Use:
Used to cache computed global discount definitions. This is the set of
global discounts that is applicable to all users.

Key:
A global discount set name (java.lang.String).

Value:
A java.util.Set of
com.bea.commerce.ebusiness.discount.mgmt.QualificationDiscountDef
objects.
-->
<cache-name>globalDiscountCache:*</cache-name>
<scheme-name>portal-partitioned</scheme-name>
<init-params>
<init-param>
<param-name>back-size-limit</param-name>
<param-value>10</param-value>
</init-param>
<init-param>
<param-name>back-expiry</param-name>
<param-value>5m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
jndiNameCache

Use:
Used to cache the JNDI names of entity property managers and unified
user profile managers.

Key:
An entity ID (java.lang.Long).

Value:
A JNDI name (java.lang.String).
-->
<cache-name>jndiNameCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
netuix.community.definition.cache

Use:
Used to cache community definitions.

Key:
A composite key of webapp name, portal path, and desktop path for a
community.

Value:
A CommunityDefinition object.
-->
<cache-name>netuix.community.definition.cache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
netuix.community.id.to.path.cache

Use:
Used to cache community webapp names, desktop paths, and portal
paths.

Key:
A CommunityDefinitionId.

Value:
The community webapp name, portal path, and desktop path.
-->
<cache-name>netuix.community.id.to.path.cache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
netuix.notification.global

Use:
Used to cache notifications targeted to a user, but not targeted to
an individual web application.

Key:
A user name.

Value:
A java.util.List of Notification objects.
-->
<cache-name>netuix.notification.global:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
nodeCache.[repository name]

Use:
Used to cache BEA Repository nodes.

Key:
A node ID (java.lang.String).

Value:
A com.bea.content.Node.
-->
<cache-name>nodeCache.*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>50</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
nodePathCache.[repository name]

Use:
Used to cache a list of nodes for the BEA Repository based on a path.

Key:
A path (java.lang.String).

Value:
A com.bea.content.Node.
-->
<cache-name>nodePathCache.*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>50</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
p13nSecurityResourceCache

Use:
Used to cache the logical hierarchical elements of WLP security
policies to speed performance of navigating the hierarchy.

Key:
A com.bea.p13n.entitlements.resource.P13nCachedResource.

Value:
A com.bea.p13n.entitlements.resource.P13nCachedResource.
-->
<cache-name>p13nSecurityResourceCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalApp_Quiescence_Decision_Cache

Use:
When Maintenance Mode is enabled, used to cache the access decisions
made per user per feature area of the Portal Administration Tool.

Key:
A com.bea.p13n.management.quiescence.QuiescenceDecisionCacheKey.

Value:
A com.bea.p13n.management.quiescence.QuiescenceDecision.
-->
<cache-name>portalApp_Quiescence_Decision_Cache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalContentUriCache

Use:
Used to cache portal content URIs for a combination of webapp, portal,
locale and optional user name.

Key:
A compound key consisting of the webapp, portal, locale and optional
user name.

Value:
A portal content URI.
-->
<cache-name>portalContentUriCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>0</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalControlTreeCache

Use:
Used to cache portal control trees for a combination of webapp,
portal, desktop, locale and optional user name.

Key:
A compound key consisting of the webapp, portal, locale and optional
user name.

Value:
A portal control tree.
-->
<cache-name>portalControlTreeCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>0</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
PortalFrameworkServiceLevelManager/[webapp]

Use:
Used to cache the state of a portlet instance, suspended or active.

Key:
A java.lang.String (identifies the portlet instance).

Value:
A com.bea.netuix.servicelevel.PortletServiceLevelDescription.
-->
<cache-name>PortalFrameworkServiceLevelManager/*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalLayoutDefinitionCache

Use:
Used to cache LayoutDefinition objects.

Key:
A LayoutDefinitionId.

Value:
A LayoutDefinition.
-->
<cache-name>portalLayoutDefinitionCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalLocalizationLocaleCache

Use:
Used to cache collections of language, character encoding, country
and variant.

Key:
A java.lang.String.

Value:
A java.lang.Set of LocalizationLocale objects.
-->
<cache-name>portalLocalizationLocaleCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>0</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalLocalizationResourceCache

Use:
Used to cache localization resources.

Key:
A com.bea.netuix.application.localization.identifier.LocalizationIntersectionId.

Value:
A com.bea.netuix.application.localization.definition.LocalizationResource.
-->
<cache-name>portalLocalizationResourceCache:*</cache-name>
<scheme-name>portal-partitioned</scheme-name>
<init-params>
<init-param>
<param-name>back-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>back-expiry</param-name>
<param-value>0</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalMarkupDefinitionCache

Use:
Used to cache markup definition information.

Key:
A com.bea.netuix.application.identifier.MarkupDefinitionId.

Value:
A com.bea.netuix.application.definition.MarkupDefinition.
-->
<cache-name>portalMarkupDefinitionCache:*</cache-name>
<scheme-name>portal-partitioned</scheme-name>
<init-params>
<init-param>
<param-name>back-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>back-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portalThemeDefinitionCache

Use:
Used to cache ThemeDefinition objects.

Key:
A ThemeDefinitionId.

Value:
A ThemeDefinition.
-->
<cache-name>portalThemeDefinitionCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
PortletCategoryCache

Use:
Used to cache PortletCategoryDefinition objects.

Key:
A PortletCategoryDefinitionId.

Value:
A PortletCategoryDefinition.
-->
<cache-name>PortletCategoryCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portletControlTreeCache

Use:
Used to cache portlet control trees for floating portlets.

Key:
A composite key of portlet instance ID and locale.

Value:
A portlet control tree.
-->
<cache-name>portletControlTreeCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>0</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
portletPreferencesCache

Use:
Used to cache portlet preferences.

Key:
A portlet preference identifier.

Value:
A com.bea.portlet.prefs.PortletPreferences.
-->
<cache-name>portletPreferencesCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>500</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
ProductItemCache

Use:
Used to cache the total number of product items in the catalog as well
as the product items themselves.

Key:
The key for the total number of product items is a java.lang.String.
The key for the product items is a
com.beasys.commerce.ebusiness.catalog.ProductItemKey.

Value:
The value for the total number of product items is a java.lang.Integer.
The value for the product item is a
com.beasys.commerce.ebusiness.catalog.ProductItem.
-->
<cache-name>ProductItemCache:*</cache-name>
<scheme-name>portal-near</scheme-name>
<init-params>
<init-param>
<param-name>back-expiry</param-name>
<param-value>6h</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
profileTypeCache

Use:
Used to cache user profile types that are used to look up the
appropriate user manager profile manager when retrieving a user
profile.

Key:
A user name (java.lang.String).

Value:
A profile type (java.lang.String).
-->
<cache-name>profileTypeCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
propertyKeyIdCache

Use:
Used to cache the unique ID associated with a property set type,
property set and property name combination.

Key:
A compound key consisting of the property set type, property set, and
property name.

Value:
A java.lang.Long.
-->
<cache-name>propertyKeyIdCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
proxyPortletCache

Use:
Used to cache ProxyPortlets.

Key:
A java.lang.String representing the portlet instance ID.

Value:
Information from the consumer registry and about the proxy portlet
instance.
-->
<cache-name>proxyPortletCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>100</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>0</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
registrationHandleCache

Use:
Used to cache whether or not a particular WSRP registration handle is
valid.

Key:
A WSRP consumer registration handle.

Value:
A java.lang.Boolean.
-->
<cache-name>registrationHandleCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
remoteProducerInfoCache

Use:
Used to cache the metadata for WSRP producers added to a WSRP consumer
application.

Key:
The name of the consumer web application (java.lang.String).

Value:
A java.util.HashMap containing WSRP producer metadata. This map is
keyed by the producer handle of each producer.
-->
<cache-name>remoteProducerInfoCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repo.explicitPropertyCache

Use:
Used to cache explicit property information for all WLP repositories.

Key:
The name of the repository (java.lang.String)

Value:
A java.util.Collection of repository property definition information
for explicit properties in that WLP repository.
-->
<cache-name>repo.explicitPropertyCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repo.nodeIdCache.[repository name]

Use:
Used to cache node information for a specific WLP repository
instance.

Key:
A node ID.

Value:
A repository node data object.
-->
<cache-name>repo.nodeIdCache.*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repo.nodePathCache.[repository name]

Use:
Used to cache node information for a specific WLP repository
instance.

Key:
A node path.

Value:
A repository node data object.
-->
<cache-name>repo.nodePathCache.*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repo.typeBinaryCache.[repository name]

Use:
Used to cache node binary property information for a specific WLP
repository instance.

Key:
A composite key of node UID and binary property UID.

Value:
A byte array representing property information.
-->
<cache-name>repo.typeBinaryCache.*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repo.typeIdCache.[repository name]

Use:
Used to cache node type information for a specific WLP repository
instance.

Key:
A type ID.

Value:
A repository type data object.
-->
<cache-name>repo.typeIdCache.*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repo.typeNameCache.[repository name]

Use:
Used to cache node type information for a specific WLP repository
instance.

Key:
A type name.

Value:
A repository type data object.
-->
<cache-name>repo.typeNameCache.*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
repositoryConfigCache

Use:
Used to cache repository configuration information.

Key:
A repository name.

Value:
A RepositoryConfig.
-->
<cache-name>repositoryConfigCache:*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
searchCache

Use:
Used to cache an array of IDs for nodes that satisfy a content search.

Key:
A com.beasys.commerce.foundation.expression.Search.

Value:
An array of node IDs that satisfy the query.
-->
<cache-name>searchCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>20</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1m</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
typeCache.[repository name]

Use:
Used to cache type information.

Key:
An ObjectClass ID.

Value:
An ObjectClass.
-->
<cache-name>typeCache.*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
typeNameCache.[repository name]

Use:
Used to cache type ID information.

Key:
An ObjectClass name.

Value:
An ObjectClass ID.
-->
<cache-name>typeNameCache.*</cache-name>
<scheme-name>portal-replicated</scheme-name>
</cache-mapping>

<cache-mapping>
<!--
Cache:
versionCache

Use:
Used to cache individual versions of a Node in the BEA Content
Repository.

Key:
A com.bea.content.ID.

Value:
A com.bea.content.virtual.version.Version.
-->
<cache-name>versionCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
virtualNodeCache

Use:
Used to cache a node from a repository that has versioning support
enabled.

Key:
A com.bea.content.ID.

Value:
A com.bea.content.virtual.VirtualNode.
-->
<cache-name>virtualNodeCache:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
wlp.urlCompression.compressed

Use:
Used to map compressed URL IDs to the expanded URL.

Key:
A numeric compressed URL ID.

Value:
An expanded URL.
-->
<cache-name>wlp.urlCompression.compressed:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Cache:
wlp.urlCompression.expanded

Use:
Used to map expanded URLs to compressed URL IDs.

Key:
An expanded URL.

Value:
A compressed URL ID.
-->
<cache-name>wlp.urlCompression.expanded:*</cache-name>
<scheme-name>portal-local</scheme-name>
<init-params>
<init-param>
<param-name>local-size-limit</param-name>
<param-value>1024</param-value>
</init-param>
<init-param>
<param-name>local-expiry</param-name>
<param-value>1d</param-value>
</init-param>
</init-params>
</cache-mapping>

<cache-mapping>
<!--
Default cache mapping.
-->
<cache-name>*</cache-name>
<scheme-name>portal-local</scheme-name>
</cache-mapping>

<!--
The clustered cache used to store Session management data.
-->
<cache-mapping>
<cache-name>session-management</cache-name>
<scheme-name>replicated</scheme-name>
</cache-mapping>

<!--
The clustered cache used to store ServletContext attributes.
-->
<cache-mapping>
<cache-name>servletcontext-storage</cache-name>
<scheme-name>replicated</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-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>

<!--
The local cache used to store Sessions that are not yet distributed (if
there is a distribution controller).
-->
<cache-mapping>
<cache-name>local-session-storage</cache-name>
<scheme-name>unlimited-local</scheme-name>
</cache-mapping>

<!--
The local cache used to store Session attributes that are not distributed
(if there is a distribution controller or attributes are allowed to become
local when serialization fails).
-->
<cache-mapping>
<cache-name>local-attribute-storage</cache-name>
<scheme-name>unlimited-local</scheme-name>
</cache-mapping>

</caching-scheme-mapping>

<caching-schemes>

<local-scheme>
<!--
Cache scheme definition used by all local caches that require size
limitation and/or expiry eviction policies.
-->
<scheme-name>portal-local</scheme-name>
<service-name>PortalLocalCache</service-name>

<eviction-policy>HYBRID</eviction-policy>
<high-units>{local-size-limit 100}</high-units>
<expiry-delay>{local-expiry 1h}</expiry-delay>
</local-scheme>

<local-scheme>
<!--
Cache scheme definition used by all near cache front maps that require
size limitation and/or expiry eviction policies.
-->
<scheme-name>portal-front</scheme-name>
<service-name>PortalLocalCache</service-name>

<eviction-policy>HYBRID</eviction-policy>
<high-units>{front-size-limit 100}</high-units>
<expiry-delay>{front-expiry 0}</expiry-delay>
</local-scheme>

<local-scheme>
<!--
Cache scheme definition used by all partitioned cache backing maps that
require size limitation and/or expiry eviction policies.
-->
<scheme-name>portal-back</scheme-name>
<service-name>PortalLocalCache</service-name>

<eviction-policy>HYBRID</eviction-policy>
<high-units>{back-size-limit 1000}</high-units>
<expiry-delay>{back-expiry 1h}</expiry-delay>
</local-scheme>

<replicated-scheme>
<!--
Replicated caching scheme.
-->
<scheme-name>portal-replicated</scheme-name>
<service-name>PortalReplicatedCache</service-name>

<serializer>
<instance>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</instance>
</serializer>

<backing-map-scheme>
<local-scheme>
<scheme-ref>portal-back</scheme-ref>
</local-scheme>
</backing-map-scheme>

<autostart>true</autostart>
</replicated-scheme>

<distributed-scheme>
<!--
Partitioned caching scheme.
-->
<scheme-name>portal-partitioned</scheme-name>
<service-name>PortalDistributedCache</service-name>

<serializer>
<instance>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</instance>
</serializer>

<local-storage system-property="tangosol.coherence.weblogic.localstorage">false</local-storage>

<backing-map-scheme>
<local-scheme>
<scheme-ref>portal-back</scheme-ref>
</local-scheme>
</backing-map-scheme>

<autostart>true</autostart>
</distributed-scheme>

<near-scheme>
<!--
Near caching scheme.
-->
<scheme-name>portal-near</scheme-name>

<front-scheme>
<local-scheme>
<scheme-ref>portal-front</scheme-ref>
</local-scheme>
</front-scheme>

<back-scheme>
<distributed-scheme>
<scheme-ref>portal-partitioned</scheme-ref>
</distributed-scheme>
</back-scheme>

<invalidation-strategy>{near-strategy present}</invalidation-strategy>
</near-scheme>

<invocation-scheme>
<!--
Invocation service scheme.
-->
<scheme-name>portal-invocation-service</scheme-name>
<service-name>PortalInvocationService</service-name>

<serializer>
<instance>
<class-name>com.tangosol.io.DefaultSerializer</class-name>
</instance>
</serializer>
</invocation-scheme>

<!--
Replicated caching scheme used by the Session management and ServletContext
attribute caches.
-->
<replicated-scheme>
<scheme-name>replicated</scheme-name>
<service-name>ReplicatedSessionsMisc</service-name>
<request-timeout>30s</request-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</replicated-scheme>

<!--
Near caching scheme used by the Session attribute cache. The front cache
uses a Local caching scheme and the back cache uses a Distributed 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>
<distributed-scheme>
<scheme-ref>session-distributed</scheme-ref>
</distributed-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>

<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>
<!-- for disk overflow use this backing scheme instead:
<overflow-scheme>
<scheme-ref>session-paging</scheme-ref>
</overflow-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>
<thread-count>0</thread-count>
<lease-granularity>member</lease-granularity>
<local-storage system-property="tangosol.coherence.session.localstorage">false</local-storage>
<partition-count>257</partition-count>
<backup-count>1</backup-count>
<backup-storage>
<type>on-heap</type>
</backup-storage>
<request-timeout>30s</request-timeout>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-local</scheme-ref>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

<!--
Disk-based Session attribute overflow caching scheme.
-->
<overflow-scheme>
<scheme-name>session-paging</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>session-front</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<external-scheme>
<bdb-store-manager/>
</external-scheme>
</back-scheme>
</overflow-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>

<!--
Clustered invocation service that manages sticky session ownership.
-->
<invocation-scheme>
<service-name>SessionOwnership</service-name>
<request-timeout>30s</request-timeout>
</invocation-scheme>

</caching-schemes>
</cache-config>

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。