8 Coherenceの起動と停止

キャッシュ・サーバーを開始および停止し、クラスタの一部であるクライアントをキャッシュできます。

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

  • ブートストラップAPIの使用
    Coherenceには、com.tangosol.net.Coherenceインスタンスを構築してこのインスタンスを起動することにより、Coherenceアプリケーションを構成および起動できるシンプルなブートストラップAPIがあります。
  • 従来のDefaultCacheServerクラスの使用
    キャッシュ・サーバーは、キャッシュされたデータを保存するクラスタ・メンバーです。
  • 従来のCacheFactoryクライアントの使用
    キャッシュ・クライアントは、クラスタに参加して、そのクラスタのサービスと通信するクラスタ・メンバーです。
  • クラスタ・メンバーの停止
    コマンドラインまたはプログラムからクラスタ・メンバーを停止できます。
  • ローリング再起動の実行
    ローリング再起動は、再起動中にデータを失うことなく、クラスタ内のキャッシュ・サーバーを再起動する技術です。

親トピック: Coherenceクラスタの使用

ブートストラップAPIの使用

Coherenceには、com.tangosol.net.Coherenceインスタンスを構築してこのインスタンスを起動することにより、Coherenceアプリケーションを構成および起動できるシンプルなブートストラップAPIがあります。

Coherenceインスタンスは、1つ以上のcom.tangosol.net.Sessionインスタンスへのアクセスを提供します。com.tangosol.net.Sessionは、Coherenceクラスタ化リソース(NamedMap、NamedCache、NamedTopicなど)へのアクセス権を付与します。セッションのタイプは様々です。たとえば、セッションには次のようなものがあります。
  • ConfigurableCacheFactoryに関連します。
  • 構成ファイルから構成されます。
  • クライアント側のgRPCセッションです。

例8-1 アプリケーションのブートストラップ・コード

import com.tangosol.net.Coherence;
import com.tangosol.net.CoherenceConfiguration;
import com.tangosol.net.SessionConfiguration;

public class Main
    {
    public static void main(String[] args)
        {
        // Create a session configuration                                
        SessionConfiguration session = SessionConfiguration.builder()
                .named("Carts")
                .withConfigUri("cache-config.xml")
                .build();

        // Create a Coherence instance configuration                     
        CoherenceConfiguration cfg = CoherenceConfiguration.builder()
                .withSession(SessionConfiguration.defaultSession())
                .withSession(session)
                .build();

        // Create the Coherence instance from the configuration          
        Coherence coherence = Coherence.clusterMember(cfg);

        // Start Coherence                                               
        coherence.start();
        }
    }
この例では:
  • 「セッション構成の作成」の部分では、Session名がCartsのcache-config.xml構成ファイルからSessionConfigurationを作成します。
  • 「Coherenceインスタンス構成の作成」の部分では、CoherenceConfigurationを作成して、Coherenceインスタンスを構成します。この構成には、Cartsセッション構成が含まれます。
  • 「構成からCoherenceインスタンスを作成」の部分では、CoherenceConfigurationからCoherenceクラスタ・メンバー・インスタンスを作成します。
  • 「Coherenceの起動」の部分では、Coherenceインスタンスを起動します。

この項には次のトピックが含まれます:

親トピック: Coherenceの起動と停止

Coherenceサーバーの実行

com.tangosol.net.Coherenceには、Coherenceサーバーの実行に使用できるmainメソッドが含まれています。このメソッドは、DefaultCacheServerのより強力な代替手段です。
$ java -cp coherence.jar com.tangosol.net.Coherence

他の構成がない場合、前述のコマンドを使用して起動されたデフォルトのCoherenceインスタンスは、DefaultCacheServerを使用して実行されるサーバーと同じサーバーを実行します。

親トピック: ブートストラップAPIの使用

セッション構成

SessionConfigurationビルダーを使用して、SessionConfigurationという名前のセッション構成を作成できます。ブートストラップAPIの使用の例を参照してください。

この項には次のトピックが含まれます:

親トピック: ブートストラップAPIの使用

デフォルト・セッションについて

Coherenceの実行時に構成を指定しなかった場合は、デフォルトの構成ファイルを使用してCoherenceを構成します。この動作は、ブートストラップAPIに引き続き適用されます。

セッション構成を指定せずにCoherenceインスタンスを起動すると、単一のデフォルトSessionが作成されます。このデフォルトのSessionは、デフォルトの構成ファイルから作成されたキャッシュ・ファクトリ・インタフェースConfigurableCacheFactoryをラップします。Interface ConfigurableCacheFactoryを参照してください。デフォルトの構成ファイルのデフォルト・ファイル名は、coherence.cacheconfigシステム・プロパティでオーバーライドされないかぎり、coherence-cache-config.xmlです。

CoherenceConfigurationという名前のCoherence構成インスタンスを作成する場合は、SessionConfiguration.defaultSession()ヘルパー・メソッドを使用してデフォルト・セッションを追加できます。このメソッドは、デフォルト・セッションSessionを作成するように構成されたSessionConfigurationを返します。

次の例では、デフォルトのセッション構成が明確にCoherenceConfigurationに追加されます。
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .withSession(SessionConfiguration.defaultSession())
        .build();

親トピック: セッション構成

セッションの命名

すべてのセッションの名前は、アプリケーション内で一意である必要があります。SessionConfigurationの作成時に名前を指定しなかった場合、デフォルト名の$Default$が使用されます。重複するSession名が存在する場合、Coherenceインスタンスは起動に失敗します。

例:

  • この構成ではデフォルト名($Default$)に設定されます:
    SessionConfiguration session = SessionConfiguration.builder()
        .build();
  • この構成ではTestという名前になります:
    SessionConfiguration session = SessionConfiguration.builder()
        .name("Test")
        .build();

親トピック: セッション構成

セッション構成URIの指定

最も一般的なセッションのタイプは、ConfigurableCacheFactoryのラッパーです。SessionConfigurationビルダーを使用する場合は、withConfigUri()メソッドを使用して構成ファイルURIを指定できます。このメソッドは、構成ファイルの場所を指定するための文字列値を受け入れます。

次の例では、cache-config.xmlという名前の構成ファイルを使用します。
SessionConfiguration session = SessionConfiguration.builder()
        .withConfigUri("cache-config.xml")
        .build();

構成URIを指定しない場合は、デフォルト値が使用されます。デフォルト値は、coherence.cacheconfigシステム・プロパティでオーバーライドされないかぎり、coherence-cache-config.xmlです。

親トピック: セッション構成

セッション・イベント・インターセプタの追加

Coherenceは様々なタイプのイベントを提供します。たとえば、Coherence自体のライフサイクル・イベント、キャッシュ・ライフサイクル・イベント、キャッシュ・エントリ・イベント、パーティション・イベントなどです。これらのイベントは、特定のタイプのイベントを受信するEventInterceptorを実装することでリスニングできます。イベント・インターセプタは、構成の一部としてSessionに登録できます。

たとえば、キャッシュの作成または破棄時にCacheLifecycleEventイベントをリスニングするCacheInterceptorというインターセプタ・クラスがアプリケーションにあるとします。次に示すように、このインターセプタをセッションに追加できます。
SessionConfiguration session = SessionConfiguration.builder()
        .withInterceptor(new CacheInterceptor())
        .build();

インターセプタは、セッションを使用して作成されたすべてのキャッシュのキャッシュ・ライフサイクル・イベントを受信します。

親トピック: セッション構成

セッション構成のスコープ指定

スコープは、サービスのスコープを指定し、同じ名前の他のサービスから分離するのに役立つ概念です。たとえば、同じXML構成ファイルからロードされた複数のConfigurableCacheFactoryインスタンスを、異なるスコープ名にすることができます。スコープ指定により、各ConfigurableCacheFactoryインスタンスがクラスタ内に独自のサービスを持ちます。

複数のセッションが必要な場合を除き、スコープは通常、構成では使用されません。

次の例に示すように、構成のwithScopeName()メソッドを使用して、セッションのスコープを構成できます。
SessionConfiguration session = SessionConfiguration.builder()
        .withScopeName("Test")
        .build();

前述の構成から作成されたセッション(およびラップするConfigurableCacheFactory)のスコープ名は、Testです。

XML構成ファイルの<defaults>セクションでスコープ名を設定することもできます。scoped-configuration.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">

  <defaults>
    <scope-name>Test</scope-name>
  </defaults>

このXMLファイルから作成されたConfigurableCacheFactoryインスタンスと、それをラップするSessionは、スコープ名がTestになります。

ノート:

ブートストラップAPIを使用する場合、SessionConfigurationに明確に構成されたスコープ名(デフォルトのスコープ名ではない)によって、XMLファイルのスコープ名がオーバーライドされます。

たとえば、次のシナリオでは、scoped-configuration.xmlファイル(前述の例を参照)を使用してスコープ名を定義する様々な方法を示します。

  • この場合、スコープ名がSessionConfigurationで明示的に設定されているため、スコープ名はFooになります。
    SessionConfiguration session = SessionConfiguration.builder()
        .withConfigUri("scoped-configuration.xml")
        .withScopeName("Foo")
        .build();
  • この場合、スコープ名がSessionConfigurationで明示的に設定されていなくても、名前がFooに設定されているため、スコープ名はFooになります。したがって、スコープ名はデフォルトでFooになります。
    SessionConfiguration session = SessionConfiguration.builder()
        .named("Foo")
        .withConfigUri("scoped-configuration.xml")
        .build();
  • この場合、スコープ名またはセッション名がSessionConfigurationで明示的に設定されていないため、スコープ名はTestになります。したがって、XML構成からTestのスコープ名が使用されます。
    SessionConfiguration session = SessionConfiguration.builder()
        .withConfigUri("scoped-configuration.xml")
        .build();
  • この場合、セッション名がFooに設定されているため、スコープ名はTestになります。ただし、スコープ名は、定数Coherence.DEFAULT_SCOPEを使用してデフォルトのスコープ名に明示的に設定されています。したがって、XML構成からTestのスコープ名が使用されます。
    SessionConfiguration session = SessionConfiguration.builder()
        .named("Foo")
        .withScopeName(Coherence.DEFAULT_SCOPE)
        .withConfigUri("scoped-configuration.xml")
        .build();

親トピック: セッション構成

Coherenceインスタンスの構成

Coherenceアプリケーションは、CoherenceConfigurationからCoherenceインスタンスを作成することで起動できます。CoherenceConfigurationのインスタンスは、ビルダーを使用して作成されます。たとえば:
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .build();

この項には次のトピックが含まれます:

親トピック: ブートストラップAPIの使用

セッションの追加

Coherenceインスタンスは、1つ以上のSessionインスタンスを管理します。これらのセッション・インスタンスをCoherenceConfigurationに追加するには、SessionConfigurationインスタンスをビルダーに追加します。

ビルダーにセッションを追加しない場合、Coherenceインスタンスは、デフォルトの構成ファイルを使用する単一のSessionを実行します。
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .build();

前述の構成では、デフォルトの名前で、デフォルトの構成ファイルを使用する単一のSessionを使用して、Coherenceインスタンスを構成します。

デフォルト・セッションを明示的にCoherenceConfigurationに追加することもできます。
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .withSession(SessionConfiguration.defaultSession())
        .build();
他のセッション構成をCoherenceConfigurationに追加することもできます。
SessionConfiguration session = SessionConfiguration.builder()
        .named("Carts")
        .withConfigUri("cache-config.xml")
        .build();

CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .withSession(session)
        .build();

構成できるセッション数に制限はありませんが、ほとんどのアプリケーションに必要なセッションは1つのみです。これはほとんどの場合、デフォルト・セッションです。

自動検出用のセッションの構成

SessionConfigurationインスタンスを自動的に検出するようにCoherenceConfigurationを構成できます。これらのインスタンスは、Java ServiceLoaderを使用して検出されます。META-INF/services/ファイルにサービスとして構成されているSessionConfigurationまたはSessionConfiguration.Providerのインスタンスがすべてロードされます。

この機能は、独自のSessionを使用する別のアプリケーション・モジュールに機能を含めるモジュラ・アプリケーションを構築する場合に便利です。モジュールのSessionConfigurationインスタンスは、Java ServiceLoaderによって検出可能になります。モジュールのjarファイルがクラスパスにある場合、Sessionが作成され、モジュールの機能がアプリケーションで使用可能になります。

たとえば:
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .discoverSessions() 
        .build();

この例では、discoverSessions()のコールによって、Java ServiceLoaderによって検出されたSessionConfigurationインスタンスがロードされます。

Coherenceインスタンスの命名

各Coherenceインスタンスに一意の名前を付ける必要があります。ビルダーでnamed()メソッドを使用して名前を指定できます。名前を指定しない場合は、デフォルト名の$Default$が使用されます。

ほとんどのユースケースでは、アプリケーションに必要なCoherenceインスタンスは1つのみです。そのため、名前を指定する必要はありません。

次のコードでは、構成によってCartsという名前のCoherenceインスタンスが作成されます。
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .named("Carts")
        .build();
グローバル・イベント・インターセプタの追加

SessionConfigurationインスタンスにイベント・インターセプタを追加して、セッションのイベントを受信できます。セッション・イベント・インターセプタの追加を参照してください。イベント・インターセプタをCoherenceインスタンスに追加して、そのCoherenceインスタンスによって管理されるすべてのSessionインスタンスのイベントを受信することもできます。

たとえば、すべてのセッションのキャッシュにCacheInterceptorクラスを再利用すると、インターセプタはデフォルト・セッションとCertsセッションの両方のイベントを受信します。
SessionConfiguration cartsSession = SessionConfiguration.builder()
         .named("Carts")
         .withConfigUri("cache-config.xml")
         .build();

CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .withSession(SessionConfiguration.defaultSession())
        .withSession(cartsSession)
        .withInterceptor(new CacheInterceptor())
        .build();

Coherenceインスタンスの作成

CoherenceConfigurationインスタンスを使用して、Coherenceインスタンスを作成できます。

Coherenceインスタンスは、次の2つのモードのいずれかで作成できます。
  • クラスタ・メンバー
  • クライアント

選択したモードは、一部のタイプのSessionの作成方法と、自動起動サービスが開始されているかどうかに影響します。

名前が示すように、クラスタ・メンバーとは、Coherenceクラスタの起動または参加が予期されるCoherenceインスタンスです。クラスタ・メンバーでは、ConfigurableCacheFactoryをラップするSessionは、そのサービスが自動起動および監視されます(これは、DefaultCacheServerを使用してサーバーを起動する場合と同じ動作です)。

クライアントCoherenceインスタンスは通常、クラスタ・メンバーではなく、Coherence*ExtendまたはgRPCクライアントです。そのため、ConfigurableCacheFactoryをラップするSessionインスタンスは自動起動されません。かわりに、マップ、キャッシュ、トピックなどのリソースがリクエストされるため、オンデマンドで起動します。

com.tangosol.net.Coherenceクラスには、様々なモードでCoherenceインスタンスを作成するための静的ファクトリ・メソッドがあります。

例:
  • クラスタ・メンバーであるCoherenceインスタンスを作成するには、次に示すようにCoherence.clusterMemberメソッドを使用します。
    CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .build();

Coherence coherence = Coherence.clusterMember(cfg);
  • クライアントであるCoherenceインスタンスを作成するには、次に示すようにCoherence.clientメソッドを使用します。
    CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .build();

Coherence coherence = Coherence.client(cfg);

この項には次のトピックが含まれます:

親トピック: ブートストラップAPIの使用

デフォルトのCoherenceインスタンスの作成
構成を指定せずにCoherenceインスタンスを作成できます。
Coherence coherence = Coherence.clusterMember();
Coherence coherence = Coherence.client();

前述の例では、CoherenceインスタンスにはデフォルトのSessionおよび検出されたセッションが含まれます。

Coherenceの起動

Coherenceインスタンスで管理されているすべてのセッションを開始するには、Coherenceインスタンスを起動する必要があります。Coherenceインスタンスを起動するには、次に示すようにstart()メソッドをコールします。
Coherence coherence = Coherence.clusterMember(cfg);
coherence.start();

親トピック: ブートストラップAPIの使用

Coherenceインスタンスの取得

アプリケーションのブートストラップに使用されたCoherenceのインスタンスを渡す必要がないように、Coherenceクラスには、インスタンスの取得を簡単にするいくつかの静的メソッドがあります。

Coherenceの単一インスタンスのみがアプリケーションで使用されている場合(ほとんどのユースケースで当てはまる)、getInstance()メソッドを使用します。
Coherence coherence = Coherence.getInstance();
次のように構成して、インスタンスを名前で取得することもできます。
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .named("Carts")
        .build();

Coherence.create(cfg);
次に、インスタンスを取得します。
Coherence coherence = Coherence.getInstance("Carts");

親トピック: ブートストラップAPIの使用

Coherenceの起動の確認

処理を行う前にアプリケーション・コードでCoherenceインスタンスが起動していることを確認する必要がある場合は、whenStarted()メソッドを使用します。このメソッドは、Coherenceインスタンスが起動したときに完了するCompletableFutureを取得します。

たとえば:
Coherence               coherence = Coherence.getInstance("Carts");
CompletableFuture<Void> future    = coherence.whenStarted();

future.join();

また、対応するwhenStopped()メソッドもあり、Coherenceインスタンスが停止したときに完了するFutureを返します。

親トピック: ブートストラップAPIの使用

Coherenceライフサイクル・インターセプタの追加

Coherenceの起動の確認で説明されている将来のメソッドを使用する以外に、Coherenceインスタンスの構成にEventInterceptorを追加して、ライフサイクル・イベントを受信できます。

次に、Coherence.LifecycleListenerを実装するインターセプタの例を示します。
public class MyInterceptor implements Coherence.LifecycleListener {
    public void onEvent(CoherenceLifecycleEvent event) {
        // process event
    }
}
インターセプタは次の構成に追加できます。
CoherenceConfiguration cfg = CoherenceConfiguration.builder()
        .withSession(SessionConfiguration.defaultSession())
        .withInterceptor(new MyInterceptor())
        .build();

この構成から作成されたCoherenceインスタンスを起動または停止すると、MyInterceptorインスタンスはライフサイクル・イベントの受信を開始します。

親トピック: ブートストラップAPIの使用

従来のDefaultCacheServerクラスの使用

キャッシュ・サーバーは、キャッシュしたデータを保存するクラスタ・メンバーです。クラスタは、多数のキャッシュ・サーバーで構成される場合があります。各キャッシュ・サーバーはそれぞれ専用のJVMを使用します。

この項には次のトピックが含まれます:

親トピック: Coherenceの起動と停止

DefaultCacheServerクラスの概要

キャッシュ・サーバーを起動するには、com.tangosol.net.DefaultCacheServerクラスを使用します。キャッシュ・サーバーはコマンド行から起動するか、またはプログラムによって起動できます。キャッシュ・サーバーを起動する際は、次の引数を使用します。

  • クラスパスで見つかるキャッシュ構成ファイルの名前、またはグリッド・アーカイブ(GAR)へのパス。両方が指定された場合、GARが優先されます。GARは、Coherenceアプリケーションからなるアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、ディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。Oracle Coherenceの管理のCoherence GARモジュールの構築を参照してください。

  • GARのアプリケーション名(オプション)。名前を指定しない場合は、アーカイブ名が使用されます。(ディレクトリ名、または.gar拡張子なしのファイル名)。この名前は、クラスタ上の別のアプリケーションに使用されるアプリケーション・スコープを提供します。

  • 停止済のサービスを確認する間隔(秒数)。停止したサービスは、自動的に開始するように設定されている場合のみ、自動的に開始されます(キャッシュ構成ファイルの<autostart>要素で構成します)。引数が指定されなかった場合のデフォルト値は5秒です。

親トピック: 従来のDefaultCacheServerクラスの使用

コマンド行からのキャッシュ・サーバーの起動

通常、キャッシュ・サーバーはコマンド行から起動します。Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成の理解を参照してください。

次の例では、キャッシュ・サーバー・メンバーを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、2秒ごとにサービスの再起動を確認します。 

java -server -Xms512m -Xmx512m -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer 2

次の例では、キャッシュ・サーバー・メンバーを起動し、MyGar.garファイル内にパッケージ化されたCoherenceアプリケーションのアーティファクトを使用します。デフォルトの名前(MyGAR)がアプリケーション名として使用されます。 

java -server -Xms512m -Xmx512m -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar

ノート:

クラスパスにあるキャッシュ構成ファイルよりも、GARファイル内にパッケージ化されたキャッシュ構成ファイルが優先されます。

キャッシュ・サーバー・インスタンスを容易に起動できるように、COHERENCE_HOME\bin\cache-serverスクリプトが用意されています。スクリプトは、Windows用(cache-server.cmd)およびUNIXベース・プラットフォーム用(cache-server.sh)の両方に対して使用できます。このスクリプトを使用すると、基本的な環境を設定してDefaultCacheServerクラスを実行できます。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。

ヒント:

テスト中は、各キャッシュ・サーバーを一意に特定する複数のスクリプトをそれぞれ異なる名前で作成しておくと便利なことがあります。たとえば、cahe-server-a、cache-server-bのようにします。

最後に、coherence.jarライブラリとともにjava -jarコマンドを使用することで、キャッシュ・サーバーをコマンド行で起動できます。キャッシュ・サーバーは、通常はテストとデモを目的とした場合に、このように起動されます。たとえば: 

java -jar COHERENCE_HOME\lib\coherence.jar

親トピック: 従来のDefaultCacheServerクラスの使用

プログラムによるキャッシュ・サーバーの起動

ブートストラップAPIを使用するか、com.tangosol.net.Coherence.main()メソッドを実行して起動されたCoherenceクラスタ・メンバーは、静的com.tangosol.net.Coherence.closeAll()メソッドをコールして停止できます。

従来のDefaultCacheServerクラスには、キャッシュ・サーバーのシャットダウンに使用する、次の2つのメソッドが用意されています:

ノート:

DefaultCacheServerクラス自身がstaticメンバーとして保持しているインスタンスをシャットダウンするスタンドアロン・アプリケーションで、シャットダウンがコールされることを想定しています。
  • shutdown() - DefaultCacheServer.main()メソッドまたはDefaultCacheServer.start()メソッドを使用して別のスレッドで起動したキャッシュ・サーバーのシャットダウンに使用するstaticメソッドです。
  • shutdownServer() - このメソッドは、アプリケーションが保持しているDefaultCacheServerインスタンスに対してコールします。

親トピック: 従来のDefaultCacheServerクラスの使用

Coherenceライフサイクル・リスナー

Coherenceでは、Coherenceクラスタ・メンバーまたはクライアントを起動する際に、Coherenceの起動ライフサイクルの前、最中および後に、アプリケーション固有のロジックのトリガーに使用できる様々なライフサイクル・イベントが作成されます。ライフサイクル・イベント・リスナーは、アプリケーション固有の起動と停止のロジックを実行するカスタムのアプリケーション・メイン・クラスのかわりによく使用されます。

ライフサイクル・イベントは、次のインスタンスで使用できます:

  • Coherenceインスタンス
  • Sessionインスタンス
  • ConfigurableCacheFactoryインスタンス
  • DefaultCacheServerインスタンス

これらのイベントおよびリスナーの詳細は、「Coherenceライフサイクル・リスナー」を参照してください。

親トピック: 従来のDefaultCacheServerクラスの使用

従来のCacheFactoryクライアントの使用

キャッシュ・クライアントは、クラスタに参加してそのクラスタのサービスとやりとりするクラスタ・メンバーです。キャッシュ・クライアントには、キャッシュとの間でデータをやりとりするアプリケーションのような単純なものもあれば、キャッシュにあるデータを処理するデータ・グリッド演算アプリケーションのような複雑なものもあります。キャッシュ・クライアントとキャッシュ・サーバーとの大きな違いは、一般的にクラスタの記憶域にはキャッシュ・クライアントは関与しないという点です。

この項には次のトピックが含まれます:

親トピック: Coherenceの起動と停止

ローカル記憶域の無効化

パーティション・キャッシュ・サービス(分散キャッシュ)を使用するキャッシュ・クライアントでは、パーティション化したデータを保持しないようにします。記憶域を無効にしたキャッシュ・クライアントは良好なパフォーマンスを示し、使用するリソースも少なくてすみます。パーティション化したデータを分散する範囲は、キャッシュ・サーバー・インスタンスどうしのみとする必要があります。

coherence.distributed.localstorageシステム・プロパティを使用して、プロセス単位でローカル記憶域を無効化します。これにより、キャッシュ・クライアントとキャッシュ・サーバーで同じ構成ディスクリプタを使用できます。たとえば: 

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.MyApp

親トピック: 従来のCacheFactoryクライアントの使用

キャッシュ・クライアントを起動するためのCacheFactoryクラスの使用

com.tangosol.net.CacheFactoryクラスを使用してキャッシュのインスタンスを取得するアプリケーションはクラスタのメンバーとなり、キャッシュ・クライアントと見なされます。次の例は、キャッシュ・クライアントを起動する最も一般的な方法を示しています。 

CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("cache_name");

キャッシュ・クライアントであるアプリケーションを起動するときは、Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成の理解を参照してください。

次の例では、キャッシュ・クライアントであるアプリケーションを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、メンバー上の記憶域を無効化します。 

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.MyApp

テスト用のCOHERENCE_HOME\bin\coherenceスクリプトが用意されており、このスクリプトでキャッシュ・クライアント・インスタンスを起動できます。スクリプトは、Windows用(coherence.cmd)およびUNIXベース・プラットフォーム用(coherence.sh)の両方に対して使用できます。このスクリプトでは、基本的な環境を設定し、記憶域を無効化して、プロンプトを返すCacheFactoryクラスを実行します。プロンプトは、キャッシュおよびクラスタとやり取りを行うコマンドを入力するために使用されます。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。このクラスは、スクリプトを使用せずに、コマンド行から直接起動することもできます。たとえば: 

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.tangosol.net.CacheFactory

CoherenceアプリケーションがGARとしてパッケージ化されている場合は、クライアント・メンバーが起動された後にプロンプトでserverコマンドを使用して、CacheFactoryインスタンスによってGARをロードできます。 

server [<path-to-gar>] [<app-name>]

次の例では、MyGar.garファイル内にパッケージ化されたCoherenceアプリケーションのアーティファクトをロードします。デフォルトの名前(MyGAR)がアプリケーション名として使用されます。 

Map (?) server D:\example\MyGAR.gar

親トピック: 従来のCacheFactoryクライアントの使用

クラスタ・メンバーの停止

コマンドラインまたはプログラムからクラスタ・メンバーを停止できます。

この項には次のトピックが含まれます:

親トピック: Coherenceの起動と停止

すべてのクラスタ・メンバーを停止するための前提条件

管理された停止中にデータ損失がないようにするために、サービス中断機能を利用することができます。サービスは、アクティブ永続性モード、非同期永続性タスク、読取り/書込みバッキング・マップのライトビハインド・キューへの入力、その他の非同期操作を含め、すべてのデータが完全に書き込まれた後にのみ一時停止状態とみなされます。未処理の操作が完了し、一時停止したサービスに対して新しい操作は許可されません。

このため、クラスタの制御された完全な停止を行うために、Coherence ClusterMBean操作suspendService("Cluster")を実行することをお薦めします。これにより、クラスタ・メンバーを停止する前にすべてのサービスが正常に停止されます。

親トピック: クラスタ・メンバーの停止

コマンド行からのクラスタ・メンバーの停止

クラスタ・メンバーをシャットダウンするには、UNIXプラットフォームではkillコマンド、WindowsプラットフォームではCtrl+cを使用することが普通です。これらのコマンドでは、JVMの通常の終了で呼び出される標準のJVMシャットダウン・フックを開始します。

ノート:

kill -9コマンドを発行すると、異常なJVM終了が始まり、シャットダウン・フックは実行されません。ただし、終了するサービスがノードセーフであることが(JMXの管理を使用した確認で)終了前にわかっている場合は、一般的には正常なシャットダウンは不要です。

シャットダウン・コマンドを受け取ったクラスタ・メンバーが実行するアクションは、オペレーション・オーバーライド・ファイルの<shutdown-listener>要素で構成します。次のオプションを使用できます。

  • none - 明示的なシャットダウン・アクションを実行しません。

  • force – Cluster.stop()をコールすることにより、ノードのハードストップ(強制停止)を実行します。

  • graceful – (デフォルト) Cluster.shutdown()をコールすることにより、通常のシャットダウンを実行します。

  • true - forceと同じ。

  • false - noneと同じ。

coherence.shutdown.timeoutシステム・プロパティには、シャットダウンの完了まで待機する時間を構成します。この時間が経過するとタイムアウトします。デフォルト値は、2分です。Coherenceアプリケーションで、永続性、ライトビハインド・キャッシュ・ストア、または2分を超える時間がかかるその他の非同期操作が使用される場合は、保留中の非同期操作が完了できるようにタイムアウトを長く構成する必要があります。このシステム・プロパティ値には、3s (3秒)、5m (5分)、または1h (1時間)のように時間を構成します。

正常なシャットダウンが完了するまでにかかる時間がcoherence.shutdown.timeoutの時間を超えると、JVMプロセスはハングしたと見なされ、haltを使用して突然終了します。シャットダウンがタイムアウトすると、未処理の非同期操作すべては完了しない可能性があります。このため、アプリケーション環境で発生する可能性がある未処理の非同期操作数に応じて、十分な長さになるようにcoherence.shutdown.timeoutを構成することが重要です。

次の例では、シャットダウン・フックをnoneに設定します。 

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config
   coherence-operational-config.xsd">
   <cluster-config>
      <shutdown-listener>
         <enabled system-property="coherence.shutdownhook">none</enabled>
      </shutdown-listener>
   </cluster-config>
</coherence>

オペレーション・オーバーライド・ファイルのかわりにcoherence.shutdownhookシステム・プロパティを使用して、シャットダウン・フックの動作を指定します。たとえば: 

-Dcoherence.shutdownhook=none

親トピック: クラスタ・メンバーの停止

プログラムによるキャッシュ・サーバーの停止

DefaultCacheServerクラスには、キャッシュ・サーバーのシャットダウンに使用するメソッドが2つ用意されています。

ノート:

DefaultCacheServerクラス自身がstaticメンバーとして保持しているインスタンスをシャットダウンするスタンドアロン・アプリケーションで、シャットダウンがコールされることを想定しています。

  • shutdown() - DefaultCacheServer.main()メソッドまたはDefaultCacheServer.start()メソッドを使用して別のスレッドで起動したキャッシュ・サーバーのシャットダウンに使用するstaticメソッドです。

  • shutdownServer() - このメソッドは、アプリケーションが保持しているDefaultCacheServerインスタンスに対してコールします。

親トピック: クラスタ・メンバーの停止

ローリング再起動の実行

ローリング再起動は、再起動中にデータを失うことなく、クラスタ内のキャッシュ・サーバーを再起動する技術です。ローリング再起動を使用すると、キャッシュ・サーバーを再起動している間も、そのキャッシュ・サーバーのデータをクラスタ上の他のキャッシュ・サーバーに再配布できます。クラスタ内の各キャッシュ・サーバーを順番に再起動して、クラスタ全体の再起動を効果的に行うことができます。

通常、ローリング再起動は、キャッシュ・サーバーやそのホスト・コンピュータを更新する必要がある場合や、キャッシュ・サーバーを新しいパッチ・セット・リリースまたはパッチ・セット更新リリースにアップグレードする場合に実行されます。ただし、この技術は、キャッシュ・データの一部を現在管理しているキャッシュ・サーバーを再起動するときにいつでも使用することもできます。

ノート:

クラスタをアップグレードするときに、ローリング再起動はパッチ・セットまたはパッチ・セット・リリースまたはパッチ・セット更新リリースにアップグレードするためにのみ使用でき、メジャーまたはマイナー・リリースのアップグレードでは使用できません。Oracle Fusion Middlewareの管理のリリース番号の形式を参照してください。

この項には次のトピックが含まれます:

親トピック: Coherenceの起動と停止

ローリング再起動の前提条件

ローリング再起動には、最初に考慮しておくべき点があり、クラスタを再起動する前に設定が必要です。次の前提条件を満たしていないクラスタでは、ローリング再起動を実行できません。

  • JDKバージョンを変更する場合、ローリング再起動は同じメジャーJDKバージョンのパッチ・バージョン間でのみ実行できます。たとえば、JDK17内のパッチ(17.07から17.0.8など)。ただし、メジャーJDKバージョン間(11から17など)を移動する場合、ローリング・アップグレードは実行できません。

  • シリアライズ・タイプの変更(たとえば、JavaからPOFシリアライズへの移行またはその反対)は、サポートされていないため、行わないでください。

  • キャッシュ・クラスにフィールドを追加し、進化可能性をサポートしていない場合(「クラスのバージョニングおよび進化」を参照)、ローリング・アップグレードを実行できません。

  • クラスタ内のキャッシュ・サーバーは、単一のキャッシュ・サーバーのシャットダウンを処理するための十分な容量を備えている必要があります(n - 1。nはクラスタ内のキャッシュ・サーバーの数)。キャッシュ・サーバーが最大容量での稼働に達すると、データの再配布中にメモリー不足の例外またはデータ・エビクションが発生する可能性があります。Oracle Coherenceの管理のキャッシュ・サイズ計算の推奨事項を参照してください。

  • すべてのキャッシュ・サーバーでリモートJMX管理が有効になっていて、最低でも2つのキャッシュ・サーバーに稼働中のMBeanサーバーが含まれている必要があります。JConsoleなどのMBeanブラウザを使用して、MBeanサーバーに接続できることを確認してください。Oracle Coherenceの管理のJMXを使用したOracle Coherenceの管理を参照してください。

  • ローリング・アップグレードが適切に成功するために、環境でラムダ・シリアライズ・モードを動的に設定する必要があるかどうかを評価します。環境でローリング・アップグレードに動的ラムダ・シリアライズ・モードが必要かどうかを評価するには、ローリング・アップグレードに関する考慮事項を参照してください。Coherence本番モードをオーバーライドし、動的ラムダ・シリアライズ・モードを構成する方法については、ラムダ・シリアライズ・モードの構成を参照してください。

    ノート:

    Oracle Coherenceリリース14.1.1.2206では、Coherence本番モードはデフォルトで静的ラムダ・シリアライズに設定されます。このリリースより前のOracle Coherence 12.2.1.0.0以降は、動的シリアライズ・モードでのみ実行されていました。

非同期バックアップを使用するようにキャッシュ・サービスが構成されている場合、stopメソッドまたはkill -9ではなく、shutdownメソッドを使用して、正しい順序でシャットダウンを実行します。そうしないと、非同期バックアップの完了前にメンバーがシャットダウンされる場合があります。shutdownメソッドは、すべての更新が完了することを保証します。

永続性を使用する場合、ローリング再起動はディスクに格納されているデータの形式に依存しませんが、致命的なイベントに直面した場合にクラスタをロールバックできる「セーブポイント」があることを確認するために、予防的なステップを実行できるシナリオがあります。ディスク上の永続ファイルは、新しいバージョンから以前のバージョンに移行するときに読み取れなくなることがあります。

したがって、ロール前に関連するサービスの永続スナップショットを実行することをお薦めします。スナップショットを使用したキャッシュ・サービスの永続化を参照してください。これは、アプリケーションの許容範囲に基づいて、サービスを一時停止しながら(グローバルな整合性を確保するために)実行することも、実行しないことも可能です。スナップショットは、ロール中に問題が発生した場合にクラスタをロールバックできる「セーブポイント」を提供します。

ノート:

Coherenceによって、ディスクに保存されているデータの形式が変更される場合があります。記憶域形式の変更を含むバージョンからローリングする場合、ロール/アップグレードの前にスナップショットを作成することを強くお薦めします。

親トピック: ローリング再起動の実行

ローリング再起動のためのキャッシュ・サーバーの再起動

次の手順を使用して、キャッシュ・サーバーを再起動します。ホスト・コンピュータを再起動する場合は、コンピュータをシャットダウンする前にすべてのキャッシュ・サーバー・プロセスが停止していることを確認してください。

ノート:

次の手順では、同じCoherence JARまたはORACLE_HOMEをどのキャッシュ・サーバーも共有しないと想定しています。一部のキャッシュ・サーバーで同じCoherence JARまたはORACLE_HOMEが共有されている場合は、サーバーを論理ユニットとして扱い、各サーバーで同時にステップを実行してください。

キャッシュ・サーバーを再起動するには:

  1. MBeanブラウザを使用して、Coherence MBeanサーバーに接続します。再起動しようとしているキャッシュ・サーバーがMBeanサーバーをホストしていないことを確認します。
  2. Coherence Service MBeanから、キャッシュ構成ファイル内で構成されているキャッシュに対応するクラスタ・サービスを選択します。
  3. 任意のクラスタ・メンバーのStatusHA属性をチェックし、属性の値がMACHINE-SAFEであることを確認します。MACHINE-SAFE状態は、所定のコンピュータで稼働しているキャッシュ・サーバーのすべてがデータを失わずに停止可能であることを示します。属性がMACHINE-SAFEでない場合は、再起動を実行する前に、(場合によっては別のコンピュータで)追加のキャッシュ・サーバーを起動する必要があります。Oracle Coherenceの管理のServiceMBeanを参照してください。
  4. キャッシュ・サーバーをシャットダウンします。
  5. MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。
  6. キャッシュ・サーバーを再起動します。
  7. MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。
  8. 他のキャッシュ・サーバーを再起動する場合は、ステップ4から7を繰り返します。

親トピック: ローリング再起動の実行

ローリング再起動後またはローリング再起動中の永続性ロールバック

ローリング再起動中に問題が発生した場合は、クラスタ全体をロールバックすることをお薦めします。新しいバージョンのアプリケーション(またはCoherenceあるいはその両方)を含むノードを以前のバージョンにロールバックするか、より深刻な場合はクラスタを完全に再起動することで、クラスタをロールバックできます。

移行先の新しいバージョンに、記憶域形式を変更するCoherenceパッチが含まれている場合(Oracle Coherenceリリース・ノートで強調表示)、永続ストアは古い形式と新しい形式が混在した状態になる可能性があります。

クラスタが完全に再起動されると、混在した状態によってリカバリに失敗し、失敗したストアがごみ箱に移動されます。この時点で、PersistenceManagerMBeanのforceRecovery操作(JConsoleではCoherence/Persistence/<servicename>/PersistenceCoordinatorなど)を選択して、リカバリできなかったパーティションの空のバージョンをCoherenceに強制的に復元させることができます。関連するサービスのスナップショットを作成した場合は、スナップショットをリカバリして、そのサービスの状態を元に戻すことができます。

親トピック: ローリング再起動の実行