| Oracle® Coherenceクライアント・ガイド リリース3.6.1 B61370-02 |
|
 前 |
 次 |
この章は次の各項で構成されています。
Coherence for C++を構成して使用するには、次の7つの基本的な手順が必要です。
Coherence for C++ APIを使用してC++アプリケーションを実装します。APIの詳細は、第9章「Coherence for C++ APIについて」を参照してください。
アプリケーションをコンパイルおよびリンクします。
パスを構成します。
クライアント、およびクラスタにある1つ以上のJVMの両方にCoherence*Extendを構成します。
クライアント、およびクラスタの中でCoherence*Extendのクラスタ・サービスを実行しているすべてのJVMにPOFコンテキストを構成します。
Coherenceクラスタが稼動中であることを確認します。
C++クライアント・アプリケーションを起動します。
これらの手順の詳細は、次の各項で説明します。
Coherence for C++に用意されているAPIを使用すると、データ、データ・イベント、データ処理などのCoherenceクラスタ・サービスに、Coherenceクラスタ外部からC++アプリケーションを使用してアクセスできます。
Coherence for C++ APIは、次のもので構成されています。
一連のC++パブリック・ヘッダー・ファイル
サポートされているすべてのC++コンパイラでビルドした、各バージョンの静的ライブラリ
いくつかのサンプル
このライブラリを使用したC++アプリケーションは、Coherenceクラスタ内で稼働するCoherence*Extendのクラスタ・サービス・インスタンスに、高性能なTCP/IPベースの通信レイヤーを使用して接続できます。このライブラリからCoherence*Extendクラスタ・サービスにすべてのクライアント・リクエストが送信され、このサービスは実際のCoherenceクラスタ・サービス(パーティション・キャッシュ・サービス、レプリケーション・キャッシュ・サービスなど)に委任することで、クライアント・リクエストに応答します。
第9章「Coherence for C++ APIについて」では、このAPIにある主要なクラスの概要を説明しています。これらのクラスの詳細は、Coherence for C++のdocディレクトリにあるAPIそのものを参照してください。
Coherence for C++を採用したアプリケーションをコンパイルできるプラットフォームのリストは、サポートされているプラットフォームとオペレーティング・システムに関するトピックを参照してください。
たとえば、次に示すWindows 32ビット・プラットフォーム用build.cmdファイルは、Coherence for C++のデモのファイルをビルド、コンパイルおよびリンクします。このファイルにある各変数の意味は次のとおりです。
OPTおよびLOPTは、コンパイラのオプションをポイントします。
INCは、includeディレクトリにあるCoherence for C++ APIのファイルをポイントします。
SRCは、commonディレクトリにあるC++のヘッダー・ファイルとコード・ファイルをポイントします。
OUTは、コードのコンパイルが完了したときにコンパイラやリンカーで生成する必要のあるファイルをポイントします。
LIBPATHは、libraryディレクトリをポイントします。
LIBSは、Coherence for C++の共有ライブラリ・ファイルをポイントします。
このファイルは、これらの環境変数を設定した後、C++のコード・ファイルとヘッダー・ファイル、APIファイルおよびOPTファイルをコンパイルし、LOPT、Coherence for C++の共有ライブラリ、生成されたオブジェクト・ファイルおよびOUTファイルをリンクします。オブジェクト・ファイルを削除することによってこの処理は終了します。build.cmdファイルの実行例を例8-1に示します。
例8-1 build.cmdファイルの実行例
@echo off setlocal set EXAMPLE=%1% if "%EXAMPLE%"=="" ( echo You must supply the name of an example to build. goto exit ) set OPT=/c /nologo /EHsc /Zi /RTC1 /MD /GR /DWIN32 set LOPT=/NOLOGO /SUBSYSTEM:CONSOLE /INCREMENTAL:NO set INC=/I%EXAMPLE% /Icommon /I..\include set SRC=%EXAMPLE%\*.cpp common\*.cpp set OUT=%EXAMPLE%\%EXAMPLE%.exe set LIBPATH=..\lib set LIBS=%LIBPATH%\coherence.lib echo building %OUT% ... cl %OPT% %INC% %SRC% link %LOPT% %LIBS% *.obj /OUT:%OUT% del *.obj echo To run this example execute 'run %EXAMPLE%' :exit
Coherence for C++ライブラリへの構成パスを設定します。この手順では、ライブラリをポイントする環境変数を設定します。環境変数名とライブラリのファイル名は、使用しているプラットフォーム環境によって異なります。プラットフォームごとの環境変数とライブラリ名のリストは、第7章「C++アプリケーション・ビルドの設定」を参照してください。
Coherence*Extendを構成するには、クラスタ側とクライアント側両方のキャッシュ構成ディスクリプタに適切な構成要素を追加します。クラスタ側のキャッシュ構成要素からCoherenceのDefaultCacheServerに対して、Coherence*Extendクライアントから受信したTCP/IPリクエストをリスニングするCoherence*Extendクラスタ・サービスを開始するように指示されます。クライアント側のキャッシュ構成要素は、クライアント・ライブラリによって、クラスタに接続するために使用されます。この構成では、クラスタの中でCoherence*Extendのクラスタ・サービスを実行している1台以上のサーバーのIPアドレスとポートを指定します。これにより、ライブラリをクラスタに接続できます。この構成では、接続やリクエストのタイムアウトなど、接続に関連する様々なパラメータも記述します。
Coherence*ExtendクライアントをCoherenceクラスタに接続するには、そのクラスタにある1つ以上のDefaultCacheServer JVMで、TCP/IP Coherence*Extendクラスタ・サービスを実行している必要があります。このサービスを実行するようにDefaultCacheServerを構成するには、そのDefaultCacheServerで使用するキャッシュ構成ディスクリプタに、子にtcp-acceptor要素を持つproxy-scheme要素を追加する必要があります。
たとえば、例8-2のキャッシュ構成ディスクリプタは、2つのクラスタ・サービスを定義します。これは、リモートCoherence*ExtendクライアントをTCP/IPでCoherenceクラスタに接続できるようにするサービス、および標準のパーティション・キャッシュ・サービスです。このディスクリプタはDefaultCacheServerで使用しているため、クラスタ・サービスの終了時に自動的に再起動するように、各サービスのautostart構成要素をtrueに設定しておくことが重要です。proxy-scheme要素には、tcp-acceptorという子要素があり、この子要素には、TCP/IPを介してクライアント接続リクエストを受け入れるために必要なTCP/IP固有の情報がすべて含まれます。acceptor-configも、そのシリアライザ用にConfigurablePofContextを使用するように構成されています。C++ Extendのクライアントでは、シリアライズにPOFを使用する必要があります。
シリアライズとPIF/POFの詳細は、第11章「C++クライアントの統合オブジェクトの構築」を参照してください。
次のように構成されたCoherence*Extendのクラスタ・サービスは、localhostアドレスとport 9099で、受信リクエストをリスニングします。たとえば、dist-extendというCoherenceキャッシュにクライアントが接続しようとすると、Coherence*Extendのクラスタ・サービスがNamedCacheへの後続リクエストを同じ名前で代行します。その名前は、この例ではパーティション・キャッシュとなります。
例8-2 2つのクラスタ・サービスのキャッシュ構成
<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>dist-*</cache-name>
<scheme-name>dist-default</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<distributed-scheme>
<scheme-name>dist-default</scheme-name>
<lease-granularity>member</lease-granularity>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<proxy-scheme>
<service-name>ExtendTcpProxyService</service-name>
<thread-count>5</thread-count>
<acceptor-config>
<tcp-acceptor>
<local-address>
<address>localhost</address>
<port>9099</port>
</local-address>
</tcp-acceptor>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
</serializer>
</acceptor-config>
<autostart>true</autostart>
</proxy-scheme>
</caching-schemes>
</cache-config>
Coherence*Extendのクライアントの構成にある主要な要素は<cache-config>です。この要素には、キャッシュ構成を含むキャッシュ構成ディスクリプタのパスを記述します。このキャッシュ構成ディスクリプタは、DefaultConfigurableCacheFactoryで使用されます。
Coherence*Extendクライアントでは、Coherenceクラスタ内で実行されるCoherence*Extendクラスタ・サービスへの接続およびCoherence*Extendクラスタ・サービスとの通信に、キャッシュ構成ディスクリプタの要素initiator-config内の情報が使用されます。
たとえば、例8-3のキャッシュ構成ディスクリプタは、リモートCoherenceクラスタに接続するキャッシング・スキームを定義します。remote-cache-scheme要素には、tcp-initiatorという子要素があり、この子要素には、リモートCoherenceクラスタ内でCoherence*Extendクラスタ・サービスが実行されているクライアントへの接続に必要なTCP/IP固有の情報がすべて含まれます。
クライアント・アプリケーションで、たとえばdist-extendという名前を使用してCacheFactoryで名前付きキャッシュを取得すると、Coherence*Extendクライアントは(アドレスlocalhostとport 9099による)TCP/IPを使用してCoherenceクラスタに接続し、NamedCache実装を返します。この実装は、リモート・クラスタの中で実行している同名のNamedCacheにリクエストをルーティングする機能を持っています。remote-addresses構成要素には、子要素socket-addressを複数記述できます。Coherence*Extendのクライアントは、記載されたアドレスをすべて試すか、またはTCP/IP接続が確立されるまで、アドレスへの接続をランダムに試行します。
例8-3 リモートCoherenceクラスタに接続するキャッシング・スキーム
<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
<cache-mapping>
<cache-name>dist-extend</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>localhost</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
ローカル・キャッシュは、特定のC++アプリケーションに対してローカルである(つまりアプリケーション内に完全に含まれる)キャッシュです。ローカル・キャッシュの特に興味深い属性について、次に示します。
ローカル・キャッシュはリモート・キャッシュと同じインタフェースを実装します。つまり、ローカル・キャッシュを使用することとリモート・キャッシュを使用することにプログラミング上の違いはありません。
ローカル・キャッシュのサイズは制限できます。つまり、ローカル・キャッシュでは、キャッシュするエントリ数を制限し、キャッシュがいっぱいになったらエントリを自動的に削除できます。さらに、エントリのサイジングとエビクション・ポリシーの両方をカスタマイズできます。たとえば、キャッシュされたエントリで使用されるメモリーに基づいてキャッシュ・サイズを制限できます。デフォルトのエビクション・ポリシーでは、対数曲線で測定された、最も頻繁に使用する(MFU)情報と最後に使用した(MRU)情報の組合せを使用して削除するキャッシュ項目が決定されます。このアルゴリズムは、短期キャッシュと長期キャッシュの両方に対して十分に機能し、頻度と新しさのバランスをとってキャッシュ・スラッシングを回避するため、最適な汎用エビクション・アルゴリズムであるといえます。また、ピュアLRUアルゴリズムおよびピュアLFUアルゴリズムがサポートされ、カスタム・エビクション・ポリシーのプラグイン機能もサポートされています。
ローカル・キャッシュはキャッシュ・エントリの自動失効をサポートしています。つまり、キャッシュ内の各キャッシュ・エントリにTTL値を割り当てることができます。さらに、定期的または事前に設定した時刻にフラッシュするようキャッシュ全体を構成できます。
ローカル・キャッシュはスレッド・セーフで、高い並行性を備えています。
ローカル・キャッシュでは、キャッシュのget統計が提供されます。ここには、キャッシュ・ヒットおよびキャッシュ・ミスの統計情報が保持されます。これらの実行時統計を使用すれば、キャッシュの有効性を正確に推定できるため、キャッシュ実行時にサイズ制限や自動失効の設定を適宜調整できます。
ローカル・キャッシュの構成要素は<local-scheme>です。ローカル・キャッシュは通常、ニアスキームのフロント層としてなど、他のキャッシュ・スキーム内にネストされています。<local-scheme>には、キャッシュの特性を定義できるいくつかのサブ要素がオプションで用意されています。たとえば、<low-units>および<high-units>サブ要素はキャッシュのサイズを制限します。キャッシュが最大許容サイズに達すると、指定されたエビクション・ポリシー(<eviction-policy>)に従って削除対象エントリが決定され、指定されたより小さなサイズに戻ります。エントリおよびサイズの制限は、該当するスキームの単位換算カリキュレータ(<unit-calculator>)で計算される単位で測定されます。
キャッシュの有効期間も制限できます。<expiry-delay>サブ要素は、前回の更新からエントリが期限切れとしてマークされるまでの、キャッシュでエントリが保持される期間を指定します。期限切れのエントリを読み取るには、構成済のキャッシュ・ストア(<cachestore-scheme>)からエントリをリロードすることになります。期限切れになった値は、フラッシュ遅延に基づいてキャッシュから定期的に破棄されます。
<cache-store-scheme>が指定されていない場合、キャッシュされたデータはメモリー内に存在して、キャッシュに対して実行された操作を反映するだけになります。使用可能なすべてのサブ要素の詳細は、<local-scheme>を参照してください。
例8-4は、ローカル・キャッシュ構成を示しています。
例8-4 ローカル・キャッシュ構成
<?xml version="1.0"?>
<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example-local-cache</cache-name>
<scheme-name>example-local</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<local-scheme>
<scheme-name>example-local</scheme-name>
<eviction-policy>LRU</eviction-policy>
<high-units>32000</high-units>
<low-units>10</low-units>
<unit-calculator>FIXED</unit-calculator>
<expiry-delay>10ms</expiry-delay>
<flush-delay>1000ms</flush-delay>
<cachestore-scheme>
<class-scheme>
<class-name>ExampleCacheStore</class-name>
</class-scheme>
</cachestore-scheme>
<pre-load>true</pre-load>
</local-scheme>
</caching-schemes>
</cache-config>
この章では、Coherence for C++クライアントに関係するニア・キャッシュについて説明します。ニア・キャッシュの概念、その構成、およびバック層との同期を維持する方法の詳細は、『Oracle Coherence開発者ガイド』のニア・キャッシュの構成に関する項を参照してください。
Coherence for C++でのニア・キャッシュは、リードスルー/ライトスルー方式を使用してフロント・キャッシュとバック・キャッシュをラップするcoherence::net::NamedCache実装です。バック・キャッシュがObservableCacheインタフェースを実装している場合、ニア・キャッシュはリスニング方針にNone、Present、All、Autoのいずれかを使用して、バック・キャッシュで変更された可能性のあるフロント・キャッシュ・エントリを無効化します。
一般的なニア・キャッシュは、ローカル・キャッシュ(スレッド・セーフで並行性が高く、かつサイズが制限されていて自動的に失効するローカル・キャッシュ)をフロント・キャッシュとして使用し、リモート・キャッシュをバック・キャッシュとして使用するように構成されます。ニア・キャッシュの構成には、2つの子要素を持つnear-schemeが使用されます。1つはローカル(フロント)キャッシュを構成するためのfront-scheme、もう1つはリモート(バック)キャッシュを定義するためのback-schemeです。
ニア・キャッシュは、coherence-cache-configファイルの<near-scheme>要素を使用して構成します。この要素には、ローカル(フロント層)キャッシュを構成するためのfront-schemeと、リモート(バック層)キャッシュを定義するためのback-schemeの2つのサブ要素が要求されます。フロント層には通常、ローカル・キャッシュ(<local-scheme>)を選択しますが、JVMヒープ・ベース以外のキャッシュ(<external-scheme>または<paged-external-scheme>)またはJavaオブジェクトに基づくスキーム(<class-scheme>)も使用できます。
リモート、すなわちバック層のキャッシュは、<back-scheme>要素を使用して記述します。バック層のキャッシュには、分散キャッシュ(<distributed-scheme>)またはリモート・キャッシュ(<remote-cache-scheme>)を定義できます。<remote-cache-scheme>要素を使用すると、現在のクラスタの外部からクラスタ・キャッシュを使用できます。
<near-scheme>のオプションのサブ要素には、フロント層とバック層のオブジェクトの同期を維持する方法を指定する<invalidation-strategy>、およびキャッシュで発生したイベントの通知を受け取るリスナーを指定する<listener>などがあります。
例8-5は、ニア・キャッシュの構成を示しています。
例8-5 ニア・キャッシュ構成
<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
<cache-scheme-mapping>
<cache-mapping>
<cache-name>dist-extend-near</cache-name>
<scheme-name>extend-near</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<near-scheme>
<scheme-name>extend-near</scheme-name>
<front-scheme>
<local-scheme>
<high-units>1000</high-units>
</local-scheme>
</front-scheme>
<back-scheme>
<remote-cache-scheme>
<scheme-ref>extend-dist</scheme-ref>
</remote-cache-scheme>
</back-scheme>
<invalidation-strategy>all</invalidation-strategy>
</near-scheme>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>localhost</address>
<port>9099</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
(ネットワーク、ソフトウェア、ハードウェアなどの障害によって)クライアントとクラスタ間の接続が切断されたことをCoherence*Extendのクライアント・サービスが検出すると、このCoherence*Extendのクライアント・サービスの実装(CacheServiceまたはInvocationService)によって(MemberEventHandlerデリゲートを使用して)MemberEventType.Leftイベントが発生し、このクライアント・サービスは停止します。クライアント・アプリケーションがその後もこのサービスを使用しようとする場合には、サービス自体が自動的に再起動してクラスタへの再接続を試行します。このサービスが接続に成功するとMemberEventType.Joinedイベントが発生し、接続に失敗するとクライアント・アプリケーションに致命的な例外がスローされます。
Coherence*Extendサービスには、接続の切断を検出するためのメカニズムがいくつか用意されています。その中には、(Extend-TCPのTCP/IPのように)基底プロトコルに固有のものもあれば、サービス自体に実装されるものもあります。後者のメカニズムは、outgoing-message-handler構成要素を使用して構成されます。
接続の切断を検出するためにCoherence*Extendのクライアント・サービスで使用される構成可能な主要メカニズムは、リクエストのタイムアウトです。サービスがリモート・クラスタにリクエストを送信したが、リクエストのタイムアウト時間内にレスポンスを受信しなかった場合(<request-timeout>を参照)、サービスでは接続が切断されたと想定されます。Coherence*Extendのクライアント・サービスおよびクラスタ・サービスは、接続を介して定期的にハートビートを送信するように構成することもできます(<heartbeat-interval>と<heartbeat-timeout>を参照)。構成されたハートビートのタイムアウト時間内にサービスがレスポンスを受信しなかった場合、サービスでは接続が切断されたと想定されます。
次のようにcoherence::net::CacheFactoryクラスを使用することによって、構成済ニア・キャッシュへの参照を名前によって取得できます。
NamedCache::Handle hCache = CacheFactory::getCache("example-near-cache");
すべてのNamedCache実装のインスタンスは、不要になった時点でNamedCache::release()メソッドをコールして明示的に解放し、インスタンスで保持されているリソースをすべて解放する必要があります。
特定のNamedCacheがアプリケーションの継続期間を通して使用される場合、リソースはそのアプリケーションがシャットダウンされたとき、または停止したときにクリーンアップされます。ただし、わずかの間だけ使用される場合は、使い終わった時点でアプリケーションからrelease()メソッドをコールする必要があります。
C++アプリケーションでCoherence for C++ライブラリを使用するには、そのアプリケーションにCoherence for C++ライブラリをリンクし、Coherence for C++のキャッシュ構成と場所を指定する必要があります。
キャッシュ構成ファイルの場所は、サンプル・アプリケーションの項で指定した環境変数、またはプログラム上の処理で設定できます。
「ランタイム・ライブラリと検索パスの設定」の説明にあるように、tangosol.coherence.cacheconfigシステム・プロパティを使用してキャッシュ構成ファイルの場所を指定できます。Windowsでこの構成ファイルの場所を設定するには、次のコマンドを実行します。
c:\coherence_cpp\examples> set tangosol.coherence.cacheconfig=config\extend-cache-config.xml
DefaultConfigurableCacheFactory::createとCacheFactory::configure(必要に応じてCacheFactory::loadXmlFileヘルパー・メソッドを使用)のいずれかを使用して、プログラム処理で構成ファイルの場所を設定できます。
例8-6 構成ファイルの場所の設定
static Handle coherence::net::DefaultConfigurableCacheFactory::create (String::View vsFile = String::NULL_STRING)
DefaultConfigurableCacheFactoryクラスのcreateメソッドで、新しいCoherence cacheファクトリを作成します。vsFileパラメータで、ロードするCoherenceの構成ファイルの名前と場所を指定します。
例8-7 Coherenceキャッシュ・ファクトリの作成
static void coherence::net::CacheFactory::configure (XmlElement::View vXmlCache, XmlElement::View vXmlCoherence = NULL)
configureメソッドで、CacheFactoryとローカル・メンバーを構成します。cache-config.dtdに対応するXML要素をvXmlCacheパラメータで指定し、coherence.dtdに対応するXML要素をvXmlCoherenceパラメータで指定します。
例8-8 CacheFactoryとローカル・メンバーの構成
static XmlElement::Handle coherence::net::CacheFactory::loadXmlFile (String::View vsFile)
loadXmlFileメソッドで、指定されたファイルからXmlElementを読み取ります。このメソッドでは、CacheFactoryを構成することはできませんが、configureメソッドに対して指定できる構成を取得することはできます。パラメータvsFileで、読込み元であるファイルの名前を指定します。
例8-9のC++コードでは、CacheFactory::configureメソッドを使用して、サーバー/クラスタのキャッシュ構成ファイル(coherence-extend-config.xml)の場所およびC++クライアントのキャッシュ構成ファイル(tangosol-operation-config.xml)の場所を設定します。
オペレーション構成オーバーライド・ファイル(デフォルトではtangosol-coherence-override.xml)では、Oracle Coherenceで使用する操作設定とランタイム設定を制御して、そのクラスタ・サービス、通信サービスおよびデータ管理サービスを作成、構成および維持します。Javaクライアント同様、C++クライアントでもこのファイルの使用はオプションです。
C++クライアントの場合、このファイルを使用して、具体的にキャッシングに関連していないCoherenceアプリケーションの一般的な操作設定を指定するか、またはオーバーライドできます。C++クライアントの場合の主要な要素は、ロギング、Coherence製品のエディション、および特定のクラスタ・メンバーの場所とロールの割当てのためのものです。
オペレーション構成は、プログラム上の処理またはtangosol-coherence-override.xmlファイルで構成できます。プログラム上の処理でオペレーション構成を構成するには、CacheFactory::configureメソッド(coherence::net::CacheFactory::configure (View vXmlCache, View vXmlCoherence))のvXmlCoherenceパラメータに次の要素が1つ以上記述され、coherence.dtdに従ったXMLファイルを指定します。
license-config: license-config要素には、Coherenceのエディションと操作モードの構成を可能にするサブ要素を記述します。edition-nameサブ要素は、メンバーが使用する製品エディション(Grid Edition、Enterprise Edition、Real Time Clientなど)を指定します。この方法では、使用するエディションをメンバーごとに指定することによって、同じくラスタの中で複数の製品エディションを使用できます。Coherence for C++クライアントの場合は、RTC(リアルタイム・クライアント)およびDC(データ・クライアント)の各値のみを認識できます。license-configは、coherence要素のオプションのサブ要素で、デフォルト値はRTCです。
logging-config: logging-config要素は、システムにメッセージのログを記録する方法の構成を可能にするサブ要素を記述します。この要素を使用して、ログ・メッセージの保存先、重大度および書式を指定できます。logging-configは、coherence要素の必須のサブ要素です。ロギングの詳細は、「Loggerの構成」を参照してください。
member-identity: member-identity要素は、クラスタ・メンバーの場所とロールの定義に役立つ詳細な識別情報を指定します。この要素を使用して、メンバーが属するクラスタ、ラック、サイト、マシン、ロールなどの名前を指定できます。member-identityは、cluster-config要素のオプションのサブ要素です。例8-10は、サンプル・ファイルtangosol-coherence.xmlの内容を示しています。
例8-10 オペレーション構成のサンプル
<?xml version='1.0'?>
<coherence>
<cluster-config>
<member-identity>
<site-name>extend site</site-name>
<rack-name>rack 1</rack-name>
<machine-name>machine 1</machine-name>
</member-identity>
</cluster-config>
<logging-config>
<destination>stderr</destination>
<severity-level>5</severity-level>
<message-format>(thread={thread}): {text}</message-format>
<character-limit>8192</character-limit>
</logging-config>
<license-config>
<edition-name>RTC</edition-name>
<license-mode>production</license-mode>
</license-config>
</coherence>
「オペレーション構成の要素」では、オペレーション構成ファイルとそこで定義できる要素について詳しく説明しています。
Loggerは、オペレーション構成ファイルのlogging-config要素を使用して構成します。この要素では次の属性を指定します。これらの属性では、ログに記録されたエラーに関する詳細情報を記録できます。
destination: Loggerで使用するLogOutputのタイプを指定します。有効な値は次のとおりです。
stderr(Console.Errorの場合)
stdout(Console.Outの場合)
ファイル・パス(メッセージをファイルに送信する必要がある場合)
severity-level: メッセージをログに記録するために満たすか、または超過する必要のあるログ・レベルを決定します。
message-format: ログ・メッセージの書式を決定します。
character-limit: ログ出力デーモンがメッセージ・キューから処理する文字の最大数を決定します。この数を超過すると、キューに残っているメッセージがすべて破棄されます。例8-11は、ロギングの構成を記述したオペレーション構成を示しています。オペレーション構成の詳細は、「オペレーション構成ファイル(tangosol-coherence-override.xml)」を参照してください。
すでに説明したクラスタ側のCoherenceキャッシュ構成を使用するDefaultCacheServerを起動し、TCP/IPを使用してCoherence for C++クライアントをCoherenceクラスタに接続できるようにするには、次の手順を実行する必要があります。
現在のディレクトリをOracle Coherenceのライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib、UNIXの場合は$COHERENCE_HOME/lib)。
Javaコマンドが実行されるようにパスを構成します。
次のコマンドラインを使用してDefaultCacheServerを起動します。
