ActiveCacheを使用すると、アプリケーションはCoherenceデータ・キャッシュに簡単にアクセスできます。ActiveCacheは@Resource
アノテーションを提供します。これによって、Coherence NamedCache
キャッシュ・オブジェクトが識別され、サーブレットまたはEJBに動的に注入できるようになります。リソース・インジェクションの代替手段として、ActiveCacheを使用するアプリケーションは、コンポーネント・ベースのJNDIツリーを使用してNamedCache
を参照できます。
次の手順は、ActiveCacheをWebLogic Server上で実行されるアプリケーションと共に使用するための手順の概要を説明します。
アプリケーションを実行するクラスタ・トポロジを選択します。ActiveCacheデプロイメント・トポロジの選択に関する項を参照してください。
アプリケーションが使用するCoherenceキャッシュの構成を指定します。データ・キャッシュの作成と構成に関する項を参照してください。
Coherenceキャッシュにアクセスするため、Webアプリケーションにコードを追加します。JNDI参照またはリソース・インジェクションのいずれかを使用して、Coherence NamedCache
キャッシュ・オブジェクトにアクセスします。アプリケーションからデータ・キャッシュへのアクセスに関する項を参照してください。
アプリケーションと共にキャッシュ構成ファイルを保存します。ファイルの保存場所は、デプロイされたアプリケーションに対してキャッシュをどのように表示するかに依存します。キャッシュ構成ファイルの配置に関する項を参照してください。
起動時にサーバーがキャッシュ構成ファイルにアクセスする仕組みを決めます。サーバー起動時のキャッシュ構成へのアクセスに関する項を参照してください。
Coherenceクラスタは、クラスローダー・スコープです。クラスローダー階層内にcoherence.jar
をデプロイする場所は、クラスタ・メンバーシップの処理方法を決定します。アプリケーションのパッケージ化とCoherenceクラスタ・スコープの構成に関する項を参照してください。
必要に応じて、デプロイしたアプリケーションの事前定義クラスタ値を調整します。WLSTまたはWebLogic Server管理コンソールを使用して、一部のクラスタ関連値を構成できます。Coherenceクラスタの作成と構成に関する項を参照してください。
スタンドアロンCoherenceキャッシュ・サーバーを起動します。キャッシュ・サーバーの起動に関する項を参照してください。
任意の方法を使用してWebLogic Serverを起動します。WebLogic Serverの起動に関する項を参照してください。
WebLogic Server管理コンソールからCoherenceクラスタのランタイム・ステータスを監視します。Coherenceクラスタ・プロパティの監視に関する項を参照してください。
通常、信頼性と拡張性を高めるため、複数のコンピュータがデータ、リソース、およびサービスの保存と管理を抑制するためにクラスタを使用できます。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ユーザー・ガイド』のトポロジのデプロイメントに関する項を参照してください。 |
ActiveCacheは、Oracle Coherenceによってサポートされる任意のキャッシュ・タイプを使用するように構成できます。Coherenceキャッシュとその構成に関する詳細は、『Oracle Coherence開発者ガイド』の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> 要素は無視されます。 |
キャッシュ構成ファイルを保存する場所によってキャッシュ・スコープ(つまり、デプロイされたアプリケーションに対するキャッシュの可視性)が決まります。キャッシュ・スコープによって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レベルで定義されたキャッシュは、EAR内の個別のアプリケーションに対してのみ表示されますが、アプリケーションにおいてすべてのEAR全体で一意のサービス名を持つ必要があります。また、EARレベルとモジュール・レベルの両方でキャッシュを定義する場合、キャッシュ名、スキーム名、およびサービス名は、EARレベルのキャッシュ構成およびモジュール・キャッシュ構成全体で一意である必要があります。 |
EARにおけるWebコンポーネント・スコープ・キャッシュ、またはスタンドアロンWARデプロイメント |
|
モジュール・レベルで定義されたキャッシュは、個々のモジュールに対してのみ表示されますが、アプリケーションにおいてすべてのモジュール全体で一意のサービス名を持つ必要があります。また、EARレベルとモジュール・レベルの両方でキャッシュを定義する場合、キャッシュ名、スキーム名、およびサービス名は、EARレベルのキャッシュ構成およびモジュール・キャッシュ構成全体で一意である必要があります。 |
スタンドアロンEJBデプロイメント |
|
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.jar
ファイルを配置する場所に従い、クラスローダー・スコープを指定されます。Coherenceクラスタは次のようになります。
アプリケーション・サーバー・スコープ: JVM全体は1つのCoherenceクラスタとして機能します。
EARスコープ: 各アプリケーションがCoherenceクラスタになります。
WARスコープ: アプリケーション内の各WebモジュールがCoherenceクラスタになります。
これら3つのスコープ・シナリオのパッケージングおよび構成オプションは、次の項で説明されます。
この構成を使用すると、Coherenceキャッシュに直接アクセスしているWebLogic Serverインスタンス上でデプロイされたすべてのアプリケーションは、1つのCoherenceクラスタの一部となります。キャッシュは、サーバー上でデプロイされたすべてのアプリケーションに表示されます。この構成は、クラスタ内で最小限の数のCoherenceノードを作成します(各WebLogic Serverインスタンス用)。
Coherenceライブラリはサーバーのクラスパスでデプロイされるため、Coherenceクラスのコピーが1つのみJVMに読み込まれ、リソース使用率が最小になります。ただし、すべてのアプリケーションがCoherenceクラスタ構成を使用しているため、1つのアプリケーションが誤動作を起こすとすべてのアプリケーションに影響が及びます。
Coherenceデータ・キャッシュをアプリケーション・サーバー・スコープのCoherenceクラスタと共に使用するには、
WebLogic Serverシステム・クラスパスを編集し、coherence.jar
とWL_HOME
/common/deployable-libraries/active-cache.jar
をシステム・クラスパス内にインクルードします。active-cache.jar
は、システム・クラスパス内のdeployable-libraries
フォルダからのみ参照し、他の場所にコピーしないでください。
(オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBean
を作成し、ServerMBean
内でそれを参照します。WebLogic Server管理コンソールまたはWLSTを使用して、MBeanを作成・参照できます。例3-9のcreateServerScopedCoherenceSystemResource
を参照してください。
この構成を使用すると、各EAR内にデプロイされたすべてのアプリケーションは、1つのCoherenceクラスタの一部となります。キャッシュは、EAR内のすべてのモジュールに対して表示されます。たとえば、すべてのモジュールが同一のCoherenceノードを共有する必要がある場合にはこれが推奨デプロイメントとなります。1つのEARのみをアプリケーション・サーバーにデプロイする場合にも推奨構成となります。
この構成は、クラスタ内で2番目に最小限の数のCoherenceノードを作成します(デプロイされた各EAR用)。Coherenceライブラリはアプリケーションのクラスパスでデプロイされるため、Coherenceクラスのコピーが1つのみ各EARに読み込まれます。
EAR内のすべてのWebアプリケーションは同一クラスタ構成を共有するため、任意のアプリケーションで誤動作が起こると、EAR内のすべてのWebアプリケーションに影響が及びます。EARスコープCoherenceクラスタは、アプリケーション・サーバー・クラスパスへの変更が必要ないため、デプロイメントの手間を省けます。
CoherenceキャッシュをEARスコープのCoherenceクラスタと共に使用するには、
次の方法のいずれかを使用し、coherence.jar
およびactive-cache.jar
ファイルを、アプリケーションがデプロイされるすべてのターゲット・サーバーに共有ライブラリとしてデプロイします。
WebLogic Server管理コンソールを使用し、coherence.jar
およびactive-cache.jar
を共有ライブラリとしてデプロイします。『Oracle Fusion Middleware 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
フォルダにコピーします。ただし、共有ライブラリとしてデプロイする方法が優先されます。
ライブラリとしてcoherence.jar
およびactive-cache.jar
ファイルを参照します。例3-4は、サンプルのweblogic-application.xml
構成ファイルを示します。
(オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBean
を作成し、weblogic-application.xml
ファイル内のcoherence-cluster-ref
要素として参照します。この要素によって、アプリケーションはCoherenceClusterSystemResourceMBean
属性によって指定されるとおりにCoherenceクラスタに登録できます。
例3-5はサンプル構成を示します。サンプル内のmyCoherenceCluster
MBeanは、CoherenceClusterSystemResourceMBean
型です。
アプリケーション・スコープCoherenceクラスタにフィルタ処理クラスローダーを定義するには、
coherence.jar
がアプリケーション・サーバー・クラスパス内に配置される場合、フィルタ処理クラスローダーを定義してEARスコープ・クラスタを構成できます。これは、次の手順で示されます。
coherence.jar
をアプリケーション・クラスパスに配置します。
EARファイル内のフィルタ処理クラスローダーを構成します。
フィルタ処理クラスローダーは、weblogic-application.xml
ファイルの<prefer-application-packages>
スタンザで定義されます。例3-6はサンプルのフィルタ処理クラスローダー構成を示します。package-name
要素は、coherence.jar
およびactive-cache.jar
内のクラスのパッケージ名を示します。
この構成を使用するか、または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クラスタと共に使用するには
WebLogic Server管理コンソールを使用し、coherence.jar
およびactive-cache.jar
を、アプリケーションがデプロイされるすべてのターゲット・サーバーに共有ライブラリとしてデプロイします。『Oracle Fusion Middleware 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
をオプション・パッケージとして、Coherenceを使用する各モジュールのmanifest.mf
ファイルにインポートします。
マニフェスト・ファイル使用の代替手段として、coherence.jar
およびactive-cache.jar
を各WARファイルのWEB-INF/lib
ディレクトリにコピーします。
例3-7は、サンプルのmanifest.mf
ファイルのコンテンツを示します。
(オプション) Coherenceクラスタ・プロパティを構成する場合は、CoherenceClusterSystemResourceMBean
を作成し、weblogic.xml
またはweblogic-ejb-jar.xml
ファイル内のcoherence-cluster-ref
要素として参照します。
例3-8は、weblogic.xml
ファイル内のWARスコープ・クラスタのサンプル構成を示します。myCoherenceCluster
MBeanは、CoherenceClusterSystemResourceMBean
型です。
WLSTまたは管理コンソールを使用し、Coherenceクラスタを作成および構成し、クラスタ構成がアクセス可能になるWebLogic Serverインスタンスまたはクラスタを選択できます。
例3-9で示されるcreateCoherenceClusterMBean.py
WLSTスクリプトは、管理サーバー(myserver
)にデプロイしたサーバー・スコープ構成を含む3つのCoherenceクラスタを構成します。
次のサンプル・コマンドを使用してWLSTを呼び出してスクリプトを実行します。
java -Dadmin.username=weblogic -Dadmin.password=welcome1 -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 Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ』のCoherenceの構成に関する項を参照してください。
クラスタ関連値は、WebLogic Server構成リポジトリの記述子ファイルに保存されます。
DOMAIN_HOME
/config/coherence/
CoherenceClusterSystemResourceName
/
CoherenceClusterSystemResourceName
-
####
-coherence.xml
、ここでDOMAIN_HOME
は、d:/oracle/MW_HOME/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 Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプ』のカスタム・クラスタ構成のインポートに関する項を参照してください。
注意: カスタム構成ファイルをインポートしてクラスタ関連プロパティを指定する場合、ファイル内で指定されるプロパティは、WLSTまたはWebLogic Server管理コンソールを使用して指定されたプロパティと同一にしてはなりません。 |
スタンドアロンCoherenceキャッシュ・サーバーは、すべてのキャッシュ・データの保存および管理に関与する専用のJVMです。Coherenceデータ・クラスタ内のシニア・ノード(1番目のノード)は、起動に数秒かかる可能性がありますが、後続のノードの起動にかかる時間は最短になります。そのため、パフォーマンスを最適化するには、常にCoherenceキャッシュ・サーバーを起動してからWebLogic Serverインスタンスを起動する必要があります。これによって、ActiveCacheを使用するアプリケーションは、最短の時間(単位はミリ秒)で起動できることが保証されます。ActiveCacheを使用する任意の追加Webアプリケーションは、シニア・データ・メンバーとなることが保証されません。そのため、WebLogic Serverの起動には最小限の影響しか及ぼされません。
注意: 最初にキャッシュ・サーバーを起動するか、またはWebLogic Serverインスタンスを起動するかは、利用するクラスタ・トポロジに依存します。
|
WebLogic Server 10.3.4では、管理コンソールまたはWLSTおよびjavaベースのノード・マネージャを介してWebLogic Server管理サーバーを使用し、スタンドアロンのCoherenceキャッシュ・サーバーのライフサイクルを管理および監視できます。
ノード・マネージャは、WebLogic Serverユーティリティです。これを使用すると、サーバーを起動・停止したり、自動的にリモートで再起動したりできます。ノード・マネージャは、ノード・マネージャを使用して制御するCoherenceサーバー・インスタンスをホストする各コンピュータ上で実行する必要があります。
ノード・マネージャを使用してキャッシュ・サーバーを起動する前提条件の手順は次のとおりです。
サーバーを起動するようにノード・マネージャを構成します。
『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの一般的な構成に関する項を参照してください。
ノード・マネージャを起動します。
ノード・マネージャは、コマンド・プロンプトまたはスクリプトを使用して手動で起動できます。『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』の「ノード・マネージャの起動」を参照。
WLSTを使用してノード・マネージャを起動するには次を実行します。
c:\>java weblogic.WLST wls:/offline> startNodeManager()
ノード・マネージャでWLSTを使用する方法の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のノード・マネージャ・コマンドに関する項を参照してください。
Windowsでは、「スタート」メニューのショートカットからノード・マネージャを起動できます(WebLogic Server>「ツール」>「ノード・マネージャ」)。
Coherenceキャッシュ・サーバー・ログ・ファイルおよびサーバー固有のノード・マネージャ情報ファイルは、DOMAIN_HOME
/
servers_coherence
/
COHserver_name
/の直下に配置されます。ここで、DOMAIN_HOME
は、d:/oracle/MW_HOME/user_projects/domains/
domain_name
などのWebLogic Serverドメインをインストールした場所を示し、COHserver_name
はCoherenceキャッシュ・サーバー名です。
管理コンソールを使用してキャッシュ・サーバーを起動する方法については、『Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプ』の管理コンソールからのCoherenceサーバーの起動に関する項を参照してください。
例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 = 'welcome1' 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 = 'welcome1' 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キャッシュ・サーバーを起動するには、次の手順を実行します。
Coherenceキャッシュ・サーバーを起動するためのスクリプトを作成します。次に示す例は、ActiveCacheと共に使用するためにストレージが有効なキャッシュ・サーバーを起動するスクリプトの非常にシンプルな例です。この例では、Sun JVMを使用することを想定します。詳細は、『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クラスタ上で稼働するアプリケーション・サーバー用に定義された構成と同一にする必要があります。
前の手順で説明されたスクリプトを使用して、1つ以上のCoherenceキャッシュ・サーバーを起動します。
Coherenceキャッシュ・サーバーは、ライフサイクル情報(ステータス)をDOMAIN_HOME
/
servers_coherence
/
COHserver_name
/data/nodemanager/
COHserver_name
.state
に書き込みます。ノード・マネージャは、当該ディレクトリ内にあるこのファイルとその他のファイルを監視し、キャッシュ・サーバーが稼働中かどうかを検出し、そのステータス(クリーン・シャットダウンによって、クラッシュや起動失敗とは異なる最終状態が生成される)に基づいて、再起動するかどうかを検出します。
また、ノード・マネージャを再起動する場合、CrashRecoveryEnabled
プロパティの値も考慮します。この値は、weblogic.nodemanager.NodeManager
起動コマンド内で指定するか、またはnodemanager.properties
ファイル内で定義できます。このファイルは、WL_HOME
/common/nodemanager
の直下に配置され、WL_HOME
はWebLogic Serverをインストールした場所を示します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャとシステム・クラッシュのリカバリに関する項とノード・マネージャ・プロパティの確認に関する項参照してください。
注意: ノード・マネージャが実行されていない場合(ダウンしている場合またはまだ起動していない場合)、キャッシュ・サーバーは状態をunknown として報告します。また、ノード・マネージャがサーバー起動にまったく使用されていない場合(初期作成時など)、キャッシュ・サーバーは状態をunknown として報告します。これは、キャッシュ・サーバーのライフサイクル・ステータスが、DOMAIN_HOME / servers_coherence / COHserver_name /data/nodemanager/ COHserver_name .state ファイルから情報を取得するノード・マネージャによってのみ決定されるためです。 |
WebLogic Serverでは、複数の方法でサーバー・インスタンスを起動および停止できます。どの方法を選ぶかは、管理コンソールとコマンド・ライン・インタフェースのどちらを使用するか、およびサーバーのライフサイクルの管理にノード・マネージャを使用するかどうかによって決まります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。クイック・リファレンスについては、「サーバーの起動と停止: クイック・リファレンス」を参照してください。
デフォルトでは、ActiveCacheを利用しているWebLogic Serverインスタンスは、ストレージが有効モードで起動します。WebLogic Serverインスタンスをストレージが有効モードで起動するには、コマンドライン・プロパティ-Dtangosol.coherence.session.localstorage=true
をサーバー起動コマンドにインクルードします。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ラインからサーバー・インスタンスを起動に関する項を参照してください。
WebLogic Server管理コンソールには、クラスタのサイズ、メンバー、およびバージョンなどの特定のアプリケーションまたはモジュールに関連付けられたCoherenceクラスタのランタイム監視情報が表示されます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプ』のCoherenceクラスタのモニタリングに関する項を参照してください。