Menu Close

管理および設定ガイド

Red Hat JBoss Data Grid 6.3

Red Hat JBoss Data Grid 6.3 向け

Misha Husnain Ali

Red Hat Engineering Content Services

Gemma Sheldon

Red Hat Engineering Content Services

Mandar Joshi

Red Hat Engineering Content Services

Rakesh Ghatvisave

Red Hat Engineering Content Services

概要

本ガイドでは、Red Hat JBoss Data Grid 6.3 の管理および設定について説明します。

第1章 Red Hat JBoss Data Grid のセットアップ

1.1. 前提条件

Red Hat JBoss Data Grid のセットアップには、Java 仮想マシンのみが必要となり、この製品のサポートされている最新バージョンがシステムにインストールされている必要があります。

1.2. Red Hat JBoss Data Grid のセットアップ手順

以下に、Red Hat JBoss Data Grid の初回に行う基本設定に必要な手順 (および指定がある場合はオプションの手順) を示します。オプションの手順であると指定されていない限り、これらの手順を指定される順番で実行することをお勧めします。

手順1.1 JBoss Data Grid のセットアップ

  1. キャッシュマネージャーのセットアップ

    JBoss Data Grid の設定手順は、キャッシュマネージャーから始まります。キャッシュマネージャーは、事前に設定した設定テンプレートを使ってキャッシュインスタンスを素早くかつ簡単に取得し、作成することができます。キャッシュマネージャーのセットアップについてさらに詳しくは、パートI「キャッシュマネージャーのセットアップ」を参照してください。
  2. JVM メモリー管理のセットアップ

    JBoss Data Grid の設定における重要な手順は、お使いの Java 仮想マシン (JVM) のメモリー管理をセットアップすることです。JBoss Data Grid は、JVM メモリーの管理に役立つ、エビクションおよびエクスパレーションなどの各種機能を提供します。
    1. エビクションのセットアップ

      エントリーがどの程度頻繁に使用されているかに基づき、インメモリーキャッシュの実装からエントリーを削除するために使用するロジックを指定します。JBoss Data Grid は、データグリッド内のエントリーのエビクションに対するきめ細やかな制御を行うための複数の異なるエビクションストラテジーを提供します。エビクションのストラテジーおよびエビクションを設定する手順については、3章エビクションのセットアップ を参照してください。
    2. エクスパレーションのセットアップ

      キャッシュにおけるエントリーの時間の上限を設定するために、エクスパレーション情報を各エントリーに添付します。エクスパレーションを使用して、エントリーがキャッシュ内に留まれる最長期間や、取得されたエントリーがキャッシュから削除される前にアイドル状態として有効となる期間をセットアップします。さらに詳しくは、4章エクスパレーションのセットアップ を参照してください。
  3. キャッシュのモニタリング

    JBoss Data Grid では、JBoss ロギングによるロギング機能を使用し、ユーザーのキャッシュをモニタリングする支援を行います。
    1. ロギングのセットアップ

      JBoss Data Grid にロギングをセットアップするのは必須ではありませんが、これを強く推奨します。JBoss Data Grid は、ユーザーがデータグリッド内の各種操作に対する自動化されたロギングを簡単にセットアップすることを可能にする JBoss ロギングを使用します。ログは、その後エラーのトラブルシューティングや予想外の失敗の原因の特定に使用することができます。さらに詳しくは、5章ロギングのセットアップを参照してください。
  4. キャッシュモードのセットアップ

    キャッシュモードは、キャッシュがローカル (単純なインメモリーキャッシュ) か、またはクラスター化されたキャッシュ (ノードの小さなサブセット上で状態変更をレプリケートする) のいずれかを指定するために使用されます。さらに、キャッシュがクラスター化されている場合、変更をノードのサブセットにどのように伝搬させるかを定めるために、レプリケーション、ディストリビューションまたはインバリデーションモードのいずれかを適用する必要があります。さらに詳しくは、パートIV「キャッシュモードのセットアップ」を参照してください。
  5. キャッシュのロックのセットアップ

    レプリケーションまたはディストリビューションが有効な場合、エントリーのコピーは複数のノードでアクセスできます。結果として、データのコピーは、異なる複数のスレッドで同時にアクセスしたり、変更したりすることができます。複数のノード間ですべてのコピーの一貫性を維持するには、ロックを設定します。さらに詳しくは、パートVI「キャッシュのロックのセットアップ」および16章分離レベルのセットアップを参照してください。
  6. キャッシュストアのセットアップと設定

    JBoss Data Grid は、メモリーから削除されたエントリーを永続外部キャッシュストアに一時的に保存するために、パッシベーション機能 (またはパッシベーションがオフになっている場合はキャッシュ書き込みストラテジー) を提供します。パッシベーションまたはキャッシュ書き込みストラテジーをセットアップするには、まずキャッシュストアをセットアップする必要があります。
    1. キャッシュストアのセットアップ

      キャッシュストアは永続ストアへの接続として機能します。キャッシュストアは、エントリーを永続ストアから取得し、変更を永続ストアに戻すために主に使用されます。さらに詳しくは、パートVII「キャッシュストアのセットアップと設定」を参照してください。
    2. パッシベーションのセットアップ

      パッシベーションは、メモリーからエビクトされたエントリーをキャッシュストアに保存します。この機能により、エントリーがメモリー内に存在しないのにもかかわらず使用可能な状態となり、永続キャッシュへの高いコストが発生する可能性のある操作を回避できます。さらに詳しくは、パートVIII「パッシベーションのセットアップ」を参照してください。
    3. キャッシュ書き込みストラテジーのセットアップ

      パッシベーションが無効な場合、キャッシュへの書き込みが試行されるたびに、キャッシュストアへの書き込みが行なわれます。これは、デフォルトのライトスルーキャッシュ書き込みストラテジーです。これらのキャッシュ書き込みが同期的または非同期的に実行されるかを定めるためにキャッシュライティングストラテジーを設定します。さらに詳しくは、パートIX「キャッシュ書き込みのセットアップ」を参照してください。
  7. キャッシュとキャッシュマネージャーのモニタリング

    JBoss Data Grid には、データグリッドが実行中の場合にキャッシュとキャッシュマネージャーをモニタリングするための 2 つの主なツールが含まれます。
    1. JMX のセットアップ

      JMX は、JBoss Data Grid に使用される標準的な統計および管理ツールです。ユースケースに応じて、JMX はキャッシュまたはキャッシュマネージャー、またはそれら両方のレベルで設定することができます。さらに詳しくは、21章Java Management Extensions (JMX) のセットアップを参照してください。
    2. Red Hat JBoss Operations Network (JON) のセットアップ

      Red Hat JBoss Operations Network (JON) は、JBoss Data Grid で利用できる 2 番目のモニタリングソリューションです。JBoss Operations Network (JON) は、キャッシュおよびキャッシュマネージャーのランタイムパラメーターおよび統計をモニタリングするためのグラフィカルインターフェースを提供します。さらに詳しくは、22章JBoss Operations Network (JON) のセットアップを参照してください。
  8. トポロジー情報の導入

    オプションとして、データグリッド内の特定タイプの情報またはオブジェクトが置かれる場所を指定するために、データグリッドにトポロジー情報を提供します。サーバーヒンティングは、トポロジー情報を JBoss Data Grid に導入する数ある方法の中の 1 つです。
    1. サーバーヒンティングのセットアップ

      サーバーヒンティングは、セットアップされると、データのオリジナルおよびバックアップコピーが同じ物理サーバー、ラックまたはデータセンターに保存されていないことを確認することにより高可用性を提供します。これは、すべてのデータがすべてのサーバー、ラックおよびデータセンターでバックアップされるレプリケートされたキャッシュなどの場合にはオプションになります。さらに詳しくは、28章サーバーヒンティングを用いた高可用性を参照してください。
後続の章では、JBoss Data Grid の標準設定のセットアップに関して各手順を詳細に説明します。

パート I. キャッシュマネージャーのセットアップ

第2章 キャッシュマネージャー

キャッシュマネージャーは、Red Hat JBoss Data Grid においてキャッシュインスタンスを取得するための主なメカニズムであり、キャッシュを使用する際のスタートポイントになります。
JBoss Data Grid では、キャッシュマネージャーは以下の理由により役に立ちます。
  • 指定された標準を使用して、複数のインスタンスをオンデマンドで作成します。
  • 既存のキャッシュインスタンスを読み出します (すでに作成されたキャッシュ)。

2.1. キャッシュマネージャーの種類

Red Hat JBoss Data Grid は、次のキャッシュマネージャーを提供します。
  • EmbeddedCacheManager は、クライアントが使用する Java 仮想マシン (JVM) 内で実行されるキャッシュマネージャーです。現在 JBoss Data Grid は、EmbeddedCacheManager インターフェースの DefaultCacheManager 実装のみを提供しています。
  • RemoteCacheManager は、リモートキャッシュにアクセスするために使用されます。RemoteCacheManager は、起動時に Hot Rod サーバー (または複数の Hot Rod サーバー) への接続をインスタンス化します。次に RemoteCacheManager は、それが実行されている間に永続的な TCP 接続を管理します。結果的に、RemoteCacheManager はリソースを集中的に使用します。そのため、それぞれの Java 仮想マシン (JVM) に対して単一の RemoteCacheManager インスタンスを設定する方法が推奨されます。

2.2. CacheManagers の作成

2.2.1. 新しい RemoteCacheManager の作成

例2.1 新しい RemoteCacheManager の設定

import org.infinispan.client.hotrod.configuration.Configuration;
import org.infinispan.client.hotrod.configuration.ConfigurationBuilder;

Configuration conf = new 
ConfigurationBuilder().addServer().host("localhost").port(11222).build();
RemoteCacheManager manager = new RemoteCacheManager(conf);
RemoteCache defaultCache = manager.getCache();
設定の説明

指定された設定の各行の説明は以下のとおりです。

  1. ConfigurationBuilder() メソッドを使用して、新しいビルダーを設定します。.addServer() プロパティーは、.host(<hostname|ip>) および .port(<port>) プロパティーで指定されたリモートサーバーを追加します。
    Configuration conf = new 
    ConfigurationBuilder().addServer().host(<hostname|ip>).port(<port>).build();
  2. 指定された設定を使用して新しい RemoteCacheManager を作成します。
    RemoteCacheManager manager = new RemoteCacheManager(conf);
  3. リモートサーバーからデフォルトキャッシュを取得します。
    RemoteCache defaultCache = manager.getCache();
    

2.2.2. 新しい組み込みキャッシュマネージャーの作成

CDI を使用せずに新規の EmbeddedCacheManager を作成するには、以下の手順を実行します。

手順2.1 新しい組み込みキャッシュマネージャーの作成

  1. 設定 XML ファイルを作成します。クラスパス上 (たとえば resources/ 内) に my-config.file.xml ファイルを作成します。このファイルに設定情報を追加します。
  2. 設定ファイルを使用してキャッシュマネージャーを作成するには、以下のプログラムを使用した設定を使用します。
    EmbeddedCacheManager manager = new DefaultCacheManager("my-config-file.xml");
    Cache defaultCache = manager.getCache();
上記の手順によって、指定された基本的な設定を使用して新規の EmbeddedCacheManager を作成できます。

2.2.3. CDI の使用による新しい組み込みキャッシュマネージャーの作成

CDI を使用して新規の EmbeddedCacheManager インスタンスを作成するには、以下の手順を実行します。

手順2.2 CDI を使用した新規 EmbeddedCacheManager の作成

  1. 次のようにデフォルト設定を指定します。
    public class Config
       @Produces
       public EmbeddedCacheManager defaultCacheManager() {
          Configuration configuration = new ConfigurationBuilder();          
          builder.eviction().strategy(EvictionStrategy.LRU).maxEntries(100).build();
          return new DefaultCacheManager(configuration);
       }
    }
  2. デフォルトのキャッシュマネージャーを挿入します。
    ...
    @Inject
    EmbeddedCacheManager cacheManager;
    ...

2.3. 複数のキャッシュマネージャー

キャッシュマネージャーは、キャッシュを使用する時の開始点であり、Red Hat JBoss Data Grid では、ユーザーが複数のキャッシュマネージャーを作成することができます。それぞれのキャッシュマネージャーは、JMX、エグゼキューターおよびクラスタリングなどの設定を含む、異なるグローバル設定を使用して設定されます。

2.3.1. 単一のキャッシュマネージャーを用いた複数キャッシュの作成

Red Hat JBoss Data Grid では、同じキャッシュマネージャーを使用し、異なるキャッシュモード (同期または非同期キャッシュモード) を持つ複数のキャッシュを作成することが可能です。

2.3.2. 複数のキャッシュマネージャーの使用

Red Hat JBoss Data Grid では、複数のキャッシュマネージャーを使用することが可能です。レプリケーションやネットワーキングコンポーネントなどほとんどの場合で、キャッシュインスタンスは内部コンポーネントを共有するため単一のキャッシュマネージャーで十分です。
ただし、1 つのキャッシュが TCP プロトコルを使用し、他のキャッシュが UDP プロトコルを使用する場合など、複数のキャッシュに異なるネットワーク特性が必要な場合は、複数のキャッシュマネージャーを使用する必要があります。

2.3.3. 複数のキャッシュマネージャーの作成

Red Hat JBoss Data Grid では、ユーザーは最初のキャッシュマネージャーを作成するために使用された手順を繰り返す (さらに、必要な場合は設定ファイルの内容を調整する) ことにより、さまざまな種類の複数のキャッシュマネージャーを作成することができます。
複数の新規キャッシュマネージャーを作成するために宣言的 API を使用するには、infinispan.xml ファイルの内容を新規の設定ファイルにコピーします。新規ファイルで必要な設定についての編集を行ってから、新しいキャッシュマネージャー用にこの新規ファイルを使用します。

パート II. JVM メモリー管理のセットアップ

第3章 エビクションのセットアップ

3.1. エビクションについて

エビクションとは、メモリー不足にならないようにするためにメモリーからエントリーを削除するプロセスのことです。永久的なデータの損失を防ぐため、メモリーからエビクトされたエントリーはキャッシュストアと残りのクラスターに留まります。
Red Hat JBoss Data Grid は、すでにデータコンテナーと対話しているユーザースレッドを利用してエビクションのタスクを実行します。JBoss Data Grid は別のスレッドを使用して、期限切れのキャッシュエントリーをキャッシュから排除します。
エビクションはクラスター全体の操作として発生せず、ノードごとに個別に発生します。各ノードはエビクションスレッドを使用してインメモリーコンテナーの内容を分析し、エビクションが必要なエントリーを判別します。Java 仮想マシン (JVM) の空きメモリーはエビクションの分析時には考慮されず、エントリーのエビクションを初期化するしきい値としても考慮されません。
JBoss Data Grid では、エビクションは、キャッシュのインメモリー表現からエントリーを効率的に削除し、それらを永続ストアにプッシュするメカニズムを提供します。これにより、メモリーは新規のエントリーがフェッチされると常にこれらを格納でき、かつエビクトされたエントリーは、失われるのではなくクラスターに保存されます。
さらに、エビクションストラテジーは、エビクトされるエントリーや、エビクションが発生するタイミングをセットアップするための設定で必要になる場合に使用することができます。

3.2. エビクションストラテジー

各エビクションストラテジーには、以下に記載されているような特定の利点およびユースケースがあります。

表3.1 エビクションストラテジー

ストラテジー名 操作 説明
EvictionStrategy.NONE エビクションは一切発生しません。 -
EvictionStrategy.LRU LRU (Least Recently Used) 方式のエビクションストラテジーです。このストラテジーは、最も長い期間にわたって使用されてこなかったエントリーをエビクトします。これにより、定期的に再利用されるエントリーが確実にメモリーに残ります。  
EvictionStrategy.UNORDERED 順序付けのないエビクションストラテジーです。このストラテジーは、順序付けのあるアルゴリズムを使用せずにエントリーをエビクトするため、後で必要になるエントリーをエビクトする可能性があります。しかし、このストラテジーでは、エビクションの前にアルゴリズムに関連する計算が不要であるため、リソースを節約します。 テストを目的とする場合にはこのストラテジーが推奨されますが、実際の作業の実装にあたっては推奨されません。
EvictionStrategy.LIRS LIRS (Low Inter-Reference Recency Set) 方式のエビクションストラテジーです。 LIRS は、実稼働での多岐にわたるユースケースに適しているため、Red Hat JBoss Data Grid のデフォルトのエビクションアルゴリズムになっています。

3.2.1. LRU エビクションアルゴリズムの制限

LRU (Least Recently Used) エビクションアルゴリズムでは、最も長い間使用されていないエントリーが最初にエビクトされます。キャッシュから最初にエビクトされるのは、最も長い間アクセスされていないエントリーです。ただし、LRU エビクションアルゴリズムは、アクセスローカリティーが弱い場合には最適に実行されないことがあります。この弱いアクセスローカリティーとは、キャッシュに入れられ、長い間アクセスされていないエントリーについて使用される技術用語であり、この場合、最も早くアクセスされるエントリーは置き換えられます。このようなケースでは、次のような問題が発生する可能性があります。
  • 1 回限りの使用のためにアクセスされるエントリーが時間内に置き換えられない。
  • 最初にアクセスされるエントリーが不必要に置き換えられる。

3.3. エビクションの使用

Red Hat JBoss Data Grid では、エビクションはデフォルトでは無効にされています。空の <eviction /> 要素を使用して、ストラテジーや最大エントリー数の設定なしにエビクションを有効にすると、次のデフォルト値が自動的に実装されます。
  • ストラテジー: 指定されたエビクションストラテジーがない場合、EvictionStrategy.NONE がデフォルトとみなされます。
  • max-entries/maxEntries: 指定された値がない場合、max-entries/maxEntries の値は無制限のエントリーを許可する -1 に設定されます。

3.3.1. エビクションの初期化

エビクションを初期化するには、エビクション要素の max-entries 属性の値をゼロよりも大きい数に設定します。max-entries に設定された値を調整して、使用する設定に最適な値を探します。max-entries に設定する値が大きすぎると、Red Hat JBoss Data Grid のメモリーが不足するため注意してください。
以下の手順は、JBoss Data Grid でエビクションを初期化するステップを簡単に説明しています。

手順3.1 エビクションの初期化

  1. エンビクションタグの追加

    <eviction> タグを次のようにプロジェクトの <cache> タグに追加します。
    <eviction />
  2. エビクションストラテジーの設定

    使用するエビクションストラテジーを設定するために strategy の値を設定します。使用可能な値は、LRUUNORDERED および LIRS (またはエビクションが不要な場合は NONE) です。以下は、このステップのサンプルです。
    <eviction strategy="LRU" />
  3. 最大エントリー数の設定

    メモリー内で許可されるエントリーの最大数を設定します。無制限のエントリーを許可するためのデフォルト値は -1 です。
    1. ライブラリーモードで、maxEntries パラメーターを次のように設定します。
      <eviction strategy="LRU" maxEntries="200" />
    2. リモートクライアントモードで、max-entries を次のように設定します。
      <eviction strategy="LRU" max-entries="200" />
結果

エンビクションがターゲットキャッシュ用に設定されます。

3.3.2. エビクションの設定例

設定 Bean または XML ファイルを使用して Red Hat JBoss Data Grid のエビクションを設定します。エビクションの設定はキャッシュごとに行います。
  • ライブラリーモードの XML 設定例は以下のようになります。
    <eviction strategy="LRU" maxEntries="2000"/>
  • リモートクライアントサーバーモードの XML 設定例は以下のようになります。
    <eviction strategy="LRU" max-entries="20"/>
  • ライブラリーモードのプログラムを用いた設定例は以下のようになります。
    Configuration c = new ConfigurationBuilder().eviction().strategy(EvictionStrategy.LRU)
                  .maxEntries(2000)
                  .build();

注記

エビクションの設定では、JBoss Data Grid のライブラリーモードは maxEntries パラメーター、リモートクライアントサーバーモードは max-entries パラメーターを使用します。

3.3.3. エビクション設定のトラブルシューティング

Red Hat JBoss Data Grid では、キャッシュのサイズを configuration 要素の max-entries パラメーターに指定された値よりも大きくすることができます。これは、max-entries の値を 2 の累乗以外の値に設定することは可能ですが、基盤のアルゴリズムがこの値を V (max-entries の値に最も近い 2 を累乗した値) に変更するからです。エビクションアルゴリズムは、キャッシュコンテナーのサイズが V の値を超えないようにします。

3.3.4. エビクションとパッシベーション

エントリーの 1 つのコピーがメモリーまたはキャッシュストアに維持されるようにするため、パッシベーションはエビクションと共に使用してください。
通常のキャッシュストアの代わりにパッシベーションを使用する主な理由は、パッシベーションを使用するとエントリーの更新に必要なリソースが少なくなることにあります。これは、パッシベーションではキャッシュストアへの更新が不要になるためです。

第4章 エクスパレーションのセットアップ

4.1. エクスパレーションについて

Red Hat JBoss Data Grid は、以下の値のいずれかまたは両方をエントリーに追加するためにエクスパレーションを使用します。
  • ライフスパンの値。
  • 最大アイドル時間の値。
エクスパレーションはエントリーまたはキャッシュごとに指定でき、エントリーごとの設定は、キャッシュごとの設定よりも優先されます。エクスパレーションがキャッシュレベルで設定されない場合、キャッシュエントリーはデフォルトで期限なし (immortal) として作成されます (それらは期限切れになりません)。逆に、エクスパレーションがキャッシュレベルで設定される場合、エクスパレーションのデフォルトが lifespan または maxIdle 値を明示的に指定しないすべてのエントリーに適用されます。
エビクトされたエントリーとは異なり、期限切れのエントリーはグローバルに削除されます。そのため、期限切れのエントリーはメモリー、キャッシュストア、およびクラスターより削除されます。
エクスパレーションは、指定した期間中に使用されなかったエントリーのメモリーからの削除を自動化します。エクスパレーションおよびエビクションは、以下の点で異なっています。
  • エクスパレーションは、エントリーがメモリーに存在していた期間に基づいてエントリーを削除します。エクスパレーションは、ライフスパンの期間が終了するか、またはエントリーが指定したアイドル時間よりも長くアイドル状態になっていた場合のみ、エントリーを削除します。
  • エビクションは、エントリーがどの程度最近 (および頻繁) に使用されるかに基づいてエントリーを削除します。エビクションは、メモリーに存在するエントリーが多すぎる場合にエントリーを削除します。キャッシュストアが設定されている場合、エビクトされたエントリーがキャッシュストアで永続化します。

4.2. エクスパレーションの操作

Red Hat JBoss Data Grid のエクスパレーションによって、キャッシュに格納されたキーバリューペアに対してライフスパンと最大アイドル時間の値を設定することができます。
ライフスパンまたは最大アイドル時間は、キャッシュ API を使用して、キャッシュ全体に適用するために設定したり、キーバリューペアごとに定義することができます。キーバリューペアごとに定義されたライフスパン (lifespan) または最大アイドル時間 (ライブラリーモードでは maxIdle、リモートクライアントサーバーモードでは max-idle) は、エントリーのキャッシュ全体のデフォルトよりも優先されます。

4.3. エビクションとエクスパレーションの比較

エクスパレーションは Red Hat JBoss Data Grid のトップレベルのコンストラクトで、グローバル設定およびキャッシュ API で表されます。
エビクションは使用されるキャッシュインスタンスに限定されますが、エクスパレーションはクラスター全体で有効です。エクスパレーションのライフスパン (lifespan) とアイドル時間 (ライブラリーモードでは maxIdle、リモートクライアントサーバーモードでは max-idle) の値は、各キャッシュエントリーと一緒にレプリケートされます。

4.4. キャッシュエントリーの期限切れ通知

Red Hat JBoss Data Grid は、タイムアウト直後のエビクションの発生を保証しません。その代わりに、複数のメカニズムを連携して使用し、効率的なエビクションが確実に行われるようにします。以下のいずれかに該当する場合、期限切れのエントリーがキャッシュから削除されます。
  • エントリーがディスクへパッシベートまたはオーバフローされ、期限切れであることが判明した場合。
  • エビクションメンテナンススレッドが見つけたエントリーが期限切れであることが判明した場合。
期限が切れているがエビクトされていないエントリーをユーザーが要求した場合は、null 値がユーザーに送信されます。このメカニズムにより、ユーザーは期限切れのエントリーを受け取らなくなります。エントリーは結果的にエビクションスレッドにより削除されます。

4.5. エクスパレーションの設定

Red Hat JBoss Data Grid では、エクスパレーションはエビクションと同様の方法で設定されます。

手順4.1 エクスパレーションの設定

  1. エクスパレーションタグの追加

    <expiration> タグを次のようにプロジェクトの <cache> タグに追加します。
    <expiration />
  2. エクスパレーションのライフスパンの設定

    エントリーがメモリーに留まる時間 (ミリ秒単位) を設定するために lifespan の値を設定します。以下はこのステップの例になります。
    <expiration lifespan="1000" />
  3. 最大アイドル時間の設定

    エントリーが削除された後にアイドル (未使用) の状態のままにすることのできる時間 (ミリ秒単位) を設定します。無制限にするためのデフォルト値は -1 です。
    1. ライブラリーモードで、maxIdle パラメーターを次のように設定します。
      <expiration lifespan="1000" maxIdle="1000" />
      • リモートクライアントサーバーモードで、max-idle を次のように設定します。
        <expiration lifespan="1000" max-idle="1000" />
結果

キャッシュの実装用にエクスパレーションが設定されます。

4.6. 期限つき (mortal) データと期限なし (immortal) データ

Red Hat JBoss Data Grid では、エンティティーを格納するだけでなく、データーに期限の情報を添付することが可能です。たとえば、標準的な put(key, value) を使用すると、期限なし (immortal) エントリーと呼ばれる永久に期限切れにならないエントリーが作成されます。また、put(key, value, lifespan, timeunit) を使用して作成されるエントリーは、指定の固定ライフスパンを持つ期限つき (mortal) エントリーで、ライフスパンの後に期限が切れます。
JBoss Data Grid は lifespan パラメーターの他に、エクスパレーションを判断するために使用される maxIdle パラメーターも提供します。maxIdle パラメーターと lifespan パラメーターをさまざまな組み合わせで使用してエントリーのライフスパンを設定することができます。
デフォルトでは、新規に作成されたエントリーにはライフスパンや最大アイドル時間値セットがありません。これらの 2 つの値がない場合、データエントリーは永久に期限切れにならないため、期限なし (immortal) データと呼ばれます。
エントリーの期限 (またはエクスパレーションの値) を設定するには、エントリーのライフスパンと最大アイドル時間の値を設定します。設定後、これらの値をキャッシュストアで永続化し、エビクションやパッシベーションの後も存続させるようにします。

4.7. エクスパレーションのトラブルシューティング

エクスパレーションが機能していないように見える場合、エントリーがエクスパレーションについてマークされていても削除されていないことが原因である可能性があります。
put() のような複数キャッシュの操作では、ライフスパン値がパラメーターとして渡されます。この値は間隔を定義し、この間隔の後にエントリーが期限切れになります。エビクションが設定されていない状態でライフスパンが期限切れになると、Red Hat JBoss Data Grid がエントリーを削除しなかったように見えます。例えば、number of entries など JMX の統計を表示する場合、無効の数字が表示されたり、JBoss Data Grid に関連する永続ストアにこのエントリーが依然含まれていることがあります。JBoss Data Grid は背後でこのエントリーを期限切れエントリーとしてマーク付けしても、削除しません。このようなエントリーの削除は、以下のように行われます。
  • エビクション機能を有効にすると、エビクションスレッドが期限切れエントリーを定期的に検出し、これらを消去します。
期限切れエントリーに対して get() または containsKey() の使用を試みると、JBoss Data Grid が null 値を返します。期限切れのエントリーはエビクションスレッドとして後で削除されます。

パート III. キャッシュのモニタリング

第5章 ロギングのセットアップ

5.1. ロギングについて

Red Hat JBoss Data Grid は、独自の内部使用とデプロイされたアプリケーションによる使用のために設定可能な高度なロギング機能を提供します。ロギングサブシステムは JBoss LogManager を基盤とし、JBoss Logging 以外にも複数のサードパーティーアプリケーションのロギングフレームワークをサポートします。
ロギングサブシステムは、ログカテゴリーとログハンドラーのシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義し、ログハンドラーはこれらのメッセージの処理方法を定義します (ディスクへの書き込みやコンソールへの送信など)。
JBoss Data Grid キャッシュは、エビクションおよびエクスパレーションなどの操作と共に設定されると、ロギングは関連アクティビティー (エラーまたは障害を含む) を追跡します。
正しくセットアップされると、ロギングは所定の環境でいつ、何が発生したかについての詳細情報を提供します。さらに、ロギングは環境でクラッシュまたは問題が起こる直前に生じたアクティビティーの追跡を行うのに役立ちます。この情報は、トラブルシューティングやクラッシュまたはエラーの原因の特定を試行する際に役立ちます。

5.2. サポート対象のアプリケーションロギングフレームワーク

Red Hat JBoss LogManager は以下のロギングフレームワークに対応しています。

5.2.1. JBoss ロギングについて

JBoss ロギングは JBoss Enterprise Application Platform 6 に含まれているアプリケーションロギングフレームワークです。そのため、Red Hat JBoss Data Grid 6 は JBoss ロギングを使用します。
JBoss ロギングはアプリケーションにロギングを追加する簡単な方法を提供します。フレームワークを使用するアプリケーションにコードを追加し、定義された形式でログメッセージを送信します。アプリケーションサーバーにアプリケーションがデプロイされると、これらのメッセージがサーバーによってキャプチャーされ、サーバーの設定通りファイルに表示されたり書き込まれたりします。

5.2.2. JBoss ロギングの機能

JBoss のロギングには次の機能が含まれます。
  • 革新的で使いやすい型指定されたロガーを提供します。
  • 国際化およびローカリゼーションを完全サポート。翻訳者は properties ファイルのメッセージバンドルを、開発者はインターフェースやアノテーションを使い作業を行います。
  • 実稼働用の型指定されたロガーを生成し、開発用の型指定されたロガーをランタイムに生成する build-time ツール。

5.3. ブートロギング

ブートログは、サーバーの起動中 (またはブート中) に発生したイベントの記録です。Red Hat JBoss Data Grid には、サーバーがブート処理を完了した後に生成されるログエントリーが含まれるサーバーログも組み込まれます。

5.3.1. ブートロギングの設定

ブートログを設定するには、logging.properties ファイルを編集します。このファイルは標準的な Java プロパティーファイルであるため、テキストエディターで編集することができます。このファイルの各行の形式は property=value になります。
Red Hat JBoss Data Grid では、logging.properties ファイルは $JDG_HOME/standalone/configuration フォルダーにあります。

5.3.2. デフォルトのログファイルの場所

以下の表は、Red Hat JBoss Data Grid のログファイルとそれらの場所のリストです。

表5.1 デフォルトのログファイルの場所

ログファイル 場所 説明
boot.log $JDG_HOME/standalone/log/ サーバーブートログ。サーバーの起動に関連するログメッセージが含まれます。
server.log $JDG_HOME/standalone/log/ サーバーログ。サーバー起動後のすべてのログメッセージが含まれます。

5.4. ロギング属性

5.4.1. ログレベルについて

ログレベルとは、ログメッセージの性質と重大度を示す列挙値の順序付けされたセットです。特定のログメッセージのレベルは、そのメッセージを送信するために選択したロギングフレームワークの適切なメソッドを使用して開発者が指定します。
Red Hat JBoss Data Grid は、サポート対象のアプリケーションロギングフレームワークによって使用されるすべてのログレベルをサポートします。最も一般的に使用される 6 つのログレベルは次の通りです (重大度の低いものから順に記載)。
  1. TRACE
  2. DEBUG
  3. INFO
  4. WARN
  5. ERROR
  6. FATAL
ログレベルはログカテゴリーとログハンドラーによって使用され、それらが対象とするメッセージを限定します。各ログレベルには、他のログレベルに対して相対的な順序を示す数値が割り当てられています。ログカテゴリーとハンドラーにはログレベルが割り当てられ、その数値以上のログメッセージのみを処理します。たとえば、WARN レベルのログハンドラーは、WARNERROR、および FATAL レベルのメッセージのみを記録します。

5.4.2. サポート対象のログレベル

以下の表は Red Hat JBoss Data Grid でサポートされるログレベルの一覧になります。ログレベル、ログレベルの値、および説明が記載されています。ログレベルの値は、他のログレベルに対する相対的な値になります。フレームワークが異なるとログレベルの名前が異なることがありますが、ログの値はこの一覧と一致します。

表5.2 サポート対象のログレベル

ログレベル 説明
FINEST 300 -
FINER 400 -
TRACE 400 アプリケーションの実行状態について詳細な情報を提供するメッセージに使用されます。TRACE レベルが有効な状態でサーバーが実行されている時に TRACE レベルのログメッセージがキャプチャーされます。
DEBUG 500 個々の要求の進捗やアプリケーションのアクティビティーを示すメッセージに使用されます。DEBUG レベルが有効な状態でサーバーが実行されている時に DEBUG レベルのログメッセージがキャプチャーされます。
FINE 500 -
CONFIG 700 -
INFO 800 アプリケーションの全体的な進捗を示すメッセージに使用されます。アプリケーションの起動やシャットダウン、その他の主なライフサイクルイベントに対して使用されます。
WARN 900 エラーではないが、理想的とは見なされない状況を示すために使用されます。将来的にエラーをもたらす可能性のある状況を示します。
WARNING 900 -
ERROR 1000 発生したエラーの中で、現在のアクティビティーや要求の完了を妨げる可能性があるが、アプリケーション実行の妨げにはならないエラーを示すために使用されます。
SEVERE 1000 -
FATAL 1100 重大なサービス障害やアプリケーションのシャットダウンをもたらしたり、JBoss Data Grid のシャットダウンを引き起こす可能性があるイベントを表示するのに使用されます。

5.4.3. ログカテゴリーについて

ログカテゴリーは、キャプチャーするログメッセージのセットと、メッセージを処理する 1 つまたは複数のログハンドラーを定義します。
キャプチャーするログメッセージは、元の Java パッケージとログレベルによって定義されます。そのパッケージ内のクラスからのメッセージおよびそのログレベル以上の (数値がその値以上の) メッセージがログカテゴリーによってキャプチャーされ、指定のログハンドラーに送信されます。たとえば、WARNING ログレベルでは、9001000、および 1100 のログの値がキャプチャーされます。
ログカテゴリーは、独自のハンドラーの代わりにルートロガーのログハンドラーを任意で使用することができます。

5.4.4. ルートロガーについて

ルートロガーは、サーバーに送信された (指定レベルの) ログメッセージの中でログカテゴリーによってキャプチャーされないすべてのログメッセージをキャプチャーします。これらのメッセージは単一または複数のハンドラーに送信されます。
デフォルトでは、ルートロガーはコンソールおよび定期ログハンドラーを使用するように設定されています。定期ログハンドラーは、server.log ファイルに書き込むように設定されています。このファイルはサーバーログと呼ばれる場合もあります。

5.4.5. ログハンドラーについて

ログハンドラーは、キャプチャーされたログメッセージがどのように Red Hat JBoss Data Grid によって記録されるかを定義します。JBoss Data Grid で設定可能な 6 種類のログハンドラーは次の通りです。
  • Console
  • File
  • Periodic
  • Size
  • Async
  • Custom
ログハンドラーは、指定されたログオブジェクトをさまざまな出力 (コンソールまたは指定されたログファイルを含む) に配信します。JBoss Data Grid で使用される一部のログハンドラーは、他のログハンドラーの挙動を配信するために使用されるラッパーログハンドラーです。
ログハンドラーは、ソートを容易にするためにログ出力を特定のファイルに送信したり、特定の期間にログを書き込むために使用されます。ログハンドラーは主として、必要なログの種類や、それらが保存または表示される場所、または JBoss Data Grid におけるロギング動作を指定するのに役立ちます。

5.4.6. ログハンドラーのタイプ

以下の表は、Red Hat JBoss Data Grid で利用可能なログハンドラーの各種タイプのリストです。

表5.3 ログハンドラーのタイプ

ログハンドラーのタイプ 説明 ユースケース
コンソール (Console) コンソールログハンドラーは、ログメッセージをホストオペレーティングシステムの標準出力 (stdout) または標準エラー (stderr) ストリームに書き込みます。これらのメッセージは、JBoss Data Grid がコマンドラインプロンプトから実行される場合に表示されます。 コンソールログハンドラーは、JBoss Data Grid がコマンドラインを使って管理されている場合に推奨されます。この場合、コンソールログハンドラーからのメッセージは、オペレーティングシステムが標準出力や標準エラーストリームをキャプチャーするように設定されていない限り、保存されません。
ファイル (File) ファイルログハンドラーは最も単純なログハンドラーです。主に、ログメッセージを指定のファイルへ書き込むために使用されます。 ファイルログハンドラーは、時間に従ってすべてのログエントリーを 1 つの場所に保存することが要件である場合に最も役に立ちます。
定期 (Periodic) 定期ファイルハンドラーは、指定した時間が経過するまで、ログメッセージを指定ファイルに書き込みます。その時間が経過した後は、指定のタイムスタンプがファイル名に追加されます。その後、ハンドラーは元の名前で新たに作成されたログファイルへの書き込みを継続します。 定期ファイルハンドラーは、環境の要件に応じて、週ごと、日ごと、時間ごと、またはその他の単位ごとにログメッセージを蓄積するために使用することができます。
サイズ (Size) サイズログハンドラーは、指定のファイルが指定サイズに到達するまで、そのファイルにログメッセージを書き込みます。ファイルが指定のサイズに到達すると、名前に数値のプレフィックスを追加して名前が変更され、ハンドラーは元の名前で新規に作成されたログファイルに書き込みを継続します。各サイズログハンドラーは、このような方式で保管されるファイルの最大数を指定する必要があります。 サイズハンドラーは、ログファイルのサイズが一致している必要のある環境に最も適しています。
非同期 (Async) 非同期ログハンドラーは、単一または複数の他のログハンドラーを対象とする非同期動作を提供するラッパーログハンドラーです。非同期ログハンドラーは、待ち時間が長かったり、ネットワークファイルシステムへのログファイルの書き込みなどの他のパフォーマンス上の問題があるログハンドラーに対して有用です。 非同期ログハンドラーは、待ち時間が長いことが問題になる環境や、ネットワークファイルシステムへログファイルを書き込む際に最も適しています。
カスタム (Custom) カスタムログハンドラーにより、実装されている新たなタイプのログハンドラーを設定することが可能になります。カスタムハンドラーは、java.util.logging.Handler を拡張する Java クラスとして実装し、モジュール内に格納する必要があります。 カスタムログハンドラーは、ログハンドラーのカスタマイズしたタイプを作成するもので、高度なユーザー用として推奨されます。

5.4.7. ログハンドラーの選択

以下は、Red Hat JBoss Data Grid で利用可能なログハンドラーのそれぞれのタイプについての最も一般的な使用例です。
  • コンソール (Console) ログハンドラーは、JBoss Data Grid がコマンドラインを使って管理される場合に推奨されます。このような場合、エラーやログメッセージはコンソールウィンドウに表示され、保存されるように別途設定されない限り保存されません。
  • ファイル (File) ログハンドラーは、ログエントリーを指定のファイルに送信するために使用されます。この単純なログハンドラーは、時間に従ってすべてのログエントリーを 1 つの場所に保存することが要件である場合に役に立ちます。
  • 定期 (Periodic) ログハンドラーは、ファイル (File) ハンドラーと似ていますが、指定された期間に応じてファイルを作成します。例として、このハンドラーは環境の要件に応じて、週ごと、日ごと、時間ごと、またはその他の単位ごとにログメッセージを蓄積するために使用することができます。
  • サイズ (Size) ログハンドラーも、指定されたファイルにログメッセージを書き込みますが、ログファイルのサイズが指定の制限内にある場合にのみ、これが実行されます。ファイルサイズが指定したサイズまで達すると、ログファイルは新規のログファイルに書き込まれます。このハンドラーは、ログファイルのサイズが一貫している必要のある環境に最も適しています。
  • 非同期 (Async) ログハンドラーは、他のログハンドラーが非同期に動作するように強制するラッパーです。このログハンドラーは、待ち時間が長いことが問題となる環境や、ネットワークファイルシステムへの書き込み時に最も適しています。
  • カスタム (Custom) ログハンドラーは、新規の、カスタマイズされたタイプのログハンドラーを作成します。これは、高度なログハンドラーです。

5.4.8. ログフォーマッターについて

ログフォーマッターは、ログハンドラーの設定プロパティーで、関連するログハンドラーから発信されるログメッセージの外観を定義します。ログフォーマッターは java.util.Formatter クラスと同じ構文を使用する文字列です。
さらに詳しくは、http://docs.oracle.com/javase/6/docs/api/java/util/Formatter.html を参照してください。

5.5. ロギングの設定例

5.5.1. ルートロガーの XML 設定例

以下の手順は、ルートロガーの設定例を示しています。

手順5.1 ルートロガーの設定

  1. level プロパティーを設定します

    level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <root-logger>
          <level name="INFO"/>
  2. handlers を一覧表示します

    handlers は、ルートロガーによって使用されるログハンドラーの一覧です。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
         <root-logger>
            <level name="INFO"/>
            <handlers>
               <handler name="CONSOLE"/>
               <handler name="FILE"/>
            </handlers>
         </root-logger>
      </subsystem>

5.5.2. ログカテゴリーの XML 設定例

以下の手順は、ログカテゴリーの設定例を示しています。

手順5.2 ログカテゴリーの設定

  1. カテゴリーの定義

    ログメッセージがキャプチャーされるログカテゴリーを指定するために、category プロパティーを使用します。
    use-parent-handlers はデフォルトで "true" に設定されています。"true" に設定した場合、このカテゴリーは、割り当てられた他のハンドラーだけでなく、ルートロガーのログハンドラーを使用します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <logger category="com.company.accounts.rec" use-parent-handlers="true">
  2. level プロパティーを設定します

    ログカテゴリーが記録するログメッセージの最大レベルを設定するために、level プロパティーを設定します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <logger category="com.company.accounts.rec" use-parent-handlers="true">
          <level name="WARN"/>
  3. handlers を一覧表示します

    handlers は、ログハンドラーの一覧です。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <logger category="com.company.accounts.rec" use-parent-handlers="true">
          <level name="WARN"/>
          <handlers>
             <handler name="accounts-rec"/>
          </handlers>
       </logger>
    </subsystem>

5.5.3. コンソールログハンドラーの XML 設定例

以下の手順は、コンソールログハンドラーの設定例を示しています。

手順5.3 コンソールログハンドラーの設定

  1. ログハンドラーの ID 情報を追加します。

    name プロパティーは、このログハンドラーの一意の ID を設定します。
    autoflush"true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
  2. level プロパティーを設定します

    level プロパティーは、記録されるログメッセージの最大レベルを設定します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
          <level name="INFO"/>
  3. encoding 出力を設定します。

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
          <level name="INFO"/>
          <encoding value="UTF-8"/>
  4. target 値を定義します。

    target プロパティーは、ログハンドラーの出力先となるシステム出力ストリームを定義します。これはシステムエラーストリームの場合は System.err、標準出力ストリームの場合は System.out とすることができます。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
          <level name="INFO"/>
          <encoding value="UTF-8"/>
          <target value="System.out"/>
  5. filter-spec プロパティーを定義します。

    filter-spec プロパティーはフィルターを定義する式の値です。以下の例では、not(match("JBAS.*")) はパターンに一致しないフィルターを定義します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
          <level name="INFO"/>
          <encoding value="UTF-8"/>
          <target value="System.out"/>
          <filter-spec value="not(match(&quot;JBAS.*&quot;))"/>
  6. formatter を指定します。

    このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
          <level name="INFO"/>
          <encoding value="UTF-8"/>
          <target value="System.out"/>
          <filter-spec value="not(match(&quot;JBAS.*&quot;))"/>
          <formatter>
             <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
          </formatter>
       </console-handler>
    </subsystem>

5.5.4. ファイルログハンドラーの XML 設定例

以下の手順は、ファイルログハンドラーの設定例を示しています。

手順5.4 ファイルログハンドラーの設定

  1. ファイルログハンドラーの ID 情報を追加します。

    name プロパティーは、このログハンドラーの一意の ID を設定します。
    autoflush"true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。
    <file-handler name="accounts-rec-trail" autoflush="true">
  2. level プロパティーを設定します

    level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。
    <file-handler name="accounts-rec-trail" autoflush="true">
        <level name="INFO"/>
  3. encoding 出力を設定します。

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <file-handler name="accounts-rec-trail" autoflush="true">
        <level name="INFO"/>
        <encoding value="UTF-8"/>
  4. file オブジェクトを設定します。

    file オブジェクトは、このログハンドラーの出力が書き込まれるファイルを表します。relative-topath の 2 つの設定プロパティーが含まれます。
    relative-to プロパティーは、ログファイルが書き込まれるディレクトリーです。JBoss Enterprise Application Platform 6 のファイルパス変数をここで指定できます。jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを指します。
    path プロパティーは、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために relative-to プロパティーの値に追加される相対パス名です。
    <file-handler name="accounts-rec-trail" autoflush="true">
        <level name="INFO"/>
        <encoding value="UTF-8"/>
        <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/>
  5. formatter を指定します。

    このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。
    <file-handler name="accounts-rec-trail" autoflush="true">
        <level name="INFO"/>
        <encoding value="UTF-8"/>
        <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/>
        <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
  6. append プロパティーを設定します。

    append プロパティーを "true" に設定した場合、このハンドラーが書き込んだすべてのメッセージが既存のファイルに追加されます。"false" に設定した場合、アプリケーションサーバーが起動するたびに新規ファイルが作成されます。append への変更を反映させるには、サーバーの再起動が必要です。
    <file-handler name="accounts-rec-trail" autoflush="true">
        <level name="INFO"/>
        <encoding value="UTF-8"/>
        <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/>
        <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
        <append value="true"/>
    </file-handler>

5.5.5. 定期ログハンドラーの XML 設定例

以下の手順は、定期ログハンドラーの設定例を示しています。

手順5.5 定期ログハンドラーの設定

  1. 定期ログハンドラーの ID 情報を追加します。

    name プロパティーは、このログハンドラーの一意の ID を設定します。
    autoflush"true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
  2. level プロパティーを設定します。

    level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
  3. encoding 出力を設定します。

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
       <encoding value="UTF-8"/>
  4. formatter を指定します。

    このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
       <encoding value="UTF-8"/>
       <formatter>
          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
       </formatter>
  5. file オブジェクトを設定します。

    file オブジェクトは、このログハンドラーの出力が書き込まれるファイルを表します。relative-topath の 2 つの設定プロパティーが含まれます。
    relative-to プロパティーは、ログファイルが書き込まれるディレクトリーです。JBoss Enterprise Application Platform 6 のファイルパス変数をここで指定できます。jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを指します。
    path プロパティーは、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために relative-to プロパティーの値に追加される相対パス名です。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
       <encoding value="UTF-8"/>
       <formatter>
          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
       </formatter>
       <file relative-to="jboss.server.log.dir" path="server.log"/>
  6. suffix 値を設定します

    suffix は、ローテーションされたログのファイル名に追加され、ローテーションの周期を決定するために使用されます。suffix の形式では、ドット (.) の後に java.text.SimpleDateFormat クラスで解析できる日付文字列が指定されます。ログは suffix で定義された最小時間単位に基づいてローテーションされます。たとえば、yyyy-MM-dd の場合は、ログが日次でローテーションされます。http://docs.oracle.com/javase/6/docs/api/index.html?java/text/SimpleDateFormat.htmlを参照してください。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
       <encoding value="UTF-8"/>
       <formatter>
          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
       </formatter>
       <file relative-to="jboss.server.log.dir" path="server.log"/>
       <suffix value=".yyyy-MM-dd"/>
  7. append プロパティーを設定します。

    append プロパティーを "true" に設定した場合、このハンドラーが書き込んだすべてのメッセージが既存のファイルに追加されます。"false" に設定した場合、アプリケーションサーバーが起動するたびに新規ファイルが作成されます。append への変更を反映させるには、サーバーの再起動が必要です。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
       <encoding value="UTF-8"/>
       <formatter>
          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
       </formatter>
       <file relative-to="jboss.server.log.dir" path="server.log"/>
       <suffix value=".yyyy-MM-dd"/>
       <append value="true"/>
    </periodic-rotating-file-handler>

5.5.6. サイズログハンドラーの XML 設定例

以下の手順は、サイズログハンドラーの設定例を示しています。

手順5.6 サイズログハンドラーの設定

  1. サイズログハンドラーの ID 情報を追加します。

    name プロパティーは、このログハンドラーの一意の ID を設定します。
    autoflush"true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
  2. level プロパティーを設定します

    level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
  3. encoding 出力を設定します。

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
  4. file オブジェクトを設定します。

    file オブジェクトは、このログハンドラーの出力が書き込まれるファイルを表します。relative-topath の 2 つの設定プロパティーが含まれます。
    relative-to プロパティーは、ログファイルが書き込まれるディレクトリーです。JBoss Enterprise Application Platform 6 のファイルパス変数をここで指定できます。jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを指します。
    path プロパティーは、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために relative-to プロパティーの値に追加される相対パス名です。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
       <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
  5. rotate-size 値を指定します。

    ログファイルがローテーションされる前に到達できる最大サイズです。数字に追加された単一の文字はサイズ単位を示します。バイトの場合は b、キロバイトの場合は k、メガバイトの場合は m、ギガバイトの場合は g になります。たとえば、50 メガバイトの場合は、50m になります。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
       <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
       <rotate-size value="500k"/>
  6. max-backup-index 数を設定します。

    保持されるローテーションログの最大数です。この数字に達すると、最も古いログが再利用されます。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
       <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
       <rotate-size value="500k"/>
       <max-backup-index value="5"/>
  7. formatter を指定します。

    このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
       <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
       <rotate-size value="500k"/>
       <max-backup-index value="5"/>
       <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
  8. append プロパティーを設定します。

    append プロパティーを "true" に設定した場合、このハンドラーが書き込んだすべてのメッセージが既存のファイルに追加されます。"false" に設定した場合、アプリケーションサーバーが起動するたびに新規ファイルが作成されます。append への変更を反映させるには、サーバーの再起動が必要です。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
       <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
       <rotate-size value="500k"/>
       <max-backup-index value="5"/>
       <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
       <append value="true"/>
    </size-rotating-file-handler>

5.5.7. 非同期ログハンドラーの XML 設定例

以下の手順は、非同期ログハンドラーの設定例を示しています。

手順5.7 非同期ログハンドラーの設定

  1. 非同期ログハンドラーの ID 情報を追加します。

    name プロパティーは、このログハンドラーの一意の ID を設定します。
    <async-handler name="Async_NFS_handlers">
  2. level プロパティーを設定します

    level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。
    <async-handler name="Async_NFS_handlers">
       <level name="INFO"/>
  3. queue-length を定義します。

    queue-length は、サブハンドラーの応答を待機する間に、このハンドラーが保持するログメッセージの最大数を定義します。
    <async-handler name="Async_NFS_handlers">
       <level name="INFO"/>
       <queue-length value="512"/>
  4. オーバーフロー応答を設定します。

    overflow-action は、キューの長さを超えたときにこのハンドラーがどのように応答するかを定義します。これは BLOCK または DISCARD に設定できます。BLOCK の場合、キューでスペースが利用可能になるまでロギングアプリケーションが待機します。これは、非同期ではないログハンドラーと同じ動作です。DISCARD の場合、ロギングアプリケーションは動作を続けますが、ログメッセージは削除されます。
    <async-handler name="Async_NFS_handlers">
       <level name="INFO"/>
       <queue-length value="512"/>
       <overflow-action value="block"/>
  5. subhandlers の一覧を表示します。

    subhandlers リストは、この非同期ハンドラーがログメッセージを渡すログハンドラーの一覧です。
    <async-handler name="Async_NFS_handlers">
       <level name="INFO"/>
       <queue-length value="512"/>
       <overflow-action value="block"/>
       <subhandlers>
          <handler name="FILE"/>
          <handler name="accounts-record"/>
       </subhandlers>
    </async-handler>

パート IV. キャッシュモードのセットアップ

第6章 キャッシュモード

Red Hat JBoss Data Grid は次の 2 つのモードを提供します。
  • ローカルモードは、JBoss Data Grid で提供される唯一のクラスターキャッシュモードではないモードです。ローカルモードの JBoss Data Grid は、簡単な単一ノードのインメモリーデータキャッシュとして動作します。ローカルモードは、スケーラビリティーおよびフェイルオーバーが不要な場合に最も効果的であり、クラスターモードに比べてパフォーマンスが高くなります。
  • クラスターモードは、状態の変更をノードの小型のサブセットにレプリケートするクラスターモードを提供します。サブセットのサイズは、フォールトトラレンスを実現するには十分なサイズですが、スケーラビリティーを妨げるほど大きくはありません。クラスターモードを使用する前に、クラスター化された設定に対して JGroup を設定することが重要です。JGroups の設定方法についてさらに詳しくは、「JGroups の設定 (ライブラリーモード) 」 を参照してください。

6.1. キャッシュコンテナーについて

キャッシュコンテナーは、キャッシュを使用する際の開始点として Red Hat JBoss Data Grid のリモートクライアントサーバーモードで使用されます。cache-container 要素は 1 つ以上の (ローカルまたはクラスター) キャッシュの親として動作します。クラスターキャッシュをコンテナーに追加するには、トランスポートを定義する必要があります。
次の手順は、キャッシュコンテナーの設定例を示しています。

手順6.1 キャッシュコンテナーの設定方法

  1. キャッシュコンテナーを指定します。

    cache-container 要素は、次のパラメーターを使用してキャッシュコンテナーに関する情報を指定します。
    <subsystem xmlns="urn:infinispan:server:core:6.0" 
    	   default-cache-container="default">
    1. キャッシュコンテナーの名前を設定します。

      name パラメーターはキャッシュコンテナーの名前を定義します。
      <subsystem xmlns="urn:infinispan:server:core:6.0" 
      	   default-cache-container="default">
      	<cache-container name="default" />
    2. デフォルトキャッシュを指定します。

      default-cache パラメーターは、キャッシュコンテナーと共に使用されるデフォルトキャッシュの名前を定義します。
      <subsystem xmlns="urn:infinispan:server:core:6.0" 
      	   default-cache-container="default">
      	<cache-container name="default" 
      			 default-cache="default" />
    3. 統計を有効/無効にします。

      statistics 属性は任意であり、デフォルトは true です。統計は、JMX または JBoss Operations Network 経由で JBoss Data Grid を監視する際に役立ちますが、パフォーマンスにはマイナスの影響を与えます。統計が不要な場合は、これを false に設定してこの属性を無効にします。
      <subsystem xmlns="urn:infinispan:server:core:6.0" 
      	   default-cache-container="default">
      	<cache-container name="default" 
      			 default-cache="default" 
      			 statistics="true"/>
    4. リスナーのエグゼキューターを定義します。

      listener-executor は非同期キャッシュリスナーの通知に使用されるエグゼキューターを定義します。
      <subsystem xmlns="urn:infinispan:server:core:6.0" 
      	   default-cache-container="default">
      	<cache-container name="default" 
      			 default-cache="default"
      			 statistics="true"
      			 listener-executor="infinispan-listener" />
    5. キャッシュコンテナーの開始モードを設定します。

      start パラメーターはキャッシュコンテナーが起動する時を示します (要求時にレイジーに起動するか、またはサーバー起動時に「イーガーに (eagerly)」起動するかなど)。このパラメーターの有効な値は EAGERLAZY です。
      <subsystem xmlns="urn:infinispan:server:core:6.0" 
      	   default-cache-container="default">
      	<cache-container name="default" 
      			 default-cache="default" 
      			 statistics="true"
      			 listener-executor="infinispan-listener" 
      			 start="EAGER">
  2. キャッシュごとの統計

    statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、監視を必要としないキャッシュについては選択的に無効にすることができます。
    <subsystem xmlns="urn:infinispan:server:core:6.0" 
    	   default-cache-container="default">
    	<cache-container name="default" 
    			 default-cache="default" 
    			 statistics="true"
    			 listener-executor="infinispan-listener" 
    			 start="EAGER">
    		<local-cache name="default"
    		   statistics="true">
    			...
    		</local-cache>
    	</cache-container>
    </subsystem>

6.2. ローカルモード

マップの代わりに Red Hat JBoss Data Grid のローカルモードを使用すると、多くの利点があります。
簡単なマップでは提供されない次のような機能をキャッシュが提供します。
  • データを永続化するライトスルーおよびライトビハインドキャッシュ。
  • Java 仮想マシン (JVM) がメモリー不足にならないようにするためのエントリーエビクション。
  • 定義された期間後に期限切れになるエントリーのサポート。
JBoss Data Grid は、楽観的および非観的ロックなどの技術を使用してロックの取得を管理する、高パフォーマンスで読み取りをベースとするデータコンテナーを中心に構築されます。
また、JBoss Data Grid は CAS (Compare and Swap) アルゴリズムやその他のロックフリーアルゴリズムも使用するため、スループットの高いマルチ CPU 環境やマルチコア環境を実現します。さらに、JBoss Data Grid のキャッシュ APIJDKConcurrentMap を拡張するため、マップから JBoss Data Grid への移行プロセスが簡単になります。

6.2.1. ローカルモードの設定 (リモートクライアントサーバーモード)

ローカルキャッシュはすべてのキャッシュコンテナーに追加することができます。以下の例は、local-cache 要素を追加する方法について説明しています。

手順6.2 local-cache 要素

local-cache 要素は次のパラメーターを使用して、キャッシュコンテナーと共に使用されるローカルキャッシュに関する情報を指定します。
  1. ローカルキャッシュ名の追加

    name パラメーターは使用するローカルキャッシュの名前を指定します。
    <cache-container name="local"
                      default-cache="default" 
                      statistics="true">
             <local-cache name="default" >
  2. キャッシュコンテナーの開始モードを設定します。

    start パラメーターはキャッシュコンテナーが起動する時を示します (要求時にレイジーに起動するか、またはサーバー起動時に「すぐに (eargerly)」起動するかなど)。このパラメーターの有効な値は EAGERLAZY です。
    <cache-container name="local"
                      default-cache="default" 
                      statistics="true">
             <local-cache name="default"
                              start="EAGER" >
  3. バッチ処理の設定

    batching パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。
    <cache-container name="local"
                      default-cache="default"
                      statistics="true">
             <local-cache name="default"
                              start="EAGER"
                              batching="false" >
  4. キャッシュごとの統計

    statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、モニタリングを必要としないキャッシュについては選択的に無効にすることができます。
    <cache-container name="local"
                      default-cache="default"
                      statistics="true">
             <local-cache name="default"
                              start="EAGER"
                              batching="false"
                              statistics="true">
  5. インデックス化のタイプの指定

    indexing パラメーターはローカルキャッシュに使用されるインデックス化のタイプを指定します。このパラメーターの有効な値は NONELOCAL、および ALL です。
    <cache-container name="local"
                      default-cache="default" 
                      statistics="true">
             <local-cache name="default"
                              start="EAGER"
                              batching="false"
                              statistics="true">
                      <indexing index="NONE">
    	                <property name="default.directory_provider">ram</property>
                      </indexing>
             </local-cache>
この代わりに、引数のないコンストラクターで DefaultCacheManager を作成することもできます。どちらの方法でも、ローカルのデフォルトキャッシュが作成されます。
ローカルキャッシュとクラスター化されたキャッシュは同じキャッシュコンテナーで共存できますが、コンテナーに <transport/> がない場合はローカルキャッシュのみ格納できます。例で使用されたコンテナーには <transport/> がないため、ローカルキャッシュのみを格納できます。
キャッシュインターフェースは ConcurrentMap を拡張し、複数のキャッシュシステムと互換性があります。

6.2.2. ローカルモードの設定 (ライブラリーモード)

Red Hat JBoss Data Grid のライブラリーモードでは、キャッシュの mode パラメーターを local に設定することは、クラスタリングモードを指定しないことと等しいということではありません。後者の場合には、キャッシュのキャッシュマネージャーがトランスポートを定義する場合でも、キャッシュはデフォルトでローカルモードに設定されます。
以下のようにクラスターモードをローカルに設定します。
<clustering mode="local" />

6.3. クラスターモード

Red Hat JBoss Data Grid は、次のクラスターモードを提供します。
  • レプリケーションモードは、クラスターのすべてのキャッシュインスタンスにわたって追加されたエントリーをレプリケートします。
  • インバリデーションモードはデータを共有しませんが、無効なエントリーの削除を開始するようリモートキャッシュに伝えます。
  • ディストリビューションモードは、クラスターの全ノード上ではなく、ノードのサブセット上の各エントリーを保管します。
ネットワーク通信に同期または非同期トランスポートを使用するよう、クラスターモードに追加設定することが可能です。

6.3.1. 非同期および同期の操作

クラスターモード (インバリデーション、レプリケーション、ディストリビューションなど) が使用されると、データが同期的または非同期的に他のノードへ伝搬されます。
同期モードが使用されると、送信側はスレッドの継続を許可する前に受信側からの応答を待ちます。非同期モードでは、データを送信しても、クラスターの他のノードからの応答を待たずに操作を継続します。
非同期モードは一貫性よりも速度を優先するため、スティッキーセッションが有効な HTTP セッションレプリケーションなどのユースケースに適しています。このようなセッション (他のユースケースではデータ) は、ノードに障害が発生しない限り常に同じクラスターノード上でアクセスされます。

6.3.2. キャッシュモードのトラブルシューティング

6.3.2.1. ReadExternal の無効なデータ

Cache.putAsync() を使用する場合、シリアライズを開始するとオブジェクトが変更される可能性があります。それによってデータストリームが破損されると、無効なデータが readExternal に渡されます。このような場合、オブジェクトへのアクセスを同期化すると、この問題を解決することができます。

6.3.2.2. 非同期通信について

Red Hat JBoss Data Grid では、ローカルモードは local-cache によって表され、ディストリビューションモードは distributed-cache、レプリケーションモードは replicated-cache によって表されます。これらの各要素には、mode プロパティーが含まれ、同期通信の場合は SYNC、非同期通信の場合は SYNC に値を設定することができます。

例6.1 非同期通信の設定例

<replicated-cache name="default" 
                  start="EAGER"
                  mode="SYNC"    
                  batching="false" 
                  statistics="true">
                 ...
</replicated-cache>

注記

この設定は、JBoss Data Grid のどちらの使用モード (ライブラリーモードとリモートクライアントサーバーモード) でも有効です。

6.3.2.3. クラスター物理アドレスの読み出し

クラスターの物理アドレスの読み出し方法

インスタンスメソッド呼び出しを使用して物理アドレスを読み出すことができます。たとえば、AdvancedCache.getRpcManager().getTransport().getPhysicalAddresses() のように読み出します。

6.4. 状態の転送 (State Transfer)

状態の転送は、ノードがクラスターに参加するか、またはクラスターを離れるときにはいつでも Red Hat JBoss Data Grid で自動的に発生します。
新規ノードは、ディストリビューションモードとレプリケーションモードの両方でクラスターに参加する際に、既存ノードからキャッシュの状態を受信します。さらに状態の転送は、ノードがディストリビューションモードでクラスターを出た後に状態を再分散する際にノードに発生します。
状態の転送は、キャッシュがインメモリーの状態か、または永続状態であるかにかかわらず発生する可能性があります。
  • レプリケーションモードでは、クラスターに参加するノードは、現在キャッシュ内の他のノードにあるデータのコピーを受信します。これは、既存のノードが現在のキャッシュの状態の一部を配置するときに発生します。
  • ディストリビューションモードでは、一貫性のあるハッシュで決定される、キー領域全体のスライスが含まれます。新規ノードがクラスターに参加すると、それぞれの既存ノードから取られたキー領域のスライスが受信されます。状態の転送により、新規ノードでキー領域のスライスが受信され、既存のノードが以前に対象としていたデータの一部が減少します。

6.4.1. 非ブロッキング状態転送

Red Hat JBoss Data Grid における 非ブロッキング状態転送は、状態の転送が進行中である場合のクラスターまたはノードが応答できない時間を最小限にすることを目的としています。
JBoss Data Grid における非ブロッキング状態転送
  • 状態の遷移を実行することを可能にします (クラスターのパフォーマンスが低下します)。ただし、状態の遷移時にパフォーマンスが低下すると、例外がスローされず、プロセスを続行できます。
  • マージ後のデータ競合を解決するためのメカニズムは追加しませんが、今後これを追加することについては実行可能です。

6.4.2. JMX による状態転送の抑制

保守を行うためにクラスターの停止および再起動を行うにあたり、JMX を使用して状態転送を抑制することができます。この操作は、より効率的なクラスターのシャットダウンと起動を許可し、グリッドを停止する際のメモリー不足のエラーの発生リスクを取り除きます。
新規ノードがクラスターに参加し、再調整が抑制される際に、getCache() 呼び出しは、再調整が再度有効にされないか、または stateTransfer.awaitInitialTransferfalse に設定されない限り、stateTransfer.timeout が期限切れになった後にタイムアウトになります。
状態転送および再調整を無効にすることは、部分的なクラスターのシャットダウンや再起動の場合に有効ですが、状態転送が無効にされているために部分的なクラスターのシャットダウンでデータが失われる可能性があります。

6.4.3. rebalancingEnabled 属性

再調整の抑制は、rebalancingEnabled JMX 属性によってのみトリガーでき、これには特定の設定は不要です。
rebalancingEnabled 属性は、いずれのノードでも LocalTopologyManager JMX Mbean から、クラスター全体に対して変更することができます。この属性はデフォルトではtrue であり、プログラムを使って設定することができます。
Hot Rod などのサーバーは、起動時に設定で宣言されるすべてのキャッシュを起動するよう試みます。再調整が無効にされる場合、キャッシュは起動に失敗します。そのため、サーバー環境で以下の設定を使用することが必須になります。
<await-initial-transfer="false"/>

第7章 ディストリビューションモードのセットアップ

7.1. ディストリビューションモードについて

Red Hat JBoss Data Grid のディストリビューションモードが有効になっている場合、全ノードの各エントリーをレプリケートせずに、グリッド内のノードのサブセット上に各エントリーが格納されます。冗長性とフォールトトラレンスを実現するため、各エントリーは通常、複数のノード上に格納されます。
ディストリビューションモードの場合、クラスター全体の選択されたノード上にエントリーを格納するため、他のクラスターモードと比べスケーラビリティーが向上します。
ディストリビューションモードを使用するキャッシュは、一貫したハッシュアルゴリズムを使用し、クラスター全体で透過的にキーを検索することが可能です。

7.2. ディストリビューションモードの一貫したハッシュアルゴリズム

ディストリビューションモードは一貫したハッシュアルゴリズムを使用して、エントリーを格納するクラスターよりノードを選択します。一貫したハッシュアルゴリズムは、クラスター内で維持される各キャッシュエントリーのコピー数で設定されます。
パフォーマンスとフォールトトラレンスのバランスを考慮して、各データ項目のコピー数を設定する必要があります。エントリーのコピーが多すぎるとパフォーマンスが低下し、コピーが少なすぎるとノードの障害時にデータを損失する可能性があります。

7.3. ディストリビューションモードにおけるエントリーの検索

Red Hat JBoss Data Grid のディストリビューションモードで使用される一貫したハッシュアルゴリズムは、要求をマルチキャストしたりコストのかかるメタデータを維持しなくてもエントリーを特定できるようにします。
PUT 操作が実行されると、リモート呼び出しが num_copies に指定された回数実行されます。クラスターのいずれかのノードで GET 操作が実行されると、リモート呼び出しが 1 回実行されます。バックグラウンドでは、GET 操作が実行されると PUT 操作と同じ回数 (num_copies パラメーターの値) のリモート呼び出しが行われますが、これらの呼び出しは同時に実行され、返されたエントリーは即座に呼び出し側に渡されます。

7.4. ディストリビューションモードの戻り値

Red Hat JBoss Data Grid のディストリビューションモードでは、以前の戻り値がローカルで見つからない場合に同期要求を使用して以前の戻り値を読み出します。ディストリビューションモードが使用する処理が非同期か同期であるかに関係なく、この作業では同期要求が使用されます。

7.5. ディストリビューションモードの設定 (リモートクライアントサーバーモード)

ディストリビューションモードは Red Hat JBoss Data Grid のクラスターモードです。以下の手順を使用して、ディストリビューションモードをキャッシュコンテナーに追加することができます。

手順7.1 distributed-cache 要素

distributed-cache 要素は、以下のパラメーターを使用して分散キャッシュの設定を行います。
  1. キャッシュ名の追加

    name パラメーターは、キャッシュの一意の ID を提供します。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<transport executor="infinispan-transport" lock-timeout="60000"/>
     	<distributed-cache name="default" />
  2. クラスター化されたキャッシュの開始モードの設定

    mode パラメーターは、クラスター化されたキャッシュモードを設定します。有効な値は SYNC (同期) と ASYNC (非同期) です。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<transport executor="infinispan-transport" lock-timeout="60000"/>
    	<distributed-cache name="default"
    			   mode="SYNC" />
  3. セグメント数の指定

    (オプションの) segments パラメーターは、クラスターごとのハッシュ領域セグメントの数を指定します。このパラメーターの推奨される値は、クラスターサイズに 10 を乗算した値であり、デフォルト値は 20 です。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<transport executor="infinispan-transport" lock-timeout="60000"/>
    	<distributed-cache name="default"
    			   mode="SYNC"
    			   segments="20" />
  4. キャッシュの開始モードの設定

    start パラメーターは、サーバーの起動時か、サーバーが要求またはデプロイされるときにキャッシュを起動させるかどうかを指定します。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<transport executor="infinispan-transport" lock-timeout="60000"/>
    	<distributed-cache name="default"
    			   mode="SYNC"
    			   segments="20"
    			   start="EAGER"/>
    
  5. キャッシュごとの統計

    statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、監視を必要としないキャッシュについては選択的に無効にすることができます。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<transport executor="infinispan-transport" lock-timeout="60000"/>
    	<distributed-cache name="default"
    			   mode="SYNC"
    			   segments="20"
    			   start="EAGER"
    			   statistics="true">
    			...
    	</distributed-cache>
    </cache-container>

重要

この設定をロードする前に、JGroups をクラスターモードに対して適切に設定する必要があります。
cache-containerlocking、および transaction 要素について詳しくは、該当する章を参照してください。

7.6. ディストリビューションモードの設定 (ライブラリーモード)

次の手順は、Red Hat JBoss Data Grid のライブラリーモードでの分散キャッシュ設定を示しています。

手順7.2 分散キャッシュの設定

  1. クラスターモードの設定

    clustering 要素の mode パラメーター値は、キャッシュに選択されたクラスタリングモードを決定します。
    <clustering mode="distribution">
  2. リモート呼び出しタイムアウトの指定

    sync 要素の replTimeout パラメーターは、リモート呼び出し後の確認に設定される最大の時間範囲 (ミリ秒単位) を指定します。この時間範囲が確認なしに終了する場合、例外がスローされます。
    <clustering mode="distribution">
            <sync replTimeout="${TIME}" />
  3. 状態の転送設定の定義

    stateTransfer 要素は、ノードがクラスターを出るか、またはクラスターに参加する際に状態がどのように転送されるかを指定します。これは以下のパラメーターを使用します。
    1. 状態転送のバッチサイズの指定

      chunkSize パラメーターは、転送するキャッシュエントリーの状態バッチのサイズを指定します。この値が 0 より大きい場合、設定される値は送信されるチャンクのサイズになります。値が 0 より小さい場合、すべての状態は同時に転送されます。
      <clustering mode="distribution">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}" />
    2. fetchInMemoryState パラメーターの設定

      true に設定される fetchInMemoryState パラメーターは、起動時に隣接したキャッシュから状態についての情報を要求します。これは、キャッシュの起動時間に影響を与えます。
      <clustering mode="distribution">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}" />
    3. awaitInitialTransfer パラメーターの定義

      awaitInitialTransfer パラメーターにより、joiner ノードでのメソッド CacheManager.getCache() への最初の呼び出しはブロックし、参加が完了し、キャッシュが隣接するキャッシュからの状態の受信を完了するまでブロックします (fetchInMemoryState が有効な場合)。このオプションは、分散キャッシュとレプリケートされたキャッシュにのみ適用され、デフォルトで有効にされます。
      <clustering mode="distribution">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}" />
    4. timeout 値の設定

      timeout パラメーターは、キャッシュが要求された状態を持つ隣接キャッシュからの応答を待機する最長時間 (ミリ秒単位) を指定します。timeout 期間内で応答が受信されない場合、起動プロセスは中止し、例外がスローされます。
      <clustering mode="distribution">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
  4. トランスポート設定の指定

    transport 要素は、以下のようにキャッシュコンテナのトランスポート設定を定義します。
    1. クラスター名の指定

      clusterName パラメーターはクラスターの名前を指定します。ノードは同じ名前を共有するクラスターのみに接続できます。
      <global>
          <transport clusterName="${NAME}" />
      </global>
    2. distributedSyncTimeout 値の設定

      distributedSyncTimeout パラメーターは、分散ロック上でロックを取得するために待機する時間を指定します。この分散ロックにより、単一キャッシュは一度に状態を転送するか、または状態をリハッシュすることができます。
      <global>
          <transport clusterName="${NAME}"
              distributedSyncTimeout="${TIME}" />
      </global>
    3. ネットワークトランスポートの設定

      transportClass パラメーターは、キャッシュコンテナのネットワークトランスポートを表すクラスを指定します。
      <global>
          <transport clusterName="${NAME}"
              distributedSyncTimeout="${TIME}"
              transportClass="${CLASS}" />
      </global>

7.7. 同期および非同期の分散

ディストリビューションモードは同期通信のみをサポートします。特定のパブリック API メソッドより意味のある戻り値を引き出すには、ディストリビューションモードを使用する時に同期された通信を使用する必要があります。

例7.1 通信モードの例

たとえば、ABC という 3 つのキャッシュがクラスターにあり、キャッシュ AB にマップする K というキーがあるとします。戻り値の必要なクラスター C 上で、Cache.remove(K) のような操作を実行するとします。正常に実行するには、操作が最初にキャッシュ AB の両方に呼び出しを同期転送し、キャッシュ A または B より返される結果を待つ必要があります。非同期通信が使用された場合、操作が想定通り動作しても戻り値の有用性は保証されません。

7.8. ディストリビューションモードにおける GET および PUT の使用

ディストリビューションモードでは、write コマンドの前にキャッシュがリモートの GET コマンドを実行します。これは、java.util.Map コントラクトに従って指定されたキーに関連する以前の値を返すメソッド (Cache.put()) があるからです。これがキーを所有しないインスタンスで実行され、エントリーが 1 次キャッシュで見つからない場合、PUT の前にリモートの GET を実行することが、戻り値を取得するための信頼できる唯一の方法になります。
Red Hat JBoss Data Grid は戻り値を待たなければならないため、キャッシュが同期または非同期であるかに関わらず、PUT 操作の前に発生する GET 操作は常に同期になります。

7.8.1. 分散された GET および PUT 操作

ディストリビューションモードでは、必要な PUT 操作を実行する前に、キャッシュが GET 操作を実行することがあります。
この操作は、リソースの面では大変コストのかかる操作になります。リモート GET 操作は同期であるにも関わらず、すべての応答を待たないため、無駄になるリソースが発生します。GET 処理は最初に受信する有効な応答を許可するため、パフォーマンスとクラスターの大きさとの関連性はありません。
ご使用の実装で戻り値が必要でない場合、呼び出し毎の設定に対する Flag.SKIP_REMOTE_LOOKUP フラグを使用します。
このような動作は、キャッシュの操作や全パブリックメソッドの正確な機能を害することはありませんが、java.util.Map インターフェースコントラクトに違反します。これは、信頼できず正確でない戻り値が特定のメソッドに提供されるため、コントラクトに違反することになります。そのため、これらの戻り値が設定上重要な目的に使用されないようにしてください。

第8章 レプリケーションモードのセットアップ

8.1. レプリケーションモードについて

Red Hat JBoss Data Grid のレプリケーションモードは、簡単なクラスターモードです。キャッシュインスタンスは、同じネットワーク上の異なる Java 仮想マシン (JVM) 上にある隣接したインスタンスを自動的に見つけ、見つけたインスタンスを用いてクラスターを形成します。キャッシュインスタンスへ追加されたエントリーは、クラスターのすべてのキャッシュインスタンス全体でレプリケートされ、すべてのクラスターキャッシュインスタンスよりローカルで読み出すことが可能です。
JBoss Data Grid のレプリケーションモードでは、レプリケーションが発生する前にローカルで戻り値を使用できます。

8.2. 最適化されたレプリケーションモードの使用

レプリケーションモードはクラスター全体のステート共有に使用されますが、ターゲットクラスターに含まれるサーバーが 10 台未満の場合のみクラスターのパフォーマンスが最適化されます。
大型のクラスターでは、大量のレプリケーションメッセージを送信する必要があるため、パフォーマンスが低下します。
大型のクラスターのパフォーマンスをある程度向上させる UDP マルチキャストを使用するよう、Red Hat JBoss Data Grid を設定できます。

8.3. レプリケーションモードの設定 (リモートクライアントサーバーモード)

レプリケーションモードは Red Hat JBoss Data Grid のクラスターモードです。以下の手順を使用して、レプリケーションモードをキャッシュコンテナーに追加することができます。

手順8.1 replicated-cache 要素

replicated-cache 要素は、以下のパラメーターを使用して分散キャッシュの設定を行います。
  1. キャッシュ名の追加

    name パラメーターは、キャッシュの一意の ID を提供します。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default">
  2. クラスター化されたキャッシュの開始モードの設定

    mode パラメーターは、クラスター化されたキャッシュモードを設定します。有効な値は SYNC (同期) と ASYNC (非同期) です。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default" 
    			  mode="SYNC">
  3. キャッシュの開始モードの設定

    start パラメーターは、サーバーの起動時か、サーバーが要求またはデプロイされるときにキャッシュを起動させるかどうかを指定します。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default" 
    				mode="SYNC"
    				start="EAGER">
  4. キャッシュごとの統計

    statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、監視を必要としないキャッシュについては選択的に無効にすることができます。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default" 
    				mode="SYNC"
    				start="EAGER"
    				statistics="true">
          		...
    	</replicated-cache>
    </cache-container>
  5. トランザクションのセットアップ

    transaction 要素は、レプリケートされたキャッシュのトランザクションモードをセットアップします。

    重要

    リモートクライアントサーバーモードでは、JBoss Data Grid が互換モードで使用され、クラスターに JBoss Data Grid サーバーインスタンスとライブラリーインスタンスの両方が含まれない限り、トランザクション要素が NONE に設定されます。このときにトランザクションがライブラリーモードインスタンスで設定される場合は、サーバーインスタンスでもトランザクションを設定する必要があります。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default" 
    				mode="SYNC"
    				start="EAGER"
    				statistics="true">
    		<transaction mode="NONE" />
    	</replicated-cache>
    </cache-container>

重要

この設定をロードする前に、JGroups をクラスターモードに対して適切に設定する必要があります。
cache-container および locking の詳細については、該当する章を参照してください。

8.4. レプリケーションモードの設定 (ライブラリーモード)

以下の手順は、Red Hat JBoss Data Grid のライブラリーモードでのレプリケーションモードの設定を示しています。

手順8.2 レプリケーションモードの設定

  1. クラスターモードの設定

    clustering 要素の mode パラメーター値は、キャッシュに選択されたクラスタリングモードを決定します。
    <clustering mode="replication">
  2. リモート呼び出しタイムアウトの指定

    sync 要素の replTimeout パラメーターは、リモート呼び出し後の確認に設定される最大の時間範囲 (ミリ秒単位) を指定します。この時間範囲が確認なしに終了する場合、例外がスローされます。
    <clustering mode="replication">
            <sync replTimeout="${TIME}" />
  3. 状態の転送設定の定義

    stateTransfer 要素は、ノードがクラスターを出るか、またはクラスターに参加する際に状態がどのように転送されるかを指定します。これは以下のパラメーターを使用します。
    1. 状態転送のバッチサイズの指定

      chunkSize パラメーターは、転送するキャッシュエントリーの状態バッチのサイズを指定します。この値が 0 より大きい場合、設定される値は送信されるチャンクのサイズになります。値が 0 より小さい場合、すべての状態は同時に転送されます。
      <clustering mode="replication">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}" />
    2. fetchInMemoryState パラメーターの設定

      true に設定される fetchInMemoryState パラメーターは、起動時に隣接したキャッシュから状態についての情報を要求します。これは、キャッシュの起動時間に影響を与えます。
      <clustering mode="replication">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"                       
                             fetchInMemoryState="{true/false}" />
    3. awaitInitialTransfer パラメーターの定義

      awaitInitialTransfer パラメーターにより、joiner ノードでのメソッド CacheManager.getCache() への最初の呼び出しはブロックし、参加が完了し、キャッシュが隣接するキャッシュからの状態の受信を完了するまでブロックします (fetchInMemoryState が有効な場合)。このオプションは、分散キャッシュとレプリケートされたキャッシュにのみ適用され、デフォルトで有効にされます。
      <clustering mode="replication">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"                       
                             fetchInMemoryState="{true/false}"                       
                             awaitInitialTransfer="{true/false}" />
    4. timeout 値を設定します。

      timeout パラメーターは、キャッシュが要求された状態を持つ隣接キャッシュからの応答を待機する最長時間 (ミリ秒単位) を指定します。timeout 期間内で応答が受信されない場合、起動プロセスは中止し、例外がスローされます。
      <clustering mode="replication">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"                       
                             fetchInMemoryState="{true/false}"                       
                             awaitInitialTransfer="{true/false}"                       
                             timeout="${TIME}" />
  4. トランスポート設定の指定

    transport 要素は、以下のようにキャッシュコンテナのトランスポート設定を定義します。
    1. クラスター名の指定

      clusterName パラメーターはクラスターの名前を指定します。ノードは同じ名前を共有するクラスターのみに接続できます。
      <global>
          <transport clusterName="${NAME}" />
      </global>
    2. distributedSyncTimeout 値の設定

      distributedSyncTimeout パラメーターは、分散ロック上でロックを取得するために待機する時間を指定します。この分散ロックにより、単一キャッシュは一度に状態を転送するか、または状態をリハッシュすることができます。
      <global>
          <transport clusterName="${NAME}"
              distributedSyncTimeout="${TIME}" />
      </global>
    3. ネットワークトランスポートの設定

      transportClass パラメーターは、キャッシュコンテナのネットワークトランスポートを表すクラスを指定します。
      <global>
          <transport clusterName="${NAME}"
              distributedSyncTimeout="${TIME}"
              transportClass="${CLASS}" />
      </global>

8.5. 同期および非同期のレプリケーション

対処する問題に応じて、レプリケーションモードは同期または非同期のいずれかになります。
  • 同期レプリケーションは、クラスターの全ノードで変更がレプリケートされるまでスレッドや呼び出し側 (put() 操作の場合など) をブロックします。確認応答を待つために、同期レプリケーションでは操作が終了する前にすべてのレプリケーションが正常に適用されます。
  • 非同期レプリケーションはノードからの応答を待つ必要がないため、同期レプリケーションよりもかなり高速になります。非同期レプリケーションはバックグラウンドでレプリケーションを実行し、呼び出しは即座に返されます。非同期レプリケーション中に発生したエラーはログに書き込まれます。そのため、クラスターのすべてのキャッシュインスタンスでトランザクションが正常にレプリケートされなくても、トランザクションは正常に終了することが可能です。

8.5.1. 非同期レプリケーションの挙動に対するトラブルシューティング

インスタンスによっては、非同期のレプリケーションや分散に対して設定されたキャッシュが、同期の場合と同様に応答を待ってしまうことがあります。これは、状態転送と非同期モードの両方が設定されていると、キャッシュは同期的に動作するためです。状態転送を想定通りに動作させるには、同期的な動作が必要となります。
この問題に対処するには、以下の方法の 1 つに従います。
  • 状態転送を無効にし、 ClusteredCacheLoader を使用して必要な時にリモート状態をレイジーにルックアップします。
  • 状態転送と REPL_SYNC を有効にします。非同期 API (cache.putAsync(k, v) など) を使用して「fire-and-forget」機能をアクティベートします。
  • 状態転送と REPL_ASYNC を有効にします。PRC はすべて同期的になりますが、レプリケーションキューを有効にすると (非同期モードで推奨) クライアントスレッドは中断されません。

8.6. レプリケーションキュー

レプリケーションモードでは、以下を基にして、Red Hat JBoss Data Grid はレプリケーションキューを使用し、ノード全体で変更をレプリケートします。
  • 以前に設定された間隔。
  • 要素数を超えるキューサイズ。
  • 以前に設定された間隔と要素数を超えるキューサイズの組み合わせ。
レプリケーションキューは、レプリケート中にキャッシュ操作が個別に送信されるのではなく、一括送信されるようにします。そのため、送信されるレプリケーションメッセージの数が減り、使用されるエンベロープも少なくなるため、JBoss Data Grid のパフォーマンスが向上します。
レプリケーションキューを使用する場合の難点は、時間やキューサイズを基にキューが周期的にフラッシュされることです。このようなフラッシュ操作は、クラスターノード全体のレプリケーション、分散、または無効化の操作を遅延させます。レプリケーションキューを無効にすると、データは直接送信されるため、クラスターノードへ達する時間が短くなります。
レプリケーションキューは非同期モードと共に使用されます。

8.6.1. レプリケーションキューの使用

レプリケーションキューを使用する場合、以下の 1 つを実行します。
  • 非同期マーシャリングを無効にします。
  • max-threads 数の値を、transport executor に対して 1 に設定します。transport executor は次のように standalone.xml で定義されます。
    <transport executor="infinispan-transport"/>
これらの方法の 1 つを実装するには、レプリケーションキューを非同期モードで使用する必要があります。非同期モードは、キュータイムアウト (queue-flush-interval、値はミリ秒単位) やキューサイズ (queue-size) と共に次のように設定することができます。

例8.1 非同期モードのレプリケーションキュー

<replicated-cache name="asyncCache" 
                  start="EAGER"
                  mode="ASYNC"
                  batching="false"
                  indexing="NONE"
                  statistics="true"
                  queue-size="1000"
                  queue-flush-interval="500">   
               ...
</replicated-cache>
レプリケーションキューにより、要求がクライアントへ返されるまでの時間が短縮されるため、レプリケーションキューを非同期マーシャリングと共に使用しても大きな利点はありません。

8.7. レプリケーション保証について

クラスター化されたキャッシュでは、ユーザーは同期レプリケーション保証と非同期レプリケーションに関連する並列性を取得することができます。Red Hat JBoss Data Grid はこの目的で非同期 API を提供します。
API で使用される非同期メソッドは、クエリ可能な Future を返します。クエリは、使用されるネットワーク呼び出しが正常に行われたことの確認を受信するまでスレッドをブロックします。

8.8. 内部ネットワークのレプリケーショントラフィック

クラウドプロバイダーによっては、内部 IP アドレスを介したトラフィックにパブリック IP アドレスを介したトラフィックよりも低い課金を行ったり、内部ネットワークトラフィックにまったく課金しないことがあります (GoGrid など)。低料金で利用できるよう、内部ネットワークを使用してレプリケーションのトラフィックを転送するよう Red Hat JBoss Data Grid を設定することが可能です。このような設定では、割り当てられた内部 IP アドレスを調べるのは簡単ではありませんが、JBoss Data Grid は JGroups インターフェースを使用してこの問題を解決します。

第9章 インバリデーションモードのセットアップ

9.1. インバリデーションモードについて

無効化はクラスターモードで、データを共有しませんが、リモートキャッシュの潜在的に古いデータを削除します。このキャッシュモードを使用するには、データベースなどのさらに永久的なデータストアが別に必要になります。
このような状況で、Red Hat JBoss Data Grid は、数多くの読み取り操作を実行するシステムを最適化するために使用され、ステートが必要となる度にデータベースが使用されないようにします。
インバリデーションモードが使用されている場合、キャッシュのデータが変更になると、クラスターの他のキャッシュが古いデータをメモリーからエビクトします。

9.2. インバリデーションモードの設定 (リモートクライアントサーバーモード)

インバリデーションモードは Red Hat JBoss Data Grid のクラスターモードです。以下の手順を使用して、インバリデーションモードをキャッシュコンテナーに追加することができます。

手順9.1 invalidation-cache 要素

invalidation-cache 要素は、以下のパラメーターを使用して分散キャッシュの設定を行います。
  1. キャッシュ名の追加

    name パラメーターは、キャッシュの一意の ID を提供します。
    <cache-container name="local" 
         		 default-cache="default"
         		 statistics="true">
     <invalidation-cache name="default">
  2. クラスター化されたキャッシュの開始モードの設定

    mode パラメーターは、クラスター化されたキャッシュモードを設定します。有効な値は SYNC (同期) と ASYNC (非同期) です。
    <cache-container name="local" 
         		 default-cache="default"
         		 statistics="true">
    	<invalidation-cache name="default"
    			    mode="ASYNC">
  3. キャッシュの開始モードの設定

    start パラメーターは、サーバーの起動時か、またはサーバーが要求またはデプロイされるときにキャッシュを起動させるかどうかを指定します。
    <cache-container name="local" 
         		 default-cache="default"
         		 statistics="true">
    	<invalidation-cache name="default"
    			    mode="ASYNC"
    			    start="EAGER">
  4. キャッシュごとの統計

    statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、モニタリングを必要としないキャッシュについては選択的に無効にすることができます。
    <cache-container name="local" 
         		 default-cache="default"
         		 statistics="true">
    	<invalidation-cache name="default"
    			    mode="ASYNC"
    			    start="EAGER"
    			    statistics="true">
    			...
    	</invalidation-cache>
    </cache-container>

重要

この設定をロードする前に、JGroups をクラスターモードに対して適切に設定する必要があります。
cache-containerlocking、および transaction 要素について詳しくは、該当する章を参照してください。

9.3. インバリデーションモードの設定 (ライブラリーモード)

次の手順は、Red Hat JBoss Data Grid のライブラリーモードにおけるインバリデーションモードのキャッシュ設定を示しています。

手順9.2 インバリデーションモードの設定

  1. クラスターモードの設定

    clustering 要素の mode パラメーター値は、キャッシュに選択されたクラスタリングモードを決定します。
    <clustering mode="invalidation">
  2. リモート呼び出しタイムアウトの指定

    sync 要素の replTimeout パラメーターは、リモート呼び出し後の確認に設定される最大の時間範囲 (ミリ秒単位) を指定します。この時間範囲が確認なしに終了する場合、例外がスローされます。
    <clustering mode="invalidation">
            <sync replTimeout="${TIME}" />
  3. 状態の転送設定の定義

    stateTransfer 要素は、ノードがクラスターを出るか、またはクラスターに参加する際に状態がどのように転送されるかを指定します。これは以下のパラメーターを使用します。
    1. 状態転送のバッチサイズの指定

      chunkSize パラメーターは、転送するキャッシュエントリーの状態バッチのサイズを指定します。この値が 0 より大きい場合、設定される値は送信されるチャンクのサイズになります。値が 0 より小さい場合、すべての状態は同時に転送されます。
      <clustering mode="invalidation">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}" />
    2. fetchInMemoryState パラメーターの設定

      true に設定される fetchInMemoryState パラメーターは、起動時に隣接したキャッシュから状態についての情報を要求します。これは、キャッシュの起動時間に影響を与えます。
      <clustering mode="invalidation">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}" />
    3. awaitInitialTransfer パラメーターの定義

      awaitInitialTransfer パラメーターにより、joiner ノードでのメソッド CacheManager.getCache() への最初の呼び出しはブロックし、参加が完了し、キャッシュが隣接するキャッシュからの状態の受信を完了するまでブロックします (fetchInMemoryState が有効な場合)。このオプションは、分散キャッシュとレプリケートされたキャッシュにのみ適用され、デフォルトで有効にされます。
      <clustering mode="invalidation">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}" />
    4. timeout 値の設定

      timeout パラメーターは、キャッシュが要求された状態を持つ隣接キャッシュからの応答を待機する最長時間 (ミリ秒単位) を指定します。timeout 期間内で応答が受信されない場合、起動プロセスは中止し、例外がスローされます。
      <clustering mode="invalidation">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
  4. トランスポート設定の指定

    transport 要素は、以下のようにキャッシュコンテナのトランスポート設定を定義します。
    1. クラスター名の指定

      clusterName パラメーターはクラスターの名前を指定します。ノードは同じ名前を共有するクラスターのみに接続できます。
      <global>
          <transport clusterName="${NAME}" />
      </global>
    2. distributedSyncTimeout 値の設定

      distributedSyncTimeout パラメーターは、分散ロック上でロックを取得するために待機する時間を指定します。この分散ロックにより、単一キャッシュは一度に状態を転送するか、または状態をリハッシュすることができます。
      <global>
          <transport clusterName="${NAME}"
              distributedSyncTimeout="${TIME}" />
      </global>
    3. ネットワークトランスポートの設定

      transportClass パラメーターは、キャッシュコンテナのネットワークトランスポートを表すクラスを指定します。
      <global>
          <transport clusterName="${NAME}"
              distributedSyncTimeout="${TIME}"
              transportClass="${CLASS}" />
      </global>

9.4. 同期的/非同期の無効化

Red Hat JBoss Data Grid のライブラリーモードでは、無効化は同期的または非同期的に操作します。
  • 同期的な無効化は、クラスターのすべてのキャッシュが無効化メッセージを受信し、古いデータをエビクトするまでスレッドをブロックします。
  • 非同期的な無効化は、応答待ちのスレッドをブロックせずに無効化メッセージがブロードキャストされる fire-and-forget モードで操作します。

9.5. 1 次キャッシュと無効化

無効化メッセージはキーが更新される度に生成されます。このメッセージは、現在の 1 次キャッシュエントリーに対応するデータが含まれる各ノードへマルチキャストされます。無効化メッセージにより、これらのノードは関連エントリーを無効としてマークするようになります。

パート V. リモートクライアントサーバーモードインターフェース

Red Hat JBoss Data Grid は、リモートクライアントサーバーモードでデータグリッドと対話するために以下の API を提供します。
  • 非同期 API (リモートクライアントサーバーモードで Hot Rod クライアントを併用する場合のみ使用可能)
  • REST インターフェース
  • Memcached インターフェース
  • Hot Rod インターフェース
    • RemoteCache API

第10章 非同期 API

Red Hat JBoss Data Grid は同期 API メソッドの他に、非ブロッキング方式で同じ機能を実現する非同期 API も提供します。
非同期メソッドの命名規則は、同期メソッドの命名規則と似ていますが、各メソッド名に Async を追加します。非同期メソッドは、操作の結果が含まれる Future を返します。
たとえば、Cache(String, String) とパラメーター化されたキャッシュでは、Cache.put(String key, String value) は String を返します。また、Cache.putAsync(String key, String value)Future(String) を返します。

10.1. 非同期 API の利点

非同期 API はブロックしないため、以下のような複数の利点があります。
  • 同期通信が保証される (エラーと例外を処理する機能が追加される)。
  • 呼び出しが完了するまでスレッドの操作をブロックする必要がない。
これらの利点により、以下のようにシステムで並列処理を向上させることができます。

例10.1 非同期 API の使用

Set<Future<?>> futures = new HashSet<Future<?>>();
futures.add(cache.putAsync("key1", "value1"));
futures.add(cache.putAsync("key2", "value2"));
futures.add(cache.putAsync("key3", "value3"));
たとえば、以下の行は実行時にスレッドをブロックしません。
  • futures.add(cache.putAsync(key1, value1));
  • futures.add(cache.putAsync(key2, value2));
  • futures.add(cache.putAsync(key3, value3));
これら 3 つの put 操作からのリモートコールは同時に実行されます。これは、分散モードで実行する場合に特に役に立ちます。

10.2. 非同期プロセスについて

Red Hat JBoss Data Grid の一般的な書き込み操作では、以下のプロセスがクリティカルパスで失敗し、リソースが最も必要なものから必要でないものに順序付けされます。
  • ネットワークコール
  • マーシャリング
  • キャッシュストアへの書き込み (オプション)
  • ロック
JBoss Data Grid では、非同期メソッドを使用すると、クリティカルパスからネットワークコールとマーシャリングが削除されます。

10.3. 戻り値と非同期 API

非同期 API が Red Hat JBoss Data Grid で使用された場合、クライアントコードでは以前の値を問い合わせるために非同期操作が Future または NotifyingFuture を返す必要があります。

注記

NotifyingFutures は、JBoss Data Grid ライブラリーモードでのみ利用できます。
非同期操作の結果を取得するには、次の操作を呼び出します。この操作は呼び出されたときにスレッドをブロックします。
Future.get()

第11章 REST インターフェース

Red Hat JBoss Data Grid は、REST インターフェースを提供します。REST API の主な利点は、クライアントとサーバー間で疎結合が可能になることです。クライアントライブラリーおよびバインディングの特定のバージョンに対する依存性がなくなります。REST API によりオーバーヘッドが発生し、REST クライアントまたはカスタムコードが REST コールを認識し、作成する必要があります。
JBoss Data Grid の REST API と対話するには、HTTP クライアントライブラリーのみが必要です。Java の場合は、Apache HTTP Commons Client が推奨されます。または、java.net API を使用できます。

11.1. Ruby クライアントコード

以下のコードは ruby を使用して Red Hat JBoss Data Grid REST API と対話する例です。提供されたコードは特別なライブラリーを必要とせず、標準的な net/HTTP ライブラリーで十分です。

例11.1 Ruby での REST API の使用

require 'net/http'

http = Net::HTTP.new('localhost', 8080)

#An example of how to create a new entry

http.post('/rest/MyData/MyKey', 'DATA_HERE', {"Content-Type" => "text/plain"})

#An example of using a GET operation to retrieve the key

puts http.get('/rest/MyData/MyKey').body

#An Example of using a PUT operation to overwrite the key

http.put('/rest/MyData/MyKey', 'MORE DATA', {"Content-Type" => "text/plain"})

#An example of Removing the remote copy of the key

http.delete('/rest/MyData/MyKey')

#An example of creating binary data

http.put('/rest/MyImages/Image.png', File.read('/Users/michaelneale/logo.png'), {"Content-Type" => "image/png"})

11.2. Ruby のサンプルで JSON を使用

要件

ruby で JavaScript Object Notation (JSON) を使用して Red Hat JBoss Data Grid の REST インターフェースと対話するために、JSON Ruby をインストールし (プラットフォームのパッケージマネージャーに問い合わせるか、Ruby ドキュメンテーションを参照)、以下のコードを使用して要件を宣言します。

require 'json'
Ruby で JSON を使用

以下のコードは、Ruby で JavaScript Object Notation (JSON) と PUT 関数を使用して特定のデータ (この場合は、個人の名前と年齢) を送信する例です。

data = {:name => "michael", :age => 42 }
http.put('/infinispan/rest/Users/data/0', data.to_json, {"Content-Type" => "application/json"})

11.3. Python クライアントコード

以下のコードは Python を使用して Red Hat JBoss Data Grid REST API と対話する例です。提供されたコードは、標準的な HTTP ライブラリーのみを必要とします。

例11.2 Python での REST API の使用

import httplib  

#How to insert data

conn = httplib.HTTPConnection("localhost:8080")
data = "SOME DATA HERE \!" #could be string, or a file...
conn.request("POST", "/rest/Bucket/0", data, {"Content-Type": "text/plain"})
response = conn.getresponse()
print response.status

#How to retrieve data

import httplib
conn = httplib.HTTPConnection("localhost:8080")
conn.request("GET", "/rest/Bucket/0")
response = conn.getresponse()
print response.status
print response.read()

11.4. Java クライアントコード

以下のコードは Java を使用して Red Hat JBoss Data Grid REST API と対話する例です。

例11.3 インポートの定義

import java.io.BufferedReader;import java.io.IOException;
import java.io.InputStreamReader;import java.io.OutputStreamWriter;
import java.net.HttpURLConnection;import java.net.URL;

例11.4 文字列値をキャッシュに追加

public class RestExample {

   /**
    * Method that puts a String value in cache.
    * @param urlServerAddress
    * @param value
    * @throws IOException
    */                        

   public void putMethod(String urlServerAddress, String value) throws IOException {
      System.out.println("----------------------------------------");
      System.out.println("Executing PUT");
      System.out.println("----------------------------------------");
      URL address = new URL(urlServerAddress);
      System.out.println("executing request " + urlServerAddress);
      HttpURLConnection connection = (HttpURLConnection) address.openConnection();
      System.out.println("Executing put method of value: " + value);
      connection.setRequestMethod("PUT");
      connection.setRequestProperty("Content-Type", "text/plain");
      connection.setDoOutput(true);

      OutputStreamWriter outputStreamWriter = new OutputStreamWriter(connection.getOutputStream());
      outputStreamWriter.write(value);
         
      connection.connect();
      outputStreamWriter.flush();
       
      System.out.println("----------------------------------------");
      System.out.println(connection.getResponseCode() + " " + connection.getResponseMessage());
      System.out.println("----------------------------------------");
         
      connection.disconnect();
   }
以下のコードは、JBoss Data Grid REST インターフェースと対話するために Java を使用して URL に指定された値を読み取るメソッドの例です。

例11.5 キャッシュから文字列値を取得

   /**
    * Method that gets an value by a key in url as param value.
    * @param urlServerAddress
    * @return String value
    * @throws IOException
    */
   public String getMethod(String urlServerAddress) throws IOException {
      String line = new String();
      StringBuilder stringBuilder = new StringBuilder();

      System.out.println("----------------------------------------");
      System.out.println("Executing GET");
      System.out.println("----------------------------------------");

      URL address = new URL(urlServerAddress);
      System.out.println("executing request " + urlServerAddress);

      HttpURLConnection connection = (HttpURLConnection) address.openConnection();
      connection.setRequestMethod("GET");
      connection.setRequestProperty("Content-Type", "text/plain");
      connection.setDoOutput(true);

      BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(connection.getInputStream()));

      connection.connect();

      while ((line = bufferedReader.readLine()) != null) {
         stringBuilder.append(line + '\n');
      }

      System.out.println("Executing get method of value: " + stringBuilder.toString());

      System.out.println("----------------------------------------");
      System.out.println(connection.getResponseCode() + " " + connection.getResponseMessage());
      System.out.println("----------------------------------------");

      connection.disconnect();

      return stringBuilder.toString();
   }

例11.6 Java Main メソッドの使用

/**
    * Main method example.
    * @param args
    * @throws IOException
    */
public static void main(String[] args) throws IOException {
//Note that the cache name is "cacheX"
RestExample restExample = new RestExample();
restExample.putMethod("http://localhost:8080/rest/cacheX/1", "Infinispan REST Test");
restExample.getMethod("http://localhost:8080/rest/cacheX/1");   
   }
}
}

11.5. REST インターフェースコネクター

Red Hat JBoss Data Grid は、以下の 3 つのコネクタータイプをサポートします。
  • Hot Rod ベースコネクターの設定を定義する hotrod-connector 要素。
  • memcached ベースコネクターの設定を定義する memcached-connector 要素。
  • REST インターフェースベースのコネクターの設定を定義する rest-connector 要素。
コネクターの宣言により、<socket-binding-group /> 内で宣言されたソケットバインディングを使用し、local コンテナーで宣言されたキャッシュを公開し、他のすべての設定でデフォルト値を使用して Hot Rod、Memcached、または REST サーバーが有効になります。以下の例は、Hot Rod、Memcached、および REST サーバーに接続する方法を示しています。
REST コネクターは、Web サブシステムを必要とするため、Hot Rod と Memcached とは異なります。したがって、ソケットバインディング、ワーカースレッド、タイムアウトなどの設定は、Web サブシステムで実行する必要があります。以下により、REST サーバーが有効になります。
<rest-connector virtual-server="default-host" cache-container="local" security-domain="other" auth-method="BASIC"/>
詳細については、「REST インターフェースの使用」を参照してください。

11.5.1. REST コネクターの設定

次の手順を使用して、Red Hat JBoss Data Grid のリモートクライアントサーバーモードで rest-connector 要素を設定します。

手順11.1 リモートクライアントサーバーモード用 REST コネクターの設定

rest-connector 要素は、REST コネクターの設定情報を指定します。
  1. virtual-server パラメーター

    virtual-server パラメーターは、REST コネクターで使用される仮想サーバーを指定します。このパラメーターのデフォルト値は default-host です。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
       <rest-connector virtual-server="default-host" />
    </subsystem>
  2. cache-container パラメーター

    cache-container パラメーターは、REST コネクターで使用されるキャッシュコンテナーを指定します。これは必須パラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
       <rest-connector virtual-server="default-host"
                     cache-container="local" />
    </subsystem>
  3. context-path パラメーター

    context-path パラメーターは、REST コネクターのコンテキストパスを指定します。このパラメーターのデフォルト値は空の文字列 ("") です。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
       <rest-connector virtual-server="default-host"
                     cache-container="local"
                     context-path="${CONTEXT_PATH}" />
    </subsystem>
  4. security-domain パラメーター

    security-domain パラメーターは、REST エンドポイントへのアクセスを認証するためにセキュリティーサブシステムで宣言された指定済みドメインを使用することを指定します。これはオプションパラメーターです。このパラメーターが省略されると、認証は実行されません。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
       <rest-connector virtual-server="default-host"
                     cache-container="local"
                     context-path="${CONTEXT_PATH}"
                     security-domain="${SECURITY_DOMAIN}" />
    </subsystem>
  5. auth-method パラメーター

    auth-method パラメーターは、エンドポイントのクレデンシャルを取得するために使用するメソッドを指定します。このパラメーターのデフォルト値は BASIC です。サポートされる別の値には BASICDIGEST、および CLIENT-CERT があります。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
       <rest-connector virtual-server="default-host"
                     cache-container="local"
                     context-path="${CONTEXT_PATH}"
                     security-domain="${SECURITY_DOMAIN}"
                     auth-method="${METHOD}"  />
    </subsystem>
  6. security-mode パラメーター

    security-mode パラメーターは、書き込み操作 (PUT、POST、DELETE など) または読み取り操作 (GET や HEAD など) に対してのみ認証が必要かどうかを指定します。このパラメーターの有効な値は WRITE (書き込み操作のみを認証する場合) または READ_WRITE (読み書き操作を認証する場合) です。このパラメーターのデフォルト値は READ_WRITE です。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
       <rest-connector virtual-server="default-host"
                     cache-container="local"
                     context-path="${CONTEXT_PATH}"
                     security-domain="${SECURITY_DOMAIN}"
                     auth-method="${METHOD}" 
                     security-mode="${MODE}" /> 
    </subsystem>

11.6. REST インターフェースの使用

REST インターフェースを Red Hat JBoss Data Grid のリモートクライアントサーバーモードで使用して、以下の操作を実行できます。
  • データの追加
  • データの取得
  • データの削除

11.6.1. REST を使用したデータの追加

Red Hat JBoss Data Grid の REST インターフェースで、以下のメソッドを使用してキャッシュにデータを追加します。
  • HTTP PUT メソッド
  • HTTP POST メソッド
PUT メソッドと POST メソッドが使用される場合、要求の本文には、ユーザーにより追加された情報を含むこのデータが含まれます。
PUT メソッドと POST メソッドの両方には、Content-Type ヘッダーが必要です。

11.6.1.1. PUT /{cacheName}/{cacheKey} について

提供された URL フォームからの PUT 要求により、提供されたキーを使用して要求本文からのペイロードがターゲットキャッシュに配置されます。このタスクが正常に完了するには、ターゲットキャッシュがサーバに存在する必要があります。
例として、以下の URL では、値 hr がキャッシュ名であり、payRoll%2F3 がキーです。値 %2F は、/ がキーで使用されたことを示します。
http://someserver/rest/hr/payRoll%2F3
既存のデータは置き換えられ、更新が必要な場合は Time-To-Live 値と Last-Modified 値が更新されます。

注記

以下の引数を使用してサーバーが起動された場合は、キーの / を表す値 %2F を含むキャッシュキー (提供された例を参照) を正常に実行できます。
-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

11.6.1.2. POST /{cacheName}/{cacheKey} について

提供された URL フォームからの POST メソッドにより、提供されたキーを使用して (要求本文からの) ペイロードがターゲットキャッシュに配置されます。ただし、POST メソッドでは、値がキャッシュ/キーに存在する場合に、HTTP CONFLICT ステータスが返され、内容が更新されません。

11.6.2. REST を使用したデータの取得

Red Hat JBoss Data Grid の REST インターフェースで、以下のメソッドを使用してキャッシュからデータを取得します。
  • HTTP GET メソッド。
  • HTTP HEAD メソッド。

11.6.2.1. GET /{cacheName}/{cacheKey} について

GET メソッドは、応答の本文として、提供された cacheName に存在し、関連するキーに一致するデータを返します。Content-Type ヘッダーは、データのタイプを提供します。ブラウザーはキャッシュに直接アクセスできます。
各エントリーに対して、要求された URL でデータの状態を示す Last-Modified ヘッダーとともに一意のエンティティータグ (ETag) が返されます。ETag により、ブラウザー (および他のクライアント) は、(帯域幅を節約するために) データが変更された場合のみデータを要求できます。ETag は、HTTP 標準の一部であり、Red Hat JBoss Data Grid によりサポートされます。
格納されたコンテンツのタイプは、返されたタイプです。例として、文字列が格納された場合は、文字列が返されます。シリアライズされた形式で格納されたオブジェクトは、手動でシリアライズ解除する必要があります。

11.6.2.2. HEAD /{cacheName}/{cacheKey} について

HEAD メソッドは、GET メソッドと同様に動作しますが、コンテンツを返しません (ヘッダーフィールドが返されます)。

11.6.3. REST を使用したデータの削除

REST インターフェースを使用して Red Hat JBoss Data Grid からデータを削除するには、HTTP DELETE メソッドを使用してキャッシュからデータを取得します。DELETE メソッドは以下のことを行えます。
  • キャッシュエントリー/値を削除します。(DELETE /{cacheName}/{cacheKey})
  • キャッシュからすべてのエントリーを削除します。(DELETE /{cacheName})

11.6.3.1. DELETE /{cacheName}/{cacheKey} について

このコンテキスト (DELETE /{cacheName}/{cacheKey}) で使用された場合は、DELETE メソッドは提供されたキーのキャッシュからキー/値を削除します。

11.6.3.2. DELETE /{cacheName} について

このコンテキスト (DELETE /{cacheName}) では、DELETE メソッドが名前付きキャッシュ内のすべてのエントリーを削除します。正常な DELETE 操作後に、HTTP ステータスコード 200 が返されます。

11.6.3.3. バックグラウンド削除操作

performAsync ヘッダーの値を true に設定して、削除操作がバックグラウンドで続行される状態で値がすぐに返されるようにします。

11.6.4. REST インターフェース操作ヘッダー

以下の表は、Red Hat JBoss Data Grid REST インターフェースに含まれるヘッダーを示しています。

表11.1 ヘッダータイプ

ヘッダー 必須/オプション デフォルト値 説明
Content-Type 必須 - - Content-Type が application/x-java-serialized-object に設定された場合は、Java オブジェクトとして格納されます。
performAsync 任意 true/false - true に設定された場合は、すぐに返され、独自にクラスターにデータがレプリケートされます。この機能は、大量のデータ挿入と大きいクラスターを取り扱う場合に役に立ちます。
timeToLiveSeconds 任意 数値 (正の値および負の値) -1 (この値により、timeToLiveSeconds の直接的な結果としてエクスパレーションが回避されます。このデフォルト値よりも、他の場所で設定されたエクスパレーションの値が優先されます。) 該当するエントリーが自動的に削除されるまでの秒数を反映します。timeToLiveSeconds に負の値を設定すると、デフォルト値と同じ結果が提供されます。
maxIdleTimeSeconds 任意 数値 (正の値および負の値) -1 (この値により、maxIdleTimeSeconds の直接的な結果としてエクスパレーションが回避されます。このデフォルト値よりも、他の場所で設定されたエクスパレーションの値が優先されます。) エントリーが自動的に削除される場合の、最後の使用時以降の秒数を含みます。負の値を渡すと、デフォルト値と同じ結果が提供されます。
timeToLiveSeconds ヘッダーと maxIdleTimeSeconds ヘッダーには以下の組み合わせを設定できます。
  • timeToLiveSeconds ヘッダーと maxIdleTimeSeconds ヘッダーに値 0 が割り当てられた場合、キャッシュは、 XML を使用するか、またはプログラミングにより設定されたデフォルトの timeToLiveSeconds 値と maxIdleTimeSeconds 値を使用します。
  • maxIdleTimeSeconds ヘッダー値のみが 0 に設定された場合は、timeToLiveSeconds 値をパラメーター (または、デフォルトの -1 (パラメーターが存在しない場合)) として渡す必要があります。また、maxIdleTimeSeconds パラメーター値は、 XML を使用するか、プログラミングにより、設定された値にデフォルトで設定されます。
  • timeToLiveSeconds ヘッダー値のみが 0 に設定された場合は、エクスパレーションが即座に発生し、maxIdleTimeSeconds 値がパラメーターとして渡された値に設定されます (パラメーターが提供されなかった場合はデフォルトの -1)。
ETag ベースのヘッダー

各 REST インターフェースエントリーに対して、提供された URL でデータの状態を示す Last-Modified ヘッダーとともに、ETags (エンティティータグ) が返されます。ETags は、帯域幅を節約するためにデータが変更された場合にのみ、データを要求する HTTP 操作で使用されます。以下のヘッダーは、ETags (エンティティータグ) ベースの楽観的ロックをサポートします。

表11.2 エンティティータグ関連ヘッダー

Header アルゴリズム 説明
If-Match If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) - (リソースから以前に取得された) 指定されたエンティティーが最新であることを確認するために、関連するエンティティータグのリストとともに使用されます。
If-None-Match - (リソースから以前に取得された) 指定されたエンティティーが最新でないことを確認するために、関連するエンティティータグのリストとともに使用されます。この機能により、必要なときに、最小のトランザクションオーバーヘッドで、キャッシュされた情報が効率的に更新されます。
If-Modified-Since If-Modified-Since = "If-Modified-Since" ":" HTTP-date If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 要求されたバリアントの最終変更日時と、提供された時間および日付の値とを比較します。指定された日時以降に要求されたバリアントが変更されなかった場合は、エンティティーの代わりに 304 (未変更) 応答がメッセージ本文なしで返されます。
If-Unmodified-Since If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 要求されたバリアントの最終変更日時と、提供された時間および日付の値とを比較します。指定された日時以降に要求されたリソースが変更されなかった場合は、指定された操作が実行されます。指定された日時以降に要求されたリソースが変更された場合は、操作が実行されず、エンティティーの代わりに 412 (事前条件失敗) 応答が返されます。

11.7. REST インターフェースセキュリティー

11.7.1. REST エンドポイントをパブリックインターフェースとして公開

Red Hat JBoss Data Grid の REST サーバーはデフォルトで管理インターフェースとして動作します。操作をパブリックインターフェースに拡張するには、以下のように、managementsocket-binding 要素の interface パラメーターの値を public に変更します。
<socket-binding name="http" interface="public" port="8080"/>

11.7.2. REST エンドポイントのセキュリティーの有効化

以下の手順を使用して、Red Hat JBoss Data Grid で REST エンドポイントのセキュリティーを有効にします。

注記

REST エンドポイントは、JBoss Enterprise Application Platform のセキュリティーサブシステムプロバイダーのいずれかをサポートします。

手順11.2 REST エンドポイントのセキュリティーの有効化

REST インターフェースを使用する場合に JBoss Data Grid のセキュリティーを有効にするには、standalone.xml に以下の変更を行います。
  1. セキュリティーパラメーターの指定

    rest エンドポイントで security-domain パラメーターおよび auth-method パラメーターの有効な値を指定するようにします。これらのパラメーターの推奨設定は以下のとおりです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
                <rest-connector virtual-server="default-host" 
                                cache-container="local" 
                                security-domain="other" 
                                auth-method="BASIC"/>
    </subsystem>
  2. セキュリティードメイン宣言のチェック

    セキュリティーサブシステムに、対応するセキュリティードメイン宣言が含まれるようにします。セキュリティードメイン宣言の設定の詳細については、JBoss Enterprise Application Platform 6 ドキュメンテーションを参照してください。
  3. アプリケーションユーザーの追加

    該当するスクリプトを実行し、アプリケーションユーザーを追加する設定を入力します。
    1. adduser.sh スクリプト ($JDG_HOME/bin に存在) を実行します。
      • Windows システムでは、adduser.bat ファイル ($JDG_HOME/bin に存在) を代わりに実行します。
    2. 追加するユーザーのタイプについて尋ねられたら、b を入力して Application User (application-users.properties) を選択します。
    3. リターンキーを押して、レルム (ApplicationRealm) のデフォルト値を使用します。
    4. ユーザー名とパスワードを指定します。
    5. 作成されたユーザーのロールを尋ねられたら、REST と入力します。
    6. プロンプトが表示されたら、ユーザー名とアプリケーションレルム情報が正しいことを確認し、"yes" と入力して作業を続行します。
  4. 作成されたアプリケーションユーザーの確認

    作成されたアプリケーションユーザーが正しく設定されていることを確認します。
    1. application-users.properties ファイル ($JDG_HOME/standalone/configuration/ に存在) にリストされた設定を確認します。以下は、このファイルの正しい設定の例です。
      user1=2dc3eacfed8cf95a4a31159167b936fc
    2. application-roles.properties ファイル ($JDG_HOME/standalone/configuration/ に存在) にリストされた設定を確認します。以下は、このファイルの正しい設定の例です。
      user1=REST
  5. サーバーのテスト

    サーバーを起動し、ブラウザーウィンドウに以下のリンクを入力して REST エンドポイントにアクセスします。
    http://localhost:8080/rest/namedCache

    注記

    GET 要求の使用をテストする場合は、405 応答コードが期待され、サーバーが正常に認証されたことが示されます。

第12章 Memcached インターフェース

Memcached は、データベース駆動 Web サイトの応答時間と操作時間を改善するために使用されるインメモリーキャッシングシステムです。Memcached キャッシングシステムは、Memached プロトコルと呼ばれるテキストベースのクライアントサーバーキャッシングプロトコルを定義します。Memcached プロトコルはインメモリーオブジェクトを使用するか、(最後の手段として) 特殊な memcached データベースなどの永続ストアに渡されます。
Red Hat JBoss Data Grid は、Memcached プロトコルを使用するサーバーを提供し、JBoss Data Grid と別に Memcached を使用する必要はありません。また、JBoss Data Grid のクラスタリング機能により、データフェールオーバー機能は Memcached で提供されるものよりも優れています。

12.1. Memcached サーバーについて

Red Hat JBoss Data Grid には、memcached プロトコルを実装するサーバーモジュールが含まれます。これにより、memcached クライアントは1 つまたは複数の JBoss Data Grid ベース memcached サーバーと対話できるようになります。
サーバーは以下のいずれかになります。
  • スタンドアロン。各サーバーは、他の memcached サーバーと通信せずに独立して動作します。
  • クラスター。サーバーはデータを他の memcached サーバーにレプリケートおよび分散します。

12.2. memcached 統計

以下の表には、Red Hat JBoss Data Grid で memcached プロトコルを使用して利用できる有効な統計のリストが含まれます。

表12.1 memcached 統計

統計 データタイプ 説明
アップタイム 32 ビット符号なし整数。 memcached インスタンスが利用可能であり、実行されている時間 (秒数単位) を含みます。
時間 32 ビット符号なし整数。 現在の時間を含みます。
version 文字列 現在のバージョンを含みます。
curr_items 32 ビット符号なし整数。 インスタンスが現在格納しているアイテムの数を含みます。
total_items 32 ビット符号なし整数。 存続期間中にインスタンスにより格納されたアイテムの合計数を含みます。
cmd_get 64 ビット符号なし整数 get 操作要求 (データ取得要求) の合計数を含みます。
cmd_set 64 ビット符号なし整数 設定された操作要求 (データ格納要求) の合計数を含みます。
get_hits 64 ビット符号なし整数 要求されたキーにあるキーの数を含みます。
get_misses 64 ビット符号なし整数 要求されたキーにないキーの数を含みます。
delete_hits 64 ビット符号なし整数 削除するキー (特定され正常に削除されたキー) の数を含みます。
delete_misses 64 ビット符号なし整数 削除するキー (特定されず、削除できなかったキー) の数を含みます。
incr_hits 64 ビット符号なし整数 増分するキー (特定され正常に増分されたキー) の数を含みます。
incr_misses 64 ビット符号なし整数 増分するキー (特定されず、増分できなかったキー) の数を含みます。
decr_hits 64 ビット符号なし整数 減分するキー (特定され正常に減分されたキー) の数を含みます。
decr_misses 64 ビット符号なし整数 減分するキー (特定されず、減分できなかったキー) の数を含みます。
cas_hits 64 ビット符号なし整数 比較し、スワップするキー (特定され正常に比較およびスワップされたキー) の数を含みます。
cas_misses 64 ビット符号なし整数 比較し、スワップするキー (特定されず、比較およびスワップされなかったキー) の数を含みます。
cas_badval 64 ビット符号なし整数 比較およびスワップが行われたが、元の値が提供された値に一致しなかったキーの数を含みます。
evictions 64 ビット符号なし整数 実行されたエビクションコールの数を含みます。
bytes_read 64 ビット符号なし整数 ネットワークからサーバーが読み取ったバイトの合計数を含みます。
bytes_written 64 ビット符号なし整数 ネットワークからサーバーが書き込んだバイトの合計数を含みます。

12.3. Memcached インターフェースコネクター

Red Hat JBoss Data Grid は、以下の 3 つのコネクタータイプをサポートします。
  • Hot Rod ベースコネクターの設定を定義する hotrod-connector 要素。
  • memcached ベースコネクターの設定を定義する memcached-connector 要素。
  • REST インターフェースベースのコネクターの設定を定義する rest-connector 要素。
コネクターの宣言により、<socket-binding-group /> 内で宣言されたソケットバインディングを使用し、local コンテナーで宣言されたキャッシュを公開し、他のすべての設定でデフォルト値を使用して Hot Rod、Memcached、または REST サーバーが有効になります。以下の例は、Hot Rod、Memcached、および REST サーバーに接続する方法を示しています。
以下により、memcached ソケットバインディングを使用して Memcached サーバーが有効になり、local コンテナーで宣言された memcachedCache キャッシュが公開され、他のすべての設定にデフォルト値が使用されます。
<memcached-connector socket-binding="memcached" cache-container="local"/>
Memcached プロトコルの制限のため、1 つのコネクター公開できるキャッシュは 1 つだけです。複数のキャッシュを公開するには、異なるソケットバインディングで追加の memcached コネクターを宣言します。「Memcached コネクターの設定」を参照してください。

12.3.1. Memcached コネクターの設定

以下の手順は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードの connectors 要素内にある memcached コネクターを設定するために使用する属性を示しています。

手順12.1 リモートクライアントサーバーモードでの Memcached コネクターの設定

memcached-connector 要素は、memcached で使用する設定要素を定義します。
  1. socket-binding パラメーター

    socket-binding パラメーターは、memcached コネクターで使用されるソケットバインディングポートを指定します。これは必須パラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" />
  2. cache-container パラメーター

    cache-container パラメーターは、memcached コネクターで使用されるキャッシュコンテナーを指定します。これは必須パラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" 
                         cache-container="local" />
  3. worker-threads パラメーター

    worker-threads パラメーターは、memcached コネクターで利用可能なワーカースレッドの数を指定します。このパラメーターのデフォルト値は、160 です。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" 
                         cache-container="local" 
                         worker-threads="${VALUE}" />
  4. idle-timeout パラメーター

    idle-timeout パラメーターは、接続がタイムアウトするまでコネクターがアイドル状態のままになる時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は -1 です (タイムアウト期間が設定されません)。これは、オプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" 
                         cache-container="local" 
                         worker-threads="${VALUE}" 
                         idle-timeout="${VALUE}" />
  5. tcp-nodelay パラメーター

    tcp-no-delay パラメーターは、TCP パケットが遅延され一括して送信されるかを指定します。このパラメーターの有効な値は truefalse になります。このパラメーターのデフォルト値は、true です。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" 
                         cache-container="local" 
                         worker-threads="${VALUE}" 
                         idle-timeout="{VALUE}"
                         tcp-nodelay="{TRUE/FALSE}"/>
  6. send-buffer-size パラメーター

    send-buffer-size パラメーターは、memcached コネクターの送信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" 
                         cache-container="local" 
                         worker-threads="${VALUE}" 
                         idle-timeout="{VALUE}"
                         tcp-nodelay="{TRUE/FALSE}" 
                         send-buffer-size="{VALUE}" />
  7. receive-buffer-size パラメーター

    receive-buffer-size パラメーターは、memcached コネクターの受信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
    <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
    <memcached-connector socket-binding="memcached" 
                         cache-container="local" 
                         worker-threads="${VALUE}" 
                         idle-timeout="{VALUE}"
                         tcp-nodelay="{TRUE/FALSE}" 
                         send-buffer-size="{VALUE}" 
                         receive-buffer-size="${VALUE}" />
    </subsystem>

12.4. Memcached インターフェースセキュリティー

12.4.1. Memcached エンドポイントをパブリックインターフェースとして公開

Red Hat JBoss Data Grid の memcached サーバーはデフォルトで管理インターフェースとして動作します。操作をパブリックインターフェースに拡張するには、以下のように、managementsocket-binding 要素の interface パラメーターの値を public に変更します。
<socket-binding name="memcached" interface="public" port="11211" />

第13章 Hot Rod インターフェース

13.1. Hot Rod について

Hot Rod は、Red Hat JBoss Data Grid で使用されるバイナリー TCP クライアントサーバープロトコルであり、Memcached などの他のクライアントサーバープロトコルの欠点を解消するために作成されました。
Hot Rod はサーバークラスターでフェールオーバーを行い、トポロジーが変更されます。Hot Rod は、クラスタートポロジーに関する更新をクライアントに定期的に提供することによりこれを行います。
Hot Rod では、クライアントはパーティション化された、または分散された JBoss Data Grid サーバークラスターで要求をスマートにルーティングできます。これを行うために、Hot Rod ではクライアントはキーを格納するパーティションを決定し、キーがあるサーバーと直接通信できます。この機能は、クライアントでクラスタートポロジーを更新する Hot Rod に依存し、クライアントはサーバーと同じ一貫性のあるハッシュアルゴリズムを使用します。
JBoss Data Grid には、Hot Rod プロトコルを実装するサーバーモジュールが含まれます。Hot Rod プロトコルを使用すると、他のテキストベースのプロトコルに比べて、クライアントとサーバーの対話が促進され、クライアントが負荷分散、フェールオーバー、およびデータ場所運用に関する決定を行えるようになります。

13.2. Memcached ではなく Hot Rod を使用する利点

Red Hat JBoss Data Grid は、クライアントがリモートクライアントサーバー環境のサーバーと対話することを可能にするプロコトルを提供します。memcached または Hot Rod のいずれを使用するか決定する場合は、以下のことを考慮する必要があります。
Memcached
memcached プロコトルでは、サーバーエンドポイントが memcached text wire protocol を使用します。memcached wire protocol の利点は、一般的に使用されていることであり、これはほとんどのプラットフォームで利用できます。memcached を使用する場合は、クラスタリング、スケーラビリティの状態共有、および高可用性を含む JBoss Data Grid のすべての機能を利用できます。
ただし、memcached プロトコルには dynamicity がなく、クラスタのいずれかのノードで障害が発生したときにクライアント上のサーバーノードのリストを手動で更新する必要があります。また、memcached クライアントはクラスタのデータの場所を認識しません。つまり、クライアントは非所有者のノードからデータを要求し、データをクライアントに返す前に、そのノードから実際の所有者への追加の要求のペナルティーが発生します。この結果、Hot Rod プロトコルは memcached よりも優れたパフォーマンスを提供できます。
Hot Rod
JBoss Data Grid の Hot Rod プロトコルは、memcached のすべての機能を提供するバイナリーワイヤープロトコルであり、優れたスケーリング、持続性、および弾力性を提供します。
Hot Rod プロトコルは、リモートキャッシュで各ノードのホスト名とポートを必要としませんが、memcached ではこれらのパラメーターを指定する必要があります。Hot Rod クライアントはクラスタ化された Hot Rod サーバーのトポロジーの変更を自動的に検出します。新しいノードがクラスタに参加したり、クラスタから脱退したりすると、クライアントは Hot Rod サーバートポロジービューを更新します。この結果、Hot Rod では、設定と保守が容易になり、動的なロードバランシングとフェイルオーバーの利点が提供されます。
また、Hot Rod ワイヤープロトコルは分散キャッシュに接続するときにスマートルーティングを使用します。この場合に、サーバーノードとクライアント間で一貫したハッシュアルゴリズムが共有され、memcached よりも高速な読み取りおよび書き込み機能が提供されます。

13.3. Hot Rod ハッシュ機能

Red Hat JBoss Data Grid のハッシュアルゴリズムは、一貫性のあるハッシュに基づきます。従来の一貫性のあるハッシュとは少し異なりますが、この実装には一貫性のあるハッシュという用語がまだ使われています。
汎用的な一貫性のあるハッシュとは異なり、JBoss Data Grid で使用される実装ではキー領域が固定セグメントに分割されます。セグメントの数は、numSegments を使用して設定でき、クラスターを再起動しても変更されません。キーとセグメントのマッピングも固定されます。クラスターのトポロジーがどのように変更するかに関係なく、キーは同じセグメントに対してマップされます。
各ハッシュセグメントはオーナーと呼ばれるノードのリストにマップされます。最初のオーナー (プライマリオーナーとも呼ばれます) は多くのキャッシュ操作 (ロックなど) で特殊な役割を担うため、この順序は重要です。他のオーナーはバックアップオーナーと呼ばれます。セグメントとオーナーのマッピングにはルールがありませんが、ハッシュアルゴリズムにより各ノードに割り当てられたセグメントの数が同時に分散され、ノードがクラスタに参加した後やクラスタから脱退した後に移動する必要があるセグメントの数が最小化されます。

13.4. Hot Rod インターフェースコネクター

Red Hat JBoss Data Grid は、以下の 3 つのコネクタータイプをサポートします。
  • Hot Rod ベースコネクターの設定を定義する hotrod-connector 要素。
  • memcached ベースコネクターの設定を定義する memcached-connector 要素。
  • REST インターフェースベースのコネクターの設定を定義する rest-connector 要素。
コネクターの宣言により、<socket-binding-group /> 内で宣言されたソケットバインディングを使用し、local コンテナーで宣言されたキャッシュを公開し、他のすべての設定でデフォルト値を使用して Hot Rod、Memcached、または REST サーバーが有効になります。以下の例は、Hot Rod、Memcached、および REST サーバーに接続する方法を示しています。
以下により、hotrod ソケットバインディングを使用して Hot Rod サーバーが有効になります。
<hotrod-connector socket-binding="hotrod" cache-container="local" />
コネクターは、サポートするトポロジーキャッシュをデフォルト設定で作成します。これらの設定は、以下のように <topology-state-transfer /> 子要素をコネクターに追加することにより、調整できます。
<hotrod-connector socket-binding="hotrod" cache-container="local">
   <topology-state-transfer lazy-retrieval="false" lock-timeout="1000" replication-timeout="5000" />
</hotrod-connector>
Hot Rod コネクターは追加の設定で調整できます。Hot Rod コネクターの設定方法の詳細については、「Hot Rod コネクターの設定」を参照してください。

注記

Hot Rod コネクターは SSL を使用してセキュアにできます。詳細については、『Developer Guide』 の 『Hot Rod Authentication Using SASL』 を参照してください。

13.4.1. Hot Rod コネクターの設定

次の手順は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードで Hot Rod コネクターを設定するために使用する属性を示しています。hotrod-connector 要素と topology-state-transfer 要素は、次の手順に基いて設定する必要があります。

手順13.1 リモートクライアントサーバーモード用 Hot Rod コネクターの設定

  1. hotrod-connector 要素

    hotrod-connector 要素は、Hot Rod で使用する設定要素を定義します。
    1. socket-binding パラメーター

      socket-binding パラメーターは、Hot Rod コネクターで使用されるソケットバインディングポートを指定します。これは必須パラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod" />
    2. cache-container パラメーター

      cache-container パラメーターは、Hot Rod コネクターで使用されるキャッシュコンテナーを指定します。これは必須パラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" />
    3. worker-threads パラメーター

      worker-threads パラメーターは、Hot Rod コネクターで利用可能なワーカースレッドの数を指定します。このパラメーターのデフォルト値は、160 です。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" />
    4. idle-timeout パラメーター

      idle-timeout パラメーターは、接続がタイムアウトするまでコネクターがアイドル状態のままになる時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は -1 です (タイムアウト期間が設定されません)。これは、オプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"/>
    5. tcp-nodelay パラメーター

      tcp-no-delay パラメーターは、TCP パケットが遅延され一括して送信されるかを指定します。このパラメーターの有効な値は truefalse になります。このパラメーターのデフォルト値は、true です。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" />
    6. send-buffer-size パラメーター

      send-buffer-size パラメーターは、Hot Rod コネクターの送信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" 
                              send-buffer-size="${VALUE}"/>
    7. receive-buffer-size パラメーター

      receive-buffer-size パラメーターは、Hot Rod コネクターの受信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
      subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" 
                              send-buffer-size="${VALUE}"
                              receive-buffer-size="${VALUE}"   />
  2. topology-state-transfer 要素

    topology-state-transfer 要素は、Hot Rod コネクターのトポロジー状態転送設定を指定します。この要素は hotrod-connector 要素内でのみ使用できます。
    1. lock-timeout パラメーター

      lock-timeout パラメーターは、ロックを取得しようとする操作がタイムアウトする時間を指定します。このパラメーターのデフォルト値は 10 秒です。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" 
                              send-buffer-size="${VALUE}"
                              receive-buffer-size="${VALUE}"   />
            <topology-state-transfer lock-timeout"="${MILLISECONDS}" />
    2. replication-timeout パラメーター

      replication-timeout パラメーターは、レプリケーション操作がタイムアウトする時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は 10 秒です。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" 
                              send-buffer-size="${VALUE}"
                              receive-buffer-size="${VALUE}"   />
            <topology-state-transfer lock-timeout"="${MILLISECONDS}" 
                                     replication-timeout="${MILLISECONDS}" />
    3. external-host パラメーター

      external-host パラメーターは、トポロジー情報にリストされたクライアントに Hot Rod サーバーが送信するホスト名を指定します。このパラメーターのデフォルト値は、ホストアドレスです。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" 
                              send-buffer-size="${VALUE}"
                              receive-buffer-size="${VALUE}"   />
            <topology-state-transfer lock-timeout"="${MILLISECONDS}" 
                                     replication-timeout="${MILLISECONDS}" 
                                     external-host="${HOSTNAME}" />
    4. external-port パラメーター

      external-port パラメーターは、トポロジー情報にリストされたクライアントに Hot Rod サーバーが送信するポートを指定します。このパラメーターのデフォルト値は、設定されたポートです。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
            <hotrod-connector socket-binding="hotrod"
                              cache-container="local" 
                              worker-threads="${VALUE}" 
                              idle-timeout="${VALUE}"
                              tcp-nodelay="${TRUE/FALSE}" 
                              send-buffer-size="${VALUE}"
                              receive-buffer-size="${VALUE}"   />
            <topology-state-transfer lock-timeout"="${MILLISECONDS}" 
                                     replication-timeout="${MILLISECONDS}" 
                                     external-host="${HOSTNAME}" 
                                     external-port="${PORT}" />
    5. lazy-retrieval パラメーター

      lazy-retrieval パラメーターは、Hot Rod コネクターが取得操作をレイジーに実行するかどうかを指定します。このパラメーターのデフォルト値は true です。これはオプションパラメーターです。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
      	<hotrod-connector socket-binding="hotrod" 
      			  cache-container="local" 
      			  worker-threads="${VALUE}" 
      			  idle-timeout="${VALUE}"
      			  tcp-nodelay="${TRUE/FALSE}"
      			  send-buffer-size="${VALUE}"
      			  receive-buffer-size="${VALUE}" />
      	<topology-state-transfer lock-timeout"="${MILLISECONDS}"
      				 replication-timeout="${MILLISECONDS}"
      				 external-host="${HOSTNAME}"
      				 external-port="${PORT}"
      				 lazy-retrieval="${TRUE/FALSE}" /> 
      </subsystem>
    6. await-initial-transfer パラメーター

      await-initial-transfer パラメーターは、初期状態の取得を起動時にすぐに行うかどうかを指定します。このパラメーターは、lazy-retrievalfalse に設定されている場合のみ適用されます。このパラメーターのデフォルト値は true です。
      <subsystem xmlns="urn:infinispan:server:endpoint:6.0">
      	<hotrod-connector socket-binding="hotrod" 
      			  cache-container="local" 
      			  worker-threads="${VALUE}" 
      			  idle-timeout="${VALUE}"
      			  tcp-nodelay="${TRUE/FALSE}"
      			  send-buffer-size="${VALUE}"
      			  receive-buffer-size="${VALUE}" />
      	<topology-state-transfer lock-timeout"="${MILLISECONDS}"
      				 replication-timeout="${MILLISECONDS}"
      				 external-host="${HOSTNAME}"
      				 external-port="${PORT}"
      				 lazy-retrieval="${TRUE/FALSE}" 
      				 await-initial-transfer="${TRUE/FALSE}" /> 
      </subsystem>

13.5. Hot Rod ヘッダー

13.5.1. Hot Rod ヘッダーデータタイプ

Red Hat JBoss Data Grid の Hot Rod で使用されたすべてのキーおよび値はバイトアレイとして格納されます。ただし、特定のヘッダー値 (REST や Memcached の値) は以下のデータタイプを使用して格納されます。

表13.1 ヘッダーデータタイプ

データタイプ サイズ 説明
vInt 1〜5 バイト。 符号なし可変長整数値。
vLong 1〜9 バイト。 符号なし可変長ロング値。
文字列 - 文字列は常に UTF-8 エンコーディングを使用して表されます。

13.5.2. 要求ヘッダー

Hot Rod を使用して Red Hat JBoss Data Grid にアクセスする場合、要求ヘッダーの内容は以下のものから構成されます。

表13.2 要求ヘッダーフィールド

フィールド名 データタイプ/サイズ 説明
Magic 1 バイト ヘッダーが要求ヘッダーまたは応答ヘッダーであるかどうかを示します。
Message ID vLong メッセージ ID を含みます。この一意の ID は、要求に応答するときに使用されます。これにより、Hot Rod クライアントは非同期でプロトコルを実装できるようになります。
Version 1 バイト Hot Rod サーバーバージョンを含みます。
Opcode 1 バイト 関連する操作コードを含みます。要求ヘッダー内でopcode には要求操作コードのみを含めることができます。
Cache Name Length vInt キャッシュ名の長さを格納します。キャッシュ名の長さが 0 に設定され、キャッシュ名に値が提供されない場合、操作はデフォルトのキャッシュと対話します。
Cache Name 文字列 指定された操作のターゲットキャッシュの名前を格納します。この名前は、キャッシュ設定ファイルの事前定義済みキャッシュの名前に一致する必要があります。
Flags vInt システムに渡されるフラグを表す可変長の数値を含みます。さらに多くのバイトを読み取る必要があるかどうかを決定するために使用される最大ビットを除き、各ビットはフラグを表します。各フラグを表すためにビットを使用すると、フラグの組み合わせが連結された状態で表されます。
Client Intelligence 1 バイト サーバーに対するクライアント機能を示す値を含みます。
Topology ID vInt クライアントの最後の既知なビュー ID を含みます。基本的なクライアントはこのフィールドに値 0 を提供します。トポロジーまたはハッシュ情報をサポートするクライアントは、サーバーが現在のビュー ID に応答するまで値 0 (新しいビュー ID が現在のビュー ID を置き換えるためにサーバーにより返されるまで使用されます) を提供します。
Transaction Type 1 バイト 2 つの既知のトランザクションタイプのいずれかを表す値を含みます。現時点でサポートされている値は 0 のみです。
Transaction ID バイトアレイ 呼び出しに関連するトランザクションを一意に識別するバイトアレイを含みます。トランザクションタイプはこのバイトアレイの長さを決定します。Transaction Type の値が 0 に設定された場合、トランザクション ID は存在しません。

13.5.3. 応答ヘッダー

Hot Rod を使用して Red Hat JBoss Data Grid にアクセスする場合、応答ヘッダーの内容は以下のものから構成されます。

表13.3 応答ヘッダーフィールド

フィールド名 データタイプ 説明
Magic 1 バイト ヘッダーが要求または応答ヘッダーであるかどうかを示します。
Message ID vLong メッセージ ID を含みます。この一意の ID は、応答を元の要求とペアにするために使用されます。これにより、Hot Rod クライアントは非同期でプロトコルを実装できるようになります。
Opcode 1 バイト 関連する操作コードを含みます。応答ヘッダー内で opcode には応答操作コードのみを含めることができます。
Status 1 バイト 応答のステータスを表すコードを含みます。
Topology Change Marker 1 バイト 応答がトポロジー変更情報に含まれるかどうかを示すマーカーバイトを含みます。

13.5.4. トポロジー変更ヘッダー

Hot Rod を使用して Red Hat JBoss Data Grid にアクセスする場合は、応答ヘッダーが、異なるトポロジーまたはハッシュ配布を区別できるクライアントを探すことによりクラスターまたはビューフォーメーションの変更に応答します。Hot Rod サーバーは現在の topology ID と、クライアントにより送信された topology ID を比較し、2 つの値が異なる場合は、新しい topology ID を返します。

13.5.4.1. トポロジー変更マーカー値

以下は、応答ヘッダー内の Topology Change Marker フィールドの有効な値のリストです。

表13.4 Topology Change Marker フィールド値

説明
0 トポロジーの変更情報は追加されません。
1 トポロジーの変更情報が追加されます。

13.5.4.2. トポロジー認識クライアントのトポロジー変更ヘッダー

トポロジーの変更がサーバーにより返された場合、トポロジー認識クライアントに送信された応答ヘッダーには以下の要素が含まれます。

表13.5 トポロジー変更ヘッダーフィールド

応答ヘッダーフィールド データタイプ/サイズ 説明
Response Header with Topology Change Marker - -
Topology ID vInt -
Num Servers in Topology vInt クラスターで稼働している Hot Rod サーバーの数を含みます。一部のノードのみが Hot Rod サーバーを稼働している場合に、この値は、クラスター全体のサブセットになることがあります。
mX: Host/IP Length vInt 個別クラスターメンバーのホスト名または IP アドレスの長さを含みます。可変長により、この要素にはホスト名、IPv4、および IPv6 アドレスを含めることができます。
mX: Host/IP Address 文字列 個別クラスターメンバーのホスト名または IP アドレスを含みます。Hot Rod クライアントはこの情報を使用して個別クラスターメンバーにアクセスします。
mX: Port 符号なしショート。2 バイト クラスターメンバーと通信するために Hot Rod クライアントが使用するポートを含みます。
トポロジー内の各サーバーに対して、接頭辞 mX の 3 つのエントリーが繰り返されます。トポロジーの情報フィールド内の最初のサーバーには接頭辞 m1 が付けられ、X の値が num servers in topology フィールドで指定されたサーバーの数と等しくなるまで、各追加サーバーに対して数値が 1 つずつ増分されます。

13.5.4.3. ハッシュ配布認識クライアントのトポロジー変更ヘッダー

トポロジーの変更がサーバーにより返された場合、クライアントに送信された応答ヘッダーには以下の要素が含まれます。

表13.6 トポロジー変更ヘッダーフィールド

フィールド データタイプ/サイズ 説明
Response Header with Topology Change Marker - -
Topology ID vInt -
Number Key Owners 符号なしショート、2 バイト 配布された各キーに対してグローバルに設定されたコピーの数を含みます。配布がキャッシュで設定されていない場合は、値 0 を含みます。
Hash Function Version 1 バイト 使用中のハッシュ機能へのポインターを含みます。配布がキャッシュで設定されていない場合は、値 0 を含みます。
Hash Space Size vInt ハッシュコード生成に関連するすべてのモジュール計算のために JBoss Data Grid により使用されるモジュールを含みます。クライアントはこの情報を使用して正しいハッシュ計算をキーに適用します。配布がキャッシュで設定されていない場合は、値 0 を含みます。
Number servers in topology vInt クラスター内で稼働している Hot Rod サーバーの数を含みます。一部のノードのみが Hot Rod サーバーを稼働している場合に、この値は、クラスター全体のサブセットになることがあります。また、この値はヘッダーに含まれるホストとポートのペアの数を表します。
Number Virtual Nodes Owners vInt 設定された仮想ノードの数を含みます。仮想ノードが設定されていない場合、または配布がキャッシュで設定されていない場合は、値 0 を含みます。
mX: Host/IP Length vInt 個別クラスターメンバーのホスト名または IP アドレスの長さを含みます。可変長により、この要素にはホスト名、IPv4、および IPv6 アドレスを含めることができます。
mX: Host/IP Address 文字列 個別クラスターメンバーのホスト名または IP アドレスを含みます。Hot Rod クライアントはこの情報を使用して個別クラスターメンバーにアクセスします。
mX: Port 符号なしショート、2 バイト クラスターメンバーと通信するために Hot Rod クライアントが使用するポートを含みます。
mX: Hashcode 4 バイト
トポロジー内の各サーバーに対して、接頭辞 mX の 3 つのエントリーが繰り返されます。トポロジーの情報フィールド内の最初のサーバーには接頭辞 m1 が付けられ、X の値が num servers in topology フィールドで指定されたサーバーの数と等しくなるまで、各追加サーバーに対して数値が 1 つずつ増分されます。

13.6. Hot Rod 操作

13.6.1. Hot Rod 操作

以下に、Hot Rod プロトコル 1.3 を使用して Red Hat JBoss Data Grid と対話する場合に有効な操作を示します。
  • BulkGetKeys
  • BulkGet
  • Clear
  • ContainsKey
  • Get
  • GetWithMetadata
  • Ping
  • PutIfAbsent
  • Put
  • Query
  • RemoveIfUnmodified
  • Remove
  • ReplaceIfUnmodified
  • Replace
  • Stats

13.6.2. Hot Rod BulkGetKeys 操作

Hot Rod BulkGetKeys 操作は、以下の要求形式を使用します。

表13.7 BulkGetKeys 操作の要求形式

フィールド データ型 説明
Header 変数 要求ヘッダー
Scope vInt
  • 0 = デフォルトのスコープ - このスコープは RemoteCache.keySet() メソッドにより使用されます。リモートキャッシュが分散キャッシュである場合は、サーバーによりマップ/削減操作が実行され、すべてのノードからすべてのキーが取得されます (トポロジー認識 Hot Rod クライアントはクラスター内の任意のノードへの要求を負荷分散できます)。それ以外の場合は、要求を受信するサーバーに対してローカルのキャッシュインスタンスからキーを取得します。キーはレプリケートされたキャッシュのすべてのノードで同じである必要があります。
  • 1 = グローバルスコープ - このスコープはデフォルトスコープと同じように動作します。
  • 2 = ローカルスコープ - リモートキャッシュが分散キャッシュである状況では、サーバーはマップ/削減操作を開始してすべてのノードからキーを取得しません。代わりに、要求を受け取るサーバーに対してローカルなキャッシュインスタンスからローカルなキーのみを取得します。
この操作の応答ヘッダーには、以下のいずれかの応答ステータスが含まれます。

表13.8 BulkGetKeys 操作の応答形式

フィールド データ型 説明
Header 変数 応答ヘッダー
Response status 1 バイト 0x00 = 成功 (データが続きます)。
More 1 バイト ストリームからより多くのキーを読み取る必要があるかを表す 1 つのバイト。1 に設定されている場合はエントリーが続き、0 に設定されている場合はストリームの最後であり、読み取るエントリーが残っていません。
Key 1 Length vInt キーの長さ
Key 1 バイトアレイ 取得されたキー
More 1 バイト -
Key 2 Length vInt -
Key 2 バイトアレイ -
...etc   

13.6.3. Hot Rod BulkGet 操作

Hot Rod BulkGet 操作は、以下の要求形式を使用します。

表13.9 BulkGet 操作要求形式

フィールド データ型 説明
Header - -
エントリー数 vInt サーバーにより返される Red Hat JBoss Data Grid エントリーの最大数が含まれます。エントリーはキーと値のペアです。
この操作の応答ヘッダーには、以下のいずれかの応答ステータスが含まれます。

表13.10 BulkGet 操作応答形式

フィールド データ型 説明
Header - -
詳細 vInt ストリームからエントリーをさらに読み取る必要があるかどうかを示します。More1 に設定される一方で、More の値が 0 (ストリームの最後を示します) に設定されるまで追加のエントリーが続きます。
キーサイズ - キーのサイズを含みます。
キー - キーの値を含みます。
値サイズ - 値のサイズを含みます。
- 値を含みます。
要求された各エントリーに対して、MoreKey SizeKeyValue Size、および Value エントリーが応答に追加されます。

13.6.4. Hot Rod clear 操作

clear 操作形式には、ヘッダーのみ含まれます。
この操作に有効な応答ステータスは以下のとおりです。

表13.11 clear 操作応答

応答ステータス 説明
0x00 Red Hat JBoss Data Grid が正常に消去されました。

13.6.5. Hot Rod ContainsKey 操作

Hot Rod ContainsKey 操作は、以下の要求形式を使用します。

表13.12 ContainsKey 操作要求形式

フィールド データ型 説明
Header - -
キーの長さ vInt キーの長さを含みます。Integer.MAX_VALUE のサイズよりも大きいサイズ (最大 5 バイト) のため、vInt データタイプが使用されます。ただし、Java では、単一アレイサイズを Integer.MAX_VALUE のサイズよりも大きくすることはできません。結果として、この vIntInteger.MAX_VALUE の最大サイズに限定されます。
キー バイトアレイ キーを含みます (このキーの対応する値が要求されます)。
この操作の応答ヘッダーには、以下のいずれかの応答ステータスが含まれます。

表13.13 ContainsKey 操作応答形式

応答ステータス 説明
0x00 操作が成功。
0x02 キーが存在しない。
この操作の応答は空白です。

13.6.6. Hot Rod Get 操作

Hot Rod Get 操作は、以下の要求形式を使用します。

表13.14 Get 操作要求形式

フィールド データタイプ 説明
Header - -
Key Length vInt キーの長さを含みます。Integer.MAX_VALUE のサイズよりも大きいサイズ (最大 5 バイト) のため、vInt データタイプが使用されます。ただし、Java では、単一アレイサイズを Integer.MAX_VALUE のサイズよりも大きくすることはできません。結果として、この vInt は Integer.MAX_VALUE の最大サイズに限定されます。
Key バイトアレイ キーを含みます (このキーの対応する値が要求されます)。
この操作の応答ヘッダーには、以下のいずれかの応答ステータスが含まれます。

表13.15 Get 操作応答形式

応答ステータス 説明
0x00 操作が成功。
0x02 キーが存在しない。
キーが見つかった場合の get 操作の応答の形式は以下のとおりです。

表13.16 Get 操作応答形式

フィールド データタイプ 説明
Header - -
Value Length vInt 値の長さを含みます。
Value バイトアレイ 要求された値を含みます。

13.6.7. Hot Rod GetWithMetadata 操作

Hot Rod GetWithMetadata 操作は以下の要求形式を使用します。

表13.17 GetWithMetadata 操作の要求形式

フィールド データ型 説明
Header 変数 要求ヘッダー。
Key Length vInt キーの長さ。vInt のサイズは最大 5 バイトであり、理論的には Integer.MAX_VALUE よりも大きい数を生成できます。ただし、Java では Integer.MAX_VALUE よりも大きい単一アレイを作成できず、プロトコルにより vInt アレイの長さが Integer.MAX_VALUE に制限されます。
Key バイトアレイ 値が要求されるキーを含むバイトアレイ。
この操作の応答ヘッダーには、以下のいずれかの応答ステータスが含まれます。

表13.18 GetWithMetadata 操作の応答要求

フィールド データ型 説明
Header 変数 応答ヘッダー。
Response status 1 バイト
0x00 = 成功 (キーが取得された場合)。
0x02 =  キーが存在しない場合。
Flag 1 バイト 応答に失効に関する情報含まれるかどうかを示すフラグ。フラグの値は、 INFINITE_LIFESPAN (0x01)INFINITE_MAXIDLE (0x02) 間のビットごとの OR 演算として取得されます。
Created Long (オプション) サーバーでエントリが作成されたときのタイムスタンプを表すLong。この値は、フラグの INFINITE_LIFESPAN ビットが設定されていない場合にのみ返されます。
Lifespan vInt (オプション) エントリのライフスパンを表すvInt (秒単位)。この値は、フラグの INFINITE_LIFESPAN ビットが設定されていない場合にのみ返されます。
LastUsed Long (オプション) サーバーでエントリが最後にアクセスされたときのタイムスタンプを表すLong。この値は、フラグの INFINITE_MAXIDLE ビットが設定されていない場合にのみ返されます。
MaxIdle vInt (オプション) エントリの maxIdle を表すvInt (秒単位)。この値は、フラグの INFINITE_MAXIDLE ビットが設定されていない場合にのみ返されます。
Entry Version 8 バイト 既存のエントリー変更の一意の値。プロトコルでは entry_version の値はシーケンシャルであることが保証されず、キーレベルで更新ごとに一意である必要があります。
Value Length vInt 成功した場合は、値の長さ。
Value バイトアレイ 成功した場合は、要求された値。

13.6.8. Hot Rod ping 操作

ping は、サーバーの可用性を確認するアプリケーションレベルの要求です。
この操作に有効な応答ステータスは以下のとおりです。

表13.19 ping 操作応答

応答ステータス 説明
0x00 エラーなしの正常な ping。

13.6.9. Hot Rod PutIfAbsent 操作

putIfAbsent 操作要求形式には、以下のものが含まれます。

表13.20 PutIfAbsent 操作要求フィールド

フィールド データ型 説明
Header - -
Key Length vInt キーの長さを含みます。
Key バイトアレイ キーの値を含みます。
Lifespan vInt エントリーが期限切れになるまでの秒数を含みます。秒数が 30 日を超える場合、その値はエントリーライフスパンの UNIX 時間 (つまり、日付 1/1/1970 以降の秒数) として処理されます。値が 0 に設定された場合、エントリーは期限切れになりません。
Max Idle vInt キャッシュからエビクトされるまでエントリーがアイドル状態のままになることが許可される秒数を含みます。このエントリーが 0 に設定された場合、エントリーは無期限でアイドル状態のままになることが許可され、max idle 値のため、エビクトされません。
Value Length vInt 値の長さを含みます。
Value バイトアレイ 要求された値を含みます。
以下は、この操作から返された応答値です。

表13.21

応答ステータス 説明
0x00 値が正常に格納されました。
0x01 キーが存在しないため、値が格納されませんでした。キーの現在の値が返されました。
この操作では空の応答がデフォルト応答になります。ただし、ForceReturnPreviousValue が渡された場合は、以前の値とキーが返されます。以前のキーと値が存在しない場合は、値の長さに値 0 が含まれます。

13.6.10. Hot Rod Put 操作

put 操作要求形式には、以下のものが含まれます。

表13.22

フィールド データ型 説明
Header - -
Key Length - キーの長さを含みます。
Key バイトアレイ キーの値を含みます。
Lifespan vInt エントリーが期限切れになるまでの秒数を含みます。秒数が 30 日を超える場合、その値はエントリーライフスパンの UNIX 時間 (つまり、日付 1/1/1970 以降の秒数) として処理されます。値が 0 に設定された場合、エントリーは期限切れになりません。
Max Idle vInt キャッシュからエビクトされるまでエントリーがアイドル状態のままになることが許可される秒数を含みます。このエントリーが 0 に設定された場合、エントリーは無期限でアイドル状態のままになることが許可され、max idle 値のため、エビクトされません。
Value Length vInt 値の長さを含みます。
Value バイトアレイ 要求された値。
以下は、この操作から返された応答値です。

表13.23

応答ステータス 説明
0x00 値が正常に格納されました。
この操作では空の応答がデフォルト応答になります。ただし、ForceReturnPreviousValue が渡された場合は、以前の値とキーが返されます。以前のキーと値が存在しない場合は、値の長さに値 0 が含まれます。

13.6.11. Hot Rod クエリー操作

Query 操作要求形式には、以下のものが含まれます。

表13.24 クエリー操作要求フィールド

フィールド データ型 詳細
Header 変数 要求ヘッダー。
Query Length vInt Protobuf エンコードされたクエリーオブジェクトの長さ。
Query バイトアレイ Protobuf エンコードされたクエリーオブジェクトを含むバイトアレイ。長さは目のフィールドにより指定されます。
以下は、この操作から返された応答値です。

表13.25 クエリー操作応答

応答ステータス データ 詳細
Header 変数 応答ヘッダー。
Response payload Length vInt Protobuf エンコードされた応答オブジェクトの長さ。
Response payload バイトアレイ Protobuf エンコードされた応答オブジェクトを含むバイトアレイ。長さは目のフィールドにより指定されます。

13.6.12. Hot Rod RemoveIfUnmodified 操作

RemoveIfUnmodified 操作要求形式には、以下のものが含まれます。

表13.26 RemoveIfUnmodified 操作要求フィールド

フィールド データ型 説明
Header - -
Key Length vInt キーの長さを含みます。
Key バイトアレイ キーの値を含みます。
Entry Version 8 バイト エントリーのバージョン番号。
以下は、この操作から返された応答値です。

表13.27 RemoveIfUnmodified 操作応答

応答ステータス 説明
0x00 エントリーが置換または削除された場合に返されたステータス。
0x01 キーが変更されたため、エントリーの置換または削除が失敗した場合に、ステータスを返します。
0x02 キーが存在しない場合に、ステータスを返します。
この操作では空の応答がデフォルト応答になります。ただし、ForceReturnPreviousValue が渡された場合は、以前の値とキーが返されます。以前のキーと値が存在しない場合は、値の長さに値 0 が含まれます。

13.6.13. Hot Rod Remove 操作

Hot Rod Remove 操作は、以下の要求形式を使用します。

表13.28 Remove 操作要求形式

フィールド データタイプ 説明
Header - -
Key Length vInt キーの長さを含みます。Integer.MAX_VALUE のサイズよりも大きいサイズ (最大 5 バイト) のため、vInt データタイプが使用されます。ただし、Java では、単一アレイサイズを Integer.MAX_VALUE のサイズよりも大きくすることはできません。結果として、この vIntInteger.MAX_VALUE の最大サイズに限定されます。
Key バイトアレイ キーを含みます (このキーの対応する値が要求されます)。
この操作の応答ヘッダーには、以下のいずれかの応答ステータスが含まれます。

表13.29 Remove 操作応答形式

応答ステータス 説明
0x00 操作が成功。
0x02 キーが存在しない。
通常、この操作の応答ヘッダーは空白です。ただし、ForceReturnPreviousValue が渡された場合は、応答ヘッダーに以下のいずれかが含まれます。
  • 以前のキーの値および長さ。
  • キーが存在しないことを示す、値の長さ 0 と応答ステータス 0x02
remove 操作の応答ヘッダーには、提供されたキーの以前の値と、以前の値の長さが含まれます (ForceReturnPreviousValue が渡された場合)。キーが存在しない場合、または以前の値が null の場合、値の長さは 0 です。

13.6.14. Hot Rod ReplaceIfUnmodified 操作

ReplaceIfUnmodified 操作要求形式には、以下のものが含まれます。

表13.30 ReplaceIfUnmodified 操作要求フィールド

フィールド データ型 説明
Header - -
Key Length vInt キーの長さを含みます。
キー バイトアレイ キーの値を含みます。
Lifespan vInt エントリーが期限切れになるまでの秒数を含みます。秒数が 30 日を超える場合、その値はエントリーライフスパンの UNIX 時間 (つまり、日付 1/1/1970 以降の秒数) として処理されます。値が 0 に設定された場合、エントリーは期限切れになりません。
Max Idle vInt キャッシュからエビクトされるまでエントリーがアイドル状態のままになることが許可される秒数を含みます。このエントリーが 0 に設定された場合、エントリーは無期限でアイドル状態のままになることが許可され、max idle 値のため、エビクトされません。
Entry Version 8 バイト エントリーのバージョン番号。
Value Length vInt 値の長さを含みます。
バイトアレイ 要求された値を含みます。
以下は、この操作から返された応答値です。

表13.31 ReplaceIfUnmodified 操作応答

応答ステータス 説明
0x00 エントリーが置換または削除された場合に返されたステータス。
0x01 キーが変更されたため、エントリーの置換または削除が失敗した場合に、ステータスを返します。
0x02 キーが存在しない場合に、ステータスを返します。
この操作では空の応答がデフォルト応答になります。ただし、ForceReturnPreviousValue が渡された場合は、以前の値とキーが返されます。以前のキーと値が存在しない場合は、値の長さに値 0 が含まれます。

13.6.15. Hot Rod replace 操作

replace 操作要求形式には、以下のものが含まれます。

表13.32 replace 操作要求フィールド

フィールド データ型 説明
Header - -
Key Length vInt キーの長さを含みます。
Key バイトアレイ キーの値を含みます。
Lifespan vInt エントリーが期限切れになるまでの秒数を含みます。秒数が 30 日を超える場合、その値はエントリーライフスパンの UNIX 時間 (つまり、日付 1/1/1970 以降の秒数) として処理されます。値が 0 に設定された場合、エントリーは期限切れになりません。
Max Idle vInt キャッシュからエビクトされるまでエントリーがアイドル状態のままになることが許可される秒数を含みます。このエントリーが 0 に設定された場合、エントリーは無期限でアイドル状態のままになることが許可され、max idle 値のため、エビクトされません。
Value Length vInt 値の長さを含みます。
Value バイトアレイ 要求された値を含みます。
以下は、この操作から返された応答値です。

表13.33 replace 操作応答

応答ステータス 説明
0x00 値が正常に格納されました。
0x01 キーが存在しないため、値が格納されませんでした。
この操作では空の応答がデフォルト応答になります。ただし、ForceReturnPreviousValue が渡された場合は、以前の値とキーが返されます。以前のキーと値が存在しない場合は、値の長さに値 0 が含まれます。

13.6.16. Hot Rod 統計操作

この操作は、利用可能なすべての統計の概要を返します。返された各統計に対して、名前と値が文字列形式と UTF-8 形式の両方で返されます。
この操作では、以下の統計がサポートされます。

表13.34 統計操作要求フィールド

名前 説明
timeSinceStart Hot Rod が起動した以降の秒数を含みます。
currentNumberOfEntries Hot Rod サーバーに現在存在するエントリーの数を含みます。
totalNumberOfEntries Hot Rod サーバーに格納されたエントリーの合計数を含みます。
stores put 操作の試行回数を含みます。
retrievals get 操作の試行回数を含みます。
hits get ヒット数を含みます。
misses get 失敗数を含みます。
removeHits remove ヒット数を含みます。
removeMisses removal 失敗数を含みます。
この操作の応答ヘッダーには以下のものが含まれます。

表13.35 統計操作応答

名前 データ型 説明
Header - -
Number of Stats vInt 返された個別統計の数を含みます。
Name Length vInt 名前付き統計の長さを含みます。
名前 文字列 統計の名前を含みます。
Value Length vInt 値の長さを含みます。
文字列 統計値を含みます。
要求された各統計に対して、値 Name LengthNameValue Length、および Value が繰り返されます。

13.7. Hot Rod 操作の値

以下は、要求ヘッダーと対応する応答ヘッダー値の有効な opcode 値のリストです。

表13.36 opcode 要求および応答ヘッダー値

操作 要求操作コード 応答操作コード
put 0x01 0x02
get 0x03 0x04
putIfAbsent 0x05 0x06
replace 0x07 0x08
replaceIfUnmodified 0x09 0x0A
remove 0x0B 0x0C
removeIfUnmodified 0x0D 0x0E
containsKey 0x0F 0x10
clear 0x13 0x14
stats 0x15 0x16
ping 0x17 0x18
bulkGet 0x19 0x1A
getWithMetadata 0x1B 0x1C
bulkKeysGet 0x1D 0x1E
query 0x1F 0x20
また、応答ヘッダーの opcode 値が 0x50 の場合は、エラー応答を示します。

13.7.1. Magic 値

以下は要求および応答ヘッダー内の Magic フィールドの有効な値のリストです。

表13.37 Magic フィールド値

説明
0xA0 キャッシュ要求マーカー。
0xA1 キャッシュ応答マーカー。

13.7.2. ステータス値

以下は、応答ヘッダー内の Status フィールドに対するすべての有効な値を含む表です。

表13.38 ステータス値

説明
0x00 エラーなし。
0x01 配置、削除、置換なし。
0x02 キーは存在しない。
0x81 無効なマジック値またはメッセージ ID。
0x82 不明なコマンド。
0x83 不明なバージョン。
0x84 要求解析エラー。
0x85 サーバーエラー。
0x86 コマンドタイムアウト。

13.7.3. トランザクションタイプ値

以下は、要求ヘッダー内の Transaction Type の有効な値のリストです。

表13.39 Transaction Type フィールド値

説明
0 非トランザクション呼び出し、またはクライアントがトランザクションをサポートしないことを示します。使用された場合は、TX_ID フィールドが省略されます。
1 X/Open XA トランザクション ID (XID) を示します。この値は現在サポートされていません。

13.7.4. Client Intelligence 値

以下は、要求ヘッダー内の Client Intelligence の有効な値のリストです。

表13.40 Client Intelligence フィールド値

説明
0x01 クラスターまたはハッシュ情報が必要でない基本的なクライアントを示します。
0x02 トポロジーを認識し、クラスター情報が必要なクラスターを示します。
0x03 ハッシュと配布を認識し、クラスターおよびハッシュ情報が必要なクライアントを示します。

13.7.5. フラグ値

以下は、要求ヘッダー内の有効な flag 値のリストです。

表13.41 フラグフィールド値

説明
0x0001 ForceReturnPreviousValue

13.7.6. Hot Rod エラー処理

表13.42 応答ヘッダーフィールドを使用した Hot Rod エラー処理

フィールド データ型 説明
Error Opcode - エラー操作コードを含みます。
Error Status Number - error opcode に対応するステータス番号を含みます。
Error Message Length vInt エラーメッセージの長さを含みます。
エラーメッセージ 文字列 実際のエラーメッセージを含みます。要求の解析エラーが存在することを示す 0x84 エラーコードが返された場合、このフィールドには、Hot Rod サーバーでサポートされた最新バージョンが含まれます。

13.8. put 要求の例

以下は、Hot Rod を使用した put 要求例からのコーディングされた要求です。

表13.43 put 要求の例

バイト 0 1 2 3 4 5 6 7
8 0xA0 0x09 0x41 0x01 0x07 0x4D ('M') 0x79 ('y') 0x43 ('C')
16 0x61 ('a') 0x63 ('c') 0x68 ('h') 0x65 ('e') 0x00 0x03 0x00 0x00
24 0x00 0x05 0x48 ('H') 0x65 ('e') 0x6C ('l') 0x6C ('l') 0x6F ('o') 0x00
32 0x00 0x05 0x57 ('W') 0x6F ('o') 0x72 ('r') 0x6C ('l') 0x64 ('d') -
以下の表には、要求の例に対するすべてのヘッダーフィールドと値が含まれます。

表13.44 要求例のフィールド名と値

フィールド名 バイト
Magic 0 0xA0
Version 2 0x41
Cache Name Length 4 0x07
Flag 12 0x00
Topology ID 14 0x00
Transaction ID 16 0x00
Key 18-22 'Hello'
Max Idle 24 0x00
26-30 'World'
Message ID 1 0x09
Opcode 3 0x01
Cache Name 5-11 'MyCache'
Client Intelligence 13 0x03
Transaction Type 15 0x00
Key Field Length 17 0x05
Lifespan 23 0x00
Value Field Length 25 0x05
以下は、put 要求の例に対するコーディングされた応答です。

表13.45 put 要求の例のコーディングされた応答

バイト 0 1 2 3 4 5 6 7
8 0xA1 0x09 0x01 0x00 0x00 - - -
以下の表には、応答の例に対するすべてのヘッダーフィールドと値が含まれます。

表13.46 応答例のフィールド名および値

フィールド名 バイト
Magic 0 0xA1
Opcode 2 0x01
Topology Change Marker 4 0x00
Message ID 1 0x09
Status 3 0x00

13.9. Hot Rod Java クライアント

Hot Rod はバイナリーの言語非依存プロトコルです。Java クライアントは、Hot Rod Java Client API を使用して Hot Rod プロトコルを介してサーバーと対話できます。

13.9.1. Hot Rod Java クライアントのダウンロード

JBoss Data Grid Hot Rod Java クライアントをダウンロードするには、次の手順に従ってください。

手順13.2 Hot Rod Java クライアントのダウンロード

  1. カスタマーポータル (https://access.redhat.com) にログインします。
  2. ページ最上部にある ダウンロード ボタンをクリックします。
  3. 製品のダウンロード ページで Red Hat JBoss Data Grid をクリックします。
  4. バージョン: ドロップダウンメニューから適切な JBoss Data Grid バージョンを選択します。
  5. Red Hat JBoss Data Grid ${VERSION} Hot Rod Java Client エントリーを探し、対応する ダウンロード リンクをクリックします。

13.9.2. Hot Rod Java クライアントの設定

Hot Rod Java クライアントは、プログラムを使用したり、設定ファイルまたはプロパティーファイルを外部的に使用したりして設定されます。次の例は、利用可能な Java 対応 API を使用したクライアントインスタンスの作成を示しています。

例13.1 クライアントインスタンスの作成

org.infinispan.client.hotrod.configuration.ConfigurationBuilder cb
= new org.infinispan.client.hotrod.configuration.ConfigurationBuilder();
cb.tcpNoDelay(true)
  .connectionPool()
      .numTestsPerEvictionRun(3)
      .testOnBorrow(false)
      .testOnReturn(false)
      .testWhileIdle(true)
  .addServer()
      .host("localhost")
      .port(11222);
RemoteCacheManager rmc = new RemoteCacheManager(cb.build());
プロパティーファイルを使用した Hot Rod Java クライアントの設定

Hot Rod Java クライアントを設定するには、クラスパス上の hotrod-client.properties ファイルを編集します。

次の例は、hotrod-client.properties ファイルの内容を示しています。

例13.2 設定

infinispan.client.hotrod.transport_factory = org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory

infinispan.client.hotrod.server_list = 127.0.0.1:11222

infinispan.client.hotrod.marshaller = org.infinispan.commons.marshall.jboss.GenericJBossMarshaller

infinispan.client.hotrod.async_executor_factory = org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory

infinispan.client.hotrod.default_executor_factory.pool_size = 1

infinispan.client.hotrod.default_executor_factory.queue_size = 10000

infinispan.client.hotrod.hash_function_impl.1 = org.infinispan.client.hotrod.impl.consistenthash.ConsistentHashV1

infinispan.client.hotrod.tcp_no_delay = true

infinispan.client.hotrod.ping_on_startup = true

infinispan.client.hotrod.request_balancing_strategy = org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy

infinispan.client.hotrod.key_size_estimate = 64

infinispan.client.hotrod.value_size_estimate = 512

infinispan.client.hotrod.force_return_values = false

infinispan.client.hotrod.tcp_keep_alive = true

## below is connection pooling config

maxActive=-1

maxTotal = -1

maxIdle = -1

whenExhaustedAction = 1

timeBetweenEvictionRunsMillis=120000

minEvictableIdleTimeMillis=300000

testWhileIdle = true

minIdle = 1

注記

TCP KEEPALIVE 設定は、 例で示された設定プロパティー (infinispan.client.hotrod.tcp_keep_alive = true/false) または org.infinispan.client.hotrod.ConfigurationBuilder.tcpKeepAlive() メソッドを使用したプログラムによって Hot Rod Java クライアントで有効/無効になります。
Red Hat JBoss Data Grid でプロパティーファイルを使用するには、次の 2 つのコンストラクターのいずれかを使用する必要があります。
  1. new RemoteCacheManager(boolean start)
  2. new RemoteCacheManager()

13.9.3. Hot Rod Java クライアント基本 API

以下のコードは、クライアント API を使用して Hot Rod Java クライアントで Hot Rod サーバーから情報を保存または取得する方法を示しています。この例では、Hot Rod サーバーがデフォルトの場所 localhost:11222 にバインドするよう起動されていることを前提とします。

例13.3 基本 API

//API entry point, by default it connects to localhost:11222
CacheContainer cacheContainer = new RemoteCacheManager();
//obtain a handle to the remote default cache
Cache<String, String> cache = cacheContainer.getCache();
//now add something to the cache and make sure it is there
cache.put("car", "ferrari");]
assert cache.get("car").equals("ferrari");
//remove the data
cache.remove("car");
assert !cache.containsKey("car") : "Value must have been removed!";
RemoteCacheManager は、DefaultCacheManager に対応し、両方とも CacheContainer を実装します。
この API は、ローカルコールから Hot Rod を介したリモートコールへの移行を実現します。これは、DefaultCacheManagerRemoteCacheManager を切り替えることによって行うことができ、共通の CacheContainer インターフェースによって単純化されます。
すべてのキーは、keySet() メソッドを使用してリモートキャッシュから取得できます。リモートキャッシュが分散キャッシュである場合は、サーバーによりマップ/削減ジョブが開始され、クラスタノードからすべてのキーが取得され、すべてのキーがクライアントに返されます。
キーの数が多い場合は、このメソッドを注意して使用してください。
Set keys = remoteCache.keySet();

13.9.4. Hot Rod Java クライアントバージョン API

データの整合性を確保するために、Hot Rod は各変更を一意に識別するバージョン番号を保存します。getVersioned を使用して、クライアントはキーと現在のバージョンに関連付けられた値を取得できます。
Hot Rod Java クライアントを使用する場合、RemoteCacheManager は、リモートクラスタ上の名前付きまたはデフォルトのキャッシュにアクセスする RemoteCache インターフェースのインスタンスを提供します。これにより、バージョン API を含む、新しいメソッドを追加する Cache インターフェースが拡張されます。

例13.4 バージョンメソッドの使用

// To use the versioned API, remote classes are specifically needed
RemoteCacheManager remoteCacheManager = new RemoteCacheManager();
RemoteCache<String, String> cache = remoteCacheManager.getCache();
remoteCache.put("car", "ferrari");
VersionedValue valueBinary = remoteCache.getVersioned("car");
// removal only takes place only if the version has not been changed
// in between. (a new version is associated with 'car' key on each change)
assert remoteCache.remove("car", valueBinary.getVersion());
assert !cache.containsKey("car");

例13.5 置換の使用

remoteCache.put("car", "ferrari");
VersionedValue valueBinary = remoteCache.getVersioned("car");
assert remoteCache.replace("car", "lamborghini", valueBinary.getVersion());

13.10. Hot Rod C ++ クライアント

Hot Rod C ++ クライアントは、Hot Rod Java クライアントを含む Hot Rod クライアントファミリーに新しく追加され、Red Hat JBoss Data Grid リモートサーバーに接続し、対話するよう C++ ランタイムアプリケーションを有効にします。
Hot Rod C++ クライアントにより、C++ で開発されたアプリケーションが JBoss Hot Rod リモートキャッシュに接続し、データを問い合わせたり、格納したりできるようになります。Hot Rod C ++ クライアントは、Linux、Unix、および Windows オペレーティングシステム向けにコンパイルできます。

13.10.1. Hot Rod C ++ クライアント形式

Hot Rod C++ クライアントは、以下の 2 つのライブラリー形式で利用可能です。
  • 静的ライブラリー
  • 共有/動的ライブラリー
静的ライブラリー

静的ライブラリーはアプリケーションに静的にリンクされます。これにより、最終的な実行可能ファイルのサイズは増加します。アプリケーションは自己完結型であり、別のライブラリーを提供する必要はありません。

共有/動的ライブラリー

共有/動的ライブラリーは、実行時にアプリケーションに動的にリンクされます。ライブラリーは別のファイルに格納され、アプリケーションを再コンパイルせずアプリケーションとは別にアップグレードできます。

注記

これは、ライブラリーのメジャーバージョンがコンパイル時にアプリケーションがリンクされたものと同じである (バイナリー互換性がある) 場合にのみ可能です。

13.10.2. Hot Rod C ++ クライアントの前提条件

Hot Rod C++ クライアントを使用するには、以下のものが必要です。
  • shared_ptr TR1 (GCC 4.0+、Visual Studio C++ 2010) をサポートする C++ 03 コンパイラー。
  • Red Hat JBoss Data Grid Server 6.1.0 以上のバージョン。

13.10.3. Hot Rod C ++ クライアントのダウンロード

Hot Rod C++ クライアントは、Red Hat カスタマーポータル (https://access.redhat.com) の Red Hat JBoss Data Grid  バイナリー下にある個別の zip ファイル、jboss-datagrid-<version>-hotrod-cpp-client-<platform>.zip に含まれます。使用しているオペレーティングシステムに適切な Hot Rod C++ クライアントをダウンロードしてください。

13.10.4. Hot Rod C ++ クライアントの設定

Hot Rod C++ クライアントは RemoteCache API を使用してリモートの Hot Rod サーバーと対話します。特定の Hot Rod サーバーとの通信を開始するために、RemoteCache を設定し、Hot Rod サーバーの特定のキャッシュを選択します。
ConfigurationBuilder API を使用すると、以下のものを設定できます。
  • 接続するサーバーの初期セット。
  • 接続プール属性。
  • 接続/ソケットタイムアウトおよび TCP nodelay。
  • Hot Rod プロトコルバージョン。
C++ 主要実行可能ファイルの設定例

以下の例は、ConfigurationBuilder を使用して RemoteCacheManager を設定する方法とデフォルトのリモートキャッシュを取得する方法を示しています。

例13.6 SimpleMain.cpp

#include "infinispan/hotrod/ConfigurationBuilder.h"
#include "infinispan/hotrod/RemoteCacheManager.h"
#include "infinispan/hotrod/RemoteCache.h"
#include <stdlib.h>
using namespace infinispan::hotrod;
int main(int argc, char** argv) {
    ConfigurationBuilder b;
    b.addServer().host("127.0.0.1").port(11222);
    RemoteCacheManager cm(builder.build());
    RemoteCache<std::string, std::string> cache = cm.getCache<std::string, std::string>();
    return 0;
}

13.10.5. Hot Rod C ++ クライアント API

RemoteCacheManager は、RemoteCache への参照を取得する開始点です。RemoteCache API は、リモート Hot Rod サーバーとサーバー上の特定のキャッシュと対話できます。
前の例で取得した RemoteCache 参照を使用すると、リモートキャッシュで値を挿入、取得、置換、および削除できます。また、すべてのキーの取得やキャッシュのクリアなどの一括操作を実行することもできます。
RemoteCacheManager が停止されると、使用中のすべてのリソースが解放されます。

例13.7 SimpleMain.cpp

RemoteCache<std::string, std::string> rc = cm.getCache<std::string, std::string>();
    std::string k1("key13");
    std::string v1("boron");
    // put
    rc.put(k1, v1);
    std::auto_ptr<std::string> rv(rc.get(k1));
    rc.putIfAbsent(k1, v1);
    std::auto_ptr<std::string> rv2(rc.get(k1));
    std::map<HR_SHARED_PTR<std::string>,HR_SHARED_PTR<std::string> > map = rc.getBulk(0);
    std::cout << "getBulk size" << map.size() << std::endl;
    ..
    .
    cm.stop();

13.11. Hot Rod C# クライアント

Hot Rod C# クライアントは、Hot Rod Java クライアントと Hot Rod C++ クライアントを含む Hot Rod クライアントのリストに新しく追加されました。Hot Rod C# クライアントでは、.NET ランタイムアプリケーションが Red Hat JBoss Data Grid サーバーに接続し、対話できます。
Hot Rod C# クライアントは、クラスタートポロジーとハッシュスキームを認識し、Hot Rod Java クライアントと Hot Rod C++ クライアントに類似した単一のホップでサーバー上のエントリーにアクセスできます。
Hot Rod C# クライアントは、.NET Framework が Microsoft によりサポートされる 32 ビットおよび 64 ビットのオペレーティングシステムと互換性があります。.NET Framework 4.0 は、Hot Rod C# クライアントを使用するサポート対象オペレーティングシステムとともに前提条件です。

警告

Hot Rod C# クライアントは技術プレビュー機能であり、JBoss Data Grid 6.3 でサポートされていません。

13.11.1. Hot Rod C# クライアントのダウンロードとインストール

Hot Rod C# クライアントは、Red Hat JBoss Data Grid  でダウンロード向けにパッケージされた .msi ファイル jboss-datagrid-<version>-hotrod-dotnet-client.msi に含まれます。Hot Rod C# クライアントをインストールするには、以下の手順を実行してください。

手順13.3 Hot Rod C# クライアントのインストール

  1. 管理者として、Hot Rod C# .msi ファイルがダウンロードされた場所に移動します。.msi ファイルを実行してウィンドウインストーラーを起動し、Next (次へ) をクリックします。
    Description

    図13.1 Hot Rod C# クライアントのセットアップの開始

  2. 使用許諾契約書の内容を確認します。I accept the terms in the License Agreement (使用許諾契約に同意します) チェックボックスを選択し、Next (次へ) をクリックします。
    Description

    図13.2 Hot Rod C# クライアントの使用許諾契約

  3. デフォルトのディレクトリーを変更するには、Change... (変更...) または Next (次へ) をクリックしてデフォルトのディレクトリーにインストールします。
    Description

    図13.3 Hot Rod C# クライアントの宛先フォルダー

  4. Finish (完了) をクリックして Hot Rod C# クライアントのインストールを完了します。
    Description

    図13.4 Hot Rod C# クライアントのセットアップの完了

13.11.2. Hot Rod C# クライアントの設定

Hot Rod C# クライアントは ConfigurationBuilder を使用してプログラミングにより設定されます。クライアントが接続する必要があるホストとポートを設定します。
C# ファイルの設定例

以下の例は、ConfigurationBuilder を使用して RemoteCacheManager を設定する方法を示しています。

例13.8 C# の設定

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Infinispan.HotRod;
using Infinispan.HotRod.Config;
namespace simpleapp
{
    class Program
    {
        static void Main(string[] args)
        {
            ConfigurationBuilder builder = new ConfigurationBuilder();
            builder.AddServer()
                .Host(args.Length > 1 ? args[0] : "127.0.0.1")
                .Port(args.Length > 2 ? int.Parse(args[1]) : 11222);
            Configuration config = builder.Build();
            RemoteCacheManager cacheManager = new RemoteCacheManager(config);
            [...]
        }
    }
}

13.11.3. Hot Rod C# クライアント API

RemoteCacheManager は、RemoteCache への参照を取得する開始点です。
以下の例は、サーバーからのデフォルトキャッシュの取得と基本的な複数の操作を示しています。

例13.9

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Infinispan.HotRod;
using Infinispan.HotRod.Config;
namespace simpleapp
{
    class Program
    {
        static void Main(string[] args)
        {
            ConfigurationBuilder builder = new ConfigurationBuilder();
            builder.AddServer()
                .Host(args.Length > 1 ? args[0] : "127.0.0.1")
                .Port(args.Length > 2 ? int.Parse(args[1]) : 11222);
            Configuration config = builder.Build();
            RemoteCacheManager cacheManager = new RemoteCacheManager(config);
            cacheManager.Start();
            // Retrieve a reference to the default cache.
            IRemoteCache<String, String> cache = cacheManager.GetCache<String, String>();
            // Add entries.
            cache.Put("key1", "value1");
            cache.PutIfAbsent("key1", "anotherValue1");
            cache.PutIfAbsent("key2", "value2");
            cache.PutIfAbsent("key3", "value3");
            // Retrive entries.
            Console.WriteLine("key1 -> " + cache.Get("key1"));
            // Bulk retrieve key/value pairs.
            int limit = 10;
            IDictionary<String, String> result = cache.GetBulk(limit);
            foreach (KeyValuePair<String, String> kv in result)
            {
                Console.WriteLine(kv.Key + " -> " + kv.Value);
            }
            // Remove entries.
            cache.Remove("key2");
            Console.WriteLine("key2 -> " + cache.Get("key2"));
            cacheManager.Stop();
        }
    }
}

13.12. Hot Rod C++ と Hot Rod Java クライアント間の相互運用性

Red Hat JBoss Data Grid は、構造化データにアクセスするために Hot Rod Java と Hot Rod C++ クライアント間の相互運用性を提供します。これは、Google の Protobuf 形式を使用してデータを構造化およびシリアル化することにより可能になります。
たとえば、言語間の相互運用性を使用すると、Hot Rod C++ クライアントが Protobuf を使用して構造化およびシリアル化された次の Person オブジェクトを記述し、Java C++ クライアントが Protobuf として構造化された同じ Person オブジェクトを読み取ることができます。

例13.10 言語間の相互運用性の使用

package sample;
message Person {
    required int32 age = 1;
    required string name = 2;
}
Protobuf オブジェクトをシリアル化するために Hot Rod Java クライアントが同梱された Protostream ライブラリーを使用することが推奨されます (ただし、これは強制ではなくサポートされていません)。Protobuf ライブラリーは、C++ 向けの推奨シリアル化ソリューションです (https://code.google.com/p/protobuf/)。
C++ と Hot Rod Java クライアント間の相互運用性は基本データ型、文字列、バイトアレイにおいて完全にサポートされています。Protobuf と Protostream はこれらのタイプの相互運用性のために必要ありません。
C++ クライアントが Protobuf エンコードデータを読み取る方法については、https://github.com/jboss-developer/jboss-jdg-quickstarts/tree/master/remote-query/src/main/cpp を参照してください。

パート VI. キャッシュのロックのセットアップ

第14章 ロック

Red Hat JBoss Data Grid は、ダーティー読み出し (トランザクションが古くなった値に変更を適用する前にその古くなった値を読み出す) と反復不可能読み出しを防ぐためのロックメカニズムを提供します。

14.1. ロックの設定 (リモートクライアントサーバーモード)

リモートクライアントサーバーモードでは、ロックは、キャッシュタグ (たとえば、invalidation-cachedistributed-cachereplicated-cache または local-cache) 内で locking 要素を使用して設定されます。

注記

リモートクライアントサーバーモードのデフォルトの分離モードは READ_COMMITTED です。分離モードを明示的に指定するために isolation 属性が含まれる場合、この属性は無視され、警告がスローされて、デフォルト値が代わりに使用されます。
以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおけるデフォルトキャッシュについての基本的なロック設定の手順例です。

手順14.1 ロックの設定 (リモートクライアントサーバーモード)

  1. acquire-timeout パラメーターを設定します。

    acquire-timeout パラメーターは、ロックの取得がタイムアウトになった後のミリ秒数を指定します。
    <distributed-cache>
    	<locking acquire-timeout="30000" />
  2. ロックストライプの数を設定します。

    concurrency-level パラメーターは、LockManager によって使用されるロックストライプの数を定義します。
    <distributed-cache>
    	<locking acquire-timeout="30000" 
    	         concurrency-level="1000" />
  3. ロックストライピングを設定します。

    striping パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
    <distributed-cache>
    	<locking acquire-timeout="30000" 
    	         concurrency-level="1000" 
    	         striping="false" />
    	         ...
    </distributed-cache>

14.2. ロックの設定 (ライブラリーモード)

ライブラリーモードの場合、locking 要素とそのパラメーターは、キャッシュごとにオプションの configuration 要素内で設定されます。たとえば、デフォルトのキャッシュの場合、configuration 要素は default 要素内で発生し、それぞれの名前付きキャッシュについては、namedCache 要素内で発生します。以下は、この設定例になります。

手順14.2 ロックの設定 (ライブラリーモード)

  1. 平行性レベルを設定します。

    concurrencyLevel パラメーターは、ロックコンテナーの平行性レベルを指定します。データグリッドと通信する並行スレッドの数に従ってこの値を設定します。
    <infinispan>
    	...
    	<default>
    		<locking concurrencyLevel="${VALUE}" />
  2. キャッシュの分離レベルを指定します。

    isolationLevel パラメーターはキャッシュの分離レベルを指定します。有効な分離レベルは、READ_COMMITTED および REPEATABLE_READ です。分離レベルについてさらに詳しくは、「分離レベルについて」を参照してください。
    <infinispan>
    	...
    	<default>
    		<locking concurrencyLevel="${VALUE}"
    				isolationLevel="${LEVEL}" />
  3. ロック取得タイムアウトを設定します。

    lockAcquisitionTimeout パラメーターは、ロック取得の試行がタイムアウトになった後の時間 (ミリ秒単位) を指定します。
    <infinispan>
    	...
    	<default>
    		<locking concurrencyLevel="${VALUE}"
    			isolationLevel="${LEVEL}"
    			lockAcquisitionTimeout="${TIME}" />
  4. ロックストライピングを設定します。

    useLockStriping パラメーターは、ロックを必要とするすべてのエントリーに対して、共有ロックのプールを維持するかどうかを指定します。FALSE に設定されると、ロックがキャッシュ内のそれぞれのエントリーに対して作成されます。さらに詳しくは、「ロックストライピングについて」を参照してください。
    <infinispan>
    	...
    	<default>
    		<locking concurrencyLevel="${VALUE}"
    			isolationLevel="${LEVEL}"
    			lockAcquisitionTimeout="${TIME}"
    			useLockStriping="${TRUE/FALSE}" />
    • writeSkewCheck パラメーターを設定します。

      writeSkewCheck パラメーターは、isolationLevelREPEATABLE_READ に設定される場合にのみ有効です。このパラメーターが FALSE に設定される場合、書き込み時に動作中のエントリーと基礎となるエントリー間の相違があると、動作中のエントリーが基礎となるエントリーを上書きします。このパラメーターが TRUE に設定されている場合、このような競合 (つまり書き込みスキュー) によって、例外がスローされます。
      <infinispan>
      	...
      	<default>
      		<locking concurrencyLevel="${VALUE}"
      			isolationLevel="${LEVEL}"
      			lockAcquisitionTimeout="${TIME}"
      			useLockStriping="${TRUE/FALSE}"
      			writeSkewCheck="${TRUE/FALSE}" />

14.3. ロックのタイプ

14.3.1. 楽観的ロックについて

楽観的ロックは、ロックの取得をトランザクションの準備時間まで延期することで複数のトランザクションが同時に終了するようにします。
楽観的モードは、複数のトランザクションが競合せずに終了するようにします。トランザクションは、他のトランザクションロックがクリアされるまで待機しなくてもコミットできるため、同時に実行されている複数のトランザクション間でほとんど競合が発生しない場合に適しています。writeSkewCheck が有効になっている場合、トランザクションが終了する前に、競合する変更が 1 つ以上データに加えられると、楽観的ロックモードのトランザクションはロールバックします。

14.3.2. 悲観的ロックについて

悲観的ロック (Pessimistic locking) は Eager locking とも呼ばれます。
悲観的ロックは、クラスターワイドのロックを各書き込み操作に強制し、複数のトランザクションがキーに書き込まれないようにします。コミットまたはロールバックによってトランザクションが完了した時のみロックが開放されます。
悲観的モードはキーで競合が発生し、効率が悪くなったり、予期されないロールバック操作が発生する場合に使用されます。

14.3.3. 悲観的ロックのタイプ

Red Hat JBoss Data Grid には、明示的な悲観的ロックと暗黙的な悲観的ロックが含まれています。
  • 明示的な楽観的ロックは、JBoss Data Grid Lock API を使用してトランザクションの期間にキャッシュユーザーがキャッシュキーを明示的にロックできるようにします。ロック呼び出しは、クラスターの全ノードにおいて、指定されたキャッシュキー上でロックの取得を試みます。ロックはすべてコミットまたはロールバックフェーズ中に開放されます。
  • 暗黙的な悲観的ロックは、キャッシュキーが変更操作のためアクセスされる時にキャッシュキーがバックグラウンドでロックされるようにします。暗黙的な悲観的ロックを使用すると、各変更操作に対してキャッシュキーが確実にローカルでロックされるよう JBoss Data Grid がチェックします。ロックされていないキャッシュキーが見つかると、JBoss Data Grid はロックされていないキャッシュキーのロックを取得するため、クラスターワイドのロックを要求します。

14.3.4. 明示的な悲観的ロックの例

以下は、キャッシュノードの 1 つで実行されるトランザクションの明示的な悲観的ロックの例になります。

手順14.3 明示的な悲観的ロックによるトランザクション

  1. cache.lock(K) が実行されると、K でクラスター全体のロックが取得されます。
    tx.begin()
    cache.lock(K)
  2. cache.put(K,V5) が実行されると、取得の成功が保証されます。
    tx.begin()
    cache.lock(K)           
    cache.put(K,V5)
  3. tx.commit() が実行されると、この処理のために保持されたロックが開放されます。
    tx.begin()
    cache.lock(K)           
    cache.put(K,V5)         
    tx.commit()
    

14.3.5. 暗黙的な悲観的ロックの例

以下は、キャッシュノードの 1 つで実行されるトランザクションを使用する暗黙的な悲観的ロックの例になります。

手順14.4 暗黙的な悲観的ロックによるトランザクション

  1. cache.put(K,V) が実行されると、K でクラスター全体のロックが取得されます。
    tx.begin()
    cache.put(K,V)
  2. cache.put(K2,V2) が実行されると、K2 でクラスター全体のロックが取得されます。
    tx.begin()
    cache.put(K,V)
    cache.put(K2,V2)
  3. cache.put(K,V5) が実行されると、 K のクラスター全体のロックは以前取得されたため、ロックの取得は実行できませんが、put 操作は発生します。
    tx.begin()
    cache.put(K,V)
    cache.put(K2,V2)
    cache.put(K,V5)
  4. tx.commit() が実行されると、このトランザクションのために保持されたすべてのロックが開放されます。
    tx.begin()
    cache.put(K,V)
    cache.put(K2,V2)
    cache.put(K,V5)
    tx.commit()

14.3.6. ロックモードの設定 (リモートクライアントサーバーモード)

Red Hat JBoss Data Grid のリモートクライアントサーバーモードでロックモードを設定するには、以下のように transaction 要素を使用します。
<transaction locking="OPTIMISTIC/PESSIMISTIC" />

14.3.7. ロックモードの設定 (ライブラリーモード)

Red Hat JBoss Data Grid のライブラリーモードでは、ロックモードが以下のように transaction 要素内で設定されます。
<transaction transactionManagerLookupClass="{TransactionManagerLookupClass}"
	     transactionMode="{TRANSACTIONAL,NON_TRANSACTIONAL}"
	     lockingMode="{OPTIMISTIC,PESSIMISTIC}"
	     useSynchronization="true">
</transaction>
トランザクションキャッシュに使用されるロックモードを設定するには、 lockingMode 値を OPTIMISTIC または PESSIMISTIC に設定します。

14.4. ロック操作

14.4.1. LockManager について

LockManager コンポーネントは、書き込み処理が始まる前にエントリーをロックします。LockManagerLockContainer を使用してロックを見つけたり、ロックを保持および作成します。このような実装では、通常 2 つのタイプの LockContainer が使用されます。1 つ目のタイプはロックストライピングのサポート提供し、2 つ目のタイプはエントリーごとに 1 つのロックをサポートします。

14.4.2. ロックの取得について

Red Hat JBoss Data Grid はデフォルトでリモートロックをレイジーに取得します。ローカルでトランザクションを実行しているノードはロックを取得し、他のクラスターノードは 2 相準備/コミットフェーズに関与するキャッシュキーをロックしようとします。JBoss Data Grid では、明示的または暗示的な悲観的ロックにてキャッシュキーをロックすることが可能です。

14.4.3. 平行性レベルについて

平行性とは、データグリッドと同時に対話するスレッド数のことです。Red Hat JBoss Data Grid では、平行性レベルは、ロックコンテナー内で使用される同時スレッドの数のことです。
JBoss Data  Data Grid では、平行性レベルがストライピングされたロックコンテナーのサイズを決定します。さらに、平行性レベルは DataContainers 内部のコレクションなど、関連するすべての JDK ConcurrentHashMap ベースのコレクションを調整します。

第15章 ロックストライピングのセットアップ

15.1. ロックストライピングについて

ロックストライピングは、キャッシュにあるロック (固定サイズ) の共有コレクションよりロックを割り当てます。ロック割り当ては各エントリーのキーに対するハッシュコードが基になります。ロックストライピングは、オーバーヘッドが固定された非常にスケーラブルなロックメカニズムを提供しますが、同じロックによって無関連なエントリーがブロックされる可能性があります。
Red Hat JBoss Data Grid では、ロックストライピングはデフォルトで無効になります。ロックストライピングが無効であると、各エントリーに対して新しいロックが作成されます。この代替の方法を用いると、より大きな平行スループットが提供されますが、メモリーの追加使用やガベージコレクションのチャーンなどのデメリットも発生します。

15.2. ロックストライピングの設定 (リモートクライアントサーバーモード)

Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおけるロックストライピングは、striping 要素を true に設定して有効になります。

例15.1 ロックストライピング (リモートクライアントサーバーモード)

<locking acquire-timeout="20000"
	 concurrency-level="500"
	 striping="true" />

注記

リモートクライアントサーバーモードのデフォルトの分離モードは READ_COMMITTED です。分離モードを明示的に指定するために isolation 属性が含まれる場合、この属性は無視され、警告がスローされて、デフォルト値が代わりに使用されます。
locking 要素は以下の属性を使用します。
  • acquire-timeout 属性は、ロックの取得を試行する最大時間を指定します。この属性のデフォルト値は 15000 ミリ秒です。
  • concurrencyLevel 属性は、ロックコンテナーの同時実行レベルを指定します。JBoss Data Grid と通信する同時スレッドの数に従ってこの値を設定します。この属性のデフォルト値は 1000 です。
  • striping 属性は、ロックを必要とするすべてのエントリーに対してロックの共有プールを維持するかどうかを指定します (true)。false に設定された場合は、各エントリーに対してロックが作成されます。ロックストライピングによりメモリーフットプリントが制御され、システムでの同時実行性を削減できます。この属性のデフォルト値は false です。

15.3. ロックストライピングの設定 (ライブラリーモード)

ロックストライピングは、Red Hat JBoss Data Grid ではデフォルトで無効にされています。JBoss Data Grid のライブラリーモードでのロックストライピングの設定は、以下の手順で示されたように useLockStriping パラメーターを使用して行います。

手順15.1 ロックストライピングの設定 (ライブラリーモード)

  1. 平行性レベルを設定します。

    concurrencyLevel は、ロックストライピングが有効な場合に使用される共有ロックコレクションのサイズを指定するために使用されます。
    <infinispan>
    	...
    	<default>
    	
    		<locking concurrencyLevel="${VALUE}" />
  2. 分離レベルの設定

    isolationLevel パラメーターは、キャッシュの分離レベルを指定します。有効な分離レベルは READ_COMMITTEDREPEATABLE_READ です。
    <infinispan>
    	...
    	<default>
    	
    		<locking concurrencyLevel="${VALUE}"
    			 isolationLevel="${LEVEL}"/>
  3. ロック取得タイムアウトの指定

    lockAcquisitionTimeout パラメーターは、ロック取得の試行がタイムアウトになった後の時間 (ミリ秒単位) を指定します。
    <infinispan>
    	...
    	<default>
    	
    		<locking concurrencyLevel="${VALUE}"
    			 isolationLevel="${LEVEL}"
    			 lockAcquisitionTimeout="${TIME}"/>
  4. ロックストライピングを設定します。

    useLockStriping パラメーターは、ロックを必要とするすべてのエントリーに対して、共有ロックのプールを維持するかどうかを指定します。FALSE に設定されると、ロックがキャッシュ内のそれぞれのエントリーに対して作成されます。TRUE に設定されると、ロックストライピングは有効にされ、共有ロックは必要に応じてプールから使用されます。
    <infinispan>
    	...
    	<default>
    	
    		<locking concurrencyLevel="${VALUE}"
    			 isolationLevel="${LEVEL}"
    			 lockAcquisitionTimeout="${TIME}"
    			 useLockStriping="${TRUE/FALSE}"/>
  5. 書き込みスキューチェックを設定します。

    writeSkewCheck は、異なるトランザクションからのエントリーへの変更によりトランザクションがロールバックされるかどうかを判別します。true に設定される書き込みスキューにより、isolation_levelREPEATABLE_READ に設定する必要があります。writeSkewCheck および isolation_level のデフォルト値はそれぞれ FALSEREAD_COMMITTED です。
    <infinispan>
    	...
    	<default>
    	
    		<locking concurrencyLevel="${VALUE}"
    			 isolationLevel="${LEVEL}"
    			 lockAcquisitionTimeout="${TIME}"
    			 useLockStriping="${TRUE/FALSE}"
    			 writeSkewCheck="${TRUE/FALSE}" />
    		...
    	
    	</default>
    </infinispan>

第16章 分離レベルのセットアップ

16.1. 分離レベルについて

分離レベルは、リーダーが同時書き込みを見ることができるタイミングを決定します。Red Hat JBoss Data Grid で提供される分離モードは READ_COMMITTEDREPEATABLE_READ の 2 つです。
  • READ_COMMITTED。この分離レベルは、さまざまな要件に適用されます。これは、リモートクライアントサーバーおよびライブラリーモードでのデフォルト値です。
  • REPEATABLE_READ

    重要

    リモートクライアントサーバーモードのロックに有効な唯一の値はデフォルトの READ_COMMITTED 値です。isolation 値で明示的に指定された値は無視されます。
    locking 要素が設定に存在しない場合、デフォルトの分離値は READ_COMMITTED です。
JBoss Data Grid における分離モードの設定例については、ロックストライピングの設定例を参照してください。

16.2. READ_COMMITTED について

READ_COMMITTED は Red Hat JBoss Data Grid で使用できる 2 つの分離モードの 1 つです。
JBoss Data Grid の READ_COMMITTED モードでは、書き込み操作はデータ自体ではなくデータのコピーとして作成されます。書き込み操作は他のデータの書き込みをブロックしますが、書き込みは読み出し操作をブロックしません。そのため、READ_COMMITTEDREPEATABLE_READ の両モードは、書き込み操作がいつ発生するかに関係なく、いつでも読み取り操作を許可します。
READ_COMMITTED モードでは、読み取りの合間に書き込み操作によってデータが変更されると、トランザクション内で同じキーが複数読み取りされた場合に結果が異なる可能性があります。 これは、反復不可能読み出しと呼ばれ、REPEATABLE_READ モードでは回避されます。

16.3. REPEATABLE_READ について

REPEATABLE_READ は Red Hat JBoss Data Grid で使用できる 2 つの分離モードの 1 つです。
従来、REPEATABLE_READ は読み取り操作中の書き込み操作や、書き込み操作時の読み取り操作を許可しません。これにより、単一のトランザクションの同じ行に 2 つの読み取り操作があるのに読み出した値が異なる時に発生する「反復不可能読み取り」が起こらないようにします。
JBoss Data Grid の REPEATABLE_READ 分離モードは、変更が発生する前にエントリーの値を保存します。これにより、同じエントリーの 2 番目の読み取り操作は変更された新しい値ではなく、保存された値を読み出すため、「反復不可能読み取り」の発生を防ぐことができます。そのため、読み出しの合間に書き込み操作が発生しても、2 つの読み取り操作によって読み出される 2 つの値は常に同じになります。

パート VII. キャッシュストアのセットアップと設定

第17章 キャッシュストア

キャッシュストアは、Red Hat JBoss Data Grid を永続データストアに接続します。キャッシュストアは個別のキャッシュに関連付けられます。同じキャッシュマネージャーに接続された個々のキャッシュには、異なるキャッシュストア設定を指定できます。

17.1. キャッシュローダーとキャッシュライター

永続ストアとの統合は、org.infinispan.persistence.spi にある以下の SPI を介して行われます。
  • CacheLoader
  • CacheWriter
  • AdvancedCacheLoader
  • AdvancedCacheWriter
CacheLoaderCacheWriter は、ストアに対して読み書きを行う基本的なメソッドを提供します。CacheLoader は、必要なデータがキャッシュにない場合にデータストアからデータを取得します。
AdvancedCacheLoaderAdvancedCacheWriter は、基礎となるストレージを一括で処理する並列反復、失効したエントリーの削除、クリア、およびサイズ指定などの操作を提供します。
org.infinispan.persistence.file.SingleFileStore インターフェースは、カスタムストア実装を記述するために利用できます (必要な場合)。

注記

以前に、JBoss Data Grid では古い API (CacheLoaderCacheStore により拡張) が使用されていました (ただし、これは引き続き使用されています)。

17.2. キャッシュストアの設定

17.2.1. キャッシュストアの設定

キャッシュストアはチェーンで設定されます。キャッシュの読み取り操作は、データの有効な null 以外の要素が見つかるまで、設定される順番でそれぞれのキャッシュストアをチェックします。書き込み操作は、ignoreModifications 要素が特定のキャッシュストアに対して "true" にされない限り、すべてのキャッシュストアに影響を与えます。

17.2.2. XML を使用したキャッシュストアの設定 (ライブラリーモード)

次の例は、JBoss Data Grid のライブラリーモードで XML を使用したキャッシュストアの設定を示しています。

手順17.1 XML を使用したキャッシュストアの設定

  1. 新しいキャッシュストアの作成

    passivationshared、および preload 設定を指定して、新規のキャッシュストアを作成します。
    1. passivation は Red Hat JBoss Data Grid がストアと通信する方法に影響を与えます。パッシベーションは、インメモリーキャッシュからオブジェクトを削除し、システムまたはデータベースなどの 2 次的なデータストアに書き込みます。パッシベーションはデフォルトで false です。
    2. shared は、キャッシュストアが異なるキャッシュインスタンスによって共有されていることを示します。例えば、クラスター内のすべてのインスタンスが、同じリモートの共有データベースと通信するために同じ JDBC 設定を使用する場合があります。shared は、デフォルトで false になります。true に設定すると、異なるキャッシュインスタンスによって重複データがキャッシュストアに書き込まれることが避けられます。
    3. preload はデフォルトでは false に設定されます。true に設定されると、キャッシュストアに保存されるデータは、キャッシュが起動するとメモリーにプリロードされます。これにより、キャッシュストアのデータが起動後すぐに利用できるようになり、データのレイジーなロードの結果としてキャッシュ操作の遅れを防ぐことができます。プリロードされたデータは、ノード上でローカルにのみに保存され、プリロードされたデータのレプリケーションや分散はありません。Red Hat JBoss Data Grid は、エビクションのエントリーの最大設定数のみをプリロードします。
    <persistence passivation="false" shared="false" preload="true">
  2. 永続性とパージのセットアップ

    1. fetchPersistentState は、キャッシュの永続ステートを取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、fetch persistent 状態は無視されます。複数のキャッシュストアがこのプロパティーを true に設定する場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
    2. purgeSynchronously は、エクスパレーションをエビクションスレッドで発生させるかどうかを制御します。true に設定されると、エビクションスレッドは、返されるものを即時にもたらすのではなく、パージが終了するまでブロックします。purgeSychronously プロパティーはデフォルトで false に設定されます。キャッシュストアが マルチスレッドパージをサポートする場合、期限の切れたエントリーを削除するために purgeThreads が使用されます。purgeThreads は、デフォルトで 1 に設定されます。マルチスレッドパージがサポートされているかを判断するには、キャッシュストアの設定を確認します。
    3. ignoreModifications は、書き込み操作を共有キャッシュストアではなく、ローカルファイルキャッシュストアに許可することで、書き込みメソッドが特定のキャッシュストアにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュストアにのみ存在します。例えば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュストアで適用されます。ignoreModifications はデフォルトではfalse です。
    <persistence passivation="false" shared="false" preload="true">
       <fileStore
               fetchPersistentState="true"
               purgerThreads="3"
               purgeSynchronously="true"
               ignoreModifications="false"
               purgeOnStartup="false"
               location="${java.io.tmpdir}" />
  3. 非同期設定

    これらの属性は、それぞれのキャッシュストアに固有の側面を設定します。例えば、location 属性は、SingleFileStore がデータが含まれるファイルを維持する場所を指します。他のストアには、さらに複雑な設定が必要な場合があります。
    <persistence passivation="false" shared="false" preload="true">
       <fileStore
               fetchPersistentState="true"
               purgerThreads="3"
               purgeSynchronously="true"
               ignoreModifications="false"
               purgeOnStartup="false"
               location="${java.io.tmpdir}" >
          <async
               enabled="true"
               flushLockTimeout="15000"
               threadPoolSize="5" />
       </fileStore>
  4. シングルトンと Push 状態の設定

    1. singletonStore は、クラスター内の 1 つのノードのみによって変更が保存されるのを可能にします。このノードはコーディネーターと呼ばれます。コーディネーターは、インメモリー状態のキャッシュをディスクにプッシュします。この機能は、すべてのノードの enabled 属性を true に設定することによりアクティベートされます。shared パラメーターは、singletonStore を有効にした状態で同時に定義することはできません。enabled 属性はデフォルトでは false です。
    2. pushStateWhenCoordinator はデフォルトでは true に設定されます。true の場合、このプロパティーは、コーディネーターになったノードに、インメモリー状態を基礎となるキャッシュストアに転送させます。このパラメーターは、コーディネーターがクラッシュし、新規のコーディネーターが選択される場合に役に立ちます。
    <persistence passivation="false" shared="false" preload="true">
       <fileStore
               fetchPersistentState="true"
               purgerThreads="3"
               purgeSynchronously="true"
               ignoreModifications="false"
               purgeOnStartup="false"
               location="${java.io.tmpdir}" >
          <async
               enabled="true"
               flushLockTimeout="15000"
               threadPoolSize="5" />
          <singletonStore
               enabled="true"
               pushStateWhenCoordinator="true"
               pushStateTimeout="20000" />
       </fileStore>
    </persistence>

17.2.3. プログラムを使用してキャッシュストアを設定

以下の例では、プログラムを使用してキャッシュストアを設定する方法について示しています。

手順17.2 プログラムを使用してキャッシュストアを設定

  1. 新規の設定ビルダーの作成

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
  2. パッシベーションの設定

    passivation は Red Hat JBoss Data Grid がストアと通信する方法に影響を与えます。パッシベーションは、インメモリーキャッシュからオブジェクトを削除し、システムまたはデータベースなどの 2 次的なデータストアに書き込みます。パッシベーションはデフォルトで false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
  3. 共有のセットアップ

    shared は、キャッシュストアが異なるキャッシュインスタンスによって共有されていることを示します。例えば、クラスター内のすべてのインスタンスが、同じリモートの共有データベースと通信するために同じ JDBC 設定を使用する場合があります。shared は、デフォルトで false になります。true に設定すると、異なるキャッシュインスタンスによって重複データがキャッシュストアに書き込まれることが避けられます。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
  4. プリロードのセットアップ

    preload はデフォルトでは false に設定されます。true に設定されると、キャッシュストアに保存されるデータは、キャッシュが起動するとメモリーにプリロードされます。これにより、キャッシュストアのデータが起動後すぐに利用できるようになり、データのレイジーなロードの結果としてキャッシュ操作の遅れを防ぐことができます。プリロードされたデータは、ノード上でローカルにのみに保存され、プリロードされたデータのレプリケーションや分散はありません。JBoss Data Grid は、エビクションのエントリーの最大設定数のみをプリロードします。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
  5. キャッシュストアの設定

    addSingleFileStore() は、この設定用のキャッシュストアとして SingleFileStore を追加します。addStore メソッドを使用して追加できる、JDBC キャッシュストアなどの他のストアを作成することができます。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
  6. 永続性のセットアップ

    fetchPersistentState は、キャッシュの永続ステートを取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、fetch persistent 状態は無視されます。複数のキャッシュストアがこのプロパティーを true に設定する場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
            .fetchPersistentState(true)
  7. パージのセットアップ

    purgeSynchronously は、エクスパレーションをエビクションスレッドで発生させるかどうかを制御します。true に設定されると、エビクションスレッドは、返されるものを即時にもたらすのではなく、パージが終了するまでブロックします。purgeSychronously プロパティーはデフォルトで false に設定されます。キャッシュストアが マルチスレッドパージをサポートする場合、期限の切れたエントリーを削除するために purgeThreads が使用されます。purgeThreads は、デフォルトで 1 に設定されます。マルチスレッドパージがサポートされているかを判断するには、キャッシュストアの設定を確認します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
            .fetchPersistentState(true)
            .purgerThreads(3)
            .purgeSynchronously(true)
  8. 変更の設定

    ignoreModifications は、書き込み操作を共有キャッシュストアではなく、ローカルファイルキャッシュストアに許可することで、書き込みメソッドが特定のキャッシュストアにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュストアにのみ存在します。例えば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュストアで適用されます。ignoreModifications はデフォルトではfalse です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
            .fetchPersistentState(true)
            .purgerThreads(3)
            .purgeSynchronously(true)
            .ignoreModifications(false)
  9. 非同期設定

    これらの属性は、それぞれのキャッシュストアに固有の側面を設定します。例えば、location 属性は、SingleFileStore がデータが含まれるファイルを維持する場所を指します。他のストアには、さらに複雑な設定が必要な場合があります。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
            .fetchPersistentState(true)
            .purgerThreads(3)
            .purgeSynchronously(true)
            .ignoreModifications(false)
            .purgeOnStartup(false)
            .location(System.getProperty("java.io.tmpdir"))
            .async()
                .enabled(true)
                .flushLockTimeout(15000)
                .threadPoolSize(5)
  10. シングルトンの設定

    singletonStore は、クラスター内の 1 つのノードのみによって変更が保存されるのを可能にします。このノードはコーディネーターと呼ばれます。コーディネーターは、インメモリー状態のキャッシュをディスクにプッシュします。この機能は、すべてのノードの enabled 属性を true に設定することによりアクティベートされます。shared パラメーターは、singletonStore を有効にした状態で同時に定義することはできません。enabled 属性はデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
            .fetchPersistentState(true)
            .purgerThreads(3)
            .purgeSynchronously(true)
            .ignoreModifications(false)
            .purgeOnStartup(false)
            .location(System.getProperty("java.io.tmpdir"))
            .async()
                .enabled(true)
                .flushLockTimeout(15000)
                .threadPoolSize(5)
            .singletonStore()
               .enabled(true)
  11. Push 状態のセットアップ

    pushStateWhenCoordinator はデフォルトでは true に設定されます。true の場合、このプロパティーは、コーディネーターになったノードに、インメモリー状態を基礎となるキャッシュストアに転送させます。このパラメーターは、コーディネーターがクラッシュし、新規のコーディネーターが選択される場合に役に立ちます。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.persistence()
        .passivation(false)
        .shared(false)
        .preload(true)
        .addSingleFileStore()
            .fetchPersistentState(true)
            .purgerThreads(3)
            .purgeSynchronously(true)
            .ignoreModifications(false)
            .purgeOnStartup(false)
            .location(System.getProperty("java.io.tmpdir"))
            .async()
                .enabled(true)
                .flushLockTimeout(15000)
                .threadPoolSize(5)
            .singletonStore()
               .enabled(true)
               .pushStateWhenCoordinator(true)
               .pushStateTimeout(20000);

17.2.4. SKIP_CACHE_LOAD フラグについて

Red Hat JBoss Data Grid のリモートクライアントモードでは、キャッシュがキャッシュストアからプレロードされ、エビクションが無効な場合に、読み取り要求がメモリーに移動します。読み取り要求時にエントリーがメモリー内にないと、キャッシュストアがアクセスされ、読み取りパフォーマンスが影響を受けることがあります。
キーがメモリーにない場合にキャッシュストアの参照を回避するには、SKIP_CACHE_LOAD フラグを使用します。

17.3. 要求キャッシュストア

共有キャッシュストアとは、複数のキャッシュインスタンスによって共有されるキャッシュストアのことです。
クラスターのすべてのインスタンスが、同じ JDBC 設定を使用して同じリモート共有データベースと通信する場合、キャッシュストアが便利です。このようなインスタンスにおいて、共有キャッシュストアを設定すると、複数のキャッシュインスタンスが同じデータをキャッシュストアに書き込もうとした場合に不必要な書き込み操作が繰り返し発生しないようにします。

17.3.1. インバリデーションモードと共有キャッシュストア

Red Hat JBoss Data Grid のインバリデーションモードを共有キャッシュストアと共に使用すると、リモートキャッシュが共有キャッシュストアを参照して、変更されたデータを読み出すようになります。
インバリデーションモードを共有キャッシュストアと共に使用する利点には次のようなものがあります。
  • 更新されたデータが含まれるレプリケーションメッセージよりも無効化メッセージはかなり小型であるため、ネットワークトラフィックが軽減されます。
  • 残りのクラスターキャッシュは、必要な場合のみ変更されたデータを共有キャッシュストアよりレイジーにルックアップするため、ネットワークトラフィックがさらに軽減されます。

17.3.2. キャッシュストアとキャッシュパッシベーション

Red Hat JBoss Data Grid では、エントリーのパッシベーションを強制したり、キャッシュでエビクションをアクティベートしたりするためにキャッシュストアを使用することができます。パッシベーションモードまたはアクティベーションモードが使用されると、設定されたキャッシュストアがデータストアに対して読み書きを実行します。
JBoss Data Grid でパッシベーションが無効になっている場合、要素の変更や追加、削除が実行された後にキャッシュストアがストアの変更を永続化します。

17.3.3. アプリケーションキャッシュストア登録

分離されたデプロイメントに対してアプリケーションキャッシュストアを登録する必要はありません。レイジーデシリアライゼーションを使用するとこの問題を回避できるため、Red Hat JBoss Data Grid では必須ではありません。

17.4. 接続ファクトリー

Red Hat JBoss Data Grid では、すべての JDBC キャッシュストアが ConnectionFactory 実装に依存してデータベースへの接続を取得します。このプロセスは接続管理またはプーリングとも呼ばれます。
接続ファクトリーは ConnectionFactoryClass 設定属性を使用して指定することができます。JBoss Data Grid には次の ConnectionFactory 実装が含まれています。
  • ManagedConnectionFactory
  • SimpleConnectionFactory。

17.4.1. ManagedConnectionFactory について

ManagedConnectionFactory は、アプリケーションサーバーなど管理された環境内での使用に適した接続ファクトリーです。この接続ファクトリーは JNDI ツリー内の設定された場所を探索し、接続管理を DataSource へ委譲できます。 ManagedConnectionFactoryDataSource が含まれる管理された環境内で使用されます。この Datasource は接続プーリングへ委譲されます。

17.4.2. SimpleConnectionFactory について

SimpleConnectionFactory は呼び出しごとにデータベース接続を作成する接続ファクトリーです。この接続ファクトリーは実稼働環境での使用向けには設計されていません。

第18章 キャッシュストアの実装

キャッシュストアは、Red Hat JBoss Data Grid を永続データストアに接続します。キャッシュストアは個別のキャッシュに関連付けられます。同じキャッシュマネージャーに接続された個々のキャッシュには、異なるキャッシュストア設定を指定できます。

18.1. キャッシュストアの比較

要件に基いてキャッシュストアを選択します。以下に、Red Hat JBoss Data Grid で利用可能なキャッシュストア間の主な違いの概要を示します。
  • 単一ファイルキャッシュストアはローカルのファイルキャッシュストアです。これにより、クラスタ化されたキャッシュの各ノードに対してデータがローカルで永続化されます。単一ファイルキャッシュストアは、優れた読み書きパフォーマンスを提供しますが、キーがメモリーに保持され、各ノードで大きいデータセットを永続化するときに使用が制限されます。詳細については、「単一ファイルキャッシュストア」を参照してください。
  • LevelDB ファイルキャッシュストアは、高い読み書きパフォーマンスを提供するローカルのファイルキャッシュストアです。キーがメモリに保持される単一ファイルキャッシュストアの制限はありません。詳細については、「LevelDB キャッシュストア」を参照してください。
  • JDBC キャッシュストアは、必要に応じて共有できるキャッシュストアです。使用時に、クラスタ化されたキャッシュのすべてのノードは、クラスターの各ノードに対して単一のデータベースまたはローカルの JDBC データベースに永続化されます。共有キャッシュストアには、LevelDB キャッシュストアなどのローカルキャッシュストアのスケーラビリティーとパフォーマンスがありませんが、永続化データに対して単一の場所が提供されます。JDBC キャッシュストアでは、エントリーがバイナリー blob として永続化され、JBoss Data Grid 外部で読み取ることができません。詳細については、「JDBC ベースのキャッシュストア」を参照してください。
  • JPA キャッシュストア (ライブラリーモードでのみサポート) は JDBC キャッシュストアのような要求キャッシュストアですが、データベースに永続化するときにスキーマ情報が保持されます。したがって、永続化されたエントリーは、JBoss Data Grid 外部で読み取ることができます。詳細については、「JPA キャッシュストア」を参照してください。

18.2. 単一ファイルキャッシュストア

Red Hat JBoss Data Grid には、ファイルシステムベースのキャッシュストアの 1 つである SingleFileCacheStore が含まれています。
SingleFileCacheStore は、単純なファイルシステムベースの実装であり、古くなったファイルシステムベースのキャッシュストアである FileCacheStore の代わりになるものです。
SingleFileCacheStore は、単一ファイルに、すべてのキーバリューペアと、それらの対応するメタデータ情報を保存します。データ検索のスピードを速めるために、すべてのキーとそれらの値およびメタデータの位置をメモリーに保存します。そのため、単一ファイルキャッシュストアを使用すると、キーのサイズと保存されるキーの数量に応じて、必要なメモリーが若干増加します。そのため、SingleFileCacheStore は、キーが大きすぎる場合のユースケースでは推奨されません。
メモリー消費量を減らすために、キャッシュストアのサイズを、ファイルに保存するエントリーの固定数に設定することができます。ただし、これは Infinispan がキャッシュとして使用される場合にのみ機能します。Infinispan がこのように使用されると、Infinispan にないデータは、正式なデータストアから再計算されるか、または再度取り込まれ、Infinispan キャッシュに保存される可能性があります。この制限がある理由は、エントリーの最大数にいったん達すると、キャッシュストアの古いデータが削除されるため、Infinispan が正式なデータストアとして使用される場合、このユースケースでは望ましくないデータ損失が発生する可能性があります。
SingleFileCacheStore には制限があるため、実稼働環境では制限内での使用が可能です。適切なファイルロックがなく、データが破損する原因となるため、共有ファイルシステム (NFS や Windows の共有など) 上では使用しないでください。また、ファイルシステムは本質的にトランザクションではないため、トランザクションコンテキストでキャッシュが使用されると、コミットフェーズ中にファイルが障害を書き込む原因となります。

18.2.1. 単一ファイルストアの設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおける単一ファイルストアの設定の例です。

手順18.1 単一ファイルストアの設定

  1. キャッシュ名の追加

    キャッシュの名前を指定するため、local-cache 属性の name パラメーターが使用されます。
    <local-cache name="default">
  2. キャッシュごとの統計

    statistics がコンテナーレベルで有効にされている場合は、statistics 属性を false に設定することにより、キャッシュごとに統計を有効または無効にします。
    <local-cache name="default" statistics="true">
  3. file-store 要素の設定

    file-store 要素は、単一ファイルストアの設定情報を指定します。
    file-store 要素の name パラメーターが、ファイルストアの名前を指定するために使用されます。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore" />
  4. passivation パラメーターの設定

    passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true" />
  5. purge パラメーターの設定

    purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターの有効な値は truefalse です。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true" />
  6. shared パラメーターを設定します。

    shared パラメーターは、複数のキャッシュストアインスタンスがキャッシュストアを共有する場合に使用されます。複数のキャッシュインスタンスが同じ変更内容を複数回書き込まないようにするため、このパラメーターを設定することができます。このパラメーターに有効な値は truefalse です。ただし、shared パラメーターは file-store には推奨されません。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false" />
  7. relative-to パラメーター内のディレクトリーパスを指定します。

    relative-to プロパティーは、file-store がデータを保存するディレクトリーです。これは名前付きのパスを定義するために使用されます。
    path プロパティーは、データが保存されるファイルの名前です。これは、完全パスを決定するために relative-to プロパティーの値に追加される相対パス名です。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}" />
    </local-cache>
  8. 最大エントリー数の設定

    maxEntries パラメーターは、許可されるエントリーの最大数を指定します。無制限のエントリーの場合のデフォルト値は -1 です。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"/>
    </local-cache>
  9. fetch-state パラメーターの設定

    fetch-state パラメーターは、true に設定されている場合に、クラスターへ参加する際に永続状態を取り込みます。複数のキャッシュストアがチェーン化されている場合、その内の 1 つのみでこのプロパティーを有効にできます。共有キャッシュストアが使用されている場合、永続状態の転送は、データを提供する同じ永続ストアがそれを受信するだけなので意味をなしません。そのため、共有キャッシュストアが使用されている場合、キャッシュストアがこのプロパティーを true に設定している場合であっても、永続状態の転送を許可しません。クラスター化環境でのみこのプロパティーを true に設定することが推奨されます。このパラメーターのデフォルト値は false です。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"
                    fetch-state="true"/>
    </local-cache>
  10. Preload パラメーターの設定

    preload パラメーターは、true に設定されている場合に、キャッシュの起動時にキャッシュストアに保存されたデータをメモリーにロードします。ただし、このパラメーターを true に設定することにより、起動時間が増加するためパフォーマンスへの影響があります。このパラメーターのデフォルト値は false です。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"
                    fetch-state="true"
                    preload="false"/>
    </local-cache>
  11. シングルトンパラメーターの設定

    singleton パラメーターは、シングルトンストアのキャッシュストアを有効にします。SingletonStore は、クラスター内の唯一のインスタンスが基礎となるストアと通信する場合にのみ使用される委譲するキャッシュストアです。ただし、singleton パラメーターは file-store には推奨されません。
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"
                    fetch-state="true"
                    preload="false"
                    singleton="true"/>
    </local-cache>

18.2.2. 単一ファイルストアの設定 (ライブラリーモード)

Red Hat JBoss Grid のライブラリーモードで、単一ファイルキャッシュストアを以下のように設定します。

手順18.2 ライブラリーモードでの単一ファイルストアの設定

singleFile 要素は、単一ファイルキャッシュストアを設定するために使用されます。infinispan.xml で以下を設定します。
  1. 名前の値を namedCache 要素に追加します。以下はこの手順の例になります。
    <namedCache name="writeThroughToFile">
  2. persistence 要素で、passivation パラメーターを false に設定します。使用できる値は「true」と「false」です。
    <namedCache name="writeThroughToFile">
          <persistence passivation="false" />
  3. singleFile 要素を使用して、単一ファイルの設定をセットアップします。
    • fetchPersistentState - true に設定されると、クラスターへ参加する時に永続状態が取り込まれます。複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアのみがこのプロパティーを true に設定できます。この値のデフォルトは false です。
    • ignoreModifications パラメーターは、キャッシュを変更する操作 (例: 配置、削除、消去、格納など) がキャッシュストアに影響を与えるかどうかを決定します。結果として、キャッシュストアは、キャッシュと同期が取れなくなります。
    • purgeOnStartup パラメーターは、初回起動時にキャッシュがパージされるかどうかを指定します。
    • shared パラメーターは、複数のキャッシュインスタンスがキャッシュストアを共有する場合に true に設定されます。これにより、複数のキャッシュインスタンスが同じ変更内容を個別に書き込むことを防ぐことができます。この属性のデフォルトは false です。ただし、shared パラメーターは file-store には推奨されません。
    • preload パラメーターは、キャッシュストアデータがメモリーにプリロードされ、起動後すぐにアクセス可能にするかどうかを設定します。これを true に設定する不利な点には、起動時間が増えることが挙げられます。この属性のデフォルト値は false です。
    • location パラメーターはファイルストアの場所を示します。
    • maxEntries パラメーターは、許可されるエントリーの最大数を指定します。無制限のエントリーの場合のデフォルト値は -1 です。
    • maxKeysInMemory パラメーターは、データのルックアップを迅速化を図るために使用されます。単一ファイルストアは、maxKeysInMemory パラメーターを使用して、キーのインデックスとファイル内のキーの場所を保持します。このパラメーターのデフォルト値は -1 です。
    <namedCache name="writeThroughToFile">
          <persistence passivation="false">
             <singleFile fetchPersistentState="true" 
                         ignoreModifications="false"
                         purgeOnStartup="false" 
                         shared="false"
                         preload="false"
                         location="/tmp/Another-FileCacheStore-Location"
                         maxEntries="100"
                         maxKeysInMemory="100">
             </singleFile>
          </persistence>
     </namedCache>
  4. 非同期設定を行うには async 要素を追加します。
    • enabled パラメーターは、ファイルストアを非同期にするかどうかを決定します。
    • threadPoolSize パラメーターは、変更をストアに同時に適用するスレッドの数を指定します。このパラメーターのデフォルト値は 5 です。
    • flushLockTimeout パラメーターは、キャッシュストアに定期的にフラッシュする状態を保護するロックを取得するための時間を指定します。このパラメーターのデフォルト値は 1 です。
    • modificationQueueSize パラメーターは、非同期ストアの変更キューのサイズを指定します。基礎となるキャッシュストアがこのキューを処理するよりも速く更新される場合に、その期間において非同期ストアは同期ストアのように動作し、キューがさらに多くの要素を許可できるようになるまでブロックします。このパラメーターのデフォルト値は 1024 要素です。
    • shutdownTimeout パラメーターは、キャッシュストアを停止する時間を指定します。このパラメーターのデフォルト値は 25 秒です。
    <namedCache name="writeThroughToFile">
          <persistence passivation="false">
             <singleFile fetchPersistentState="true" 
                         ignoreModifications="false"
                         purgeOnStartup="false" 
                         shared="false"
                         preload="false"
                         location="/tmp/Another-FileCacheStore-Location"
                         maxEntries="100"
                         maxKeysInMemory="100">
                <async enabled="true" 
        	           threadPoolSize="500"
        	           flushLockTimeout="1"
    	           modificationQueueSize="1024"
    	           shutdownTimeout="25000"/>
            </singleFile>
          </persistence>
     </namedCache>

18.2.3. FileCacheStore から SingleFileCacheStore へのデータ移行

Red Hat JBoss Data Grid  は、以前のバージョンの JBoss Data Grid とは異なる形式でデータを保存します。そのため、新しいバージョンの JBoss Data Grid は、古いバージョンで保存されたデータを読み込むことはできません。ローリングアップグレードを使用すると、旧バージョンの JBoss Data Grid で使用された形式で永続化されたデータを新しい形式にアップグレードすることができます。さらに、新たなバージョンの JBoss Data Grid は、永続性設定情報を別の場所に保存します。
ローリングアップグレードは、JBoss Data Grid インストールをサービスをシャットダウンせずにアップグレードするプロセスです。ライブラリーモードでは、JBoss Data Grid がライブラリーモードで実行されるノードのインストールを指します。JBoss Data Grid サーバーの場合は、サーバー側のコンポーネントを指します。このアップグレードは、ハードウェア変更または JBoss Data Grid のアップグレードなどのソフトウェアの変更のいずれかによって発生する場合があります。
ローリングアップグレードは JBoss Data Grid のリモートクライアントサーバーモードでのみ利用できます。

18.3. LevelDB キャッシュストア

LevelDB は、文字列キーから文字列値への順序付けられたマッピングを提供するキーバリューのストレージエンジンです。
LevelDB キャッシュストアは 2 つのファイルシステムディレクトリーを使用します。それぞれのディレクトリーは、LevelDB データベースについて設定されます。1 つのディレクトリーは、期限が切れていないデータを保存し、2 つ目のディレクトリーは、パージの前に期限の切れたキーを保存します。

18.3.1. LevelDB キャッシュストアの設定

手順18.3 LevelDB キャッシュストアの設定

  • データベースを設定するには、standalone.xml のキャッシュ定義に以下の要素を追加します。
    <leveldb-store path="/path/to/leveldb/data"
        passivation="false"
        purge="false" >
        <expiration path="/path/to/leveldb/expires/data" />
        <implementation type="JNI" />
    </leveldb-store>

18.3.2. LevelDB キャッシュストアのプログラムを使用した設定

以下は、LevelDB キャッシュストアのプログラミンによる設定例です。

手順18.4 LevelDB キャッシュストアのプログラムを使用した設定

  1. 新規の設定ビルダーの作成

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
  2. LevelDBStoreConfigurationBuilder ストアの追加

    ストアを LevelDBCacheStoreConfigurationBuilder インスタンスに追加して、その設定を構築します。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
                    .addStore(LevelDBStoreConfigurationBuilder.class)
  3. ロケーションのセットアップ

    LevelDB キャッシュストアのロケーションパスを設定します。指定したパスは、主なキャッシュストアデータを保存します。ディレクトリーがない場合は自動的に作成されます。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
                    .addStore(LevelDBStoreConfigurationBuilder.class)
                    .location("/tmp/leveldb/data")
  4. 期限切れのロケーションのセットアップ

    LevelDB ストアの expiredLocation パラメーターを使用して、期限切れデータのロケーションを指定します。指定されたパスは、パージされる前に期限切れデータを保存します。ディレクトリーがない場合は自動的に作成されます。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
                    .addStore(LevelDBStoreConfigurationBuilder.class)
                    .location("/tmp/leveldb/data")
                    .expiredLocation("/tmp/leveldb/expired").build();

注記

プログラムを使用した設定は、Red Hat JBoss Data Grid ライブラリーモードのみで利用できます。

18.3.3. LevelDB キャッシュストアの XML 設定例 (ライブラリーモード)

以下は、LevelDB キャッシュストアの XML 設定例です。

手順18.5 LevelDB キャッシュストアの XML 設定例

  1. namedCache 要素の追加

    以下のように namedCache 要素の name パラメーターを使用して LevelDB キャッシュストアの名前を指定します。
    <namedCache name="vehicleCache">
  2. persistence 要素の追加

    以下のように persistence 要素の passivation パラメーターの値を指定します。使用できる値は true および false です。
    <namedCache name="vehicleCache">
        <persistence passivation="false">
  3. leveldbStore 要素の追加

    以下のように leveldbStore 要素の location パラメーターを使用して主なキャッシュストア日付を保存するロケーションを指定します。ディレクトリーがない場合は自動的に作成されます。以下はこの手順の例になります。
    <namedCache name="vehicleCache">
          <persistence passivation="false">
              <leveldbStore location="/path/to/leveldb/data" />
  4. 期限切れの値の設定

    以下のように expiredLocation パラメーターを使用して期限切れデータのロケーションを指定します。ディレクトリーは、パージされる前の期限切れのデータを保存します。ディレクトリーがない場合は自動的に作成されます。
    <namedCache name="vehicleCache">
          <persistence passivation="false">
              <leveldbStore location="/path/to/leveldb/data"  
                         expiredLocation="/path/to/expired/data" />
  5. Shared パラメーターの設定

    以下のように leveldbStore 要素の shared パラメーターの値を指定します。使用できる値は true および false です。
    <namedCache name="vehicleCache">
          <persistence passivation="false">
              <leveldbStore location="/path/to/leveldb/data"  
                         expiredLocation="/path/to/expired/data" shared="true" />
  6. Preload パラメーターの設定

    以下のように leveldbStore 要素の preload パラメーターの値を指定します。使用できる値は true および false です。
    <namedCache name="vehicleCache">
          <persistence passivation="false">
              <leveldbStore location="/path/to/leveldb/data"  
                         expiredLocation="/path/to/expired/data" shared="true" preload="true"/>
          </persistence>
       </namedCache>

18.3.4. JBoss Operations Network を使用した LevelDB キャッシュストアの設定

以下の手順に従い、JBoss Operations Network を使用して新しい LevelDB キャッシュストアをセットアップします。

手順18.6

  1. Red Hat JBoss Operations Network 3.2 以上がインストールされ、起動されていることを確認します。
  2. JBoss Operations Network 3.2.0 用 Red Hat JBoss Data Grid プラグインパックをインストールします。
  3. JBoss Data Grid がインストールされ、起動されていることを確認します。
  4. JBoss Data Grid サーバーをインベントリーにインポートします。
  5. JBoss Data Grid 接続設定を実行します。
  6. 以下のように新しい LevelDB キャッシュストアを作成します。
    Use JBoss Operations Network to create a new cache store.

    図18.1 新しい LevelDB キャッシュストアの作成

    1. default キャッシュを右クリックします。
    2. メニューで、Create Child オプションにカーソルを置きます。
    3. サブメニューで、LevelDB Store をクリックします。
  7. 以下のように新しい LevelDB キャッシュストアの名前を指定します。
    Name the new LevelDB Cache Store

    図18.2 新しい LevelDB キャッシュストアの名前指定

    1. 表示された Resource Create Wizard で、新しい LevelDB キャッシュストアの名前を追加します。
    2. Next クリックして作業を継続します。
  8. 以下のように LevelDB キャッシュストアを設定します。
    Configure the new LevelDB Cache Store

    図18.3 LevelDB キャッシュストアの設定

    1. 設定ウィンドウのオプションを使用して新しい LevelDB キャッシュストアを設定します。
    2. Finish をクリックして設定を完了します。
  9. 以下のように再起動操作をスケジュールします。
    Schedule a restart operation

    図18.4 再起動操作のスケジュール

    1. 画面の左パネルで、JBossAS7 Standalone Servers エントリーを展開します (まだ展開されていない場合)。
    2. 展開されたメニュー項目から JDG (0.0.0.0:9990) をクリックします。
    3. 画面の右パネルに、選択されたサーバーの詳細が表示されます。Operations タブをクリックします。
    4. Operation ドロップダウンボックスで、Restart 操作を選択します。
    5. Now エントリーのラジオボタンを選択します。
    6. Schedule をクリックしてサーバーをすぐに再起動します。
  10. 以下のように新しい LevelDB キャッシュストアを検出します。
    Discover the new LevelDB cache store

    図18.5 新しい LevelDB キャッシュストアの検出

    1. 画面の左パネルで、指定された順序で次の項目を選択して展開します: JBossAS7 Standalong ServersJDG (0.0.0.0:9990)infinispanCache ContainerslocalCachesdefaultLevelDB Stores
    2. 新しい LevelDB キャッシュストアの名前をクリックして右パネルの設定情報を表示します。

18.4. JDBC ベースのキャッシュストア

Red Hat JBoss Data Grid は、一般的なデータストレージ形式と共に使用される複数のキャッシュストアを提供します。JDBC ベースのキャッシュストアは、JDBC ドライバーを公開するキャッシュストアと共に使用されます。JBoss Data Grid は、永続化されるキーに応じて以下の JDBC ベースのキャッシュストアを提供します。
  • JdbcBinaryStore
  • JdbcStringBasedStore
  • JdbcMixedStore

18.4.1. JdbcBinaryStores

JdbcBinaryStore はすべてのキータイプをサポートします。同じテーブル行/Blob の同じハッシュ値 (キー上の hashCode メソッド) を持つすべてのキーを格納します。組み込まれるキーに共通するハッシュ値が、テーブルの行/Blob の主キーとして設定されます。このハッシュ値により、JdbcBinaryStore は大変優れた柔軟性を提供しますが、これにより平行性とスループットのレベルが下がります。
たとえば、3 つのキー (k1k2k3) のハッシュコードが同じである場合、同じテーブル行に格納されます。3 つの異なるスレッドが k1k2k3 を同時に更新しようとすると、すべてのキーが同じ行を共有するため同時には更新できないことから、順次更新する必要があります。

18.4.1.1. JdbcBinaryStore の設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcBinaryStore の設定です。

手順18.7 リモートクライアントサーバーノード用に JdbcBinaryStore を設定します。

  1. binary-keyed-jdbc-store 要素

    binary-keyed-jdbc-store 要素は、バイナリのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. datasource パラメーターはデータソースの JNDI 名を定義します。データソースの詳細については、「JDBC 」を参照してください。
    2. passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
    3. preload パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターの有効な値は truefalse です。
    4. purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターの有効な値は truefalse です。
    <local-cache>
    	...
    	<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="${true/false}" 
    				 preload="${true/false}" 
    				 purge="${true/false}">
  2. binary-keyed-table 要素

    binary-keyed-table 要素は、バイナリーのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
    1. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <local-cache>
    	...
    	<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="${true/false}" 
    				 preload="${true/false}" 
    				 purge="${true/false}">
                   	<binary-keyed-table prefix="JDG">
  3. id-column 要素

    id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <local-cache>
    	...
    	<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="${true/false}" 
    				 preload="${true/false}" 
    				 purge="${true/false}">
                   	<binary-keyed-table prefix="JDG">
                   		<id-column name="id" 
    				   type="${id.column.type}"/>
  4. data-column 要素

    data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <local-cache>
    	...
    	<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="${true/false}" 
    				 preload="${true/false}" 
    				 purge="${true/false}">
                   	<binary-keyed-table prefix="JDG">
                   		<id-column name="id" 
    				   type="${id.column.type}"/>
                   		<data-column name="datum" 
    				     type="${data.column.type}"/>
  5. timestamp-column 要素

    timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <local-cache>
    	...
    	<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="${true/false}" 
    				 preload="${true/false}" 
    				 purge="${true/false}">
                   	<binary-keyed-table prefix="JDG">
                   		<id-column name="id" 
    				   type="${id.column.type}"/>
                   		<data-column name="datum" 
    				     type="${data.column.type}"/>
                  		<timestamp-column name="version" 
    					  type="${timestamp.column.type}"/>
                  	</binary-keyed-table>
           	</binary-keyed-jdbc-store>
    </local-cache>
    

18.4.1.2. JdbcBinaryStore の設定 (ライブラリーモード)

以下は、JdbcBinaryStore の設定例です。

手順18.8 ライブラリーモードの JdbcBinaryStore の設定

  1. binaryKeyedJdbcStore 要素

    binaryKeyedJdbcStore 要素は、キャッシュストアを設定するための次のパラメーターを使用します。
    1. fetchPersistentState パラメーターは、クラスターへ参加する時に永続状態が取り込まれるかを決定します。クラスター環境でレプリケーションとインバリデーションを使用している場合は、これを true に設定します。さらに、複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアのみがこのプロパティーを有効に設定できます。共有キャッシュストアが使用されている場合、キャッシュは、このプロパティーが true に設定されているにも関わらず、永続状態の転送を許可しません。fetchPersistentState パラメーターはデフォルトでは false に設定されます。
    2. ignoreModifications パラメーターは、キャッシュを変更する操作 (例: 配置、削除、消去、保存など) がキャッシュストアに影響を与えるかどうかを決定します。結果として、キャッシュストアは、キャッシュと同期しなくなります。
    3. purgeOnStartup パラメーターは、初回起動時にキャッシュがパージされるかどうかを指定します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
  2. connectionPool 要素

    connectionPool 要素は、次のパラメーターを使用して JDBC ドライバーの接続プールを指定します。
    1. connectionUrl パラメーターは、JDBC ドライバー固有の接続 URL を指定します。
    2. username パラメーターには、connectionUrl 経由で接続するために使用されるユーザー名が含まれます。
    3. driverClass パラメーターは、データベースに接続するために使用されるドライバーのクラス名を指定します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
  3. binaryKeyedTable 要素

    binaryKeyedTable 要素は、キャッシュエントリーを保存するテーブルを定義します。これは、キャッシュストアを設定するために以下のパラメーターを使用します。
    1. dropOnExit パラメーターは、シャットダウン時にデータベーステーブルがドロップされるかどうかを指定します。
    2. createOnStart パラメーターは、スタートアップ時にストアによってデータベーステーブルが作成されるかどうかを指定します。
    3. prefix パラメーターは、キャッシュバケットテーブルの名前を作成する際に、ターゲットキャッシュの名前に付与される文字列を定義します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<binaryKeyedTable dropOnExit="true" 
    				  createOnStart="true" 
    				  prefix="ISPN_BUCKET_TABLE">
  4. idColumn 要素

    idColumn 要素は、キャッシュキーまたはバケット ID が保存される列を定義します。これは以下のパラメーターを使用します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<binaryKeyedTable dropOnExit="true" 
    				  createOnStart="true" 
    				  prefix="ISPN_BUCKET_TABLE">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
  5. dataColumn 要素

    dataColumn 要素は、キャッシュエントリーまたはバケットが保存される列を指定します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<binaryKeyedTable dropOnExit="true" 
    				  createOnStart="true" 
    				  prefix="ISPN_BUCKET_TABLE">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
  6. timestampColumn 要素

    timestampColumn 要素は、キャッシュエントリーまたはバケットのタイムスタンプが保存される列を指定します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<binaryKeyedTable dropOnExit="true" 
    				  createOnStart="true" 
    				  prefix="ISPN_BUCKET_TABLE">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
    			<timestampColumn name="TIMESTAMP_COLUMN" 
    					 type="BIGINT" />
    		</binaryKeyedTable>
    	</binaryKeyedJdbcStore>
    </persistence>

18.4.1.3. JdbcBinaryStore のプログラムを用いた設定

以下は、JdbcBinaryStore の設定例です。

手順18.9 JdbcBinaryStore のプログラムを用いた設定 (ライブラリーモード)

  1. 新規の設定ビルダーの作成

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
  2. JdbcBinaryStoreConfigurationBuilder の追加

    このストアに関連する特定の設定を構築するには、 JdbcBinaryStore 設定ビルダーを追加します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
  3. 永続性のセットアップ

    fetchPersistentState は、キャッシュの永続状態を取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、永続状態の取り込みは無視されます。複数のキャッシュローダーがこのプロパティーを true に設定する場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
  4. 変更の設定

    ignoreModifications は、書き込み操作を共有キャッシュローダーではなく、ローカルファイルキャッシュローダーに許可することで、書き込みメソッドが特定のキャッシュローダーにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュローダーにのみ存在します。たとえば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュローダーで適用されます。ignoreModifications はデフォルトではfalse です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
  5. パージの設定

    purgeOnStartup は、初回の起動時にキャッシュがパージされるかどうかを指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
  6. テーブルの設定

    1. Drop Table On Exit メソッドの設定

      dropOnExit は、キャッシュストアが停止している際にテーブルを破棄するかどうかを決定します。これは、デフォルトでは false に設定されます。
    2. Create Table On Start メソッドの設定

      createOnStart は、現在テーブルが存在しない場合にキャッシュストアを起動すると、テーブルを作成します。このメソッドはデフォルトでは true です。
    3. Table Name Prefix の設定

      tableNamePrefix は、データが保存されるテーブルの名前にプレフィックスを設定します。
    4. idColumnName

      idColumnName プロパティーは、キャッシュキーまたはバケット ID が保存される列を定義します。
    5. dataColumnName

      dataColumnName プロパティーは、キャッシュエントリーまたはバケット ID が保存される列を指定します。
    6. timestampColumnName

      timestampColumnName 要素は、キャッシュエントリーのタイムスタンプまたはバケットが保存される列を指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
         .table()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_BUCKET_TABLE")
            .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
            .dataColumnName("DATA_COLUMN").dataColumnType("BINARY")
            .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
  7. connectionPool 要素

    connectionPool 要素は、次のパラメーターを使用して JDBC ドライバーの接続プールを指定します。
    1. connectionUrl パラメーターは、JDBC ドライバー固有の接続 URL を指定します。
    2. username パラメーターには、connectionUrl 経由で接続するために使用されるユーザー名が含まれます。
    3. driverClass パラメーターは、データベースに接続するために使用されるドライバーのクラス名を指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
         .table()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_BUCKET_TABLE")
            .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
            .dataColumnName("DATA_COLUMN").dataColumnType("BINARY")
            .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
         .connectionPool()
            .connectionUrl("jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1")
            .username("sa")
            .driverClass("org.h2.Driver");
    

注記

プログラムを使用した設定は、Red Hat JBoss Data Grid ライブラリーモードのみで利用できます。

18.4.2. JdbcStringBasedStores

JdbcStringBasedStore は複数のエントリーを各行にグループ化せずに、各エントリーをテーブルの独自の行に格納するため、同時負荷の下でスループットが増加します。また、各キーを String オブジェクトへマッピングする (プラグ可能な) バイジェクション (bijection) も使用します。Key2StringMapper インターフェースはバイジェクションを定義します。
Red Hat JBoss Data Grid には、プリミティブタイプを処理する DefaultTwoWayKey2StringMapper と呼ばれるデフォルトの実装が含まれています。

18.4.2.1. JdbcStringBasedStore の設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードの JdbcStringBasedStore のサンプル設定です。

手順18.10 リモートクライアントサーバーモードでの JdbcStringBasedStore の設定

  1. string-keyed-jdbc-store 要素

    string-keyed-jdbc-store 要素は、文字列ベースのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. datasource パラメーターはデータソースの JNDI 名を定義します。データソースの詳細については、「JDBC 」を参照してください。
    2. passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
    3. preload パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターの有効な値は truefalse です。
    4. purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターの有効な値は truefalse です。
    5. shared パラメーターは、複数のキャッシュストアインスタンスがキャッシュストアを共有する場合に使用されます。複数のキャッシュインスタンスが同じ変更内容を複数回書き込まないようにするため、このパラメーターを設定することができます。このパラメーターに有効な値は truefalse です。
    6. singleton パラメーターは、シングルトンストアのキャッシュストアを有効にします。SingletonStore は、クラスター内の唯一のインスタンスが基礎となるストアと通信する場合にのみ使用される委任中のキャッシュストアです。
    <local-cache> 
    	...
    	<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="true" 
    				 preload="false" 
    				 purge="false"
    				 shared="false"
    				 singleton="true">
  2. string-keyed-table 要素

    string-keyed-table 要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
    1. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <local-cache> 
    	...
    	<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="true" 
    				 preload="false" 
    				 purge="false"
    				 shared="false"
    				 singleton="true">
                   	<string-keyed-table prefix="JDG">
  3. id-column 要素

    id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
    1. name パラメーターは ID 列の名前を指定します。
    2. type パラメーターは ID 列のタイプを指定します。
    <local-cache> 
    	...
    	<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="true" 
    				 preload="false" 
    				 purge="false"
    				 shared="false"
    				 singleton="true">
                   	<string-keyed-table prefix="JDG">
                   		<id-column name="id" 
    				   type="${id.column.type}"/>
  4. data-column 要素

    data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <local-cache> 
    	...
    	<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="true" 
    				 preload="false" 
    				 purge="false"
    				 shared="false"
    				 singleton="true">
                   	<string-keyed-table prefix="JDG">
                   		<id-column name="id" 
    				   type="${id.column.type}"/>
    			<data-column name="datum" 
    				     type="${data.column.type}"/>
  5. timestamp-column 要素

    timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <local-cache> 
    	...
    	<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				 passivation="true" 
    				 preload="false" 
    				 purge="false"
    				 shared="false"
    				 singleton="true">
                   	<string-keyed-table prefix="JDG">
                   		<id-column name="id" 
    				   type="${id.column.type}"/>
    			<data-column name="datum" 
    				     type="${data.column.type}"/>
    			<timestamp-column name="version" 
    					  type="${timestamp.column.type}"/>
    	        </string-keyed-table>
    	</string-keyed-jdbc-store>
    </local-cache>

18.4.2.2. JdbcStringBasedStore 設定 (ライブラリーモード)

JdbcStringBasedStore の設定例は次の通りです。

手順18.11 ライブラリーモードでの JdbcStringBasedStore の設定

  1. stringKeyedJdbcStore 要素

    stringKeyedJdbcStore 要素は、キャッシュストアを設定するための次のパラメーターを使用します。
    1. fetchPersistentState パラメーターは、クラスターへ参加する時に永続状態が取り込まれるかを決定します。クラスター環境でレプリケーションとインバリデーションを使用している場合は、これを true に設定します。さらに、複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアのみがこのプロパティーを有効に設定できます。共有キャッシュストアが使用されている場合、キャッシュは、このプロパティーが true に設定されているにも関わらず、永続状態の転送を許可しません。fetchPersistentState パラメーターはデフォルトでは false に設定されます。
    2. ignoreModifications パラメーターは、キャッシュを変更する操作 (例: 配置、削除、消去、保存など) がキャッシュストアに影響を与えるかどうかを決定します。結果として、キャッシュストアは、キャッシュと同期しなくなります。
    3. purgeOnStartup パラメーターは、初回起動時にキャッシュがパージされるかどうかを指定します。
    4. key2StringMapper パラメーターは、キーをデータベーステーブルの文字列にマップするために使用される Key2StringMapper のクラス名を指定します。
    <persistence>
    	<stringKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.loaders.keymappers.DefaultTwoWayKey2StringMapper">
  2. connectionPool 要素

    connectionPool 要素は、次のパラメーターを使用して JDBC ドライバーの接続プールを指定します。
    1. connectionUrl パラメーターは、JDBC ドライバー固有の接続 URL を指定します。
    2. username パラメーターには、connectionUrl 経由で接続するために使用されるユーザー名が含まれます。
    3. driverClass パラメーターは、データベースに接続するために使用されるドライバーのクラス名を指定します。
    <persistence>
    	<stringKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.loaders.keymappers.DefaultTwoWayKey2StringMapper">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
  3. stringKeyedTable 要素

    stringKeyedTable 要素を追加すると、キャッシュエントリーを保存するテーブルが定義されます。これは、キャッシュストアを設定するために以下のパラメーターを使用します。
    1. dropOnExit パラメーターは、シャットダウン時にデータベーステーブルがドロップされるかどうかを指定します。
    2. createOnStart パラメーターは、スタートアップ時にストアによってデータベーステーブルが作成されるかどうかを指定します。
    3. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <persistence>
    	<stringKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.loaders.keymappers.DefaultTwoWayKey2StringMapper">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<stringKeyedTable dropOnExit="true"
    				  createOnStart="true"
    				  prefix="ISPN_STRING_TABLE">
  4. idColumn 要素

    idColumn 要素は、キャッシュキーまたはバケット ID が保存される列を定義します。これは以下のパラメーターを使用します。
    1. ID 列の名前を指定するには、name パラメーターを指定します。
    2. ID 列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<stringKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.loaders.keymappers.DefaultTwoWayKey2StringMapper">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<stringKeyedTable dropOnExit="true"
    				  createOnStart="true"
    				  prefix="ISPN_STRING_TABLE">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
  5. dataColumn 要素

    dataColumn 要素は、キャッシュエントリーまたはバケットが保存される列を指定します。
    1. データベース列の名前を指定するには、name パラメーターを使用します。
    2. データベース列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<stringKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.loaders.keymappers.DefaultTwoWayKey2StringMapper">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<stringKeyedTable dropOnExit="true"
    				  createOnStart="true"
    				  prefix="ISPN_STRING_TABLE">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
  6. timestampColumn 要素

    timestampColumn 要素は、キャッシュエントリーまたはバケットのタイムスタンプが保存される列を指定します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<stringKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.loaders.keymappers.DefaultTwoWayKey2StringMapper">
    		<connectionPool connectionUrl="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1" 
    				username="sa" 
    				driverClass="org.h2.Driver"/>
    		<stringKeyedTable dropOnExit="true"
    				  createOnStart="true" 
    				  prefix="ISPN_STRING_TABLE">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
    			<timestampColumn name="TIMESTAMP_COLUMN" 
    					 type="BIGINT" />
    		</stringKeyedTable>
    	</stringKeyedJdbcStore>
    </persistence>

18.4.2.3. JdbcStringBasedStore の複数ノード設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおける JdbcStringBasedStore の設定になります。この設定は、複数のノードを使用しなければならない場合に使用されます。

手順18.12 リモートクライアントサーバーノード用の JdbcStringBasedStore の複数ノード設定

  1. string-keyed-jdbc-store 要素

    string-keyed-jdbc-store 要素は、文字列ベースのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. fetch-state パラメーターは、クラスターへ参加する時にキャッシュの永続状態が取り込まれるかを決定します。複数のキャッシュストアがチェーン化されている場合に、それらの内の 1 つのみでこのプロパティーを有効にすることができます。
    2. datasource パラメーターはデータソースの JNDI 名を定義します。データソースの詳細については、「JDBC 」を参照してください。
    3. passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
    4. preload パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターの有効な値は truefalse です。
    5. purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターの有効な値は truefalse です。
    6. shared パラメーターは、複数のキャッシュストアインスタンスがキャッシュストアを共有する場合に使用されます。複数のキャッシュインスタンスが同じ変更内容を複数回書き込まないようにするため、このパラメーターを設定することができます。このパラメーターに有効な値は truefalse です。
    7. singleton パラメーターは、シングルトンストアのキャッシュストアを有効にします。SingletonStore は、クラスター内の唯一のインスタンスが基礎となるストアと通信する場合にのみ使用される委譲するキャッシュストアです。
    <subsystem xmlns="urn:infinispan:server:core:5.2" default-cache-container="default">
    	<cache-container ... >
    		...
          <replicated-cache>
    			...
    	      <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS"
    	            		       fetch-state="true"                        
    	            		       passivation="false"
    	            		       preload="false" 
    	            		       purge="false" 
    	            		       shared="false" 
    	            		       singleton="true">
  2. string-keyed-table 要素

    string-keyed-table 要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
    1. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <subsystem xmlns="urn:infinispan:server:core:5.2" default-cache-container="default">
    	<cache-container ... >
    		...
          <replicated-cache>
    			...
    	      <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS"
    	            		       fetch-state="true"                        
    	            		       passivation="false"
    	            		       preload="false" 
    	            		       purge="false" 
    	            		       shared="false" 
    	            		       singleton="true"> 
    	         <string-keyed-table prefix="JDG">
  3. id-column 要素

    id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
    1. name パラメーターは ID 列の名前を指定します。
    2. type パラメーターは ID 列のタイプを指定します。
    <subsystem xmlns="urn:infinispan:server:core:5.2" default-cache-container="default">
    	<cache-container ... >
    		...
          <replicated-cache>
    			...
    	      <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS"
    	            		       fetch-state="true"                        
    	            		       passivation="false"
    	            		       preload="false" 
    	            		       purge="false" 
    	            		       shared="false" 
    	            		       singleton="true"> 
    	         <string-keyed-table prefix="JDG">
    	             <id-column name="id" 
    	                        type="${id.column.type}"/>
  4. data-column 要素

    data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <subsystem xmlns="urn:infinispan:server:core:5.2" default-cache-container="default">
    	<cache-container ... >
    		...
          <replicated-cache>
    			...
    	      <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS"
    	            		       fetch-state="true"                        
    	            		       passivation="false"
    	            		       preload="false" 
    	            		       purge="false" 
    	            		       shared="false" 
    	            		       singleton="true"> 
    	         <string-keyed-table prefix="JDG">
    	             <id-column name="id" 
    	                        type="${id.column.type}"/>
    	             <data-column name="datum" 
    	                          type="${data.column.type}"/>
  5. timestamp-column 要素

    timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
    1. name パラメーターはタイムスタンプ列の名前を指定します。
    2. type パラメーターはタイムスタンプ列のタイプを指定します。
    <subsystem xmlns="urn:infinispan:server:core:5.2" default-cache-container="default">
    	<cache-container ... >
    		...
          <replicated-cache>
    			...
    	      <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS"
    	            		       fetch-state="true"                        
    	            		       passivation="false"
    	            		       preload="false" 
    	            		       purge="false" 
    	            		       shared="false" 
    	            		       singleton="true"> 
    	         <string-keyed-table prefix="JDG">
    	             <id-column name="id" 
    	                        type="${id.column.type}"/>
    	             <data-column name="datum" 
    	                          type="${data.column.type}"/>
    	             <timestamp-column name="version"
    	                               type="${timestamp.column.type}"/>
    				</string-keyed-table> 
    			</string-keyed-jdbc-store>
    		</replicated-cache>
    	</cache-container>
    </subsystem>

18.4.2.4. JdbcStringBasedStore のプログラムを使用した設定

JdbcStringBasedStore の設定例は次の通りです。

手順18.13 プログラムを使用した JdbcStringBasedStore の設定

  1. 新規設定ビルダーの作成

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
  2. JdbcStringBasedStoreConfigurationBuilder の追加

    このストアに関連する特定の設定を構築するには JdbcStringBasedStore 設定ビルダーを追加します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
  3. 永続性のセットアップ

    fetchPersistentState は、キャッシュの永続状態を取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、永続状態の取り込みは無視されます。複数のキャッシュローダーがこのプロパティーを true に設定する場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
  4. 変更の設定

    ignoreModifications は、書き込み操作を共有キャッシュローダーではなく、ローカルファイルキャッシュローダーに許可することで、書き込みメソッドが特定のキャッシュローダーにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュローダーにのみ存在します。たとえば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュローダーで適用されます。ignoreModifications はデフォルトではfalse です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
  5. パージの設定

    purgeOnStartup は、初回の起動時にキャッシュがパージされるかどうかを指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
  6. テーブルの設定

    1. Drop Table On Exit メソッドの設定

      dropOnExit は、キャッシュストアが停止している際にテーブルを破棄するかどうかを決定します。これは、デフォルトでは false に設定されます。
    2. Create Table On Start メソッドの設定

      createOnStart は、現在テーブルが存在しない場合にキャッシュストアを起動すると、テーブルを作成します。このメソッドはデフォルトでは true です。
    3. Table Name Prefix の設定

      tableNamePrefix は、データが保存されるテーブルの名前にプレフィックスを設定します。
    4. idColumnName

      idColumnName プロパティーは、キャッシュキーまたはバケット ID が保存される列を定義します。
    5. dataColumnName

      dataColumnName プロパティーは、キャッシュエントリーまたはバケット ID が保存される列を指定します。
    6. timestampColumnName

      timestampColumnName 要素は、キャッシュエントリーのタイムスタンプまたはバケットが保存される列を指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
         .table()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_STRING_TABLE")
            .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
            .dataColumnName("DATA_COLUMN").dataColumnType("BINARY")
            .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
  7. connectionPool 要素

    connectionPool 要素は、次のパラメーターを使用して JDBC ドライバーの接続プールを指定します。
    1. connectionUrl パラメーターは、JDBC ドライバー固有の接続 URL を指定します。
    2. username パラメーターには、connectionUrl 経由で接続するために使用されるユーザー名が含まれます。
    3. driverClass パラメーターは、データベースに接続するために使用されるドライバーのクラス名を指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
         .table()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_STRING_TABLE")
            .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
            .dataColumnName("DATA_COLUMN").dataColumnType("BINARY")
            .