ヘッダーをスキップ
Oracle® Coherenceクライアント・ガイド
リリース3.7.1
B65027-01
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

17 .NETクライアントの構成と使用

この章は次の各項で構成されています。

17.1 一般的な手順

Coherence for .NETを構成して使用するには、次の5つの基本的な手順が必要です。

  1. クライアント、およびクラスタにある1つ以上のJVMの両方にCoherence*Extendを構成します。詳細は、次の「Coherence*Extendの構成」を参照してください。

  2. クライアント、およびクラスタの中でCoherence*Extendのクラスタ・サービスを実行しているすべてのJVMにPOFコンテキストを構成します。「統合オブジェクトの構築(.NET)の概要」を参照してください。

  3. Coherence for .NET APIを使用して.NETクライアント・アプリケーションを実装します。「Coherence .NET APIの使用」を参照してください。

  4. Coherenceクラスタが稼動中であることを確認します。「CoherenceのDefaultCacheServerプロセスの起動」を参照してください。

  5. .NETクライアント・アプリケーションを起動します。

17.2 Coherence*Extendの構成

Coherence*Extendを構成するには、クラスタ側とクライアント側両方のキャッシュ構成ディスクリプタに適切な構成要素を追加する必要があります。クラスタ側のキャッシュ構成要素からCoherenceのDefaultCacheServerに対して、Coherence*Extendクライアントから受信したTCP/IPリクエストをリスニングするCoherence*Extendクラスタ・サービスを開始するように指示されます。クライアント側のキャッシュ構成要素は、クラスタの中でCoherence*Extendクラスタ・サービスを実行している1台以上のサーバーのIPアドレスとポートを特定するためにクライアント・ライブラリで使用されます。これにより、ライブラリをクラスタに接続できます。この構成では、接続やリクエストのタイムアウトなど、接続に関連する様々なパラメータも記述します。

17.2.1 クラスタでのCoherence*Extendの構成

Coherence*ExtendクライアントをCoherenceクラスタに接続するには、そのクラスタにある1つ以上のDefaultCacheServer JVMで、TCP/IP Coherence*Extendクラスタ・サービスを実行している必要があります。このサービスを実行するようにDefaultCacheServerを構成するには、そのDefaultCacheServerで使用するキャッシュ構成ディスクリプタに、tcp-acceptor子要素を持つproxy-scheme要素を追加する必要があります。これを例17-1に示します。

例17-1 Coherence*Extendに対応したデフォルト・キャッシュ・サーバーの構成

<?xml version="1.0"?>

<cache-config xmlns="http://schemas.tangosol.com/cache"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://schemas.tangosol.com/cache
  assembly://Coherence/Tangosol.Config/cache-config.xsd">
  <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>
      </acceptor-config>
      <autostart>true</autostart>
    </proxy-scheme>
  </caching-schemes>
</cache-config>

このキャッシュ構成ディスクリプタは、2つのクラスタ・サービスを定義します。これは、リモートCoherence*ExtendクライアントをTCP/IPでCoherenceクラスタに接続できるようにするサービス、および標準のパーティション・キャッシュ・サービスです。このディスクリプタはDefaultCacheServerで使用しているため、クラスタ・サービスの終了時に自動的に再起動するように、各サービスのautostart構成要素をtrueに設定しておくことが重要です。proxy-scheme要素には、tcp-acceptorという子要素があり、この子要素には、TCP/IPを介してクライアント接続リクエストを受け入れるために必要なTCP/IP固有の情報がすべて含まれます。

前述のように構成されたCoherence*Extendのクラスタ・サービスは、localhostアドレスとport 9099で、受信リクエストをリスニングします。たとえば、dist-extendというCoherenceキャッシュにクライアントが接続しようとすると、Coherence*Extendのクラスタ・サービスがNamedCacheへの後続リクエストを同じ名前で代行します。その名前は、この例ではパーティション・キャッシュとなります。

17.2.2 クライアントでのCoherence*Extendの構成

Coherence*Extendクライアントでは、Coherenceクラスタ内で実行されるCoherence*Extendクラスタ・サービスへの接続およびCoherence*Extendクラスタ・サービスとの通信に、キャッシュ構成ディスクリプタの要素initiator-config内の情報が使用されます。これを例17-2に示します。

例17-2 リモートCoherenceクラスタに接続するための構成

<?xml version='1.0'?>

<cache-config xmlns="http://schemas.tangosol.com/cache"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://schemas.tangosol.com/cache
  assembly://Coherence/Tangosol.Config/cache-config.xsd">
  <caching-scheme-mapping>
    <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>
        </tcp-initiator>
        <outgoing-message-handler>
          <request-timeout>5s</request-timeout>
        </outgoing-message-handler>
      </initiator-config>
    </remote-cache-scheme>
  </caching-schemes>
</cache-config>

このキャッシュ構成ディスクリプタは、リモートCoherenceクラスタに接続するキャッシング・スキームを定義します。remote-cache-scheme要素には、tcp-initiatorという子要素があり、この子要素には、リモートCoherenceクラスタ内でCoherence*Extendクラスタ・サービスが実行されているクライアントへの接続に必要なTCP/IP固有の情報がすべて含まれます。

クライアント・アプリケーションで、たとえばdist-extendという名前を使用してCacheFactoryで名前付きキャッシュを取得すると、Coherence*Extendクライアントは(アドレスlocalhostport 9099による)TCP/IPを使用してCoherenceクラスタに接続し、INamedCache実装を返します。この実装は、リモート・クラスタの中で実行している同名のNamedCacheにリクエストをルーティングする機能を持っています。remote-addresses構成要素には、子要素socket-addressを複数記述できます。Coherence*Extendのクライアントは、記載されたアドレスをすべて試すか、またはTCP/IP接続が確立されるまで、アドレスへの接続をランダムに試行します。

17.2.2.1 .NETクライアント用ローカル・キャッシュの定義

ローカル・キャッシュは、特定の.NETアプリケーションに対してローカルである(つまりアプリケーション内に完全に含まれる)キャッシュです。ローカル・キャッシュの特に興味深い属性について、次に示します。

  • ローカル・キャッシュは、リモート・キャッシュが実装するものと同じ標準キャッシュ・インタフェースを実装します(ICacheIObservableCacheIConcurrentCacheIQueryCacheおよびIInvocableCache)。つまり、使用するキャッシュがローカルであってもリモートであっても、プログラミング上の違いはありません。

  • ローカル・キャッシュのサイズは制限できます。サイズの制限とは、ローカル・キャッシュでキャッシュするエントリ数を制限し、キャッシュがいっぱいになったらエントリを自動的に削除できることを意味します。さらに、エントリのサイジングとエビクション・ポリシーの両方をカスタマイズできます。たとえば、キャッシュされたエントリで使用されるメモリーに基づいてキャッシュ・サイズを制限できます。デフォルトのエビクション・ポリシーでは、対数曲線で測定された、最も頻繁に使用する(MFU)情報と最後に使用した(MRU)情報の組合せを使用して削除するキャッシュ項目が決定されます。このアルゴリズムは、短期キャッシュと長期キャッシュの両方に対して十分に機能し、頻度と新しさのバランスをとってキャッシュ・スラッシングを回避するため、最適な汎用エビクション・アルゴリズムであるといえます。また、ピュアLRUアルゴリズムおよびピュアLFUアルゴリズムがサポートされ、カスタム・エビクション・ポリシーのプラグイン機能もサポートされています。

  • ローカル・キャッシュはキャッシュ・エントリの自動失効をサポートしています。つまり、キャッシュ内の各キャッシュ・エントリにTTL値を割り当てることができます。さらに、定期的または事前に設定した時刻にフラッシュするようキャッシュ全体を構成できます。

  • ローカル・キャッシュはスレッド・セーフで、高い並行性を備えています。

  • ローカル・キャッシュでは、キャッシュのget統計が提供されます。ここには、キャッシュ・ヒットおよびキャッシュ・ミスの統計情報が保持されます。これらの実行時統計は、キャッシュの有効性を正確に推定できるため、キャッシュ実行時にそのサイズ制限や自動失効の設定を適宜調整できます。

Coherence for .NETのローカル・キャッシュ機能は、Tangosol.Net.Cache.LocalCacheクラスによって実装されます。したがって、このキャッシュはプログラムでインスタンス化して構成することが可能ですが、Coherence for .NETの他のキャッシュ同様、LocalCacheはキャッシュ構成ディスクリプタを使用して構成することをお薦めします。

ローカル・キャッシュの主要な構成要素は<local-scheme>です。ローカル・キャッシュは通常、ニアスキームのフロント層としてなど、他のキャッシュ・スキーム内にネストされています。このため、この要素はcoherence-cache-configファイル内の、<caching-schemes>、<distributed-scheme>、<replicated-scheme>、<optimistic-scheme>、<near-scheme>、<overflow-scheme>および<read-write-backing-map>の各要素のサブ要素として使用できます。

<local-scheme>には、キャッシュの特性を定義できるいくつかのサブ要素がオプションで用意されています。たとえば、<low-units>および<high-units>サブ要素はキャッシュのサイズを制限します。キャッシュが最大許容サイズに達すると、指定されたエビクション・ポリシー(<eviction-policy>)に従って削除対象エントリが決定され、指定されたより小さなサイズに戻ります。エントリおよびサイズの制限は、該当するスキームの単位換算カリキュレータ(<unit-calculator>)で計算される単位で測定されます。カスタム・クラスを定義するには、<eviction-policy>要素と<unit-calculator>要素の両方の<class-scheme>サブ要素を使用して、必要に応じてカスタム動作を指定します。

キャッシュの有効期間も制限できます。<expiry-delay>サブ要素は、前回の更新からエントリが期限切れとしてマークされるまでの、キャッシュでエントリが保持される期間を指定します。期限切れのエントリを読み取るには、構成済のキャッシュ・ストア(<cachestore-scheme>)からエントリをリロードすることになります。期限切れになった値は、フラッシュ遅延に基づいてキャッシュから定期的に破棄されます。

<cachestore-scheme>が指定されていない場合、キャッシュされたデータはメモリー内に存在して、キャッシュに対して実行された操作のみが反映されます。使用可能なすべてのサブ要素の詳細は、<local-scheme>を参照してください。

例17-3は、ニア・キャッシュの構成を示しています。

例17-3 ローカル・キャッシュの構成

<?xml version='1.0'?>

<cache-config xmlns="http://schemas.tangosol.com/cache"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://schemas.tangosol.com/cache
  assembly://Coherence/Tangosol.Config/cache-config.xsd">
  <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>
      <cachestore-scheme>
        <class-scheme>
          <class-name>ExampleCacheStore</class-name>
        </class-scheme>
      </cachestore-scheme>
      <pre-load>true</pre-load>
    </local-scheme>
  </caching-schemes>
</cache-config>

17.2.2.2 .NETクライアント用ニア・キャッシュの定義

この項では、Coherence for .NETクライアントに関係するニア・キャッシュについて説明します。ニア・キャッシュの概念、その構成、およびバック層との同期を維持する方法の詳細は、『Oracle Coherence開発者ガイド』を参照してください。

Coherence for .NETでのニア・キャッシュは、リードスルー/ライトスルー方式を使用してフロント・キャッシュとバック・キャッシュをラップするINamedCache実装です。バック・キャッシュがIObservableCacheインタフェースを実装している場合、ニア・キャッシュはListen NoneListen PresentListen AllListen Autoのいずれかの方針を使用して、バック・キャッシュで変更された可能性のあるフロント・キャッシュ・エントリを無効化します。

Tangosol.Net.Cache.NearCacheクラスを使用すると、.NETニア・キャッシュ機能をプログラムでインスタンス化して構成できます。ただし、ニア・キャッシュの構成にはキャッシュ構成ディスクリプタを使用することをお薦めします。

一般的なニア・キャッシュは、ローカル・キャッシュ(スレッド・セーフで並行性が高く、かつサイズが制限されていて、場合によっては自動的に失効するもの)をフロント・キャッシュとして使用し、リモート・キャッシュをバック・キャッシュとして使用するように構成されます。ニア・キャッシュの構成には、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>などがあります。

例17-4は、ニア・キャッシュの構成を示しています。

例17-4 ニア・キャッシュの構成

<?xml version="1.0"?>

<cache-config xmlns="http://schemas.tangosol.com/cache"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://schemas.tangosol.com/cache
  assembly://Coherence/Tangosol.Config/cache-config.xsd">
   <caching-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>

17.2.3 接続エラーの検出とフェイルオーバー

ネットワーク、ソフトウェア、ハードウェアなどの障害によってクライアントとクラスタ間の接続が切断されたことをCoherence*Extendのクライアント・サービスが検出すると、このCoherence*Extendのクライアント・サービスの実装(ICacheServiceまたはIInvocationService)によってMemberEventHandlerデリゲートを使用してMemberEventType.Leftイベントが発生し、このクライアント・サービスは停止します。クライアント・アプリケーションがその後もこのサービスを使用しようとする場合には、サービス自体が自動的に再起動してクラスタへの再接続を試行します。このサービスが接続に成功するとMemberEventType.Joinedイベントが発生し、接続に失敗するとクライアント・アプリケーションに修復できないエラーの例外がスローされます。

Coherence*Extendサービスには、接続の切断を検出するためのメカニズムがいくつか用意されています。その中には、(Extend-TCPのTCP/IPのように)基底プロトコルに固有のものもあれば、サービス自体に実装されるものもあります。後者のメカニズムは、outgoing-message-handler構成要素を使用して構成されます。

接続の切断を検出するためにCoherence*Extendのクライアント・サービスで使用される構成可能な主要メカニズムは、リクエストのタイムアウトです。サービスがリモート・クラスタにリクエストを送信したが、リクエストのタイムアウト時間内にレスポンスを受信しなかった場合(<request-timeout>を参照)、サービスでは接続が切断されたと想定されます。Coherence*Extendのクライアント・サービスおよびクラスタ・サービスは、接続を介して定期的にハートビートを送信するように構成することもできます(<heartbeat-interval><heartbeat-timeout>を参照)。構成されたハートビートのタイムアウト時間内にサービスがレスポンスを受信しなかった場合、サービスでは接続が切断されたと想定されます。

17.3 CoherenceのDefaultCacheServerプロセスの起動

すでに説明したクラスタ側のCoherenceキャッシュ構成を使用するDefaultCacheServerを起動し、TCP/IPを使用してCoherence for .NETクライアントをCoherenceクラスタに接続できるようにするには、次の手順を実行する必要があります。

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

  2. Javaコマンドが実行されるようにパスを構成します。

  3. DefaultCacheServerコマンドライン・アプリケーションを起動します。その際に、-Dtangosol.coherence.cacheconfigシステム・プロパティを、すでに説明したクラスタ側Coherenceキャッシュ構成ディスクリプタの場所に設定します。

例17-5にコマンドラインのサンプルを示します。

例17-5 Coherenceのデフォルト・キャッシュ・サーバーを起動するコマンド

java -cp coherence.jar -Dtangosol.coherence.cacheconfig=file://<path to the server-side cache configuration descriptor> com.tangosol.net.DefaultCacheServer

17.4 .NETによるキャッシュ参照の取得

CacheFactoryクラスを使用することによって、構成済キャッシュへの参照を名前によって取得できます。

例17-6 キャッシュへの参照の取得

INamedCache cache = CacheFactory.GetCache("example-local-cache");

17.5 キャッシュに関連付けられたリソースのクリーンアップ

すべてのINamedCache実装のインスタンスは、LocalCacheを含め、不要になった時点でINamedCache.Release()メソッドをコールして明示的に解放し、これらのインスタンスで保持されているリソースをすべて解放する必要があります。

特定のINamedCacheがアプリケーションの継続期間を通して使用される場合、リソースはそのアプリケーションがシャットダウンされたとき、または停止したときにクリーンアップされます。ただし、わずかの間だけ使用される場合は、使い終わった時点でアプリケーションからRelease()メソッドをコールする必要があります。

または、INamedCacheIDisposableを拡張し、すべてのキャッシュ実装がIDisposable.Dispose()のコールをINamedCache.Release()に委任しているという事実を利用する方法もあります。単一メソッド内でキャッシュ・インスタンスを取得および解放する必要がある場合、次のusingブロックを使用してそれを実現できます。

例17-7 キャッシュへの参照の取得と解放

using (INamedCache cache = CacheFactory.GetCache("my-cache"))
{
   // use cache as usual
}

usingブロックが終了すると、INamedCacheインスタンスでIDisposable.Dispose()がコールされ、そのインスタンスに関連付けられているすべてのリソースが解放されます。