3 アプリケーションからデータ・キャッシュへのアクセス

この章では、アプリケーションがActiveCacheを使用してどのように簡単にCoherenceデータ・キャッシュにアクセスできるかについて説明します。ActiveCacheは@Resourceアノテーションを提供します。これによって、Coherence NamedCacheキャッシュ・オブジェクトが識別され、サーブレットまたはEJBに動的に注入できるようになります。リソース・インジェクションの代替手段として、ActiveCacheを使用するアプリケーションは、コンポーネント・ベースのJNDIツリーを使用してNamedCacheを参照できます。

注意: WebLogic Server 12.1.2には、WebLogic Serverドメイン内でのCoherenceアプリケーションのデプロイおよび管理方法を標準化するCoherenceコンテナ統合が含まれています。このガイドでは、下位互換性を考慮してCoherenceの設定手順が示されています。新しい実装ではCoherenceコンテナ統合を使用する必要があります。Coherenceベースのアプリケーションのパッケージ化の詳細は、『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。WebLogic ServerドメインでのCoherenceクラスタの作成および構成の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

この章の内容は以下のとおりです。

• ActiveCacheを使用するためのアプリケーションの開発: 主要手順

• ActiveCacheデプロイメント・トポロジの選択

• データ・キャッシュの作成と構成

• アプリケーションからデータ・キャッシュへのアクセス

• キャッシュ構成ファイルの配置

• サーバー起動時のキャッシュ構成へのアクセス

• アプリケーションのパッケージ化とCoherenceクラスタ・スコープの構成

• Coherenceクラスタの作成と構成

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

• WebLogic Serverの起動

• Coherenceクラスタ・プロパティの監視

ActiveCacheを使用するためのアプリケーションの開発: 主要手順

次の手順は、ActiveCacheをWebLogic Server上で実行されるアプリケーションと共に使用するための手順の概要を説明します。

1. アプリケーションを実行するクラスタ・トポロジを選択します。ActiveCacheデプロイメント・トポロジの選択に関する項を参照してください。

2. アプリケーションが使用するCoherenceキャッシュの構成を指定します。データ・キャッシュの作成と構成に関する項を参照してください。

3. Coherenceキャッシュにアクセスするため、Webアプリケーションにコードを追加します。JNDI参照またはリソース・インジェクションのいずれかを使用して、Coherence NamedCacheキャッシュ・オブジェクトにアクセスします。アプリケーションからデータ・キャッシュへのアクセスに関する項を参照してください。

4. アプリケーションと共にキャッシュ構成ファイルを保存します。ファイルの保存場所は、デプロイされたアプリケーションに対してキャッシュをどのように表示するかに依存します。キャッシュ構成ファイルの配置に関する項を参照してください。

5. 起動時にサーバーがキャッシュ構成ファイルにアクセスする仕組みを決めます。サーバー起動時のキャッシュ構成へのアクセスに関する項を参照してください。

6. Coherenceクラスタは、クラスローダー・スコープです。クラスローダー階層内にcoherence.jarをデプロイする場所は、クラスタ・メンバーシップの処理方法を決定します。アプリケーションのパッケージ化とCoherenceクラスタ・スコープの構成に関する項を参照してください。

7. 必要に応じて、デプロイしたアプリケーションの事前定義クラスタ値を調整します。WLSTまたはWebLogic Server管理コンソールを使用して、一部のクラスタ関連値を構成できます。Coherenceクラスタの作成と構成に関する項を参照してください。

8. スタンドアロンCoherenceキャッシュ・サーバーを起動します。キャッシュ・サーバーの起動に関する項を参照してください。

9. 任意の方法を使用してWebLogic Serverを起動します。WebLogic Serverの起動に関する項を参照してください。

10. WebLogic Server管理コンソールからCoherenceクラスタのランタイム・ステータスを監視します。Coherenceクラスタ・プロパティの監視に関する項を参照してください。

ActiveCacheデプロイメント・トポロジの選択

通常、信頼性と拡張性を高めるため、複数のコンピュータがデータ、リソース、およびサービスの保存と管理を抑制するためにクラスタを使用できます。Coherenceクラスタは、アプリケーションのオブジェクトとデータを保存・管理します。Coherenceデータ・キャッシュに挿入されるデータはすべて、同一のキャッシュ構成を共有するアプリケーションのCoherenceクラスタにあるすべてのサーバーによってアクセス可能です。

ActiveCacheは、いくつかの異なる組合せのアプリケーションとデータ層、またはクラスタ・トポロジに利用できます。異なるクラスタ・トポロジは、WebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバーを組み合わせることで形成できます。ここでは、データ保持専用のJVMインスタンスで稼働しているCoherenceデータ・サーバーとして定義されます。

• In-Processトポロジでは、クラスタ内の(ActiveCacheを活用する)すべてのWebLogic Serverインスタンスは、ストレージが有効化されています。この場合、ストレージの有効化とは、当該サーバーがキャッシュ・ストレージとバックアップ・ストレージを提供することを意味します。個別のデータ層を作成する必要はありません。アプリケーションとデータ・キャッシュは連結され、各サーバー・インスタンスはリクエストとキャッシュ・データを送信できます。

  このトポロジは、開発とテストを主な目的としてサポートされます。処理中のセッション・データをアプリケーション・サーバーを使用して保存することで、このトポロジはきわめて簡単に設定でき、開発とテストを目的として迅速に稼働します。このトポロジは本番向けにお薦めできません。

• Out-Of-Processトポロジでは、スタンドアロンCoherenceキャッシュ・サーバーを使用してデータをホストします。WebLogic Serverインスタンスがストレージ無効になるように構成します。このインスタンスは、リクエストの送信に使用されます。このトポロジは、正しい個別のデータ層を作成し、リクエストを処理中のWebLogic Serverインスタンスのオーバーヘッドを削減します。

• WebLogic Out-Of-Processトポロジは、Out-Of-Processトポロジ上の少し異なるバリエーションです。このトポロジでは、ストレージが有効なWebLogic ServerインスタンスはスタンドアロンCoherenceキャッシュ・サーバーを置き換えます。ストレージが有効/無効なWebLogic Serverインスタンスの組合せが混在します。このトポロジでは、リクエストとデータも独自のサーバーに対して分離されるため、リクエストの処理待機時間も短縮されます。

注意: In-ProcessおよびOut-of-Processデプロイメント・トポロジの詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のデプロイメント・トポロジに関する項を参照してください。

データ・キャッシュの作成と構成

ActiveCacheは、Oracle Coherenceによってサポートされる任意のキャッシュ・タイプを使用するように構成できます。Coherenceキャッシュとその構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』のキャッシュの概要に関する項を参照してください。

アプリケーションからデータ・キャッシュへのアクセス

WebLogic Server 10.3.3以降で実行されるアプリケーションは、ActiveCacheを使用してデータ・キャッシュにアクセスできます。データ・キャッシュは、Coherence NamedCacheキャッシュ・オブジェクトによって表示されます。このオブジェクトは、Coherenceクラスタのメンバー間で共有されるリソースを保持するために設計されています。このようなリソースはメモリー内で管理され、通常はデータベースに恒久的に保存されるデータまたはアセンブル/クラスタ化されたデータから構成されます。つまり、こうしたリソースはキャッシュ済と言われます。

コンポーネント・スコープのJNDIリソース・ツリー内でリソース・インジェクションまたは参照のいずれかによって、アプリケーションはNamedCacheを取得できます。参照を使用する手法は、EJB、サーブレット、またはJSPで使用できます。リソースを注入する手法は、サーブレットまたはEJBで使用できます。

注意: Coherenceの名前が付けられたキャッシュにもCoherence*WebベースのHTTPセッションにも、リモートEJB参照を保存しないことをお薦めします。

リソースを注入してNamedCacheを取得するには

@Resourceアノテーションは、動的にNamedCacheを注入するためにサーブレットまたはEJBで使用されます。このアノテーションは、JSPでは使用できません。アノテーションで使用されるキャッシュの名前は、Coherenceキャッシュ構成ファイルcoherence-cache-config.xmlで定義する必要があります。

例3-1は、NamedCache myCacheのリソース・インジェクションを示します。

例3-1 リソース・インジェクションによるNamedCacheの取得

...
@Resource(mappedName="myCache")
com.tangosol.net.NamedCache nc;
...

JNDIを参照してNamedCacheを取得するには

コンポーネント・スコープJNDIツリーは、NamedCacheを参照するためにEJB、サーブレット、またはJSPで使用されます。

コンポーネント・スコープJNDI参照を使用するには、web.xmlまたはejb-jar.xmlファイルで、com.tangosol.net.NamedCache型のresource-refを定義します。例3-2は、myCacheをNamedCacheとして識別する<resource-ref>スタンザを示します。

注意: <res-auth>および<res-sharing-scope>要素は、この例には登場しません。現在、データ・キャッシュにアクセスするためにリソース・サインオンは実行されないため、<res-auth>要素は無視されます。データ・キャッシュはデフォルトで共有可能でこの挙動はオーバーライドされないため、<res-sharing-scope>要素は無視されます。

例3-2 JNDI参照のresource-refとしてNamedCacheの定義

...
<resource-ref>
  <res-ref-name>coherence/myCache</res-ref-name>
  <res-type>com.tangosol.net.NamedCache</res-type>
  <mapped-name>MyCache</mapped-name>
</resource-ref>
...

キャッシュ構成ファイルの配置

キャッシュ構成ファイルを保存する場所によってキャッシュ・スコープ(つまり、デプロイされたアプリケーションに対するキャッシュの可視性)が決まります。キャッシュ・スコープによってCoherenceノードが定義されます。Coherenceノードは、単一のサーバー・プロセス(WebLogic Serverインスタンス(実行中のCoherence)またはスタンドアロンCoherenceキャッシュ・サーバー)、WebLogic Serverアプリケーション(EAR)、またはアプリケーション・モジュール(Webアプリケーション)になります。1つのCoherenceノード内には多数のデータ・キャッシュが存在できます。

キャッシュの可視性には次の3つのオプションがあります。

• アプリケーション・サーバー・スコープ: コンテナ内にデプロイされたすべてのアプリケーションは、1つのCoherenceノードの一部となります。キャッシュは、サーバー上でデプロイされたすべてのアプリケーションにグローバルに表示されます。

• EARスコープ: 各EAR内にデプロイされたすべてのアプリケーションは、1つのCoherenceノードの一部となります。キャッシュは、EAR内のすべてのモジュールに対して表示されます。たとえば、すべてのモジュールが同一キャッシュを共有する必要がある場合にはこれが推奨デプロイメントとなります。

• WARスコープ: デプロイされた各Webアプリケーションは、独自のCoherenceノードになります。キャッシュは、個々のモジュールに対してのみ表示されます。たとえば、スタンドアロンWARデプロイメントまたはスタンドアロンEJBデプロイメントに対してこれは推奨デプロイメントとなります。

注意: キャッシュ構成は、WebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバーの両方に対して整合性を持つ必要があります。

表3-1 キャッシュのスコープによるキャッシュ構成ファイルの配置

このキャッシュのスコープを指定するには...	キャッシュ構成ファイルを保存するには...	コメント
アプリケーション・サーバー・スコープ	サーバー・クラスパス	詳細は、「サーバー起動時のキャッシュ構成へのアクセス」を参照してください。
EARファイルのアプリケーション・スコープのキャッシュ	EARライブラリ・ディレクトリ内のJARファイル EARのAPP-INF/classesディレクトリ	coherence-cache-config.xmlで定義され、EARレベルで配置されたキャッシュは、EAR内のすべてのモジュールによって参照および共有できます。 EARレベルで定義されたキャッシュは、EAR内の個別のアプリケーションに対してのみ表示されますが、アプリケーションにおいてすべてのEAR全体で一意のサービス名を持つ必要があります。また、EARレベルとモジュール・レベルの両方でキャッシュを定義する場合、キャッシュ名、スキーム名、およびサービス名は、EARレベルのキャッシュ構成およびモジュール・キャッシュ構成全体で一意である必要があります。
EARにおけるWebコンポーネント・スコープ・キャッシュ、またはスタンドアロンWARデプロイメント	WARファイルのWEB-INF/libディレクトリ内のJARファイル WARファイルのWEB-INF/classesディレクトリ	モジュール・レベルで定義されたキャッシュは、個々のモジュールに対してのみ表示されますが、アプリケーションにおいてすべてのモジュール全体で一意のサービス名を持つ必要があります。また、EARレベルとモジュール・レベルの両方でキャッシュを定義する場合、キャッシュ名、スキーム名、およびサービス名は、EARレベルのキャッシュ構成およびモジュール・キャッシュ構成全体で一意である必要があります。
スタンドアロンEJBデプロイメント	EJB-JARファイル	EAR内のEJBモジュールは、モジュール・スコープのキャッシュを持つことはできません。アプリケーション・スコープのキャッシュのみ持つことができます。

サーバー起動時のキャッシュ構成へのアクセス

サーバーは、起動時にキャッシュ構成ファイルにアクセスできる必要があります。これを行うには次の2つの方法があります。

• キャッシュ構成ファイルをサーバー・クラスパスに配置するか、または

• tangosol.coherence.cacheconfigシステム・プロパティを持つサーバー起動コマンドで、キャッシュ構成ファイルの場所を宣言します。このプロパティの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

  例3-3は、サンプルのキャッシュ・サーバー起動コマンドにおけるtangosol.coherence.cacheconfigシステム・プロパティを示します。

  例3-3 サーバー起動コマンドにおけるキャッシュ構成ファイルの宣言

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

2つ(以上)のアプリケーションを取り扱う場合、2つ(以上)の異なるキャッシュ構成を持つ可能性があります。この場合、Coherenceキャッシュ・サーバー上のキャッシュ構成にはこれらを統合した構成が含まれる必要があります。これによって、アプリケーションが同一キャッシュ・クラスタでサポートされるようになります。これはスタンドアロン・キャッシュ・サーバー用にのみ有効です。

アプリケーションのパッケージ化とCoherenceクラスタ・スコープの構成

Coherenceクラスタは、クラスタの通信を可能にするグループ・アドレスを共有するCoherenceノードのグループです。Coherenceクラスタは、クラスローダー階層内にcoherence.jarファイルを配置する場所に従い、クラスローダー・スコープを指定されます。Coherenceクラスタは次のようになります。

• アプリケーション・サーバー・スコープ: JVM全体は1つのCoherenceクラスタとして機能します。

• EARスコープ: 各アプリケーションがCoherenceクラスタになります。

• WARスコープ: アプリケーション内の各WebモジュールがCoherenceクラスタになります。

これら3つのスコープ・シナリオのパッケージングおよび構成オプションは、次の項で説明されます。

• アプリケーション・サーバー・スコープのCoherenceクラスタの構成

• EARスコープのCoherenceクラスタの構成

• WARスコープのCoherenceクラスタの構成

アプリケーション・サーバー・スコープのCoherenceクラスタの構成

この構成を使用すると、Coherenceキャッシュに直接アクセスしているWebLogic Serverインスタンス上でデプロイされたすべてのアプリケーションは、1つのCoherenceクラスタの一部となります。キャッシュは、サーバー上でデプロイされたすべてのアプリケーションに表示されます。この構成は、クラスタ内で最小限の数のCoherenceノードを作成します(各WebLogic Serverインスタンス用)。

Coherenceライブラリはサーバーのクラスパスでデプロイされるため、Coherenceクラスのコピーが1つのみJVMに読み込まれ、リソース使用率が最小になります。ただし、すべてのアプリケーションがCoherenceクラスタ構成を使用しているため、1つのアプリケーションが誤動作を起こすとすべてのアプリケーションに影響が及びます。

Coherenceデータ・キャッシュをアプリケーション・サーバー・スコープのCoherenceクラスタと共に使用するには、

1. WebLogic Serverシステム・クラスパスを編集し、coherence.jarとWL_HOME/common/deployable-libraries/active-cache.jarをシステム・クラスパス内にインクルードします。active-cache.jarは、システム・クラスパス内のdeployable-librariesフォルダからのみ参照し、他の場所にコピーしないでください。

2. (オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBeanを作成し、ServerMBean内でそれを参照します。WebLogic Server管理コンソールまたはWLSTを使用して、MBeanを作成・参照できます。例3-9のcreateServerScopedCoherenceSystemResourceを参照してください。

EARスコープのCoherenceクラスタの構成

この構成を使用すると、各EAR内にデプロイされたすべてのアプリケーションは、1つのCoherenceクラスタの一部となります。キャッシュは、EAR内のすべてのモジュールに対して表示されます。たとえば、すべてのモジュールが同一のCoherenceノードを共有する必要がある場合にはこれが推奨デプロイメントとなります。1つのEARのみをアプリケーション・サーバーにデプロイする場合にも推奨構成となります。

この構成は、クラスタ内で2番目に最小限の数のCoherenceノードを作成します(デプロイされた各EAR用)。Coherenceライブラリはアプリケーションのクラスパスでデプロイされるため、Coherenceクラスのコピーが1つのみ各EARに読み込まれます。

EAR内のすべてのWebアプリケーションは同一クラスタ構成を共有するため、任意のアプリケーションで誤動作が起こると、EAR内のすべてのWebアプリケーションに影響が及びます。EARスコープCoherenceクラスタは、アプリケーション・サーバー・クラスパスへの変更が必要ないため、デプロイメントの手間を省けます。

CoherenceキャッシュをEARスコープのCoherenceクラスタと共に使用するには、

1. 次の方法のいずれかを使用し、coherence.jarおよびactive-cache.jarファイルを、アプリケーションがデプロイされるすべてのターゲット・サーバーに共有ライブラリとしてデプロイします。

   • WebLogic Server管理コンソールを使用し、coherence.jarおよびactive-cache.jarを共有ライブラリとしてデプロイします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJava EEライブラリのインストールに関する項を参照してください。

     管理コンソールの代替手段として、コマンドライン上でJARファイルをデプロイできます。次はデプロイメント・コマンドのサンプルです。

     java weblogic.Deployer -username <> -password <> -adminurl <> -deploy coherence.jar -name coherence -library -targets <>
     
     java weblogic.Deployer -username <> -password <> -adminurl <> -deploy active-cache.jar -name active-cache -nostage -library -targets <>
     

   • coherence.jarおよびactive-cache.jarをアプリケーションのEAR APP-INF/libフォルダにコピーします。ただし、共有ライブラリとしてデプロイする方法が優先されます。

2. ライブラリとしてcoherence.jarおよびactive-cache.jarファイルを参照します。例3-4は、サンプルのweblogic-application.xml構成ファイルを示します。

   例3-4 weblogic-application.xmlファイルで参照されるcoherenceおよびactive-cache JAR

   <weblogic-application>
   ...
     <library-ref>
       <library-name>coherence</library-name>
     </library-ref>
      ...
     <library-ref>
       <library-name>active-cache</library-name>
     </library-ref>
   ...
   </weblogic-application>
   

3. (オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBeanを作成し、weblogic-application.xmlファイル内のcoherence-cluster-ref要素として参照します。この要素によって、アプリケーションはCoherenceClusterSystemResourceMBean属性によって指定されるとおりにCoherenceクラスタに登録できます。

   例3-5はサンプル構成を示します。サンプル内のmyCoherenceCluster MBeanは、CoherenceClusterSystemResourceMBean型です。

   例3-5 EARスコープ・クラスタのcoherence-cluster-ref要素

   <weblogic-application>
   ...
     <coherence-cluster-ref>
       <coherence-cluster-name>
        myCoherenceCluster
       </coherence-cluster-name>
     </coherence-cluster-ref> 
   ...
   </weblogic-application>  
   

アプリケーション・スコープCoherenceクラスタにフィルタ処理クラスローダーを定義するには、

coherence.jarがアプリケーション・サーバー・クラスパス内に配置される場合、フィルタ処理クラスローダーを定義してEARスコープ・クラスタを構成できます。これは、次の手順で示されます。

1. coherence.jarをアプリケーション・クラスパスに配置します。

2. EARファイル内のフィルタ処理クラスローダーを構成します。

   フィルタ処理クラスローダーは、weblogic-application.xmlファイルの<prefer-application-packages>スタンザで定義されます。例3-6はサンプルのフィルタ処理クラスローダー構成を示します。package-name要素は、coherence.jarおよびactive-cache.jar内のクラスのパッケージ名を示します。

   例3-6 フィルタ処理クラスローダーの構成

   <weblogic-application>
   ...
    <prefer-application-packages>
      <package-name>com.tangosol.*</package-name>
      <package-name>weblogic.coherence.service.*</package-name>
      <package-name>com.oracle.coherence.common.*</package-name>
    </prefer-application-packages>
   ...
   </weblogic-application>
   

WARスコープのCoherenceクラスタの構成

この構成を使用するか、または1つのアプリケーションのみがCoherenceキャッシュを使用できるようにする場合、デプロイされた各Webアプリケーションは独自のCoherenceクラスタになります。キャッシュは、個々のモジュールに対してのみ表示されます。たとえば、スタンドアロンWARデプロイメントまたはスタンドアロンEJBデプロイメントに対してこれは推奨デプロイメントとなります。

複数のWARファイルをデプロイしている場合、この構成はクラスタ内で最大数のCoherenceノード(coherence.jarを使用するデプロイされた各WARファイル用)を作成します。また、これによって3つの構成のリソース使用率が最大になります。つまり、Coherenceクラスの1つのコピーがデプロイされた各WARに読み込まれます。他方、デプロイされた各Webアプリケーションはその独自クラスタであるため、Webアプリケーションは他の潜在的に誤動作を起こす可能性があるWebアプリケーションから完全に孤立します。

注意: EAR内のWebモジュールには、モジュール・スコープCoherenceノードを含めることができますが、EAR内のEJBモジュールにはアプリケーション・スコープCoherenceノードを含めることができます。

CoherenceキャッシュをWARスコープのCoherenceクラスタと共に使用するには

1. WebLogic Server管理コンソールを使用し、coherence.jarおよびactive-cache.jarを、アプリケーションがデプロイされるすべてのターゲット・サーバーに共有ライブラリとしてデプロイします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJava EEライブラリのインストールに関する項を参照してください。

   管理コンソールの代替手段として、コマンド・ライン上でJARファイルもデプロイできます。次はデプロイメント・コマンドのサンプルです。

   java weblogic.Deployer -username <> -password <> -adminurl <> -deploy coherence.jar -name coherence -library -targets <>
   
   java weblogic.Deployer -username <> -password <> -adminurl <> -deploy active-cache.jar -name active-cache -nostage -library -targets <>
   

2. coherence.jarおよびactive-cache.jarをオプション・パッケージとして、Coherenceを使用する各モジュールのmanifest.mfファイルにインポートします。

   マニフェスト・ファイル使用の代替手段として、coherence.jarおよびactive-cache.jarを各WARファイルのWEB-INF/libディレクトリにコピーします。

   例3-7は、サンプルのmanifest.mfファイルのコンテンツを示します。

   例3-7 manifest.mfファイルにおけるcoherenceおよびactive-cache JARの参照

   Manifest-Version: 1.0
   Extension-List: coherence active-cache
   coherence-Extension-Name: coherence
   active-cache-Extension-Name: active-cache
   

3. (オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBeanを作成し、weblogic.xmlまたはweblogic-ejb-jar.xmlファイル内のcoherence-cluster-ref要素として参照します。

   例3-8は、weblogic.xmlファイル内のWARスコープ・クラスタのサンプル構成を示します。myCoherenceCluster MBeanは、CoherenceClusterSystemResourceMBean型です。

   例3-8 WARスコープ・クラスタのcoherence-cluster-ref要素

   <weblogic-web-app>
   ...
     <coherence-cluster-ref>
       <coherence-cluster-name>
        myCoherenceCluster
       </coherence-cluster-name>
     </coherence-cluster-ref> 
   ...
   </weblogic-web-app>
   

Coherenceクラスタの作成と構成

WLSTまたは管理コンソールを使用し、Coherenceクラスタを作成および構成し、クラスタ構成がアクセス可能になるWebLogic Serverインスタンスまたはクラスタを選択できます。

例3-9で示されるcreateCoherenceClusterMBean.py WLSTスクリプトは、管理サーバー(myserver)にデプロイしたサーバー・スコープ構成を含む3つのCoherenceクラスタを構成します。

次のサンプル・コマンドを使用してWLSTを呼び出してスクリプトを実行します。

java -Dadmin.username=weblogic -Dadmin.password=password -Dadmin.host=localhost
-Dadmin.port=7001 -Dtangosol-override="c:/temp/tangosol-coherence-override.xml"
weblogic.WLST c:/temp/createCoherenceClusterMBean.py

例3-9 createCoherenceClusterMBean.py

from java.util import *
from javax.management import *
from java.lang import *
import javax.management.Attribute

"""
This script configures three Coherence Cluster System Resource MBeans and deploys them to the admin server
"""

def createCoherenceSystemResource(wlsTargetNames, coherenceClusterSourceName):

       name = coherenceClusterSourceName
       # start creation
       print 'Creating CoherenceClusterSystemResource with name '+ name
       cohSR = create(name,"CoherenceClusterSystemResource")
       cohBean = cohSR.getCoherenceClusterResource()
       cohCluster = cohBean.getCoherenceClusterParams()
         cohCluster.setUnicastListenAddress("localhost")
         cohCluster.setUnicastListenPort(7001)
       cohCluster.setUnicastPortAutoAdjust(true)
       # you can set up the multicast port or define WKAs
       cohCluster.setMulticastListenAddress("231.1.1.1")
       cohCluster.setMulticastListenPort(8001)
       cohCluster.setTimeToLive(5)

       for wlsTargetName in wlsTargetNames:
          cd("Servers/"+wlsTargetName)
          target = cmo
          cohSR.addTarget(target)
          cd("../..")

def createServerScopedCoherenceSystemResource(wlsTargetNames, coherenceClusterSourceName):

       name = coherenceClusterSourceName
       # start creation
       print 'Creating CoherenceClusterSystemResource with name '+ name
       cohSR = create(name,"CoherenceClusterSystemResource")
       cohBean = cohSR.getCoherenceClusterResource()
       cohCluster = cohBean.getCoherenceClusterParams()
         cohCluster.setUnicastListenAddress("localhost")
         cohCluster.setUnicastListenPort(7002)
       cohCluster.setUnicastPortAutoAdjust(true)
       # you can set up the multicast port or define WKAs
       cohWKAs = cohCluster.getCoherenceClusterWellKnownAddresses()
       cohWKA = cohWKAs.createCoherenceClusterWellKnownAddress("wka1")
       cohWKA.setName("wka1")
       cohWKA.setListenAddress("localhost")
       cohWKA.setListenPort(9001)

       for wlsTargetName in wlsTargetNames:
          cd("Servers/"+wlsTargetName)
          target = cmo
          cohSR.addTarget(target)
            print cmo
            serverBean = cmo
            serverBean.setCoherenceClusterSystemResource(cohSR)
          cd("../..")

def createCustomCoherenceSystemResource(wlsTargetNames, coherenceClusterSourceName, tangosolOverrideFile):

       name = coherenceClusterSourceName
       # start creation
       cohSR = getMBean("/CoherenceClusterSystemResources/"+name)
       if cohSR == None:
         print 'Creating CoherenceClusterSystemResource with name '+ name
         cohSR = create(name,"CoherenceClusterSystemResource")
         cohSR.importCustomClusterConfigurationFile(tangosolOverrideFile)       

       for wlsTargetName in wlsTargetNames:
          cd("Servers/"+wlsTargetName)
          target = cmo
          cohSR.addTarget(target)
          cd("../..")

props = System.getProperties()
ADMIN_NAME = props.getProperty("admin.username")
ADMIN_PASSWORD = props.getProperty("admin.password")
ADMIN_HOST = props.getProperty("admin.host")
ADMIN_PORT = props.getProperty("admin.port")
ADMIN_URL = "t3://"+ADMIN_HOST+":"+ADMIN_PORT

TANGOSOL_OVERRIDE = props.getProperty("tangosol-override")

TARGETS = [ 'myserver' ]

print "Starting the script ..."
try :
       connect(ADMIN_NAME, ADMIN_PASSWORD, ADMIN_URL)
       edit()
       startEdit()
       createCoherenceSystemResource(TARGETS, 'cohSystemResource') 
       createServerScopedCoherenceSystemResource(TARGETS, 'serverScopedCohSystemResource') 
       createCustomCoherenceSystemResource(TARGETS, 'customCohSystemResource',TANGOSOL_OVERRIDE) 
       save()
       activate(block="true")
       disconnect()
       print 'Done configuring the Coherence Cluster System Resources'
except:
       dumpStack()
       undo('true','y')

管理コンソールの手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのCoherenceクラスタの作成に関する項およびCoherenceクラスタの構成に関する項を参照してください。

クラスタ関連値は、WebLogic Server構成リポジトリの記述子ファイルに保存されます。

DOMAIN_HOME/config/coherence/CoherenceClusterSystemResourceName/CoherenceClusterSystemResourceName-####-coherence.xml (DOMAIN_HOMEは、d:/oracle//user_projects/domains/domain_nameなどのWebLogic Serverドメインをインストールした場所です。)

たとえば、C:\Oracle\Middleware\user_projects\domains\base_domain\config\coherence\cohSystemResource\cohSystemResource-0759-coherence.xml

あるいは、例3-10で示すように、tangosol-coherence-override.xmlなどのカスタム構成ファイル内で構成することで、クラスタに指定されていないプロパティを構成できます。

例3-10 tangosol-coherence-override.xml

<?xml version='1.0'?>
<!--
This operational configuration override file is for use with Coherence in
a development mode.
-->
<coherence xml-override="/tangosol-coherence-override.xml">
 <cluster-config>
  <multicast-listener>
    <time-to-live system-property="tangosol.coherence.ttl">4</time-to-live>
    <join-timeout-milliseconds>3000</join-timeout-milliseconds>
  </multicast-listener>

  <packet-publisher>
   <packet-delivery>
    <timeout-milliseconds>30000</timeout-milliseconds>
   </packet-delivery>
  </packet-publisher>
 </cluster-config>

 <logging-config>
  <severity-level system-property="tangosol.coherence.log.level">5</severity-level>
  <character-limit system-property="tangosol.coherence.log.limit">0</character-limit>
 </logging-config>
</coherence>

WLSTを使用して、カスタム・クラスタ構成ファイル(例3-9のcreateCustomCoherenceSystemResourceを参照)またはWebLogic Server管理コンソールをインポートします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・クラスタ構成のインポートに関する項を参照してください。

注意: カスタム構成ファイルをインポートしてクラスタ関連プロパティを指定する場合、ファイル内で指定されるプロパティは、WLSTまたはWebLogic Server管理コンソールを使用して指定されたプロパティと同一にしてはなりません。

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

スタンドアロンCoherenceキャッシュ・サーバーは、すべてのキャッシュ・データの保存および管理に関与する専用のJVMです。Coherenceデータ・クラスタ内のシニア・ノード(1番目のノード)は、起動に数秒かかる可能性がありますが、後続のノードの起動にかかる時間は最短になります。そのため、パフォーマンスを最適化するには、常にCoherenceキャッシュ・サーバーを起動してからWebLogic Serverインスタンスを起動する必要があります。これによって、ActiveCacheを使用するアプリケーションは、最短の時間(単位はミリ秒)で起動できることが保証されます。ActiveCacheを使用する任意の追加Webアプリケーションは、シニア・データ・メンバーとなることが保証されません。そのため、WebLogic Serverの起動には最小限の影響しか及ぼされません。

注意: 最初にキャッシュ・サーバーを起動するか、またはWebLogic Serverインスタンスを起動するかは、利用するクラスタ・トポロジに依存します。 In-Processトポロジ(ActiveCacheを利用しているすべてのストレージが有効なWebLogic Serverインスタンス)を使用している場合、どちらのWebLogic Serverインスタンスを最初に起動するかは関係ありません。 Out-of-Processトポロジ(ストレージが無効なWebLogic serverインスタンスおよびスタンドアロン・キャッシュ・サーバー)を使用している場合、最初にキャッシュ・サーバーを起動した後、WebLogic Serverインスタンスを起動します。 WebLogic Out-of-Processトポロジを使用している場合、使用するトポロジでは、ストレージが有効/無効なWebLogic Serverインスタンスが混在します。ストレージが有効なインスタンスを最初に起動し、その次にストレージが無効なインスタンスを起動してください。

ノード・マネージャを使用したキャッシュ・サーバーの起動

WebLogic Server 10.3.4では、WebLogic Server管理サーバー(管理コンソールまたはWLSTによる)およびjavaベースのノード・マネージャを使用して、スタンドアロンのCoherenceキャッシュ・サーバーのライフサイクルを管理および監視できます。

ノード・マネージャは、WebLogic Serverユーティリティです。これを使用すると、サーバーを起動・停止したり、自動的にリモートで再起動したりできます。ノード・マネージャは、ノード・マネージャを使用して制御するCoherenceサーバー・インスタンスをホストする各コンピュータ上で実行する必要があります。

ノード・マネージャを使用してキャッシュ・サーバーを起動する前提条件の手順は次のとおりです。

1. サーバーを起動するようにノード・マネージャを構成します。

   『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの一般的な構成に関する項を参照してください。

2. ノード・マネージャを起動します。

   ノード・マネージャは、コマンド・プロンプトまたはスクリプトを使用して手動で起動できます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの起動および停止に関する項を参照してください。

注意: ユーザー・クラスをクラスパスに追加する必要がある場合、FEATURES_HOME/weblogic.server.modules.coherence.server_10.3.4.0.jar:COHERENCE_HOME/lib/coherence.jarも追加する必要があります。ここで、FEATURES_HOMEは機能ディレクトリを示し、通常はORACLE_HOME\wlserver\modules\featuresで、COHERENCE_HOMEはCoherenceディレクトリを示し、通常はORACLE_HOME\coherence_3.6です(ノード・マネージャ・マシンの)。クラスパスを指定しない場合、デフォルトで直前のクラスパスが使用されます。

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

管理コンソールを使用してCoherenceキャッシュ・サーバーを起動する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理コンソールからのCoherenceサーバーの起動に関する項を参照してください。

WLSTを使用したキャッシュ・サーバーの起動

例3-11で示されるstartCoh.py WLSTスクリプトは、スタンドアロンCoherenceサーバー(COH_server1)を起動します。

次のサンプル・コマンドを使用してWLSTを呼び出してスクリプトを実行します。

java weblogic.WLST d:/temp/startCoh.py

例3-11 startCoh.py

props = System.getProperties()
 
ADMIN_NAME = props.getProperty("admin.username")
if ADMIN_NAME == None: ADMIN_NAME = 'weblogic'
 
ADMIN_PASSWORD = props.getProperty("admin.password")
if ADMIN_PASSWORD == None : ADMIN_PASSWORD = 'password'
 
ADMIN_HOST = props.getProperty("admin.host")
if ADMIN_HOST == None : ADMIN_HOST = 'localhost'
 
ADMIN_PORT = props.getProperty("admin.port")
if ADMIN_PORT == None : ADMIN_PORT = '7001'
 
ADMIN_URL = "t3://" + ADMIN_HOST + ":" + ADMIN_PORT
 
COH_SERVER = props.getProperty("server")
if COH_SERVER == None : COH_SERVER = 'COH_server1'
 
connect(ADMIN_NAME, ADMIN_PASSWORD, ADMIN_URL)
 
domainRuntime()
 
lifecycle = getMBean('/CoherenceServerLifeCycleRuntimes/' + COH_SERVER)
seconds = 5
 
print("starting: " + COH_SERVER);
print("before state:" + lifecycle.getState())
lifecycle.start()
print("after state:" + lifecycle.getState())
java.lang.Thread.sleep(seconds * 1000)
print("after state:" + lifecycle.getState())
 
disconnect()

例3-12で示すように、stopCoh.py WLSTスクリプトを使用し、同一のCoherenceキャッシュ・サーバーをシャットダウンできます。

例3-12 stopCoh.py

props = System.getProperties()
 
ADMIN_NAME = props.getProperty("admin.username")
if ADMIN_NAME == None: ADMIN_NAME = 'weblogic'
 
ADMIN_PASSWORD = props.getProperty("admin.password")
if ADMIN_PASSWORD == None : ADMIN_PASSWORD = 'password'
 
ADMIN_HOST = props.getProperty("admin.host")
if ADMIN_HOST == None : ADMIN_HOST = 'localhost'
 
ADMIN_PORT = props.getProperty("admin.port")
if ADMIN_PORT == None : ADMIN_PORT = '7001'
 
ADMIN_URL = "t3://" + ADMIN_HOST + ":" + ADMIN_PORT
 
COH_SERVER = props.getProperty("server")
if COH_SERVER == None : COH_SERVER = 'COH_server1'
 
connect(ADMIN_NAME, ADMIN_PASSWORD, ADMIN_URL)
 
domainRuntime()
 
lifecycle = getMBean('/CoherenceServerLifeCycleRuntimes/' + COH_SERVER)
seconds = 5
 
print("forceShutdown: " + COH_SERVER);
lifecycle.forceShutdown()
print("after state:" + lifecycle.getState())
 
disconnect()

起動スクリプトによるキャッシュ・サーバーの起動

もう1つの方法として、WebLogic Server管理サーバーを使用せずにCoherenceキャッシュ・サーバーを起動するには、次の手順を実行します。

1. Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。次に示す例は、ActiveCacheと共に使用するためにストレージが有効なキャッシュ・サーバーを起動するスクリプトの非常にシンプルな例です。このサンプルは、Java HotSpot VMを使用していることを前提としています。詳細は、『Oracle Coherence開発者ガイド』のJVMチューニングに関する項を参照してください。

   java -server -Xms512m -Xmx512m 
   -cp <Coherence installation dir>/lib/coherence.jar
   -Dtangosol.coherence.management.remote=true 
   -Dtangosol.coherence.cacheconfig=WEB-INF/classes/cache_configuration_file 
   -Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer
   

   この例では、cache_configuration_fileは、coherence-cache-config.xmlファイル内のキャッシュ構成を参照します。キャッシュ・サーバーに定義されたキャッシュ構成は、同一のCoherenceクラスタ上で稼働するアプリケーション・サーバー用に定義された構成と同一にする必要があります。

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

ノード・マネージャを使用したキャッシュ・サーバーの再起動

Coherenceキャッシュ・サーバーは、ライフサイクル情報(ステータス)をDOMAIN_HOME/servers_coherence/COHserver_name/data/nodemanager/COHserver_name.stateに書き込みます。ノード・マネージャは、当該ディレクトリ内にあるこのファイルとその他のファイルを監視し、キャッシュ・サーバーが稼働中かどうかを検出し、そのステータス(クリーン・シャットダウンによって、クラッシュや起動失敗とは異なる最終状態が生成される)に基づいて、再起動するかどうかを検出します。

また、ノード・マネージャを再起動する場合、CrashRecoveryEnabledプロパティの値も考慮します。この値は、weblogic.nodemanager.NodeManager起動コマンド内で指定するか、NodeManagerHome (通常は、ORACLE_HOME\user_projects\domains\domain_name\nodemanager (ORACLE_HOMEはWebLogic ServerをインストールしたときにOracleホームとして指定した場所))にあるnodemanager.propertiesファイル内で定義できます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャとシステム・クラッシュ・リカバリに関する項およびnodemanager.propertiesの確認に関する項を参照してください。

注意: ノード・マネージャが実行されていない場合(ダウンしている場合またはまだ起動していない場合)、キャッシュ・サーバーは状態をunknownとして報告します。また、ノード・マネージャがサーバー起動にまったく使用されていない場合(初期作成時など)、キャッシュ・サーバーは状態をunknownとして報告します。これは、キャッシュ・サーバーのライフサイクル・ステータスが、DOMAIN_HOME/servers_coherence/COHserver_name/data/nodemanager/COHserver_name.stateファイルから情報を取得するノード・マネージャによってのみ決定されるためです。

Coherenceキャッシュ・サーバー・ログ・ファイルおよびサーバー固有のノード・マネージャ情報ファイルは、DOMAIN_HOME/servers_coherence/COHserver_name/の直下に配置されます。ここで、DOMAIN_HOMEはORACLE_HOME/user_projects/domains/domain_nameなどのWebLogic Serverドメインをインストールした場所、COHserver_nameはCoherenceキャッシュ・サーバー名です。

WebLogic Serverの起動

WebLogic Serverでは、複数の方法でサーバー・インスタンスを起動および停止できます。どの方法を選ぶかは、管理コンソールとコマンド・ライン・インタフェースのどちらを使用するか、およびサーバーのライフサイクルの管理にノード・マネージャを使用するかどうかによって決まります。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。クイック・リファレンスについては、サーバーの起動と停止:クイック・リファレンスに関する項を参照してください。

デフォルトでは、ActiveCacheを利用しているWebLogic Serverインスタンスは、ストレージが有効モードで起動します。WebLogic Serverインスタンスをストレージが有効モードで起動するには、コマンドライン・プロパティ-Dtangosol.coherence.session.localstorage=trueをサーバー起動コマンドにインクルードします。

詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドラインを使用したサーバー・インスタンスの起動に関する項を参照してください。

Coherenceクラスタ・プロパティの監視

WebLogic Server管理コンソールには、クラスタのサイズ、メンバー、およびバージョンなどの特定のアプリケーションまたはモジュールに関連付けられたCoherenceクラスタのランタイム監視情報が表示されます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのCoherenceクラスタの監視に関する項を参照してください。