管理および設定ガイド


Red Hat JBoss Data Grid 6.2

Red Hat JBoss Data Grid 6.2.1 を設定および管理するためのガイド

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.2.1 の管理および設定について説明します。

第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. キャッシュのロックのセットアップ

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

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

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

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

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

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

      JMX は、JBoss Data Grid に使用される標準的な統計および管理ツールです。ユースケースに応じて、JMX はキャッシュまたはキャッシュマネージャー、またはそれら両方のレベルで設定することができます。さらに詳しくは、19章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) は、キャッシュおよびキャッシュマネージャーのランタイムパラメーターおよび統計をモニタリングするためのグラフィカルインターフェースを提供します。さらに詳しくは、20章JBoss Operations Network (JON) のセットアップを参照してください。
  8. トポロジー情報の導入

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

      サーバーヒンティングは、セットアップされると、データのオリジナルおよびバックアップコピーが同じ物理サーバー、ラックまたはデータセンターに保存されていないことを確認することにより高可用性を提供します。これは、すべてのデータがすべてのサーバー、ラックおよびデータセンターでバックアップされるレプリケートされたキャッシュなどの場合にはオプションになります。さらに詳しくは、26章サーバーヒンティングを用いた高可用性を参照してください。
後続の章では、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 の作成

次の設定を用いて、新しい 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();
Copy to Clipboard Toggle word wrap
設定の説明

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

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

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();
    
    Copy to Clipboard Toggle word wrap
上記の手順によって、指定された基本的な設定を使用して新規の EmbeddedCacheManager を作成できます。

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

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

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

  1. 次のようにデフォルト設定を指定します。
    public class Config {
        @Produces
        public Configuration defaultEmbeddedConfiguration () {
            return new ConfigurationBuilder()
                             .eviction()
                                     .strategy(EvictionStrategy.LRU)
                                     .maxEntries(100)
                             .build();
        }
    }
    
    Copy to Clipboard Toggle word wrap
  2. クラスター化されたキャッシュまたはクラスター化されていないキャッシュを作成します。
  3. EmbeddedCacheManager を作成するためのメソッドを呼び出します。
    ...
    @Inject
    EmbeddedCacheManager cacheManager;
    ...
    
    Copy to Clipboard Toggle word wrap

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. エビクションストラテジー

各エビクションストラテジーには、以下に記載されているような特定の利点およびユースケースがあります。
Expand
表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 />
    
    Copy to Clipboard Toggle word wrap
  2. エビクションストラテジーの設定

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

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

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 は背後でこのエントリーを期限切れエントリーとしてマーク付けしても、削除しません。このようなエントリーの削除は、以下の場合の 1 つに該当すると実行されます。
  • 期限切れエントリーに対して get() または containsKey() の使用を試みると、JBoss Data Grid がエントリーを期限切れとして検出し、これを削除します。
  • エビクション機能を有効にすると、エビクションスレッドが期限切れエントリーを定期的に検出し、これらを消去します。

パート 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 のログファイルとそれらの場所のリストです。
Expand
表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 でサポートされるログレベルの一覧になります。ログレベル、ログレベルの値、および説明が記載されています。ログレベルの値は、他のログレベルに対する相対的な値になります。フレームワークが異なるとログレベルの名前が異なることがありますが、ログの値はこの一覧と一致します。
Expand
表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 で利用可能なログハンドラーの各種タイプのリストです。
Expand
表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"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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">
    
    Copy to Clipboard Toggle word wrap
  2. level プロパティーを設定します

    ログカテゴリーが記録するログメッセージの最大レベルを設定するために、level プロパティーを設定します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <logger category="com.company.accounts.rec" use-parent-handlers="true">
          <level name="WARN"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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">
    
    Copy to Clipboard Toggle word wrap
  2. level プロパティーを設定します

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

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
       <console-handler name="CONSOLE" autoflush="true">
          <level name="INFO"/>
          <encoding value="UTF-8"/>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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;))"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <file-handler name="accounts-rec-trail" autoflush="true">
        <level name="INFO"/>
        <encoding value="UTF-8"/>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <periodic-rotating-file-handler name="FILE" autoflush="true">
       <level name="INFO"/>
       <encoding value="UTF-8"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

    出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。
    <size-rotating-file-handler name="accounts_debug" autoflush="false">
       <level name="DEBUG"/>
       <encoding value="UTF-8"/>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

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

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

パート 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">
    
    Copy to Clipboard Toggle word wrap
    1. キャッシュコンテナーの名前を設定します。

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

      default-cache パラメーターは、キャッシュコンテナーと共に使用されるデフォルトキャッシュの名前を定義します。
      <subsystem xmlns="urn:infinispan:server:core:6.0" 
      	   default-cache-container="default">
      	<cache-container name="default" 
      			 default-cache="default" />
      
      Copy to Clipboard Toggle word wrap
    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"/>
      
      Copy to Clipboard Toggle word wrap
    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" />
      
      Copy to Clipboard Toggle word wrap
    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">
      
      Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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" >
    
    Copy to Clipboard Toggle word wrap
  2. キャッシュコンテナーの開始モードを設定します。

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

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

    statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、モニタリングを必要としないキャッシュについては選択的に無効にすることができます。
    <cache-container name="local"
                      default-cache="default"
                      statistics="true">
             <local-cache name="default"
                              start="EAGER"
                              batching="false"
                              statistics="true">
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap
この代わりに、引数のないコンストラクターで DefaultCacheManager を作成することもできます。どちらの方法でも、ローカルのデフォルトキャッシュが作成されます。
ローカルキャッシュとクラスター化されたキャッシュは同じキャッシュコンテナーで共存できますが、コンテナーに <transport/> がない場合はローカルキャッシュのみ格納できます。例で使用されたコンテナーには <transport/> がないため、ローカルキャッシュのみを格納できます。
キャッシュインターフェースは ConcurrentMap を拡張し、複数のキャッシュシステムと互換性があります。

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

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

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 に値を設定することができます。
設定例は次の通りです。
<replicated-cache name="default" 
                  start="EAGER"
                  mode="SYNC"    
                  batching="false" 
                  statistics="true">
                 ...
</replicated-cache>
Copy to Clipboard Toggle word wrap

注記

この設定は、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 から、クラスター全体に対して変更することができます。この属性はデフォルトではon true であり、プログラムを使って設定することができます。
Hot Rod などのサーバーは、起動時に設定で宣言されるすべてのキャッシュを起動するよう試みます。再調整が無効にされる場合、キャッシュは起動に失敗します。そのため、サーバー環境で以下の設定を使用することが必須になります。
<await-initial-transfer="false"/>
Copy to Clipboard Toggle word wrap

第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" />
    
    Copy to Clipboard Toggle word wrap
  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" />
    
    Copy to Clipboard Toggle word wrap
  3. セグメント数を指定します。

    (オプションの) segments パラメーターは、クラスターごとのハッシュ領域セグメントの数を指定します。このパラメーターの推奨される値は、10 をクラスターサイズで乗算した値であり、デフォルト値は 80 です。
    <cache-container name="clustered" 
    		 default-cache="default" 
    		 statistics="true">
    	<transport executor="infinispan-transport" lock-timeout="60000"/>
    	<distributed-cache name="default"
    			   mode="SYNC"
    			   segments="20" />
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

      clusterName パラメーターはクラスターの名前を指定します。ノードは同じ名前を共有するクラスターのみに接続できます。
      <clustering mode="dist">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
              <transport clusterName="${NAME}" />
      
      Copy to Clipboard Toggle word wrap
    2. distributedSyncTimeout 値の設定

      distributedSyncTimeout パラメーターは、分散ロック上でロックを取得するために待機する時間を指定します。この分散ロックにより、単一キャッシュは一度に状態を転送するか、または状態をリハッシュすることができます。
      <clustering mode="dist">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
              <transport clusterName="${NAME}"
                         distributedSyncTimeout="${TIME}" />
      
      Copy to Clipboard Toggle word wrap
    3. ネットワークトランスポートの設定

      transportClass パラメーターは、キャッシュのネットワークトランスポートを表すクラスを指定します。
      <clustering mode="dist">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
              <transport clusterName="${NAME}"
                         distributedSyncTimeout="${TIME}"
                         transportClass="${CLASS}" />
      </clustering>
      
      Copy to Clipboard Toggle word wrap

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="local" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default">
    
    Copy to Clipboard Toggle word wrap
  2. クラスター化されたキャッシュの開始モードの設定

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

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

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

    transaction 要素は、レプリケートされたキャッシュのトランザクションモードをセットアップします。
    <cache-container name="local" 
    		 default-cache="default" 
    		 statistics="true">
    	<replicated-cache name="default" 
    				mode="SYNC"
    				start="EAGER"
    				statistics="true">
    		<transaction mode="NONE" />
    	</replicated-cache>
    </cache-container>
    
    Copy to Clipboard Toggle word wrap

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

      clusterName パラメーターはクラスターの名前を指定します。ノードは同じ名前を共有するクラスターのみに接続できます。
      <clustering mode="repl">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"                       
                             fetchInMemoryState="{true/false}"                       
                             awaitInitialTransfer="{true/false}"                       
                             timeout="${TIME}" />
              <transport clusterName="${NAME}" />
      
      Copy to Clipboard Toggle word wrap
    2. distributedSyncTimeout 値の設定

      distributedSyncTimeout パラメーターは、分散ロック上でロックを取得するために待機する時間を指定します。この分散ロックにより、単一キャッシュは一度に状態を転送するか、または状態をリハッシュすることができます。
      <clustering mode="repl">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"                       
                             fetchInMemoryState="{true/false}"                       
                             awaitInitialTransfer="{true/false}"                       
                             timeout="${TIME}" />
              <transport clusterName="${NAME}"
                         distributedSyncTimeout="${TIME}" />
      
      Copy to Clipboard Toggle word wrap
    3. ネットワークトランスポートの設定

      transportClass パラメーターは、キャッシュのネットワークトランスポートを表すクラスを指定します。
      <clustering mode="repl">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"                       
                             fetchInMemoryState="{true/false}"                       
                             awaitInitialTransfer="{true/false}"                       
                             timeout="${TIME}" />
              <transport clusterName="${NAME}"
                         distributedSyncTimeout="${TIME}"                  
                         transportClass="${CLASS}" />
      </clustering>
      
      Copy to Clipboard Toggle word wrap

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"/>
    
    Copy to Clipboard Toggle word wrap
これらの方法の 1 つを実装するには、レプリケーションキューを非同期モードで使用する必要があります。非同期モードは、キュータイムアウト (queue-flush-interval、値はミリ秒単位) やキューサイズ (queue-size) と共に次のように設定することができます。
<replicated-cache name="asyncCache" 
                  start="EAGER"
                  mode="ASYNC"
                  batching="false"
                  indexing="NONE"
                  statistics="true"
                  queue-size="1000"
                  queue-flush-interval="500">   
               ...
</replicated-cache>
Copy to Clipboard Toggle word wrap
レプリケーションキューにより、要求がクライアントへ返されるまでの時間が短縮されるため、レプリケーションキューを非同期マーシャリングと共に使用しても大きな利点はありません。

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">
    
    Copy to Clipboard Toggle word wrap
  2. クラスター化されたキャッシュの開始モードの設定

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

    start パラメーターは、サーバーの起動時か、またはサーバーが要求またはデプロイされるときにキャッシュを起動させるかどうかを指定します。
    <cache-container name="local" 
         		 default-cache="default"
         		 statistics="true">
    	<invalidation-cache name="default"
    			    mode="ASYNC"
    			    start="EAGER">
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

      clusterName パラメーターはクラスターの名前を指定します。ノードは同じ名前を共有するクラスターのみに接続できます。
      <clustering mode="inv">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
              <transport clusterName="${NAME}" />
      
      Copy to Clipboard Toggle word wrap
    2. distributedSyncTimeout 値の設定

      distributedSyncTimeout パラメーターは、分散ロック上でロックを取得するために待機する時間を指定します。この分散ロックにより、単一キャッシュは一度に状態を転送するか、または状態をリハッシュすることができます。
      <clustering mode="inv">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
              <transport clusterName="${NAME}"
                                  distributedSyncTimeout="${TIME}" />
      
      Copy to Clipboard Toggle word wrap
    3. ネットワークトランスポートの設定

      transportClass パラメーターは、キャッシュのネットワークトランスポートを表すクラスを指定します。
      <clustering mode="inv">
              <sync replTimeout="${TIME}" />
              <stateTransfer chunkSize="${SIZE}"
                             fetchInMemoryState="{true/false}"
                             awaitInitialTransfer="{true/false}"
                             timeout="${TIME}" />
              <transport clusterName="${NAME}"
                                  distributedSyncTimeout="${TIME}"
                                  transportClass="${CLASS}" />
      </clustering>
      
      Copy to Clipboard Toggle word wrap

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

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

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

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

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

第10章 ロック

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

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

リモートクライアントサーバーモードでは、ロックは、キャッシュタグ (たとえば、invalidation-cachedistributed-cachereplicated-cache または local-cache) 内で locking 要素を使用して設定されます。
以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおけるデフォルトキャッシュについての基本的なロック設定の手順例です。

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

  1. 分離レベルを定義します。

    isolation パラメーターは、ローカルキャッシュに使用される分離レベルを定義します。このパラメーターの有効な値は REPEATABLE_READ および READ_COMMITTED です。
    <distributed-cache>
    	<locking isolation="REPEATABLE_READ" />
    
    Copy to Clipboard Toggle word wrap
  2. acquire-timeout パラメーターを設定します。

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

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

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

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

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

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

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

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

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

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

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

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

10.3. ロックのタイプ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.4. ロック操作

10.4.1. LockManager について

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

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

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

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

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

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

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

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

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

Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおけるロックストライピングは、striping 要素を true に設定して有効になります。
<locking isolation="REPEATABLE_READ"
	 acquire-timeout="20000"
	 concurrency-level="500"
	 striping="true" />
Copy to Clipboard Toggle word wrap

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

ロックストライピングは、Red Hat JBoss Data Grid ではデフォルトで無効にされています。JBoss Data Grid のライブラリーモードでのロックストライピングの設定は、以下のように useLockStriping パラメーターを使用して行います。
<infinispan>
	...
	<default>
		
			<locking concurrencyLevel="${VALUE}"
				 isolationLevel="${LEVEL}"
				 lockAcquisitionTimeout="${TIME}"
				 useLockStriping="${TRUE/FALSE}"
				 writeSkewCheck="${TRUE/FALSE}" />
			...
		
	</default>
</infinispan>
Copy to Clipboard Toggle word wrap
useLockStriping パラメーターは、ロックを必要とするすべてのエントリーに対して、共有ロックのプールを維持するかどうかを指定します。FALSE に設定されると、ロックがキャッシュ内のそれぞれのエントリーに対して作成されます。TRUE に設定されると、ロックストライピングは有効にされ、共有ロックは必要に応じてプールから使用されます。
concurrencyLevel は、ロックストライピングが有効な場合に使用される共有ロックコレクションのサイズを指定するために使用されます。
isolationLevel パラメーターは、キャッシュの分離レベルを指定します。有効な分離レベルは READ_COMMITTEDREPEATABLE_READ です。
lockAcquisitionTimeout パラメーターは、ロック取得の試行がタイムアウトになった後の時間 (ミリ秒単位) を指定します。
writeSkewCheck は、異なるトランザクションからのエントリーへの変更によりトランザクションがロールバックされるかどうかを判別します。true に設定される書き込みスキューにより、isolation_levelREPEATABLE_READ に設定する必要があります。writeSkewCheck および isolation_level のデフォルト値はそれぞれ FALSEREAD_COMMITTED です。

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

12.1. 分離レベルについて

分離レベルは、リーダーが同時書き込みを見ることができるタイミングを決定します。Red Hat JBoss Data Grid で提供される分離モードは READ_COMMITTEDREPEATABLE_READ の 2 つです。
  • READ_COMMITTED は、幅広い要件に適用できるデフォルトの分離レベルです。
  • REPEATABLE_READlocking 設定要素を使用して設定できます。
JBoss Data Grid における分離モードの設定例については、ロックストライピングの設定例を参照してください。

12.2. READ_COMMITTED について

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

12.3. REPEATABLE_READ について

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

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

第13章 キャッシュストア

キャッシュストアは Red Hat JBoss Data Grid を永続データストアに接続します。キャッシュストアは以下の目的で使用されます。
  • キャッシュにコピーがない時にデータストアよりデータを取り込みます。
  • キャッシュのデータに加えられた変更をデータストアにプッシュします。
キャッシュストアは個別のキャッシュに関連付けされるため、同じキャッシュマネージャーを共有するキャッシュに異なるキャッシュストア設定を使用することができます。

13.1. ファイルシステムベースのキャッシュストア

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

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

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

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

  1. キャッシュ名の追加

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

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

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

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

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

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

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

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

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

singleFile 要素は、単一ファイルキャッシュストアを設定するために使用されます。infinispan.xml で以下を設定します。
  1. 名前の値を namedCache 要素に追加します。以下はこの手順の例になります。
    <namedCache name="writeThroughToFile">
    
    Copy to Clipboard Toggle word wrap
  2. persistence 要素で、passivation パラメーターを false に設定します。使用できる値は「true」と「false」です。
    <namedCache name="writeThroughToFile">
          <persistence passivation="false" />
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

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

Red Hat JBoss Data Grid 6.2 は、以前のバージョンの 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 のライブラリーおよびリモートクライアントサーバーモードで利用できます。

13.2. リモートキャッシュストア

RemoteCacheStore は、リモート Red Hat JBoss Data Grid クラスターにデータを保存するキャッシュローダーの実装です。RemoteCacheStore は Hot Rod クライアントサーバーアーキテクチャーを使用してリモートクラスターと通信します。
Hot Rod はリモートキャッシュストアに対して ロードバランシングやフォールトトラレンスを提供します。また、 RemoteCacheStore とクラスター間の接続を細かく調整する機能も提供します。

13.2.1. リモートキャッシュストアの設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおけるリモートキャッシュストアのサンプル設定を示しています。

手順13.3 リモートキャッシュストアの設定

remote-store 要素のパラメーターは次の情報を定義します。
  1. cache パラメーターは、リモートキャッシュの名前を定義します。定義されない状態のままの場合、デフォルトのキャッシュが代わりに使用されます。
    <remote-store cache="default">
    
    Copy to Clipboard Toggle word wrap
  2. socket-timeout パラメーターは、SO_TIMEOUT で定義される値 (ミリ秒単位) が指定されるタイムアウトでリモート Hot Rod サーバーに適用されるかどうかを設定します。タイムアウト値が 0 の場合は、無限のタイムアウトを示します。
    <remote-store cache="default" 
                  socket-timeout="60000">
    
    Copy to Clipboard Toggle word wrap
  3. tcp-no-delay は、TCP_NODELAY がソケット接続でリモートの Hot Rod サーバーに適用されるかどうかを設定します。
    <remote-store cache="default" 
                  socket-timeout="60000" 
                  tcp-no-delay="true">
    
    Copy to Clipboard Toggle word wrap
  4. hotrod-wrapping は、リモートストア上でラッパーが Hot Rod に必要となるかどうかを設定します。
    <remote-store cache="default" 
                  socket-timeout="60000" 
                  tcp-no-delay="true" 
                  hotrod-wrapping="true">
    
    Copy to Clipboard Toggle word wrap
  5. remote-server 要素の単一パラメーターは以下の通りです。
    1. outbound-socket-binding パラメーターは、リモートサーバーのアウトバウンドソケットバインディングを設定します。
    <remote-store cache="default" 
                  socket-timeout="60000" 
                  tcp-no-delay="true" 
                  hotrod-wrapping="true">
    	<remote-server outbound-socket-binding="remote-store-hotrod-server" />
    </remote-store>
    
    Copy to Clipboard Toggle word wrap

13.2.2. リモートキャッシュストアの設定 (ライブラリーモード)

手順13.4 リモートキャッシュストアの設定

以下は、Red Hat JBoss Data Grid のライブラリーモードにおけるリモートキャッシュストアのサンプル設定を示しています。
  1. Persistence 要素の設定

    passivationfalse に設定した状態で、persistence 要素を作成します。
    <persistence passivation="false" />
    
    
    Copy to Clipboard Toggle word wrap
  2. リモートキャッシュストアの属性を設定するために、persistence 要素内に remoteStore 要素を作成します。
    <persistence passivation="false">
    	<remoteStore xmlns="urn:infinispan:config:remote:6.0"
    		     fetchPersistentState="false" 
    		     shared="true" 
    		     preload="false" 
    		     ignoreModifications="false" 
    		     purgeOnStartup="false"
    		     tcpNoDelay="true" 
    		     pingOnStartup="true"
    		     keySizeEstimate="62" 
    		     valueSizeEstimate="512"
    		     forceReturnValues="false">
    	</remoteStore>
    </persistence>
    
    Copy to Clipboard Toggle word wrap
    • fetchPersistentState 属性を追加します。true に設定されると、リモートキャッシュがクラスターに加わる際に永続状態が取り込まれます。複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアでのみこのプロパティーを true に設定できます。この値のデフォルトは false です。
    • shared 属性を追加します。これは、複数のキャッシュインスタンスがキャッシュストアを共有する場合に true に設定されます。これにより、複数のキャッシュインスタンスが同じ変更内容を個別に書き込むことを避けられます。この属性のデフォルトは false です。
    • preload 属性を追加します。true に設定されている場合、キャッシュストアデータがメモリーに事前にロードされ、起動後すぐにアクセス可能になります。これを true に設定する不利な点には、起動時間が増えることが挙げられます。この属性のデフォルト値は false です。
    • ignoreModifications 属性を追加します。true に設定されると、この属性は、キャッシュを変更する操作 (例: 配置、削除、消去、保存など) がキャッシュストアに影響を与えることを防ぎます。その結果、キャッシュストアは、キャッシュと同期しなくなります。この属性のデフォルト値は false です。
    • purgeOnStartup 属性を追加します。true に設定されると、キャッシュストアは起動プロセス時にパージされます。この属性のデフォルト値は false です。
    • tcpNoDelay 属性を追加します。true に設定されると、これは TCPNODELAY スタックをトリガーします。この属性のデフォルト値は true です。
    • pingOnStartup 属性を追加します。true に設定されると、クラスタートポロジーを取り込むために ping 要求がバックエンドサーバーに送信されます。この属性のデフォルト値は true です。
    • keySizeEstimate 属性を追加します。この値は、データベースに接続するためのドライバーユーザーのクラス名です。この属性のデフォルト値は 64 です。
    • valueSizeEstimate 属性を追加します。この値は、値をシリアライズおよびデシリアライズする時のバイトバッファーのサイズです。この属性のデフォルト値は 512 です。
    • forceReturnValues 属性を追加します。この属性は、FORCE_RETURN_VALUE をすべての呼び出しに対して有効にするかどうかを設定します。この属性のデフォルト値は false です。
  3. サーバー情報をセットアップするために remoteStore 要素内に servers 要素を作成します。情報を単一サーバーに追加するには、一般的な servers 要素内に server 要素を追加します。
    <persistence passivation="false">
    	<remoteStore xmlns="urn:infinispan:config:remote:6.0"
    		     fetchPersistentState="false" 
    		     shared="true" 
    		     preload="false" 
    		     ignoreModifications="false" 
    		     purgeOnStartup="false"
    		     tcpNoDelay="true" 
    		     pingOnStartup="true"
    		     keySizeEstimate="62" 
    		     valueSizeEstimate="512"
    		     forceReturnValues="false">
    		<servers>
    			<server host="127.0.0.1" 
    				port="19711"/>
    		</servers>
    	</remoteStore>
    </persistence>
    
    Copy to Clipboard Toggle word wrap
    • ホストアドレスを設定するには host 属性を追加します。
    • リモートキャッシュストアで使用されるポートを設定するには port 属性を追加します。
  4. connectionPool 要素を remoteStore 要素に対して作成します。
    <persistence passivation="false">
    	<remoteStore xmlns="urn:infinispan:config:remote:6.0"
    		     fetchPersistentState="false" 
    		     shared="true" 
    		     preload="false" 
    		     ignoreModifications="false" 
    		     purgeOnStartup="false"
    		     tcpNoDelay="true" 
    		     pingOnStartup="true"
    		     keySizeEstimate="62" 
    		     valueSizeEstimate="512"
    		     forceReturnValues="false">
    		<servers>
    			<server host="127.0.0.1" 
    				port="19711"/>
    		</servers>
    		<connectionPool maxActive="99" 
    				maxIdle="97" 
    				maxTotal="98" />
    	</remoteStore>
    </persistence>
    
    Copy to Clipboard Toggle word wrap
    • maxActive 属性を追加します。これは、一度に各サーバーに設定できるアクティブな接続の最大数を示します。この属性のデフォルト値は -1 であり、これはアクティブな接続の無限な数を示します。
    • maxIdle 属性を追加します。これは、一度に各サーバーに設定できるアイドル状態の接続の最大数を示します。この属性のデフォルト値は -1 であり、これはアイドル状態の接続の無限な数を示します。
    • maxTotal 属性を追加します。これは、組み合わされたサーバーセット内の永続的な接続の最大数を示します。この属性のデフォルト設定は -1 であり、これは接続の無限な数を示します。

13.2.3. リモートキャッシュストアのアウトバウンドソケットの定義

リモートキャッシュストアによって使用される Hot Rod サーバーは、standalone.xml ファイルの outbound-socket-binding 要素を使用して定義されます。
standalone.xml ファイルにおけるこの設定の例は次の通りです。
<server>
    ...
    <socket-binding-group name="standard-sockets" 
    			  default-interface="public" 
    			  port-offset="${jboss.socket.binding.port-offset:0}">
        ...
        <outbound-socket-binding name="remote-store-hotrod-server">
            <remote-destination host="remote-host" 
            			port="11222"/>
        </outbound-socket-binding>
    </socket-binding-group>
</server>
Copy to Clipboard Toggle word wrap

13.3. カスタムキャッシュストア

カスタムキャッシュストアは Red Hat JBoss Data Grid のキャッシュストアのカスタマイズされた実装です。

重要

カスタムキャッシュストアは Red Hat JBoss Data Grid ではサポートされていません。

13.3.1. カスタムキャッシュストアの設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおけるカスタムキャッシュストアの設定例になります。
<local-cache name="default"
	statistics="true">
     <store class="my.package.CustomCacheStore">
         <properties>
             <property name="customStoreProperty" value="10" />
         </properties>
     </store>
</local-cache>
Copy to Clipboard Toggle word wrap

重要

JBoss Data Grid が定義されたクラスを見つけられるようにするため、他の (関連する) キャッシュストアのモジュールを使用してテンプレートとしてモジュールを作成し、org.jboss.as.clustering.infinispan モジュールの依存関係に追加します。

重要

カスタムキャッシュストアは JBoss Data Grid ではサポートされていません。

13.3.2. カスタムキャッシュストアの設定 (ライブラリーモード)

以下は、Red Hat JBoss Data Grid のライブラリーモードにおけるカスタムキャッシュストアの設定例になります。
<persistence>
	<store class="org.infinispan.custom.CustomCacheStore" 
	       preload="true" 
	       shared="true">
		<properties>
			<property name="customStoreProperty" 
				  value="10" />
		</properties>
            </store>
</persistence>
Copy to Clipboard Toggle word wrap

重要

カスタムキャッシュストアは JBoss Data Grid ではサポートされていません。

13.4. 非同期キャッシュストアの変更について

Red Hat JBoss Data Grid では非同期キャッシュストアへの変更は、変更スレッドによって適用された間隔に対して合体または集約されます。これにより、同じキーに対する複数の変更が検出されるようにし、キーの最終ステートのみが適用されるようにします。キャッシュストアへの呼び出し数が削減されるため、効率がよくなります。

13.5. LevelDB キャッシュストア

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

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

手順13.5 LevelDB キャッシュストアを設定するには、以下を実行します。

  1. https://github.com/fusesource/leveldbjni から leveldbjni-all-1.7.jar ファイルを取得し、これを modules/system/layers/base/org/fusesource/leveldbjni-all/main ディレクトリーにコピーします。
  2. JAR ファイルをリソースに組み込むように module.xml ファイルを変更します。
    <module xmlns="urn:jboss:module:1.1" name="org.fusesource.leveldbjni-all">
       <properties>
          <property name="jboss.api" value="private"/>
       </properties>
    
       <resources>
          <resource-root path="leveldbjni-all-1.7.jar"/>
            <!-- Insert resources here -->
       </resources>
    
       <dependencies>
       </dependencies>
    </module>
    
    Copy to Clipboard Toggle word wrap
  3. データベースを設定するには、standalone.xml のキャッシュ定義に以下を追加します。
    <leveldb-store path="/path/to/leveldb/data"
        passivation="false"
        purge="false" >
        <expiration path="/path/to/leveldb/expires/data" />
    </leveldb-store>
    
    Copy to Clipboard Toggle word wrap

注記

LevelDB ライブラリーおよび JNI コネクターは JBoss Data Grid 6.2 ディストリビューションの一部ではありません。テスト済みバージョンを使用するには、https://github.com/fusesource/leveldbjni のファイル leveldbjni-all-1.7.jar を JBoss Data Grid デプロイメントに追加します。

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

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

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

  1. 新規の設定ビルダーを作成します。

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

    ストアを LevelDBCacheStoreConfigurationBuilder インスタンスに追加して、その設定を構築します。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
                    .addStore(LevelDBStoreConfigurationBuilder.class)
    
    Copy to Clipboard Toggle word wrap
  3. ロケーションのセットアップ

    LevelDB キャッシュストアのロケーションパスを設定します。指定したパスは、主なキャッシュストアデータを保存します。ディレクトリーがない場合は自動的に作成されます。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
                    .addStore(LevelDBStoreConfigurationBuilder.class)
                    .location("/tmp/leveldb/data")
    
    Copy to Clipboard Toggle word wrap
  4. 期限切れのロケーションのセットアップ

    LevelDB ストアの expiredLocation パラメーターを使用して、期限切れデータのロケーションを指定します。指定されたパスは、パージされる前に期限切れデータを保存します。ディレクトリーがない場合は自動的に作成されます。
    Configuration cacheConfig = new ConfigurationBuilder().persistence()
                    .addStore(LevelDBStoreConfigurationBuilder.class)
                    .location("/tmp/leveldb/data")
                    .expiredLocation("/tmp/leveldb/expired").build();
    
    Copy to Clipboard Toggle word wrap

注記

プログラムを使用した設定は、Red Hat JBoss Data Grid ライブラリーモードのみで利用できます。

13.5.3. LevelDB キャッシュストアの XML 設定例 (ライブラリーモード)

以下は、LevelDB キャッシュストアの XML 設定例です。

手順13.7 LevelDB キャッシュストアの XML 設定例

  1. namedCache 要素を追加します。

    以下のように namedCache 要素の name パラメーターを使用して LevelDB キャッシュストアの名前を指定します。
    <namedCache name="vehicleCache">
    
    Copy to Clipboard Toggle word wrap
  2. persistence 要素を追加します。

    以下のように persistence 要素の passivation パラメーターの値を指定します。使用できる値は true および false です。
    <namedCache name="vehicleCache">
        <persistence passivation="false">
    
    Copy to Clipboard Toggle word wrap
  3. leveldbStore 要素を追加します。

    以下のように leveldbStore 要素の location パラメーターを使用して主なキャッシュストア日付を保存するロケーションを指定します。ディレクトリーがない場合は自動的に作成されます。以下はこの手順の例になります。
    <namedCache name="vehicleCache">
          <persistence passivation="false">
              <leveldbStore location="/path/to/leveldb/data" />
    
    Copy to Clipboard Toggle word wrap
  4. 期限切れの値の設定

    以下のように expiredLocation パラメーターを使用して期限切れデータのロケーションを指定します。ディレクトリーは、パージされる前の期限切れのデータを保存します。ディレクトリーがない場合は自動的に作成されます。
    <namedCache name="vehicleCache">
          <persistence passivation="false">
              <leveldbStore location="/path/to/leveldb/data"  
                         expiredLocation="/path/to/expired/data" />
    
    Copy to Clipboard Toggle word wrap
  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" />
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

第14章 データソース管理

14.1. JDBC について

JDBC API は、Java アプリケーションがデータベースにアクセスする方法を定義する基準です。アプリケーションは JDBC ドライバーを参照するデータソースを設定します。その後、データベースではなくドライバーに対してアプリケーションを記述できます。ドライバーはコードをデータベース言語に変換します。そのため、適切なドライバーがインストールされていればアプリケーションをサポートされるデータベースで使用できます。
JDBC 4.0 の仕様は、http://jcp.org/en/jsr/detail?id=221 に定義されています。
JDBC とデータソースを開始するには、JDBC ドライバーについてのセクションを参照してください。

14.2. データソースの型

一般的なリソースタイプには、datasourcesXA datasources の 2 つがあります。
非 XA データソースは、トランザクションを使用しないアプリケーション、または単一のデータベースでトランザクションを使用するアプリケーションに使用されます。
XA データソースは、トランザクションが複数のデータベースにわたって分散されるアプリケーションによって使用されます。
管理コンソールあるいは管理 CLI でデータソースを作成するときに、データソースの型を指定します。

14.3. JDBC ドライバーの使用

14.3.1. コアモジュールとしての JDBC ドライバーのインストール

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

手順14.1 コアモジュールとしての JDBC ドライバーのインストール

  1. EAP_HOME/modules/ ディレクトリー下にファイルパス構造を作成します。たとえば、MySQL JDBC ドライバーの場合には、EAP_HOME/modules/com/mysql/main/ のようなディレクトリー構造を作成します。
  2. JDBC ドライバー JAR を main/ サブディレクトリーにコピーします。
  3. main/ サブディレクトリーに、module.xml ファイルを作成します。以下は、module.xml ファイルの例です。
    <?xml version="1.0" encoding="UTF-8"?>
    <module xmlns="urn:jboss:module:1.0" name="com.mysql">
      <resources>
        <resource-root path="mysql-connector-java-5.1.15.jar"/>
      </resources>
      <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
      </dependencies>
    </module>
    
    Copy to Clipboard Toggle word wrap
  4. サーバーを起動します。
  5. 管理 CLI を起動します。
  6. 次の CLI コマンドを実行して、JDBC ドライバーモジュールをドライバーとして追加します。
    /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)
    Copy to Clipboard Toggle word wrap

    例14.1 CLI コマンドの例

    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
    Copy to Clipboard Toggle word wrap
結果

JDBC ドライバーがインストールされ、コアモジュールとして設定されます。アプリケーションのデータソースが JDBC ドライバーを参照できる状態になります。

14.3.2. JDBC ドライバーをダウンロードできる場所

以下の表は、JBoss EAP 6 で使用する一般的なデータベースの JDBC ドライバーをダウンロードする場所を示しています。これらのリンク先は、Red Hat が管理および監視していない他社の Web サイトであります。データベースの最新のドライバーについては、データベースのベンダーのドキュメントや Web サイトを確認してください。

14.3.3. ベンダー固有クラスへのアクセス

概要

このトピックでは、JDBC 固有クラスを使用するのに必要な手順について説明します。これは、アプリケーションが JDBC API の一部でないベンダー固有の機能を使用する必要がある場合に必要です。

警告

これは、高度な手順であり、JDBC API に含まれない機能を必要とするアプリケーションのみこれを実装します。

重要

このプロセスは、再認証メカニズムを使用し、ベンダー固有のクラスにアクセスする場合に必要です。

重要

接続は IronJacamar コンテナーによって制御されるため、ベンダー固有の API ガイドラインに厳密に従ってください。

手順14.2 アプリケーションへの依存関係の追加

    • MANIFEST.MF ファイルの設定

      1. テキストエディターでアプリケーションの META-INF/MANIFEST.MF ファイルを開きます。
      2. JDBC モジュールの依存関係を追加し、ファイルを保存します。
        依存関係: MODULE_NAME
        Copy to Clipboard Toggle word wrap

        例14.2 依存関係の例

        依存関係: com.mysql
        Copy to Clipboard Toggle word wrap
      1. jboss-deployment-structure.xml ファイルの作成

        アプリケーションの META-INF/ または WEB-INF フォルダーで jboss-deployment-structure.xml という名前のファイルを作成します。

        例14.3 サンプル jboss-deployment-structure.xml ファイル

        <jboss-deployment-structure>
          <deployment>
            <dependencies>
              <module name="com.mysql" />
            </dependencies>
          </deployment>
        </jboss-deployment-structure>
        
        
        Copy to Clipboard Toggle word wrap

例14.4 ベンダー固有 API へのアクセス

以下のサンプルは MySQL API にアクセスします。
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();

Copy to Clipboard Toggle word wrap

14.4. データソース設定

14.4.1. データソースのパラメーター

Expand
表14.2 非 XA および XA データソースに共通のデータソースパラメーター
パラメーター 説明
jndi-name データソースの一意の JNDI 名。
pool-name データソースの管理プール名。
enabled データソースが有効かどうかを指定します。
use-java-context
データソースをグローバルの JNDI にバインドするかどうかを指定します。
spy
JDBC レイヤーで spy 機能を有効にします。この機能は、データソースへの JDBC トラフィックをすべてログに記録します。ロギングカテゴリーの jboss.jdbc.spy もロギングサブシステムのログレベルである DEBUG に設定する必要があることに注意してください。
use-ccm キャッシュ接続マネージャーを有効にします。
new-connection-sql 接続プールに接続が追加された時に実行する SQL ステートメント。
transaction-isolation
次のいずれかになります。
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-delimiter 高可用性 (HA) クラスターデータベースの connection-url にある URL の区切り文字。 
url-selector-strategy-class-name インターフェース org.jboss.jca.adapters.jdbc.URLSelectorStrategy を実装するクラス。
security
セキュリティー設定である子要素が含まれます。表14.7「セキュリティーパラメーター」 を参照してください。
validation
検証設定である子要素が含まれます。表14.8「検証パラメーター」 を参照してください。
timeout
タイムアウト設定である子要素が含まれます。表14.9「タイムアウトパラメーター」 を参照してください。
statement
ステートメント設定である子要素が含まれます。表14.10「ステートメントのパラメーター」 を参照してください。
Expand
表14.3 非 XA データソースのパラメーター
パラメーター 説明
jta 非 XA データソースの JTA 統合を有効にします。XA データソースには適用されません。
connection-url JDBC ドライバーの接続 URL。
driver-class JDBC ドライバークラスの完全修飾名。
connection-property
Driver.connect(url,props) メソッドに渡される任意の接続プロパティー。各 connection-property は、文字列名と値のペアを指定します。プロパティー名は名前、値は要素の内容に基づいています。
pool
プーリング設定である子要素が含まれます。表14.5「非 XA および XA データソースに共通のプールパラメーター」 を参照してください。
Expand
表14.4 XA データソースのパラメーター
パラメーター 説明
xa-datasource-property
実装クラス XADataSource に割り当てるプロパティー。name=value で指定。 setName という形式で setter メソッドが存在する場合、プロパティーは setName(value) という形式の setter メソッドを呼び出すことで設定されます。
xa-datasource-class
実装クラス javax.sql.XADataSource の完全修飾名。
driver
JDBC ドライバーが含まれるクラスローダーモジュールへの一意参照。driverName#majorVersion.minorVersion の形式にのみ対応しています。
xa-pool
プーリング設定である子要素が含まれます。表14.5「非 XA および XA データソースに共通のプールパラメーター」 および 表14.6「XA プールパラメーター」 を参照してください。
recovery
リカバリー設定である子要素が含まれます。表14.11「リカバリーパラメーター」 を参照してください。
Expand
表14.5 非 XA および XA データソースに共通のプールパラメーター
パラメーター 説明
min-pool-size プールが保持する最小接続数
max-pool-size プールが保持可能な最大接続数
prefill 接続プールのプレフィルを試行するかどうかを指定します。要素が空の場合は true を示します。デフォルトは、false です。
use-strict-min pool-size が厳密かどうかを指定します。デフォルトは false に設定されています。
flush-strategy
エラーの場合にプールをフラッシュするかどうかを指定します。有効な値は次の通りです。
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
デフォルトは FailingConnectionOnly です。
allow-multiple-users 複数のユーザーが getConnection(user, password) メソッドを使いデータソースへアクセスするかどうか、また内部プールタイプがこの動作に対応するかを指定します。
Expand
表14.6 XA プールパラメーター
パラメーター 説明
is-same-rm-override javax.transaction.xa.XAResource.isSameRM(XAResource) クラスが true あるいは false のどちらを返すかを指定します。
interleaving XA 接続ファクトリのインターリービングを有効にするかどうかを指定します。
no-tx-separate-pools
コンテキスト毎に sub-pool を作成するかどうかを指定します。これには Oracle のデータソースが必要ですが、このデータソースは JTA トランザクションの内部、外部に関わらず、XA 接続の利用ができなくなります。
このオプションを使用することにより、2 つの実際のファイルが作成されるため、プールサイズの合計が max-pool-size の 2 倍になります。
pad-xid Xid のパディングを行うかどうかを指定します。
wrap-xa-resource
XAResource を org.jboss.tm.XAResourceWrapper インスタンスでラップするかどうかを指定します。
Expand
表14.7 セキュリティーパラメーター
パラメーター 説明
user-name 新規接続の作成に使うユーザー名
password 新規接続の作成に使うパスワード
security-domain 認証処理を行う JAAS security-manager 名が含まれます。この名前は、JAAS ログイン設定の application-policy/name 属性に相関します。
reauth-plugin 物理接続の再認証に使う再認証プラグインを定義します。
Expand
表14.8 検証パラメーター
パラメーター 説明
valid-connection-checker
SQLException.isValidConnection(Connection e) メソッドを提供し接続を検証するインターフェース org.jboss.jca.adaptors.jdbc.ValidConnectionChecker の実装。例外が発生すると接続が破棄されます。存在する場合、check-valid-connection-sql パラメーターが上書きされます。
check-valid-connection-sql プール接続の妥当性を確認する SQL ステートメント。これは、管理接続をプールから取得し利用する場合に呼び出される場合があります。
validate-on-match
接続ファクトリが指定のセットに対して管理対象接続をマッチしようとした時に接続レベルの検証を実行するかどうかを示します。
通常、validate-on-match に「true」を指定した時に background-validation を「true」に指定することはありません。クライアントが使用前に接続を検証する必要がある場合に Validate-on-match が必要になります。このパラメーターはデフォルトでは false になっています。
background-validation
接続がバックグラウンドスレッドで検証されることを指定します。validate-on-match を使用しない場合、バックグラウンドの検証はパフォーマンスを最適化します。validate-on-match が true の時に background-validation を使用すると、チェックが冗長になることがあります。バックグラウンド検証では、不良の接続がクライアントに提供される可能性があります (検証スキャンと接続がクライアントに提供されるまでの間に接続が悪くなります)。そのため、クライアントアプリケーションはこの接続不良の可能性に対応する必要があります。
background-validation-millis バックグラウンド検証を実行する期間 (ミリ秒単位)。
use-fast-fail
true の場合、接続が無効であれば最初に接続を割り当てしようとした時点で失敗します。デフォルトは false です。
stale-connection-checker
ブール値の isStaleConnection(SQLException e) メソッドを提供する org.jboss.jca.adapters.jdbc.StaleConnectionChecker のインスタンス。このメソッドが true を返すと、SQLException のサブクラスである org.jboss.jca.adapters.jdbc.StaleConnectionException に例外がラップされます。
exception-sorter
ブール値である isExceptionFatal(SQLException e) メソッドを提供する org.jboss.jca.adapters.jdbc.ExceptionSorter のインスタンス。このメソッドは、例外が connectionErrorOccurred メッセージとして javax.resource.spi.ConnectionEventListener のすべてのインスタンスへブロードキャストされるかどうかを検証します。
Expand
表14.9 タイムアウトパラメーター
パラメーター 説明
use-try-lock lock() の代わりに tryLock() を使用します。これは、ロックが使用できない場合に即座に失敗するのではなく、設定された秒数間ロックの取得を試みます。デフォルトは 60 秒です。たとえば、タイムアウトを 5 分に設定するには、<use-try-lock>300</use-try-lock> を設定します。
blocking-timeout-millis 接続待機中にブロックする最大時間 (ミリ秒)。この時間を超過すると、例外がスローされます。これは、接続許可の待機中のみブロックし、新規接続の作成に長時間要している場合は例外をスローしません。デフォルトは 30000 (30 秒) です。
idle-timeout-minutes
アイドル接続が切断されるまでの最大時間 (分単位)。実際の最大時間は idleRemover のスキャン時間によって異なります。idleRemover のスキャン時間はプールの最小 idle-timeout-minutes の半分になります。
set-tx-query-timeout
トランザクションがタイムアウトするまでの残り時間を基にクエリーのタイムアウトを設定するかどうかを指定します。トランザクションが存在しない場合は設定済みのクエリーのタイムアウトが使用されます。デフォルトは false です。
query-timeout クエリーのタイムアウト (秒)。デフォルトはタイムアウトなしです。
allocation-retry 例外をスローする前に接続の割り当てを再試行する回数。デフォルトは 0 で、初回の割り当て失敗で例外がスローされます。
allocation-retry-wait-millis
接続の割り当てを再試行するまで待機する期間 (ミリ秒単位)。デフォルトは 5000 (5 秒) です。
xa-resource-timeout
ゼロでない場合、この値は XAResource.setTransactionTimeout メソッドへ渡されます。
Expand
表14.10 ステートメントのパラメーター
パラメーター 説明
track-statements
接続がプールへ返され、ステートメントが準備済みステートメントキャッシュへ返された時に、閉じられていないステートメントをチェックするかどうかを指定します。false の場合、ステートメントは追跡されません。
  • true: ステートメントと結果セットが追跡され、ステートメントが閉じられていない場合は警告が出力されます。
  • false: ステートメントと結果セットのいずれも追跡されません。
  • nowarn: ステートメントは追跡されますが、警告は出力されません。これがデフォルト設定となっています。
prepared-statement-cache-size LRU (Least Recently Used) キャッシュにある接続毎の準備済みステートメントの数。
share-prepared-statements
閉じずに同じステートメントを 2 回要求した場合に、同じ基盤の準備済みステートメントを使用するかどうかを指定します。デフォルトは false です。
Expand
表14.11 リカバリーパラメーター
パラメーター 説明
recover-credential リカバリーに使用するユーザー名とパスワードのペア、あるいはセキュリティドメイン。
recover-plugin
リカバリーに使用される org.jboss.jca.core.spi.recoveryRecoveryPlugin クラスの実装。

14.4.2. データソース接続 URL

Expand
表14.12 データソース接続 URL
データソース 接続 URL
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

14.4.3. データソースの拡張

データソースのデプロイメントは、JDBC リソースアダプターにある複数の拡張を使用して接続の検証を改善でき、例外が接続を再確立するべきかどうかを確認できます。これらの拡張は次の通りです。
Expand
表14.13 データソースの拡張
データソースの拡張 設定パラメーター 説明
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> SQLException が発生した接続にとってこの例外は致命的かどうかを確認します。
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> org.jboss.jca.adapters.jdbc.StaleConnectionException の古い SQLExceptions をラップします。
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> アプリケーションによる接続の使用が有効であるかどうかを確認します。
JBoss EAP 6 は、これらの拡張の実装を、サポートされるいくつかのデータベース用に提供します。

拡張の実装

汎用
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

14.4.4. データソース統計の表示

以下のコマンドを適切に編集すると、jdbc および pool の定義済みデータソースより統計を表示できます。

手順14.3

  • /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
    
    Copy to Clipboard Toggle word wrap
    /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
    
    Copy to Clipboard Toggle word wrap

注記

統計はすべてランタイムのみの情報で、デフォルトは false であるため、必ず include-runtime=true 引数を指定するようにしてください。

14.4.5. データソースの統計

主要統計

サポートされるデータソースの主要統計は以下の表の通りです。

Expand
表14.14 主要統計
名前 説明
ActiveCount
アクティブな接続の数。各接続はアプリケーションによって使用されているか、プールで使用可能な状態であるかのいずれかになります。
AvailableCount
プールの使用可能な接続の数。
AverageBlockingTime
プールの排他ロックの取得をブロックするために費やされた平均時間。値はミリ秒単位です。
AverageCreationTime
接続の作成に費やされた平均時間。値はミリ秒単位です。
CreatedCount
作成された接続の数。
DestroyedCount
破棄された接続の数。
InUseCount
現在使用中の接続の数。
MaxCreationTime
接続の作成にかかった最大時間。値はミリ秒単位です。
MaxUsedCount
使用される接続の最大数。
MaxWaitCount
同時に接続を待機するリクエストの最大数。
MaxWaitTime
プールの排他ロックの待機に費やされた最大時間。
TimedOut
タイムアウトした接続の数。
TotalBlockingTime
プールの排他ロックの待機に費やされた合計時間。値はミリ秒単位です。
TotalCreationTime
接続の作成に費やされた合計時間。値はミリ秒単位です。
WaitCount
接続を待機する必要があるリクエストの数。
JDBC の統計

サポートされるデータソースの JDBC 統計は以下の表の通りです。

Expand
表14.15 JDBC の統計
名前 説明
PreparedStatementCacheAccessCount
ステートメントキャッシュがアクセスされた回数。
PreparedStatementCacheAddCount
ステートメントキャッシュに追加されたステートメントの数。
PreparedStatementCacheCurrentSize
ステートメントキャッシュに現在キャッシュされた準備済みおよび呼び出し可能ステートメントの数。
PreparedStatementCacheDeleteCount
キャッシュから破棄されたステートメントの数。
PreparedStatementCacheHitCount
キャッシュからのステートメントが使用された回数。
PreparedStatementCacheMissCount
ステートメント要求がキャッシュのステートメントと一致しなかった回数。

14.5. データソース例

14.5.1. PostgreSQL のデータソースの例

例14.5

PostgreSQL のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 PostgreSQL データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.2. PostgreSQL XA のデータソースの例

例14.6

PostgreSQL XA のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 PostgreSQL XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.3. MySQL のデータソースの例

例14.7

MySQL のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 MySQL データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.4. MySQL XA のデータソースの例

例14.8

MySQL XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 MySQL XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.5. Oracle のデータソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。

例14.9

Oracle のデータソース設定例は以下の通りです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記の Oracle データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.6. Oracle XA データソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが不要になりました。

重要

Oracle XA データソースにアクセスするユーザーは、以下の設定を適用しないと XA リカバリーが適切に操作しません。値 user は、JBoss から Oracle に接続するために定義されたユーザーです。
  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user; (パッチ済みの Oracle 10g R2、または Oracle 11g を使用する場合)
    または
    GRANT EXECUTE ON sys.dbms_system TO user; (パッチされていない 11g 以前のバージョンの Oracle を使用する場合)

例14.10

Oracle XA のデータソース設定例は以下の通りです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記の Oracle XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.7. Microsoft SQLServer のデータソースの例

例14.11

Microsoft SQLServer のデータソース設定例は以下の通りです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
</datasources>
Copy to Clipboard Toggle word wrap
上記の Microsoft SQLServer データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.8. Microsoft SQLServer XA のデータソースの例

例14.12

Microsoft SQLServer XA のデータソース設定例は以下の通りです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記の Microsoft SQLServer XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.9. IBM DB2 のデータソースの例

例14.13

IBM DB2 のデータソース設定例は以下の通りです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

Copy to Clipboard Toggle word wrap
上記 IBM DB2 データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.10. IBM DB2 XA のデータソースの例

例14.14

IBM DB2 XA のデータソース設定例は以下の通りです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">false</config-property>
        <config-property name="IsValidOverride">false</config-property>
        <config-property name="EnableClose">false</config-property>
      </recover-plugin>
    </recovery>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記の IBM DB2 XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
    <resource-root path="db2jcc_license_cisuz.jar"/>
    <resource-root path="db2jcc_license_cu.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.11. Sybase データソースの例

例14.15

Sybase データソースの設定例は以下の通りです。データソースが有効化され、ユーザーが追加されてから、検証オプションが設定されます。
<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Sybase データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

14.5.12. Sybase XA データソースの例

例14.16

Sybase XA データソースの設定例は以下の通りです。データソースが有効化され、ユーザーが追加されてから、検証オプションが設定されます。
<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Sybase XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

第15章 JDBC ベースのキャッシュストア

Red Hat JBoss Data Grid は、一般的なデータストレージ形式と共に使用される複数のキャッシュストアを提供します。JDBC ベースのキャッシュストアは、JDBC ドライバーを公開するキャッシュストアと共に使用されます。JBoss Data Grid は、永続化されるキーに応じて以下の JDBC ベースのキャッシュストアを提供します。
  • JdbcBinaryStore
  • JdbcStringBasedStore
  • JdbcMixedStore

15.1. JdbcBinaryStores

JdbcBinaryStore はすべてのキータイプをサポートします。同じテーブル行/Blob の同じハッシュ値 (キー上の hashCode メソッド) を持つすべてのキーを格納します。組み込まれるキーに共通するハッシュ値が、テーブルの行/Blob の主キーとして設定されます。このハッシュ値により、JdbcBinaryStore は大変優れた柔軟性を提供しますが、これにより平行性とスループットのレベルが下がります。
たとえば、3 つのキー (k1k2k3) のハッシュコードが同じである場合、同じテーブル行に格納されます。3 つの異なるスレッドが k1k2k3 を同時に更新しようとすると、すべてのキーが同じ行を共有するため同時には更新できないことから、順次更新する必要があります。

15.1.1. JdbcBinaryStore の設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcBinaryStore の設定です。

手順15.1 リモートクライアントサーバーノード用に JdbcBinaryStore を設定します。

  1. binary-keyed-jdbc-store 要素

    binary-keyed-jdbc-store 要素は、バイナリのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. datasource パラメーターはデータソースの JNDI 名を定義します。
    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}">
    
    Copy to Clipboard Toggle word wrap
  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">
    
    Copy to Clipboard Toggle word wrap
  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}"/>
    
    Copy to Clipboard Toggle word wrap
  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}"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    
    Copy to Clipboard Toggle word wrap

15.1.2. JdbcBinaryStore の設定 (ライブラリーモード)

以下は、JdbcBinaryStore の設定例です。

手順15.2 ライブラリーモードの JdbcBinaryStore の設定

  1. binaryKeyedJdbcStore 要素

    binaryKeyedJdbcStore 要素は、キャッシュストアを設定するための次のパラメーターを使用します。
    1. fetchPersistentState パラメーターは、クラスターへ参加する時に永続状態が取り込まれるかを決定します。クラスター環境でレプリケーションとインバリデーションを使用している場合は、これを true に設定します。さらに、複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアのみがこのプロパティーを有効に設定できます。共有キャッシュストアが使用されている場合、キャッシュは、このプロパティーが true に設定されているにも関わらず、永続状態の転送を許可しません。fetchPersistentState パラメーターはデフォルトでは false に設定されます。
    2. ignoreModifications パラメーターは、キャッシュを変更する操作 (例: 配置、削除、消去、保存など) がキャッシュストアに影響を与えるかどうかを決定します。結果として、キャッシュストアは、キャッシュと同期しなくなります。
    3. purgeOnStartup パラメーターは、初回起動時にキャッシュがパージされるかどうかを指定します。
    <persistence>
    	<binaryKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false">
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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">
    
    Copy to Clipboard Toggle word wrap
  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)" />
    
    Copy to Clipboard Toggle word wrap
  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" />
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

15.1.3. JdbcBinaryStore のプログラムを用いた設定

以下は、JdbcBinaryStore の設定例です。

手順15.3 JdbcBinaryStore のプログラムを用いた設定 (ライブラリーモード)

  1. 新規設定ビルダーを作成します。

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
    
    Copy to Clipboard Toggle word wrap
  2. JdbcBinaryStoreConfigurationBuilder を追加します。

    このストアに関連する特定の設定を構築するには、 JdbcBinaryStore 設定ビルダーを追加します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
    
    Copy to Clipboard Toggle word wrap
  3. 永続性のセットアップ

    fetchPersistentState は、キャッシュの永続状態を取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、永続状態の取り込みは無視されます。複数のキャッシュローダーがこのプロパティーを true に設定する場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
    
    Copy to Clipboard Toggle word wrap
  4. 変更の設定

    ignoreModifications は、書き込み操作を共有キャッシュローダーではなく、ローカルファイルキャッシュローダーに許可することで、書き込みメソッドが特定のキャッシュローダーにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュローダーにのみ存在します。たとえば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュローダーで適用されます。ignoreModifications はデフォルトではfalse です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
    
    Copy to Clipboard Toggle word wrap
  5. パージの設定

    purgeOnStartup は、初回の起動時にキャッシュがパージされるかどうかを指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence()
         .addStore(JdbcBinaryStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
    
    Copy to Clipboard Toggle word wrap
  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")
    
    Copy to Clipboard Toggle word wrap
  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");
    
    
    Copy to Clipboard Toggle word wrap

注記

プログラムを使用した設定は、Red Hat JBoss Data Grid ライブラリーモードのみで利用できます。

15.2. JdbcStringBasedStores

JdbcStringBasedStore は複数のエントリーを各行にグループ化せずに、各エントリーをテーブルの独自の行に格納するため、同時負荷の下でスループットが増加します。また、各キーを String オブジェクトへマッピングする (プラグ可能な) バイジェクション (bijection) も使用します。Key2StringMapper インターフェースはバイジェクションを定義します。
Red Hat JBoss Data Grid には、プリミティブタイプを処理する DefaultTwoWayKey2StringMapper と呼ばれるデフォルトの実装が含まれています。

15.2.1. JdbcStringBasedStore の設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcStringBasedStore のサンプル設定です。

手順15.4 リモートクライアントサーバーモードでの JdbcStringBasedStore の設定

  1. string-keyed-jdbc-store 要素

    string-keyed-jdbc-store 要素は、文字列ベースのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. datasource パラメーターはデータソースの JNDI 名を定義します。
    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">
    
    Copy to Clipboard Toggle word wrap
  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">
    
    Copy to Clipboard Toggle word wrap
  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}"/>
    
    Copy to Clipboard Toggle word wrap
  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}"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

15.2.2. JdbcStringBasedStore 設定 (ライブラリーモード)

JdbcStringBasedStore の設定例は次の通りです。

手順15.5 ライブラリーモードでの 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">
    
    Copy to Clipboard Toggle word wrap
  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"/>
    
    Copy to Clipboard Toggle word wrap
  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">
    
    Copy to Clipboard Toggle word wrap
  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)" />
    
    Copy to Clipboard Toggle word wrap
  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" />
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

15.2.3. JdbcStringBasedStore の複数ノード設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおける JdbcStringBasedStore の設定になります。この設定は、複数のノードを使用しなければならない場合に使用されます。

手順15.6 リモートクライアントサーバーノード用の JdbcStringBasedStore の複数ノード設定

  1. string-keyed-jdbc-store 要素

    string-keyed-jdbc-store 要素は、文字列ベースのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. fetch-state パラメーターは、クラスターへ参加する時にキャッシュの永続状態が取り込まれるかを決定します。複数のキャッシュストアがチェーン化されている場合に、それらの内の 1 つのみでこのプロパティーを有効にすることができます。
    2. datasource パラメーターはデータソースの JNDI 名を定義します。
    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">
    
    Copy to Clipboard Toggle word wrap
  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">
    
    Copy to Clipboard Toggle word wrap
  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}"/>>
    
    Copy to Clipboard Toggle word wrap
  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}"/>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

15.2.4. JdbcStringBasedStore のプログラムを使用した設定

JdbcStringBasedStore の設定例は次の通りです。

手順15.7 プログラムを使用した JdbcStringBasedStore の設定

  1. 新規設定ビルダーを作成します。

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    
    Copy to Clipboard Toggle word wrap
  2. JdbcStringBasedStoreConfigurationBuilder を追加します。

    このストアに関連する特定の設定を構築するには JdbcStringBasedStore 設定ビルダーを追加します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
    
    Copy to Clipboard Toggle word wrap
  3. 永続性のセットアップ

    fetchPersistentState は、キャッシュの永続状態を取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、永続状態の取り込みは無視されます。複数のキャッシュローダーがこのプロパティーを true に設定する場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
    
    Copy to Clipboard Toggle word wrap
  4. 変更の設定

    ignoreModifications は、書き込み操作を共有キャッシュローダーではなく、ローカルファイルキャッシュローダーに許可することで、書き込みメソッドが特定のキャッシュローダーにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュローダーにのみ存在します。たとえば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュローダーで適用されます。ignoreModifications はデフォルトではfalse です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
    
    Copy to Clipboard Toggle word wrap
  5. パージの設定

    purgeOnStartup は、初回の起動時にキャッシュがパージされるかどうかを指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcStringBasedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
    
    Copy to Clipboard Toggle word wrap
  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")
    
    Copy to Clipboard Toggle word wrap
  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")
            .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
         .connectionPool()
            .connectionUrl("jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1")
            .username("sa")
            .driverClass("org.h2.Driver");
    
    
    Copy to Clipboard Toggle word wrap

注記

プログラムを使用した設定は、Red Hat JBoss Data Grid ライブラリーモードのみで利用できます。

15.3. JdbcMixedStores

JdbcMixedStore は、キーのタイプを基にキーを JdbcBinaryStore または JdbcStringBasedStore に委譲するハイブリッド実装です。

15.3.1. JdbcMixedStore の設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcBinaryStore の設定です。

手順15.8 リモートクライアントサーバーモードでの JdbcMixedStore の設定

  1. mixed-keyed-jdbc-store 要素

    mixed-keyed-jdbc-store 要素は、混合のキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
    1. datasource パラメーターはデータソースの JNDI 名を定義します。
    2. passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
    3. preload パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターで有効な値は truefalse です。
    4. purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値は truefalse です。
    <local-cache>
                 <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				     passivation="true" 
    				     preload="false" 
    				     purge="false">
    
    Copy to Clipboard Toggle word wrap
  2. binary-keyed-table 要素

    binary-keyed-table 要素は、混合のキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
    1. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <local-cache>
          <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				     passivation="true" 
    				     preload="false" 
    				     purge="false">
    	         <binary-keyed-table prefix="MIX_BKT2">
                         <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>
    
    Copy to Clipboard Toggle word wrap
  3. string-keyed-table 要素

    string-keyed-table 要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
    1. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <local-cache>
          <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				     passivation="true" 
    				     preload="false" 
    				     purge="false">
    	         <binary-keyed-table prefix="MIX_BKT2">
                         <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>
                <string-keyed-table prefix="MIX_STR2">
    
    Copy to Clipboard Toggle word wrap
  4. id-column 要素

    id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
    1. name パラメーターは ID 列の名前を指定します。
    2. type パラメーターは ID 列のタイプを指定します。
    <local-cache>
           <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				     passivation="true" 
    				     preload="false" 
    				     purge="false">
    	         <binary-keyed-table prefix="MIX_BKT2">
                         <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>
                <string-keyed-table prefix="MIX_STR2">
                         <id-column name="id" 
    			                          type="${id.column.type}"/>
    
    Copy to Clipboard Toggle word wrap
  5. data-column 要素

    data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
    1. name パラメーターはデータベース列の名前を指定します。
    2. type パラメーターはデータベース列のタイプを指定します。
    <local-cache>
            <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				     passivation="true" 
    				     preload="false" 
    				     purge="false">
    	         <binary-keyed-table prefix="MIX_BKT2">
                         <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>
                     <string-keyed-table prefix="MIX_STR2">
                         <id-column name="id" 
    			                          type="${id.column.type}"/>
    		                 <data-column name="datum" 
    			                            type="${data.column.type}"/>
    
    Copy to Clipboard Toggle word wrap
  6. timestamp-column 要素

    timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
    1. name パラメーターはタイムスタンプ列の名前を指定します。
    2. type パラメーターはタイムスタンプ列のタイプを指定します。
      <local-cache>
          <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
    				     passivation="true" 
    				     preload="false" 
    				     purge="false">
    	         <binary-keyed-table prefix="MIX_BKT2">
                         <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>
                     <string-keyed-table prefix="MIX_STR2">
                         <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>
            </mixed-keyed-jdbc-store>
    			</local-cache>
        </cache-container>
    </subsystem>
    
    
    Copy to Clipboard Toggle word wrap

15.3.2. JdbcMixedStore の設定 (ライブラリーモード)

mixedKeyedJdbcStore の設定例は次の通りです。

手順15.9 ライブラリーモードでの JdbcMixedStore の設定

  1. mixedKeyedJdbcStore 要素

    mixedKeyedJdbcStore 要素は、キャッシュストアを設定するための次のパラメーターを使用します。
    1. fetchPersistentState パラメーターは、クラスターへ参加する時に永続状態が取り込まれるかを決定します。クラスター環境でレプリケーションとインバリデーションを使用している場合は、これを true に設定します。さらに、複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアのみがこのプロパティーを有効に設定できます。共有キャッシュストアが使用されている場合、キャッシュは、このプロパティーが true に設定されているにも関わらず、永続状態の転送を許可しません。fetchPersistentState パラメーターはデフォルトでは false に設定されます。
    2. ignoreModifications パラメーターは、キャッシュを変更する操作 (例: 配置、削除、消去、保存など) がキャッシュストアに影響を与えるかどうかを決定します。結果として、キャッシュストアは、キャッシュと同期しなくなります。
    3. purgeOnStartup パラメーターは、初回起動時にキャッシュがパージされるかどうかを指定します。
    4. key2StringMapper パラメーターは、キーをデータベーステーブルの文字列にマップするために使用される Key2StringMapper のクラス名を指定します。
    <persistence>
    	<mixedKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.persistence.keymappers.DefaultTwoWayKey2StringMapper">
    
    Copy to Clipboard Toggle word wrap
  2. binaryKeyedTable 要素および stringKeyedTable 要素

    binaryKeyedTable および stringKeyedTable 要素は、キャッシュエントリーを保存するテーブルを定義します。それぞれのユーザーは以下のパラメーターを使用してキャッシュストアを設定します。
    1. dropOnExit パラメーターは、シャットダウン時にデータベーステーブルがドロップされるかどうかを指定します。
    2. createOnStart パラメーターは、スタートアップ時にストアによってデータベーステーブルが作成されるかどうかを指定します。
    3. prefix パラメーターは、キャッシュバケットテーブルの名前を作成する際に、ターゲットキャッシュの名前に付与される文字列を定義します。
    <persistence>
    	<mixedKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.persistence.keymappers.DefaultTwoWayKey2StringMapper">
    		<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_BINARY">
    
    Copy to Clipboard Toggle word wrap
  3. idColumn 要素

    idColumn 要素は、キャッシュキーまたはバケット ID が保存される列を定義します。これは以下のパラメーターを使用します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<mixedKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.persistence.keymappers.DefaultTwoWayKey2StringMapper">
    		<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_BINARY">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    
    Copy to Clipboard Toggle word wrap
  4. dataColumn 要素

    dataColumn 要素は、キャッシュエントリーまたはバケットが保存される列を指定します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<mixedKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.persistence.keymappers.DefaultTwoWayKey2StringMapper">
    		<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_BINARY">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
    
    Copy to Clipboard Toggle word wrap
  5. timestampColumn 要素

    timestampColumn 要素は、キャッシュエントリーまたはバケットのタイムスタンプが保存される列を指定します。
    1. 使用されている列の名前を指定するには、name パラメーターを使用します。
    2. 使用されている列のタイプを指定するには、type パラメーターを使用します。
    <persistence>
    	<mixedKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.persistence.keymappers.DefaultTwoWayKey2StringMapper">
    		<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_BINARY">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
    			<timestampColumn name="TIMESTAMP_COLUMN" 
    					 type="BIGINT" />
    		</binaryKeyedTable>
    
    Copy to Clipboard Toggle word wrap
  6. string-keyed-table 要素

    string-keyed-table 要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
    1. prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
    <persistence>
    	<mixedKeyedJdbcStore fetchPersistentState="false"
    			      ignoreModifications="false" 
    			      purgeOnStartup="false"
    			      key2StringMapper="org.infinispan.persistence.keymappers.DefaultTwoWayKey2StringMapper">
    		<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_BINARY">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
    			<timestampColumn name="TIMESTAMP_COLUMN" 
    					 type="BIGINT" />
    		</binaryKeyedTable>
    		<stringKeyedTable dropOnExit="true" 
    				  createOnStart="true" 
    				  prefix="ISPN_BUCKET_TABLE_STRING">
    			<idColumn name="ID_COLUMN" 
    				  type="VARCHAR(255)" />
    			<dataColumn name="DATA_COLUMN" 
    				    type="BINARY" />
    			<timestampColumn name="TIMESTAMP_COLUMN" 
    					 type="BIGINT" />
    		</stringKeyedTable>
    	</mixedKeyedJdbcStore>
    </persistence>
    
    Copy to Clipboard Toggle word wrap

15.3.3. JdbcMixedStore のプログラムを使用した設定

以下は、JdbcMixedStore の設定例です。

手順15.10 プログラムを使用した JdbcMixedStore の設定

  1. 新規設定ビルダーを作成します。

    ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    
    Copy to Clipboard Toggle word wrap
  2. JdbcMixedStoreConfigurationBuilder を追加します。

    このストアに関連する特定の設定を構築するには、JdbcMixedStore 設定ビルダーを追加します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcMixedStoreConfigurationBuilder.class)
    
    Copy to Clipboard Toggle word wrap
  3. 永続性のセットアップ

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

    ignoreModifications は、書き込み操作を共有キャッシュローダーではなく、ローカルファイルキャッシュローダーに許可することで、書き込みメソッドが特定のキャッシュローダーにプッシュされるかどうかを決定します。特定の場合に、一時的なアプリケーションデータは、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュローダーにのみ存在します。たとえば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュローダーで適用されます。ignoreModifications はデフォルトではfalse です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcMixedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
    
    Copy to Clipboard Toggle word wrap
  5. パージの設定

    purgeOnStartup は、初回の起動時にキャッシュがパージされるかどうかを指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcMixedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
    
    Copy to Clipboard Toggle word wrap
  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(JdbcMixedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
         .stringTable()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_MIXED_STR_TABLE")
            .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
            .dataColumnName("DATA_COLUMN").dataColumnType("BINARY")
            .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
    
    Copy to Clipboard Toggle word wrap
  7. connectionPool 要素

    connectionPool 要素は、次のパラメーターを使用して JDBC ドライバーの接続プールを指定します。
    1. connectionUrl パラメーターは、JDBC ドライバー固有の接続 URL を指定します。
    2. username パラメーターには、connectionUrl 経由で接続するために使用されるユーザー名が含まれます。
    3. driverClass パラメーターは、データベースに接続するために使用されるドライバーのクラス名を指定します。
    ConfigurationBuilder builder = new ConfigurationBuilder();
      builder.persistence().addStore(JdbcMixedStoreConfigurationBuilder.class)
         .fetchPersistentState(false)
         .ignoreModifications(false)
         .purgeOnStartup(false)
         .stringTable()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_MIXED_STR_TABLE")
            .idColumnName("ID_COLUMN").idColumnType("VARCHAR(255)")
            .dataColumnName("DATA_COLUMN").dataColumnType("BINARY")
            .timestampColumnName("TIMESTAMP_COLUMN").timestampColumnType("BIGINT")
         .binaryTable()
            .dropOnExit(true)
            .createOnStart(true)
            .tableNamePrefix("ISPN_MIXED_BINARY_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");
    
    
    Copy to Clipboard Toggle word wrap

注記

プログラムを使用した設定は、Red Hat JBoss Data Grid ライブラリーモードのみで利用できます。

15.4. キャッシュストアのトラブルシューティング

15.4.1. JdbcStringBasedStore の IOExceptions

JdbcStringBasedStore を使用している時に IOException Unsupported protocol version 48 エラーが発生した場合、データ列タイプが正しいタイプである BLOBVARBINARY ではなく、VARCHARCLOB などに設定されていることを示しています。JdbcStringBasedStore は文字列であるキーのみを必要とし、値はバイナリー列に保存されるため、すべてのデータタイプを値に使用できます。

第16章 キャッシュローダー

キャッシュローダーは、Red Hat JBoss Data Grid の永続データストアへの接続を提供します。必要なデータがキャッシュにない場合、キャッシュローダーはデータストアよりデータを読み出します。キャッシュローダーが拡張されると、キャッシュストアとして使用することができ、変更されたデータをデータストアへコピーすることが可能です。
キャッシュローダーは個別のキャッシュに関連付けされます。同じキャッシュマネージャーに属する異なるキャッシュには、異なるキャッシュストアの設定を行うことが可能です。

16.1. キャッシュローダーとキャッシュストア

JBoss Cache には CacheLoader インターフェースと複数の実装が含まれていました。Red Hat JBoss Data Grid ではこれらが CacheLoaderCacheStore の 2 つの異なるインターフェースに分割されました。CacheLoader は以前に存在したステートを別の場所よりロードし、CacheStore (CacheLoader を拡張します) はメソッドを公開してステートを格納し、ロードします。この分割により、読み取り専用ソースの定義が容易になりました。
JBoss Data Grid には、これらのインターフェースの高パフォーマンスな実装が複数含まれます。

16.2. キャッシュローダーの設定

16.2.1. キャッシュローダーの設定

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

16.2.2. XML を使用したキャッシュローダーの設定

以下の例では、XML を使用してキャッシュローダーを設定する方法について示しています。

手順16.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">
    
    Copy to Clipboard Toggle word wrap
  2. 永続性とパージのセットアップ

    1. fetchPersistentState は、キャッシュの永続状態を取り込むかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、永続状態の取り込みは無視されます。複数のキャッシュローダーがこのプロパティーを 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}" />
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap
  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>
    
    Copy to Clipboard Toggle word wrap

16.2.3. プログラムを使用したキャッシュローダーの設定

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

手順16.2 プログラムを使用したキャッシュローダーの設定

  1. 新規の設定ビルダーを作成します。

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

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

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

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

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

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

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

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

    これらの属性は、それぞれのキャッシュローダーに固有の部分を設定します。たとえば、location 属性は、SingleFileStore がデータが含まれるファイルを維持する場所を参照します。他のローダーには、さらに複雑な設定が必要な場合があります。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.loaders()
        .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)
    
    Copy to Clipboard Toggle word wrap
  10. シングルトンの設定

    singletonStore は、クラスター内の 1 つのノードのみによって変更が保存されるのを可能にします。このノードはコーディネーターと呼ばれます。コーディネーターは、インメモリー状態のキャッシュをディスクにプッシュします。この機能は、すべてのノードの enabled 属性を true に設定することによりアクティベートされます。shared パラメーターは、singletonStore を有効にした状態では同時に定義することはできません。enabled 属性はデフォルトでは false です。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.loaders()
        .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)
    
    Copy to Clipboard Toggle word wrap
  11. Push 状態のセットアップ

    pushStateWhenCoordinator はデフォルトでは true に設定されます。true の場合、このプロパティーは、コーディネーターになったノードに、インメモリー状態を基礎となるキャッシュローダーに転送させます。このパラメーターは、コーディネーターがクラッシュし、新規のコーディネーターが選択される場合に役に立ちます。
    ConfigurationBuilder builder = new ConfigurationBuilder();
    builder.loaders()
        .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);
    
    Copy to Clipboard Toggle word wrap

16.3. 共有キャッシュローダー

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

16.3.1. 共有キャッシュローダーの有効化

ライブラリーモード

Red Hat JBoss Data Grid のライブラリーモードでは、loader 要素内で shared パラメーターを使用してキャッシュローダーの共有を切り替えます。このパラメーターはデフォルトでは FALSE に設定されています。キャッシュローダーの共有を有効にするには、shared パラメーターを TRUE に設定します。

リモートクライアントサーバーモード

JBoss Data Grid のリモートクライアントサーバーモードでは、store 要素内で shared パラメーターを使用してキャッシュローダーの共有を切り替えます。このパラメーターはデフォルトでは FALSE に設定されています。キャッシュローダーの共有を有効にするには、shared パラメーターを TRUE に設定します。以下のようになります。

<jdbc-store shared="true">
...
</jdbc-store>
Copy to Clipboard Toggle word wrap

16.3.2. インバリデーションモードと共有キャッシュローダー

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

16.3.3. キャッシュローダーとキャッシュパッシベーション

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

16.3.4. アプリケーションキャッシュローダーの登録

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

16.4. 接続ファクトリー

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

16.4.1. ManagedConnectionFactory について

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

16.4.2. SimpleConnectionFactory について

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

パート VII. パッシベーションのセットアップ

第17章 アクティベーションモードとパッシベーションモード

アクティベーションは、エントリーをメモリーへロードし、キャッシュストアから削除する処理のことです。ストアに存在し、メモリーには存在しないエントリー (パッシベートされたエントリー) へスレッドがアクセスしようとした時にアクティベーションが発生します。
パッシベーションモードでは、エントリーがメモリーからエビクトされた後にエントリーをキャッシュストアに格納することができます。パッシベーションは、不必要で潜在的に費用のかかる書き込みが発生しないようにします。パッシベーションは頻繁に使用または参照されるため、メモリーからエビクトされないエントリーに使用されます。
パッシベーションが有効である場合、キャッシュストアはオーバーフロータンクとして使用されます。オーバーフロータンクは、メモリーページをディスクへスワップするオペレーティングシステムの仮想メモリー実装と似ています。
パッシベーションフラグは、パッシベーションモードの切り替えに使用されます。パッシベーションモードは、エントリーがメモリーからエビクトされた後でのみキャッシュストアにエントリーを格納するモードです。

17.1. パッシベーションモードの利点

パッシベーションモードの主な利点は、不必要で潜在的に費用のかかる書き込みの発生を防ぐことです。これは、エントリーが頻繁に使用されたり参照されたりする場合に便利で、エントリーはメモリーからエビクトされません。

17.2. パッシベーションの設定

Red Hat JBoss Data Grid のリモートクライアントサーバーモードでは、パッシベーションの切り替えを実行するために passivation パラメーターをキャッシュストア要素に追加します。
<local-cache>
	...
	<file-store passivation="true"
		    ... />
	...
</local-cache>
Copy to Clipboard Toggle word wrap
ライブラリーモードでは、パッシベーションの切り替えを実行するために passivation パラメーターを loaders 要素に追加します。
<persistence passivation="true"
         ... />
   ...
</persistence>
Copy to Clipboard Toggle word wrap

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

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

17.3.1. エビクションとパッシベーションの用途

エビクションポリシーが原因で、パッシベーションが有効な間にキャッシュからエントリーがエビクトされた場合、結果として以下が発生します。
  • パッシベートされたエントリーに関する通知がキャッシュリスナーへ送信されます。
  • エビクトされたエントリーが保存されます。
エビクトされたエントリーの読み出しを試みると、エントリーがキャッシュローダーよりメモリーへレイジーにロードされます。エントリーとその子エントリーは、ロードされた後にキャッシュローダーより削除され、エントリーのアクティベーションに関する通知がキャッシュリスナーへ送信されます。

17.3.2. パッシベーションが無効な場合のエビクションの例

以下の例は、パッシベーションが無効な状態でエビクションを操作する間のメモリーおよび永続ストアの状態を示しています。
Expand
表17.1 パッシベーションが無効な場合のエビクション
手順 メモリー内のキー ディスク上のキー
keyOne の挿入 メモリー: keyOne ディスク: keyOne
keyTwo の挿入 メモリー: keyOnekeyTwo ディスク: keyOnekeyTwo
エビクションスレッドが実行され、keyOne をエビクトする メモリー: keyTwo ディスク: keyOnekeyTwo
keyOne の読み取り メモリー: keyOnekeyTwo ディスク: keyOnekeyTwo
エビクションスレッドが実行され、keyTwo をエビクトする メモリー: keyOne ディスク: keyOnekeyTwo
keyTwo の削除 メモリー: keyOne ディスク: keyOne

17.3.3. パッシベーションが有効な場合のエビクションの例

以下の例は、パッシベーションが有効な状態でエビクションを操作する間のメモリーおよび永続ストアの状態を示しています。
Expand
表17.2 パッシベーションが有効な場合のエビクション
手順 メモリー内のキー ディスク上のキー
keyOne の挿入 メモリー: keyOne ディスク:
keyTwo の挿入 メモリー: keyOnekeyTwo ディスク:
エビクションスレッドが実行され、keyOne をエビクトする メモリー: keyTwo ディスク: keyOne
keyOne の読み取り メモリー: keyOnekeyTwo ディスク:
エビクションスレッドが実行され、keyTwo をエビクトする メモリー: keyOne ディスク: keyTwo
keyTwo の削除 メモリー: keyOne ディスク:

パート VIII. キャッシュ書き込みのセットアップ

第18章 キャッシュ書き込みモード

Red Hat JBoss Data Grid では、単一または複数のキャッシュストアを用いた設定オプションが使用できます。このようなオプションにより、共有の JDBC データベースやローカルファイルシステムなど、永続的な場所にデータを格納することができます。JBoss Data Grid は、以下の 2 つのキャッシングモードをサポートします。
  • ライトスルー (同期)
  • ライトビハインド (非同期)

18.1. ライトスルーキャッシング

Red Hat JBoss Data Grid のライトスルー (または同期) モードは、クライアントがキャッシュエントリーを更新する時に (通常はCache.put() 呼び出しより)、JBoss Data Grid が基盤のキャッシュストアを見つけ、更新するまで呼び出しが返されないようにします。この機能により、キャッシュストアへの更新をクライアントスレッド境界内で終了させることができます。

18.1.1. ライトスルーキャッシングの利点

ライトスルーモードの主な利点は、キャッシュとキャッシュストアが同時に更新されるため、キャッシュストアとキャッシュの内容の整合性を保つことができることです。ただし、キャッシュストアへのアクセスやキャッシュ操作中の更新により、キャッシュ操作のパフォーマンスが低下します。

18.1.2. ライトスルーキャッシングの設定 (ライブラリーモード)

ライトスルーまたは同期キャッシュストアの設定には、特別な設定操作は必要ありません。すべてのキャッシュストアは、明示的にライトビハインドまたは非同期とマーク付けされていない限り、ライトスルーまたは同期になります。以下の手順は、ライトスルーの共有されないローカルファイルキャッシュストアの設定ファイルの例について説明しています。

手順18.1 ライトスルーのローカルファイルキャッシュストアの設定

  1. namedCache を特定します。

    name パラメーターは、使用する namedCache の名前を指定します。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    
    Copy to Clipboard Toggle word wrap
  2. キャッシュローダーの設定

    shared パラメーターは、複数のキャッシュストアインスタンスがキャッシュストアを共有する場合に使用されます。複数のキャッシュインスタンスが同じ変更内容を複数回書き込まないようにするため、このパラメーターを設定することができます。このパラメーターに有効な値は truefalse です。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    		<persistence shared="false">
    
    Copy to Clipboard Toggle word wrap
  3. ローダークラスを指定します。

    class 属性は、キャッシュローダー実装のクラスを定義します。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    		<persistence shared="false">
    		<store class="org.infinispan.loaders.file.FileCacheStore"
    
    Copy to Clipboard Toggle word wrap
  4. fetchPersistentState パラメーターの設定

    fetchPersistentState パラメーターは、クラスターへ参加する時に永続状態が取り込まれるかを決定します。クラスター環境でレプリケーションとインバリデーションを使用している場合は、これを true に設定します。さらに、複数のキャッシュストアがチェーンされている場合、1 つのキャッシュストアのみがこのプロパティーを有効に設定できます。共有キャッシュストアが使用されている場合、キャッシュは、このプロパティーが true に設定されているにも関わらず、永続状態の転送を許可しません。fetchPersistentState パラメーターはデフォルトでは false に設定されます。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    		<persistence shared="false">
    		<store class="org.infinispan.loaders.file.FileCacheStore" 
    	       			fetchPersistentState="true"
    
    Copy to Clipboard Toggle word wrap
  5. ignoreModifications パラメーターを設定します。

    ignoreModifications パラメーターは、キャッシュを変更する操作 (例: 配置、削除、消去、保存など) がキャッシュストアに影響を与えるかどうかを決定します。結果として、キャッシュストアは、キャッシュと同期しなくなります。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    		<persistence shared="false">
    		<store class="org.infinispan.loaders.file.FileCacheStore" 
    	       			fetchPersistentState="true" 
    	       			ignoreModifications="false"
    
    Copy to Clipboard Toggle word wrap
  6. 起動時のパージの設定

    purgeOnStartup パラメーターは、初回起動時にキャッシュがパージされるかどうかを指定します。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    		<persistence shared="false">
    		<store class="org.infinispan.loaders.file.FileCacheStore" 
    	       			fetchPersistentState="true" 
    	       			ignoreModifications="false"
    	       			purgeOnStartup="false">
    
    Copy to Clipboard Toggle word wrap
  7. property 要素

    property 要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。
    1. name パラメーターは、プロパティーの名前を指定します。
    <?xml version="1.0" encoding="UTF-8"?>
    <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                xmlns="urn:infinispan:config:5.0">
    	<global />
    	<default />
    	<namedCache name="persistentCache">
    		<persistence shared="false">
    		<store class="org.infinispan.loaders.file.FileCacheStore" 
    	       			fetchPersistentState="true" 
    	       			ignoreModifications="false"
    	       			purgeOnStartup="false">
    				<properties>
    					<property name="location" 
    						  value="${java.io.tmpdir}" />
    				</properties>
    			</store>
    		</persistence>
      	</namedCache>
    </infinispan>
    
    
    Copy to Clipboard Toggle word wrap

18.2. ライトビハインドキャッシング

Red Hat JBoss Data Grid のライトビハインド (非同期) モードでは、キャッシュの更新が非同期的にキャッシュストアへ書き込みされます。非同期的な更新は、キャッシュと対話するクライアントスレッド以外のスレッドによってキャッシュストアの更新が実行されるようにします。
ライトビハインドモードの主な利点は、キャッシュ操作のパフォーマンスが基礎のストア更新によって影響されないことです。ただし、非同期の更新であるため、キャッシュと比較した場合にキャッシュストアに陳腐データが短期間存在することになります。

18.2.1. スケジュール外のライトビハインドストラテジーについて

スケジュール外のライトビハインドストラテジーモードでは、Red Hat JBoss Enterprise Data Grid は保留の変更を平行して適用し、変更をできるだけ早く保管しようとします。そのため、複数のスレッドが変更の完了を待つことになります。これらの変更が完了すると、スレッドが使用可能になり、基礎のキャッシュストアに適用されます。
このストラテジーは、待ち時間が短く、運用コストが低いキャッシュストアに適しています。例としては、キャッシュストアがキャッシュ自体に対してローカルとなる、共有されていないローカルのファイルベースキャッスストアなどが挙げられます。このストラテジーを使用すると、キャッシュの内容とキャッシュストアの内容に不整合が生じる時間が、可能な限り最短の間隔まで削減されます。
Red Hat JBoss Data Grid のリモートクライアントサーバーモードでライトビハインドストラテジーを設定するには、次のように write-behind 要素をターゲットキャッシュストアの設定に追加します。

手順18.2 write-behind 要素

write-behind 要素は次の設定パラメーターを使用します。
  1. modification-queue-size パラメーター

    modification-queue-size パラメーターは、非同期ストアの変更キューサイズを設定します。更新がキャッシュストアがキューを処理するよりも速く行なわれる場合に、非同期ストアは同期ストアのように動作します。ストアの動作は、キューが要素を許可できるようになるまで同期された状態になり、要素をブロックします。その後ストアの動作は再び非同期になります。
    <file-store passivation="false" 
                path="${PATH}" 
                purge="true" 
                shared="false">
        <write-behind modification-queue-size="1024" />
    
    Copy to Clipboard Toggle word wrap
  2. shutdown-timeout パラメーター

    shutdown-timeout パラメーターは、キャッシュストアがシャットダウンするまでのミリ秒単位の時間を指定します。ストアが停止している場合でも、いくらかの変更が依然として適用される必要がある場合があります。タイムアウトの値として大きな値を設定すると、データを損失する可能性が低くなります。このパラメーターのデフォルト値は 25000 です。
    <file-store passivation="false" 
                path="${PATH}" 
                purge="true" 
                shared="false">
        <write-behind modification-queue-size="1024" 
                      shutdown-timeout="25000" />
    
    Copy to Clipboard Toggle word wrap
  3. flush-lock-timeout パラメーター

    flush-lock-timeout パラメーターは、定期的にフラッシュされる状態を保護するロックを取得するための時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は 15000 です。
    <file-store passivation="false" 
                path="${PATH}" 
                purge="true" 
                shared="false">
        <write-behind modification-queue-size="1024" 
                      shutdown-timeout="25000"  
                      flush-lock-timeout="15000" />
    
    Copy to Clipboard Toggle word wrap
  4. thread-pool-size パラメーター

    thread-pool-size パラメーターはスレッドプールのサイズを指定します。このスレッドプール内のスレッドによって、変更がキャッシュストアに適用されます。このパラメーターのデフォルト値は 5 です。
    <file-store passivation="false" 
                path="${PATH}" 
                purge="true" 
                shared="false">
        <write-behind modification-queue-size="1024" 
                      shutdown-timeout="25000"  
                      flush-lock-timeout="15000" 
                      thread-pool-size="5" />
    </file-store>
    
    Copy to Clipboard Toggle word wrap

18.2.3. スケジュール外のライトビハインドストラテジーの設定 (ライブラリーモード)

キャッシュのストアへのエントリーのライトビハインドストラテジーを有効にするには、以下のように async 要素をストア設定に追加します。

手順18.3 async 要素

async 要素は次の設定パラメーターを使用します。
  1. modificationQueueSize パラメーターは、非同期ストアの変更キューサイズを設定します。更新がキャッシュストアがキューを処理するよりも速く行なわれる場合に、非同期ストアは同期ストアのように動作します。ストアの動作は、キューが要素を受け入れるまで同期が取られた状態のままになり、要素をブロックします。その後ストアの動作は再び非同期になります。
    <persistence>
        <fileStore location="${LOCATION}">
            <async enabled="true" 
                        modificationQueueSize="1024" />
    
    Copy to Clipboard Toggle word wrap
  2. shutdownTimeout パラメーターは、キャッシュストアがシャットダウンされた後の時間 (ミリ秒単位) を指定します。これにより、キャッシュがシャットダウンされた際に非同期ライターがデータをストアへフラッシュする時間が提供されます。このパラメーターのデフォルト値は 25000 です。
    <persistence>
        <fileStore location="${LOCATION}">
            <async enabled="true" 
                        modificationQueueSize="1024" 
                        shutdownTimeout="25000" />
    
    Copy to Clipboard Toggle word wrap
  3. flushLockTimeout パラメーターは、定期的にフラッシュする状態を保護するロックを取得するための時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は 15000 です。
    <persistence>
        <fileStore location="${LOCATION}">
            <async enabled="true" 
                        modificationQueueSize="1024" 
                        shutdownTimeout="25000" 
                        flushLockTimeout="15000" />
    
    Copy to Clipboard Toggle word wrap
  4. threadPoolSize パラメーターは、変更をストアに同時に適用するスレッドの数を指定します。このパラメーターのデフォルト値は 5 です。
    <persistence>
        <fileStore location="${LOCATION}">
            <async enabled="true" 
                        modificationQueueSize="1024" 
                        shutdownTimeout="25000" 
                        flushLockTimeout="15000" 
                        threadPoolSize="5"/>
        </fileStore>
    </persistence>
    
    Copy to Clipboard Toggle word wrap

パート IX. キャッシュとキャッシュマネージャーのモニタリング

第19章 Java Management Extensions (JMX) のセットアップ

19.1. Java Management Extensions (JMX) について

Java Management Extensions (JMX) は、アプリケーション、デバイス、システムオブジェクト、およびサービス指向ネットワークを管理および監視するツールを提供する Java ベースの技術です。これらの各オブジェクトは MBeans によって管理および監視されます。
JMX はミドルウェア管理の事実上の業界標準です。そのため、Red Hat JBoss Data Grid では管理および統計情報を公開するために JMX が使用されます。

19.2. Red Hat JBoss Data Grid における JMX の使用

Red Hat JBoss Data Grid インスタンスの管理は、関連する統計情報をできるだけ多く公開することを目的としています。この統計情報により、管理者は各インスタンスの状態を確認することができます。1 つのインストールは数十または数百のインスタンスを構成することがあるため、各インスタンスの統計情報を明確で簡潔に公開し、表示する必要があります。
このような統計情報を公開し、管理者に対して適切な情報を見やすく表示するため、JBoss Data Grid では、JMX は JBoss Operations Network (JON) と共に使用されます。

19.3. JMX 統計レベル

JMX 統計は、次の 2 つのレベルで有効にすることが可能です。
  • 個別のキャッシュインスタンスによって管理情報が生成されるキャッシュレベル。
  • CacheManager レベル。このレベルでは、CacheManager エンティティーが CacheManager より作成されたすべてのキャッシュインスタンスを管理します。そのため、管理情報は個別のキャッシュではなく、これらすべてのキャッシュインスタンスに対して生成されます。

重要

Red Hat JBoss Data Grid では、統計がデフォルトで有効になります。統計は JBoss Data Grid の状態を評価する際に役に立ちますが、パフォーマンスにはマイナスの影響を与えるため、統計が不要な場合には無効にする必要があります。

19.4. キャッシュインスタンスに対して JMX を有効にする

キャッシュレベルでは、宣言的に、またはプログラムを用いて、次のように JMX 統計を有効にすることができます。
キャッシュレベルで JMX を宣言的に有効にする

デフォルトキャッシュインスタンスに対する <default> 要素内または特定の名前付きキャッシュに対するターゲット <namedCache> 要素の下に、次のスニペットを追加します。

<jmxStatistics enabled="true"/>
Copy to Clipboard Toggle word wrap
キャッシュレベルでプログラムを用いて JMX を有効にする

プログラムを用いて JMX をキャッシュレベルで有効にするには、以下のコードを追加します。

Configuration configuration = ...
configuration.setExposeJmxStatistics(true);
Copy to Clipboard Toggle word wrap

19.5. CacheManagers に対して JMX を有効にする

CacheManager レベルでは、宣言的に、またはプログラムを用いて次のように JMX 統計を有効にすることができます。
CacheManager レベルで JMX を宣言的に有効にする

次の <global> 要素を追加して、CacheManager レベルで JMX を宣言的に有効にします。

<globalJmxStatistics enabled="true"/>
Copy to Clipboard Toggle word wrap
CacheManager レベルでプログラムを用いて JMX を有効にする

次のコードを追加して、プログラムを用いて JMX を CacheManager レベルで有効にします。

GlobalConfiguration globalConfiguration = ...
globalConfiguration.setExposeGlobalJmxStatistics(true);
Copy to Clipboard Toggle word wrap

19.6. JMX による CacheStore の無効化

Red Hat JBoss Data Grid は、RollingUpgradeManager MBean で disconnectSource 操作を呼び出すことで、JMX を使用して CacheStore を無効にすることができます。

関連トピック:

19.7. 複数の JMX ドメイン

複数の CacheManager インスタンスが 1 つの仮想マシンに存在したり、キャッシュインスタンスの名前が CacheManager と異なる場合に、複数の JMX ドメインが使用されます。
この問題を解決するには、JMX や JBoss Operations Network などの監視ツールが簡単に識別および使用できるような名前を各 CacheManager に付けるようにします。
CacheManager の名前を宣言的に設定する

次のスニペットを関係する CacheManager 設定に追加します。

<globalJmxStatistics enabled="true" cacheManagerName="Hibernate2LC"/>
Copy to Clipboard Toggle word wrap
CacheManager の名前をプログラムを用いて設定する

次のコードを追加し、プログラムを用いて CacheManager の名前を設定します。

GlobalConfiguration globalConfiguration = ...
globalConfiguration.setExposeGlobalJmxStatistics(true);
globalConfiguration.setCacheManagerName("Hibernate2LC");
Copy to Clipboard Toggle word wrap

19.8. MBeans

MBean は、サービス、コンポーネント、デバイス、またはアプリケーションなどの管理可能なリソースを表します。
Red Hat JBoss Data Grid は複数の側面を監視および管理する MBeans を提供します。たとえば、トランスポート層で統計を提供する MBeans などが提供されます。JBoss Data Grid サーバーは、JMX 統計で設定されます。JMX 統計はホスト名、ポート、読み取りバイト、書き込みバイト、およびワーカースレッドの数を提供する MBean で、次の場所に存在します。
jboss.infinispan:type=Server,name=<Memcached|Hotrod>,component=Transport
Copy to Clipboard Toggle word wrap

注記

利用可能な MBeans の一覧、それらのサポートされている操作と属性については、付録で参照することができます。

19.8.1. MBean を理解する

キャッシュマネージャーまたはキャッシュレベルのいずれかで JMX レポートが有効になっている場合、JConsole や VisualVM などの標準的な JMX GUI を使用して Red Hat JBoss Data Grid を実行する Java 仮想マシンに接続します。接続した場合、次の MBean を使用できます。
  • キャッシュマネージャーレベルの JMX 統計が有効になっている場合、jboss.infinispan:type=CacheManager,name="DefaultCacheManager" という名前の MBean が存在し、キャッシュマネージャー MBean によってプロパティーが指定されます。
  • キャッシュレベルの JMX 統計が有効になっている場合、使用される設定に応じて複数の MBean が表示されます。たとえば、ライトビハインドキャッシュストアが設定されている場合、キャッシュストアコンポーネントに属するプロパティーを公開する MBean が表示されます。すべてのキャッシュレベルの MBeans は同じ形式を使用します。
    jboss.infinispan:type=Cache,name="<name-of-cache>(<cache-mode>)",manager="<name-of-cache-manager>",component=<component-name>
    
    Copy to Clipboard Toggle word wrap
    この形式の詳細は次の通りです。
    • cache-container 要素の default-cache 属性を使用してキャッシュのデフォルト名を指定します。
    • cache-mode はキャッシュのキャッシュモードに置き換えられます。可能な列挙値を小文字にしたものがキャッシュモードを表します。
    • component-name は、 JMX 参考ドキュメントにある JMX コンポーネント名の 1 つに置き換えられます。
たとえば、同期分散に対して設定されたデフォルトキャッシュのキャッシュストア JMX コンポーネント MBean の名前は次のようになります。
jboss.infinispan:type=Cache,name="default(dist_sync)", manager="default",component=CacheStore
Copy to Clipboard Toggle word wrap
ユーザー定義の名前でサポートされていない文字が使用されないようにするため、キャッシュおよびキャッシュマネージャーの名前は引用符で囲まれています。

19.8.2. デフォルトでない MBean サーバーでの MBean の登録

使用されるすべての MBean がデフォルトで登録される場所は、標準の JVM MBeanServer プラットフォームです。ユーザーは代替の MBeanServer インスタンスを設定することもできます。MBeanServerLookup インターフェースを実装して、確実に getMBeanServer() メソッドが必要な (デフォルト以外の) MBeanServer を返すようにします。
デフォルト以外の場所を設定して MBeans を登録するには、実装を作成してからクラスの完全修飾名を用いて Red Hat JBoss Data Grid を設定します。例は次の通りです。
完全修飾ドメイン名を宣言的に追加する

次のスニペットを追加します。

<globalJmxStatistics enabled="true" mBeanServerLookup="com.acme.MyMBeanServerLookup"/>
Copy to Clipboard Toggle word wrap
完全修飾ドメイン名をプログラムを用いて追加する

次のコードを追加します。

GlobalConfiguration globalConfiguration = ...
globalConfiguration.setExposeGlobalJmxStatistics(true);
globalConfiguration.setMBeanServerLookup("com.acme.MyMBeanServerLookup")
Copy to Clipboard Toggle word wrap

第20章 JBoss Operations Network (JON) のセットアップ

20.1. JBoss Operations Network (JON) について

JBoss Operations Network (JON) は、アプリケーションのライフサイクルを開発、テスト、デプロイおよび監視するために使用される JBoss の管理プラットフォームです。JBoss Operations Network は JBoss のエンタープライズ管理ソリューションで、サーバーにまたがる複数の Red Hat JBoss Data Grid インスタンスを管理するための使用が推奨されます。JBoss Operations Network のエージェントおよび自動ディスカバリー機能は、JBoss Data Grid のキャッシュマネージャーおよびキャッシュインスタンスの監視を円滑にします。JBoss Operations Network は主なランタイムパラメーターと統計をグラフィカルに表示し、管理者がしきい値を設定したり、使用率が設定したしきい値を上回ったり、下回ったりした時に通知を受けるようにすることが可能です。

重要

Red Hat JBoss Data Grid では、統計がデフォルトで有効になります。統計は JBoss Data Grid の状態を評価する際に役に立ちますが、パフォーマンスにはマイナスの影響を与えるため、統計が不要な場合には無効にする必要があります。

20.2. JBoss Operations Network (JON) のダウンロード

20.2.1. JBoss Operations Network (JON) インストールの前提条件

JBoss Operations Network を Red Hat JBoss Data Grid にインストールするには、以下が必要です。
  • Linux、Windows、または Mac OSX オペレーティングシステム、および x86_64、i686、または ia64 プロセッサー。
  • JBoss Operations Network サーバーおよび JBoss Operations Network エージェントの両方を実行するには、Java 6 以上が必要です。
  • JBoss Operations Network サーバー とエージェントで同期されたクロック。
  • 外部データベースをインストールする必要があります。

20.2.2. JBoss Operations Network のダウンロード

以下の手順を使用して、カスタマーポータルから Red Hat JBoss Operations Network をダウンロードします。

手順20.1 JBoss Operations Network のダウンロード

  1. カスタマーポータルのアクセス

    https://access.redhat.com にあるカスタマーポータルにログインします。
  2. 製品の検索

    Downloads にカーソルを置き、JBoss Enterprise Middleware にナビゲートします。
  3. 製品の選択

    メニューから JBoss Operations Network for JDG を選択します。
  4. JBoss Operations Network のダウンロード

    • 最新バージョンの JBoss Operations Network Base Distribution を選択し、Download リンクをクリックします。
    • 最新の JBoss Data Grid Plugin Pack for JBoss Operations Network を選択し、Download リンクをクリックします。

20.2.3. リモート JMX ポートの値

Red Hat JBoss Data Grid インスタンスを見つけられるようにするには、ポートの値を提供する必要があります。使用できるポートの値を使用します。
一意 (使用可能な) のリモート JMX ポートを提供し、単一のマシン上で複数の JBoss Data Grid インスタンスを実行します。ローカルで実行されている JBoss Operations Network エージェントは、リモートポートの値を使用して各インスタンスを見つけることができます。

20.2.4. JBoss Operations Network (JON) プラグインのダウンロード

Red Hat カスタマーポータルから Red Hat JBoss Data Grid の JBoss Operations Network (JON) プラグインをダウンロードするにはこのタスクを実行します。

手順20.2 インストールファイルのダウンロード

  1. web ブラウザーで http://access.redhat.com を開きます。
  2. ページ上部にあるメニュー内の ダウンロードをクリックします。
  3. JBoss Enterprise Middleware 以下のリスト内にある ダウンロード をクリックします。
  4. ログイン情報を入力します。
    「Software Downloads」ページに移動します。
  5. JBoss Operations Network プラグインをダウンロードします。

    JBoss Data Grid の JBoss Operations Network プラグインを使用する予定であれば、「Software Downloads」ドロップダウンボックスか、または左側のメニューのいずれかから JBoss ON for JDG を選択します。
    1. JBoss Operations Network VERSION Base Distribution ダウンロードリンクをクリックします。
    2. Base Distribution のダウンロードを開始するには、Download リンクをクリックします。
    3. JDG Plugin Pack for JBoss ON VERSION をダウンロードする手順を繰り返します。

20.3. JBoss Operations Network サーバーのインストール

JBoss Operations Network のコアとなるのはサーバーです。このサーバーは、エージェントと通信し、インベントリーを維持し、リソース設定を管理し、コンテンツプロバイダーと対話し、中央管理 UI を提供します。

注記

JBoss Operations Network の設定方法についてさらに詳しくは、『JBoss Operations Network インストールガイド』を参照してください。

20.4. JBoss Operations Network エージェント

JBoss Operations Network エージェントはスタンドアロンの Java アプリケーションです。エージェントが管理を要求されるリソース数にかかわらず、1 台のマシンにつき 1 つのエージェントのみが必要です。
JBoss Operations Network エージェントは、完全に設定された状態では出荷されません。いったんエージェントのインストールおよび設定が完了すると、エージェントをコンソールから Windows サービスとして実行できるか、または UNIX 環境でデーモンまたは init.d スクリプトとして実行できます。
JBoss Operations Network エージェントは、データを収集するために監視されるそれぞれのマシンにインストールする必要があります。
JBoss Operations Network エージェントは、通常 Red Hat JBoss Data Grid が実行されているのと同じマシンにインストールされますが、複数のマシンがある場合には、エージェントはそれぞれのマシンにインストールされる必要があります。

注記

JBoss Operations Network エージェントの設定方法についてさらに詳しくは、JBoss Operations Network の『インストールガイド』を参照してください。

20.5. リモートクライアントサーバーモード用の JBoss Operations Network

Red Hat JBoss Data Grid のリモートクライアントサーバーモードでは、JBoss Operations Network プラグインを使って以下が実行されます。
  • インストールおよび設定操作の開始および実行。
  • リソースおよびメトリックスの監視。
リモートクライアントサーバーモードでは、JBoss Operations Network プラグインは、メトリックスを取得し、JBoss Data Grid サーバー上で各種操作を実行するために JBoss Enterprise Application Platform の管理プロトコルを使用します。

20.5.1. JBoss Operations Network プラグインのインストール (リモートクライアントサーバーモード)

次の手順では、Red Hat JBoss Data Grid のリモートクライアントサーバーモード用に JBoss Operations Network プラグインをインストールする方法について詳細に説明します。
  1. プラグインのインストール

    • JBoss Data Grid サーバーの RHQ プラグインを $JON_SERVER_HOME/plugins にコピーします。
    • Wildfly 7 プラグインを $JON_SERVER_HOME/plugins にコピーします。
    サーバーはここでプラグインを自動的に検出し、これらをデプロイします。プラグインはデプロイメントが成功すると、プラグインディレクトリーから削除されます。
  2. プラグインの取得

    JBoss Operations Network サーバーから利用可能なすべてのプラグインを取得します。これを実行するには、以下をエージェントのコンソールに入力します。
    plugins update
    Copy to Clipboard Toggle word wrap
  3. インストール済みプラグインのリスト

    Wildfly 7 プラグインと JBoss Data Grid サーバー RHQ プラグインが、以下を使用して正しくインストールされていることを確認してください。
    plugins info
    Copy to Clipboard Toggle word wrap
JBoss Operation Network が実行中の JBoss Data Grid サーバーを検出できるようになります。

20.6. ライブラリーモード用の JBoss Operations Network

Red Hat JBoss Data Grid のライブラリーモードでは、JBoss Operations Network プラグインを使って以下が実行されます。
  • インストールおよび設定操作の開始および実行。
  • リソースおよびメトリックスの監視。
ライブラリーモードでは、JBoss Operations Network プラグインは JBOSS Data Grid ライブラリーを使ってメトリックスを取得し、アプリケーション上で各種操作を実行するために JMX を使用します。

20.6.1. JBoss Operations Network プラグインのインストール (ライブラリーモード)  

次の手順を使用して、Red Hat JBoss Data Grid のライブラリーモード用に JBoss Operations Network プラグインをインストールします。

手順20.3 JBoss Operations Network ライブラリーモードプラグインのインストール

  1. JBoss Operations Network コンソールを開きます。

    1. JBoss Operations Network コンソールから、Administration を選択します。
    2. コンソールの左側にある Configuration オプションから Agent Plugins を選択します。
    JBoss Data Grid 用の JBoss Operations Network コンソール

    図20.1 JBoss Data Grid 用の JBoss Operations Network コンソール

  2. ライブラリーモードプラグインをアップロードします。

    1. Browse をクリックし、ローカルファイルシステムで InfinispanPlugin を見つけます。
    2. Upload をクリックして、プラグインを JBoss Operations Network サーバーに追加します。
    InfinispanPlugin のアップロード。

    図20.2 InfinispanPlugin のアップロード。

  3. 更新のためのスキャン

    1. ファイルが正常にアップロードされたら、画面の下部にある Scan For Updates をクリックします。
    2. InfinispanPlugin がインストール済みプラグインのリストに表示されます。
    更新済みプラグインのためのスキャン。

    図20.3 更新済みプラグインのためのスキャン。

  4. プラットフォームのインポート

    1. Inventory にナビゲートし、コンソールの左側の Resources リストから Discovery Queue を選択します。
    2. アプリケーションが実行されているプラットフォームを選択し、画面の下部で Import をクリックします。
    Discovery Queue からのプラットフォームのインポート。

    図20.4 Discovery Queue からのプラットフォームのインポート。

  5. プラットフォーム上のサーバーへのアクセス

    1. jdg プラットフォームが Platforms リストに表示されます。
    2. 実行中のサーバーにアクセスするためにプラットフォームをクリックします。
    サーバーのリストを表示するために jdg プラットフォームを開く。

    図20.5 サーバーのリストを表示するために jdg プラットフォームを開く。

  6. JMX サーバーのインポート

    1. Inventory タブから、Child Resources を選択します。
    2. 画面の下部で Import ボタンをクリックし、リストから JMX Server オプションを選択します。
    JMX サーバーのインポート

    図20.6 JMX サーバーのインポート

  7. JDK 接続設定を有効にします。

    1. Resource Import Wizard ウィンドウで、Connection Settings Template オプションのリストから JDK 5 を指定します。
    JDK 5 テンプレートの選択。

    図20.7 JDK 5 テンプレートの選択。

  8. コネクターアドレスを変更します。

    1. Deployment Options メニューで、指定された Connector Address を、Infinispan ライブラリーを含むプロセスのホスト名と JMX ポートで修正します。
    2. 必要な場合は、Principal および Credentials 情報を指定します。
    3. Finish をクリックします。
    Deployment Options 画面での値の修正。

    図20.8 Deployment Options 画面での値の修正。

  9. キャッシュ統計および操作を表示します。

    1. Refresh をクリックして、サーバー一覧を最新の情報に更新します。
    2. 画面の左側のパネルにある JMX Servers ツリーには、Infinispan Cache Managers ノードが含まれ、これには利用可能なキャッシュマネージャーが含まれます。利用可能なキャッシュマネージャ−には利用可能なキャッシュが含まれます。
    3. メトリックスを表示するために利用可能なキャッシュからキャッシュを選択します。
    4. Monitoring タブを選択します。
    5. Tables ビューは、統計およびメトリックスを表示します。
    6. Operations タブは、サービスで実行できるさまざまな操作へのアクセスを提供します。
    JMX 経由でリレーされるメトリックスおよび操作データは、JBoss Operations Network コンソールで利用可能。

    図20.9 JMX 経由でリレーされるメトリックスおよび操作データは、JBoss Operations Network コンソールで利用可能。

20.6.2. ライブラリーモードでの JBoss Data Grid インスタンスの手動による追加

Red Hat JBoss Data Grid インスタンスを JBoss Operations Network に手動で追加するには、JBoss Operations Network インターフェースで次の手順を使用します。
  1. Resources>Platforms>localhost>Inventory の順に選択します。
  2. ページの下部にある Manually Add セクションの横のドロップダウンメニューを開きます。
  3. Infinispan Cache Manager を選択し、Ok をクリックします。
  4. 次のページの default テンプレートを選択します。
  5. JBoss Data Grid インスタンスの手動による追加

    1. 監視する新規 JBoss Data Grid インスタンスの JMX コネクターのアドレスとキャッシュマネージャーの Mbean オブジェクト名の両方を入力します。以下が例になります。
      コネクターアドレス:
      service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:7997/jmxrmi
      Copy to Clipboard Toggle word wrap
    2. オブジェクト名:
      org.infinispan:type=CacheManager,name="<name_of_cache_manager>
      
      Copy to Clipboard Toggle word wrap

注記

オブジェクト名は変わりませんが、コネクターアドレスは、ホストと新規インスタンスに割り当てられた JMX ポートによって変わります。この場合、インスタンスには起動時に以下のシステムプロパティーが必要になります。
-Dcom.sun.management.jmxremote.port=7997 -Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false
Copy to Clipboard Toggle word wrap

20.7. JBoss Operations Network リモートクライアントサーバーのプラグイン

20.7.1. JBoss Operations Network プラグインのメトリックス

Expand
表20.1 キャッシュコンテナーの JBoss Operations Network 特性 (キャッシュマネージャー)
メトリック名 表示名 説明
cache-manager-status Cache Container Status キャッシュコンテナーの現在のランタイム状態です。
cluster-name Cluster Name クラスターの名前です。
coordinator-address Coordinator Address コーディネーターノードのアドレスです。
local-address Local Address ローカルノードのアドレスです。
Expand
表20.2 キャッシュについての JBoss Operations Network メトリックス
メトリック名 表示名 説明
cache-status Cache Status キャッシュの現在のランタイム状態です。
number-of-locks-available [LockManager] Number of locks available 現在利用可能な排他ロックの数です。
concurrency-level [LockManager] Concurrency level LockManager の設定済みの平行性レベルです。
average-read-time [Statistics] Average read time キャッシュでの読み取り操作が完了するまでに必要な平均のミリ秒数です。
hit-ratio [Statistics] Hit ratio ヒット数 (試行が成功した回数) を試行の合計数で割った結果 (パーセント単位) です。
elapsed-time [Statistics] Seconds since cache started キャッシュ起動後の秒数です。
read-write-ratio [Statistics] Read/write ratio キャッシュの読み取り/書き込み比率 (パーセント単位) です。
average-write-time [Statistics] Average write time キャッシュでの書き込み操作の完了に必要な平均のミリ秒数です。
hits [Statistics] Number of cache hits キャッシュヒット数です。
evictions [Statistics] Number of cache evictions キャッシュエビクション操作の数です。
remove-misses [Statistics] Number of cache removal misses キーが見つからなかった場合のキャッシュ除去の回数です。
time-since-reset [Statistics] Seconds since cache statistics were reset 最後にキャッシュ統計がリセットされてからの秒数です。
number-of-entries [Statistics] Number of current cache entries キャッシュ内の現在のエントリーの数です。
stores [Statistics] Number of cache puts キャッシュの put 操作の回数
remove-hits [Statistics] Number of cache removal hits キャッシュの remove 操作のヒット数です。
misses [Statistics] Number of cache misses キャッシュミスの数です。
success-ratio [RpcManager] Successful replication ratio 数値 (double) 形式でのレプリケーションの合計数に対する正常なレプリケーションの比率です。
replication-count [RpcManager] Number of successful replications 成功したレプリケーションの数
replication-failures [RpcManager] Number of failed replications 失敗したレプリケーションの数
average-replication-time [RpcManager] Average time spent in the transport layer トランスポート層で費やされた平均時間 (ミリ秒単位) です。
commits [Transactions] Commits 最終リセット時から実行されるトランザクションのコミット数です。
prepares [Transactions] Prepares 最終リセット時から実行されるトランザクションの準備回数です。
rollbacks [Transactions] Rollbacks 最終リセット時から実行されるトランザクションのロールバック回数です。
invalidations [Invalidation] Number of invalidations インバリデーションの数です。
passivations [Passivation] Number of cache passivations パッシベーションイベントの数です。
activations [Activations] Number of cache entries activated アクティベーションイベントの数です。
cache-loader-loads [Activation] Number of cache store loads キャッシュストアから読み込まれるエントリーの数です。
cache-loader-misses [Activation] Number of cache store misses キャッシュストアに存在しなかったエントリーの数です。
cache-loader-stores [CacheStore] Number of cache store stores キャッシュストアに保存されるエントリーの数です。

注記

これらの統計の一部の収集は、デフォルトで無効にされます。
コネクターついての JBoss Operations Network メトリックス

Red Hat JBoss Data Grid の JBoss Operations Network (JON) プラグインによって提供されるメトリックスは、REST と Hot Rod エンドポイント用のみです。REST プロトコルの場合、データは Web サブシステムのメトリックスから取られる必要があります。これらのエンドポイントのそれぞれについてさらに詳しくは、『スタートガイド』を参照してください。

Expand
表20.3 コネクターついての JBoss Operations Network メトリックス
メトリック名 表示名 説明
bytesRead Bytes Read 読み込まれるバイト数です。
bytesWritten Bytes Written 書き込まれるバイト数です。

注記

これらの統計の収集は、デフォルトで無効にされます。

20.7.2. JBoss Operations Network プラグイン操作

Expand
表20.4 キャッシュについての JBoss ON プラグイン操作
操作名 説明
Clear Cache キャッシュ内容をクリアにします。
Reset Statistics キャッシュによって収集される統計をリセットします。
Reset Activation Statistics キャッシュによって収集されるアクティベーション統計をリセットします。
Reset Invalidation Statistics キャッシュによって収集されるインバリデーション統計をリセットします。
Reset Passivation Statistics キャッシュによって収集されるパッシベーション統計をリセットします。
Reset Rpc Statistics キャッシュによって収集されるレプリケーション統計をリセットします。
Remove Cache キャッシュコンテナーから所定のキャッシュを削除します。
キャッシュバックアップについての JBoss Operations Network プラグイン操作

これらの操作に使用されるキャッシュバックアップは、データセンター間レプリケーションを使用して設定されます。JBoss Operations Network (JON) ユーザーインターフェースでは、それぞれのキャッシュバックアップはキャッシュの子です。データセンター間のレプリケーションについてさらに詳しくは、「データセンター間レプリケーションについて」を参照してください。

Expand
表20.5 キャッシュバックアップについての JBoss Operations Network プラグイン操作
操作名 説明
status サイトの状態を表示します。
bring-site-online サイトをオンラインにします。
take-site-offline サイトをオフラインにします。
キャッシュ (トランザクション)

Red Hat JBoss Data Grid は、リモートクライアントサーバーモードでのトランザクションの使用をサポートしません。結果として、いずれのエンドポイントでもトランザクションを使用することができません。

20.7.3. JBoss Operations Network プラグイン属性

Expand
表20.6 キャッシュの JBoss ON プラグイン属性 (トランスポート)
属性名 タイプ 説明
cluster string グループ通信クラスターの名前。
executor string トランスポートに使用されるエグゼキューター。
lock-timeout long トランスポートにおけるロックのタイムアウト期間。デフォルト値は 240000 です。
machine string トランスポートのマシン ID。
rack string トランスポートのラック ID。
site string トランスポートのサイト ID。
stack string トランスポートに使用される JGroups スタック。

20.8.1. 前提条件

  • JBoss Operations Network (JON) 3.1.x 以上の正しく設定されたインスタンス。
  • アプリケーションが実行されるサーバー上での JBoss Operations Network (JON) エージェントの実行中のインスタンスです。さらに詳しくは、「JBoss Operations Network エージェント」を参照してください。
  • 完全な JDK を含む RHQ エージェントの操作インスタンス。エージェントには、とくに JDK からの tools.jar ファイルへのアクセスがあることを確認します。JBoss Operations Network (JON) エージェントの環境ファイル (bin/rhq-env.sh) で、RHQ_AGENT_JAVA_HOME プロパティーの値を完全な JDK に設定します。
  • RHQ エージェントは、JBoss Enterprise Application Platform インスタンスと同じユーザーを使用して起動している必要があります。例として、JBoss Operations Network (JON) エージェントを root 権限を持つユーザーとして実行し、JBoss Enterprise Application Platform プロセスを異なるユーザーとして実行しても予想通りには機能しないため、この実行を避ける必要があります。
  • ライブラリーモード用にインストールされた JBoss Operations Network (JON) プラグインです。さらに詳しくは、「JBoss Operations Network プラグインのインストール (ライブラリーモード)  」を参照してください。
  • Red Hat JBoss Data Grid のライブラリーモードを使用したカスタムアプリケーションです。このアプリケーションでは、jmxStatistics を有効にする必要があります (宣言的にか、またはプログラムを使用するかのいずれかによる)。さらに詳しくは、「キャッシュインスタンスに対して JMX を有効にする」を参照してください。
  • Java 仮想マシン (JVM) は、JMX MBean Server を公開するために設定する必要があります。Oracle/Sun JDK については、http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.htmlを参照してください。
  • JBoss Enterprise Application Platform の正しく追加され、設定された管理ユーザーです。

20.8.2. スタンドアロンモードでデプロイされたアプリケーションの監視

スタンドアロンモードを使って JBoss Enterprise Application Platform 6 でデプロイされたアプリケーションを監視するには以下の手順を使用します。

手順20.4 スタンドアロンモードでデプロイされたアプリケーションの監視

  1. JBoss Enterprise Application Platform インスタンスを起動します。

    JBoss Enterprise Application Platform インスタンスを以下のように起動します。
    1. 以下のコマンドをコマンドラインに入力し、新規オプションをスタンドアロン設定ファイル (/bin/standalone.conf) に追加します。
      JAVA_OPTS="$JAVA_OPTS -Dorg.rhq.resourceKey=MyEAP"
      Copy to Clipboard Toggle word wrap
    2. JBoss Enterprise Application Platform インスタンスをスタンドアロンモードで以下のように起動します。
      $JBOSS_HOME/bin/standalone.sh
      Copy to Clipboard Toggle word wrap
  2. JBoss Operations Network (JON) 検出を実行します。

    JBoss Operations Network (JON) エージェントで discovery --full コマンドを実行します。
  3. アプリケーションサーバープロセスを見つけます。

    JBoss Operations Network (JON) web インターフェースに、JBoss Enterprise Application Platform 6 プロセスが JMX サーバーとしてリストされます。
  4. プロセスをインベントリーにインポートします。

    プロセスを JBoss Operations Network (JON) インベントリーにインポートします。
  5. Red Hat JBoss Data Grid アプリケーションをデプロイします。

    globalJmxStatistics および jmxStatistics を有効にした JJBoss Data Grid ライブラリーモードアプリケーションが含まれる WAR ファイルをデプロイします。
  6. オプション: 検出を再度実行します。

    必要な場合は、discovery --full コマンドを再び実行し、新規リソースを検出します。
結果

JBoss Data Grid ライブラリーモードアプリケーションが JBoss Enterprise Application Platform のスタンドアロンモードでデプロイされ、JBoss Operations Network (JON) を使用して監視することができるようになります。

20.8.3. ドメインモードでデプロイされたアプリケーションの監視

ドメインモードを使って JBoss Enterprise Application Platform 6 でデプロイされたアプリケーションを監視するには以下の手順を使用します。

手順20.5 ドメインモードでデプロイされたアプリケーションの監視

  1. ホスト設定の編集

    domain/configuration/host.xml ファイルを編集し、server 要素を以下の設定に置き換えます。
    <servers>
    	<server name="server-one" group="main-server-group">
    		<jvm name="default">
    			<jvm-options>
    				<option value="-Dorg.rhq.resourceKey=EAP1"/>
    			</jvm-options>
    		</jvm>
    	</server>
    	<server name="server-two" group="main-server-group" auto-start="true">
    		<socket-bindings port-offset="150"/>
    		<jvm name="default">
    			<jvm-options>
    				<option value="-Dorg.rhq.resourceKey=EAP2"/>
    			</jvm-options>
    		</jvm>
    	</server>
    </servers>
    
    Copy to Clipboard Toggle word wrap
  2. JBoss Enterprise Application Platform の起動

    ドメインモードによる JBoss Enterprise Application Platform 6 の起動:
    $JBOSS_HOME/bin/domain.sh
    Copy to Clipboard Toggle word wrap
  3. Red Hat JBoss Data Grid アプリケーションのデプロイ

    globalJmxStatistics および jmxStatistics を有効にした JBoss Data Grid ライブラリーモードアプリケーションが含まれる WAR ファイルをデプロイします。
  4. JBoss Operations Network (JON) での検出の実行

    必要な場合は、新規リソースを検出するために JBoss Operations Network (JON) エージェントについて discovery --full コマンドを実行します。
結果

JBoss Data Grid ライブラリーモードアプリケーションが、JBoss Enterprise Application Platform のドメインモードでデプロイされ、JBoss Operations Network (JON) を使用して監視することができるようになります。

20.9. JBoss Operations Network のプラグインクイックスタート

単一の JBoss Operation Network エージェント向けのテストおよびデモンストレーション目的で、プラグインをサーバーにアップロードし、エージェントのコマンドラインに「plugins update」と入力して、サーバーから最新のプラグインを強制的に読み出します。

20.10. 他の管理ツールと操作

Red Hat JBoss Data Grid インスタンスの管理には、関連する統計情報を大量に公開する必要があります。管理者は統計情報より、 JBoss Data Grid の各ノードの状態を明確に把握することができます。1 つのインストールが、何十または何百もの JBoss Data Grid ノードによって構成されることもあるため、明確で簡潔に情報を提供することが重要になります。JBoss Operations Network はランタイムを可視化するツールの 1 つです。JMX が有効である場合、JConsole などの他のツールも使用できます。

20.10.1. URL 経由のデータアクセス

REST インターフェースで設定されたキャッシュは、RESTful HTTP アクセスを使用して Red Hat JBoss Data Grid へアクセスできます。
RESTful サービスは HTTP クライアントライブラリーのみが必要なため、密結合されたクライアントライブラリーやバインディングは必要ありません。
HTTP put() および post() メソッドは、キャッシュにデータを格納します。使用される URL より使用されるキャッシュ名とキーを判断することができます。データはキャッシュに格納される値で、要求のボディーに置かれます。
これらのメソッドに対して Content-Type ヘッダーを設定する必要があります。データの読み出しには GET および HEAD メソッドが使用され、他のヘッダーはキャッシュの設定と挙動を制御します。

注記

競合するサーバーモジュールがデータグリッドとやりとりすることはできません。JBoss Data Grid にアクセスするには、互換性のあるインターフェースでキャッシュを設定する必要があります。

20.10.2. Map メソッドの制限

size()values()keySet()entrySet() など特定の Map メソッドは不安定であるため、Red Hat JBoss Data Grid で一定の制限を用いて使用することが可能です。これらのメソッドはロック (グローバルまたはローカル) を取得せず、同時編集、追加および削除はこれらの呼び出しでは考慮されません。さらに、前述のメソッドはローカルのデータコンテナー上でのみ操作可能で、ステートのグローバルビューは提供しません。
前述のメソッドがグローバルに実行されると、パフォーマンスに大きく影響し、スケーラビリティーのボトルネックが発生します。そのため、情報収集やデバッグの目的でのみこれらのメソッドを使用することが推奨されます。

パート X. コマンドラインツール

Red Hat JBoss Data Grid には、データグリッド内のキャッシュのインタラクションに使用するコマンドラインツールが含まれます。これらのツールの最初のものは Infinispan コマンドラインツールです。

第21章 Red Hat JBoss Data Grid CLI

Red Hat JBoss Data Grid には、(トランザクション、データセンター間のレプリケーションサイト、およびローリングアップグレードなどの) キャッシュや内部コンポーネント内のデータを検査し、変更するために使用する Red Hat JBoss Data Grid コマンドラインインターフェース (CLI) が含まれます。JBoss Data Grid CLI は、トランザクションなどのさらに高度な操作に使用することもできます。
CLI は、サーバー側のモジュールとクライアントコマンドツールから構成されます。サーバー側のモジュール (infinispan-cli-server-$VERSION.jar) にはコマンドのインタープリターが含まれており、このモジュールはアプリケーションに組み込まれている必要があります。

21.1. CLI の起動 (サーバー)

Red Hat JBoss Data Grid CLI のサーバー側のモジュールを、standalone および cluster ファイルを使って起動します。Linux の場合、standlaone.sh または clustered.sh スクリプトを使用し、Windows の場合、standalone.bat または clustered.bat ファイルを使用します。

21.2. CLI の起動 (クライアント)

bin/ にある ispn-cli ファイルを使用して JBoss Data Grid CLI クライアントを起動します。Linux の場合、bin/ispn-cli.sh を使用し、Windows の場合、bin/ispn-cli.bat を実行します。
CLI クライアントを起動する際、特定のコマンドラインスイッチを使用して起動をカスタマイズすることができます。

21.3. CLI クライアントのコマンドラインスイッチ

リストされているコマンドラインスイッチは、Red Hat JBoss Data Grid CLI コマンドの起動時にコマンドラインに追加されます。
Expand
表21.1 CLI クライアントのコマンドラインスイッチ
短縮表記 全表記 説明
-c --connect=${URL} 実行中の Red Hat JBoss Data Grid インスタンスに接続します。たとえば、JMX over RMI の場合、jmx://[username[:password]]@host:port[/container[/cache]] を使用し、JMX over JBoss Remoting の場合は remoting://[username[:password]]@host:port[/container[/cache]] を使用します。
-f --file=${FILE} インタラクティブモードではなく、指定されたファイルからの入力を読み込みます。値が - に設定されると、stdin が入力として使用されます。
-h --help ヘルプ情報を表示します。
-v --version CLI のバージョン情報を表示します。

21.4. アプリケーションへの接続

以下のコマンドを用いて、CLI によりアプリケーションに接続します。
[disconnected//]> connect jmx://localhost:12000
[jmx://localhost:12000/MyCacheManager/>
Copy to Clipboard Toggle word wrap

注記

ポートの値 12000 は、JVM が開始される際の値によって変わります。たとえば、JVM を -Dcom.sun.management.jmxremote.port=12000 コマンドラインパラメーターを使用して開始する場合はこのポートが使用されますが、それ以外の場合はランダムポートが選択されます。リモートプロトコル (remoting://localhost:9999) が使用される場合、Red Hat JBoss Data Grid サーバー管理ポートが使用されます (デフォルトはポート 9999)。
コマンドラインプロンプトは、現在選択されている CacheManager を含む、アクティブな接続情報を表示します。
キャッシュ操作を実行する前に、cache コマンドを使用してキャッシュを選択します。CLI はタブ補完をサポートしているため、cache を使用してタブボタンを押すと、アクティブなキャッシュのリストが表示されます。
[[jmx://localhost:12000/MyCacheManager/> cache
___defaultcache  namedCache
[jmx://localhost:12000/MyCacheManager/]> cache ___defaultcache
[jmx://localhost:12000/MyCacheManager/___defaultcache]>
Copy to Clipboard Toggle word wrap
さらに、タブを押すと CLI の有効なコマンドのリストが表示されます。

21.5. CLI による Red Hat JBoss Data Grid インスタンスの終了

ライブラリーモード

コンテナー内で Red Hat JBoss Data Grid インスタンスをライブラリーモードのデプロイとして実行している場合、JBoss Data Grid のライフサイクルはユーザーデプロイメントのライフサイクルにバインドされます。

コンテナーの管理インターフェースを使用してユーザーデプロイメントを終了またはデプロイを解除します。たとえば、Red Hat JBoss Enterprise Application Platform では、管理 CLI を使用します。さらに詳しくは、JBoss Enterprise Application Platform 『Administration and Configuration Guide』 の 『Management Interfaces』 の章を参照してください。
リモートクライアントサーバーモード

リモートクライアントサーバーの JBoss Data Grid インスタンスは、以下のスクリプトを使用して終了することができます。

jboss-datagrid-6.2.0-server/bin/init.d/jboss-datagrid.sh stop
Copy to Clipboard Toggle word wrap
または、kill コマンドを直接使用することができます。
kill -15 $pid # send the TERM signal
Copy to Clipboard Toggle word wrap
一定の期間が経過しても PID が残っている場合、以下を使用してください。
kill -9 $pid
Copy to Clipboard Toggle word wrap

21.6. CLI コマンド

21.6.1. abort コマンド

abort コマンドは、start コマンドを使用して開始された実行中のバッチを中止します。バッチ処理は指定したキャッシュに対して有効にされている必要があります。以下は使用例です。
[jmx://localhost:12000/MyCacheManager/namedCache]> start
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> abort
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
null
Copy to Clipboard Toggle word wrap

21.6.2. begin コマンド

begin コマンドはトランザクションを開始します。このコマンドでは、対象とするキャッシュに対してトランザクションを有効にする必要があります。このコマンドの使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> begin
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> put b b
[jmx://localhost:12000/MyCacheManager/namedCache]> commit
Copy to Clipboard Toggle word wrap

21.6.3. cache コマンド

cache コマンドは、すべての後続の操作に使用されるデフォルトキャッシュを指定します。パラメーターを指定せずに呼び出されると、現在選択されているキャッシュを表示します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> cache ___defaultcache
[jmx://localhost:12000/MyCacheManager/___defaultcache]> cache
___defaultcache
[jmx://localhost:12000/MyCacheManager/___defaultcache]>
Copy to Clipboard Toggle word wrap

21.6.4. clear コマンド

clear コマンドは、キャッシュからすべてのコンテンツをクリアします。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> clear
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
null
Copy to Clipboard Toggle word wrap

21.6.5. commit コマンド

commit コマンドは、進行中のトランザクションへの変更をコミットします。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> begin
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> put b b
[jmx://localhost:12000/MyCacheManager/namedCache]> commit
Copy to Clipboard Toggle word wrap

21.6.6. container コマンド

container コマンドはデフォルトのキャッシュコンテナー (キャッシュマネージャー) を選択します。パラメーターを指定せずに呼び出されると、利用可能なすべてのコンテナーをリストします。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> container
MyCacheManager OtherCacheManager
[jmx://localhost:12000/MyCacheManager/namedCache]> container OtherCacheManager
[jmx://localhost:12000/OtherCacheManager/]>
Copy to Clipboard Toggle word wrap

21.6.7. create コマンド

create コマンドは、既存のキャッシュ定義に基づいて新規のキャッシュを作成します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> create newCache like namedCache
[jmx://localhost:12000/MyCacheManager/namedCache]> cache newCache
[jmx://localhost:12000/MyCacheManager/newCache]>
Copy to Clipboard Toggle word wrap

21.6.8. disconnect コマンド

disconnect コマンドは、現在アクティブな接続を解除します。これにより、CLI は別のインスタンスに接続できます。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> disconnect
[disconnected//]
Copy to Clipboard Toggle word wrap

21.6.9. encoding コマンド

encoding コマンドは、キャッシュから/へのエントリーの読み書きを行う際に使用するデフォルトのコーデックを設定します。引数なしで呼び出される場合、現在選択されているコーデックが表示されます。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> encoding
none
[jmx://localhost:12000/MyCacheManager/namedCache]> encoding --list
memcached
hotrod
none
rest
[jmx://localhost:12000/MyCacheManager/namedCache]> encoding hotrod
Copy to Clipboard Toggle word wrap

21.6.10. end コマンド

end コマンドは、 start コマンドを使用して開始された実行中のバッチを終了します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> start
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> end
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
a
Copy to Clipboard Toggle word wrap

21.6.11. evict コマンド

evict コマンドは、キャッシュから特定のキーに関連付けられたエントリーをエビクトします。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> evict a
Copy to Clipboard Toggle word wrap

21.6.12. get コマンド

get コマンドは、指定されたキーと関連付けられている値を表示します。プリミティブ型および 文字列の場合に、get コマンドはデフォルト表現のみを表示します。他のオブジェクトの場合、オブジェクトの JSON 表現が表示されます。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
a
Copy to Clipboard Toggle word wrap

21.6.13. info コマンド

info コマンドは選択されたキャッシュまたはコンテナーの設定を表示します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> info
GlobalConfiguration{asyncListenerExecutor=ExecutorFactoryConfiguration{factory=org.infinispan.executors.DefaultExecutorFactory@98add58}, asyncTransportExecutor=ExecutorFactoryConfiguration{factory=org.infinispan.executors.DefaultExecutorFactory@7bc9c14c}, evictionScheduledExecutor=ScheduledExecutorFactoryConfiguration{factory=org.infinispan.executors.DefaultScheduledExecutorFactory@7ab1a411}, replicationQueueScheduledExecutor=ScheduledExecutorFactoryConfiguration{factory=org.infinispan.executors.DefaultScheduledExecutorFactory@248a9705}, globalJmxStatistics=GlobalJmxStatisticsConfiguration{allowDuplicateDomains=true, enabled=true, jmxDomain='jboss.infinispan', mBeanServerLookup=org.jboss.as.clustering.infinispan.MBeanServerProvider@6c0dc01, cacheManagerName='local', properties={}}, transport=TransportConfiguration{clusterName='ISPN', machineId='null', rackId='null', siteId='null', strictPeerToPeer=false, distributedSyncTimeout=240000, transport=null, nodeName='null', properties={}}, serialization=SerializationConfiguration{advancedExternalizers={1100=org.infinispan.server.core.CacheValue$Externalizer@5fabc91d, 1101=org.infinispan.server.memcached.MemcachedValue$Externalizer@720bffd, 1104=org.infinispan.server.hotrod.ServerAddress$Externalizer@771c7eb2}, marshaller=org.infinispan.marshall.VersionAwareMarshaller@6fc21535, version=52, classResolver=org.jboss.marshalling.ModularClassResolver@2efe83e5}, shutdown=ShutdownConfiguration{hookBehavior=DONT_REGISTER}, modules={}, site=SiteConfiguration{localSite='null'}}
Copy to Clipboard Toggle word wrap

21.6.14. locate コマンド

locate コマンドは、分散クラスター内の指定されたエントリーの物理的な場所を表示します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> locate a
[host/node1,host/node2]
Copy to Clipboard Toggle word wrap

21.6.15. put コマンド

put コマンドはエントリーをキャッシュに挿入します。キーに対するマッピングが存在する場合、put コマンドは古い値を上書きします。CLI により、キーと値を保存するために使用されるデータのタイプに対して制御が可能になります。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> put b 100
[jmx://localhost:12000/MyCacheManager/namedCache]> put c 4139l
[jmx://localhost:12000/MyCacheManager/namedCache]> put d true
[jmx://localhost:12000/MyCacheManager/namedCache]> put e { "package.MyClass": {"i": 5, "x": null, "b": true } }
Copy to Clipboard Toggle word wrap
オプションとして、put は次のようにライフスパンと最大アイドル時間の値を指定することができます。
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a expires 10s
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a expires 10m maxidle 1m
Copy to Clipboard Toggle word wrap

21.6.16. replace コマンド

replace コマンドはキャッシュ内の既存のエントリーを指定した新しい値に置き換えます。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> replace a b
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
b
[jmx://localhost:12000/MyCacheManager/namedCache]> replace a b c
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
c
[jmx://localhost:12000/MyCacheManager/namedCache]> replace a b d
[jmx://localhost:12000/MyCacheManager/namedCache]> get a
c
Copy to Clipboard Toggle word wrap

21.6.17. rollback コマンド

rollback コマンドは、進行中のトランザクションによる変更をロールバックします。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> begin
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> put b b
[jmx://localhost:12000/MyCacheManager/namedCache]> rollback
Copy to Clipboard Toggle word wrap

21.6.18. site コマンド

site コマンドは、データセンター間レプリケーションに関連する管理タスクを実行します。また、このコマンドはサイトの状態についての情報を取得し、サイトの状態を切り替えます。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> site --status NYC
online
[jmx://localhost:12000/MyCacheManager/namedCache]> site --offline NYC
ok
[jmx://localhost:12000/MyCacheManager/namedCache]> site --status NYC
offline
[jmx://localhost:12000/MyCacheManager/namedCache]> site --online NYC
Copy to Clipboard Toggle word wrap

21.6.19. start コマンド

start コマンドは、操作のバッチを開始します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> start
[jmx://localhost:12000/MyCacheManager/namedCache]> put a a
[jmx://localhost:12000/MyCacheManager/namedCache]> put b b
[jmx://localhost:12000/MyCacheManager/namedCache]> end
Copy to Clipboard Toggle word wrap

21.6.20. stats コマンド

stats コマンドはキャッシュの統計を表示します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> stats
Statistics: {
  averageWriteTime: 143
  evictions: 10
  misses: 5
  hitRatio: 1.0
  readWriteRatio: 10.0
  removeMisses: 0
  timeSinceReset: 2123
  statisticsEnabled: true
  stores: 100
  elapsedTime: 93
  averageReadTime: 14
  removeHits: 0
  numberOfEntries: 100
  hits: 1000
}
LockManager: {
  concurrencyLevel: 1000
  numberOfLocksAvailable: 0
  numberOfLocksHeld: 0
}
Copy to Clipboard Toggle word wrap

21.6.21. upgrade コマンド

upgrade コマンドは、ローリングアップグレードの手順を実装します。ローリングアップグレードの詳細については、『Red Hat JBoss Data Grid 開発者ガイド』の『ローリングアップグレード』の章を参照してください。
upgrade コマンドの使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> upgrade --synchronize=hotrod --all
[jmx://localhost:12000/MyCacheManager/namedCache]> upgrade --disconnectsource=hotrod --all
Copy to Clipboard Toggle word wrap

21.6.22. version コマンド

version コマンドは、CLI クライアントおよびサーバーのバージョン情報を表示します。この使用例は次の通りです。
[jmx://localhost:12000/MyCacheManager/namedCache]> version
Client Version 5.2.1.Final
Server Version 5.2.1.Final
Copy to Clipboard Toggle word wrap

パート XI. 他の Red Hat JBoss Data Grid 機能

第22章 1 次キャッシュのセットアップ

22.1. 1 次キャッシュについて

1 次 (L1) キャッシュは、最初にアクセスされた後にリモートキャッシュエントリーを格納するため、同じエントリーがその後使用される時に不必要なリモートフェッチ操作が行われないようにします。1 次キャッシュは、Red Hat JBoss Data Grid のキャッシュモードがディストリビューションに設定されている場合にのみ利用できます。他のキャッシュモードでは、1 次キャッシュに関連するいずれの設定も無視されます。
キャッシュがディストリビューションモードで設定される場合、エントリーがすべてのクラスター化されたキャッシュ間で均等に分散されます。それぞれのエントリーは、必要な数の所有者にコピーされ、その数はキャッシュの合計数より小さくなる可能性があります。その結果、システムのスケーラビリティーが改善されるだけでなく、いくつかのエントリーがすべてのノードで利用できなくなり、それらの所有者ノードから取り込まれる必要があります。この状態では、後続のユーザーに対して繰り返される取り込みを避けるために、キャッシュコンポーネントを、所有しないエントリーを一時的に保存するための 1 次キャッシュを使用できるように設定します。
キーが更新される度に、インバリデーションメッセージが生成されます。このメッセージは、現在の 1 次キャッシュエントリーに対応するデータを含むそれぞれのノードのマルチキャストです。インバリデーションメッセージにより、それらの各ノードは、関連するエントリーを無効なものとしてマークします。さらに、エントリーのロケーションがクラスター内で変更されると、対応する 1 次キャッシュエントリーは無効にされ、古くなったキャッシュエントリーが発生しないようにします。

22.2. 1 次キャッシュの設定

22.2.1. 1 次キャッシュの設定 (ライブラリーモード)

次の設定例は、Red Hat JBoss Data Grid のライブラリーモードにおける 1 次キャッシュのデフォルト値を示しています。
<clustering mode="distribution">
	<sync/>
	<l1 enabled="true"
            lifespan="60000" />
</clustering>
Copy to Clipboard Toggle word wrap
l1 要素は、分散キャッシュインスタンスにおけるキャッシュの動作を設定します。分散されていないキャッシュと共に使用されている場合、この要素は無視されます。
  • enabled パラメーターは 1 次キャッシュを有効にします。
  • lifespan パラメーターは、1 次キャッシュに置かれる際に、エントリーの最大ライフスパンを設定します。

22.2.2. 1 次キャッシュの設定 (リモートクライアントサーバーモード)

以下は、Red Hat JBoss Data Grid のリモートクライアントサーバーモードにおける 1 次キャッシュのデフォルト値を示しています。
<distributed-cache l1-lifespan="${VALUE}">
	...
</distributed-cache>
Copy to Clipboard Toggle word wrap
l1-lifespan 要素は、1 次キャッシュを有効にし、キャッシュの 1 次キャッシュエントリーについてのライフスパンを設定するために distributed-cache 要素に追加されます。この要素は、分散キャッシュにのみ有効です。
l1-lifespan0 または負の数値 (-1) に設定される場合、1 次キャッシュは無効になります。1 次キャッシュは、l1-lifespan の値が 0 より大きくなる場合に有効になります。

注記

キャッシュが Hot Rod プロトコル経由でリモートでアクセスされる場合、クライアントは所有者ノードに直接アクセスします。したがって、この状態で 1 次キャッシュを使用してもパフォーマンスは改善されないため、1 次キャッシュの使用は推奨されません。他のリモートクライアント (Memcached、REST) は、所有者をターゲットにしないため、1 次キャッシュを使用するとパフォーマンスが向上します (同時に高いメモリー使用量が発生します)。

第23章 トランザクションのセットアップ

23.1. トランザクションについて

トランザクションは、相互に依存しているか、または関連のある操作またはタスクのコレクションで構成されています。単一トランザクション内のすべての操作が成功しないと、トランザクションの全体の成功にはつながりません。トランザクション内のいずれかの操作が失敗すると、トランザクションは全体として失敗し、すべての変更をロールバックします。トランザクションは、大規模な操作の一部として一連の変更を処理する場合にとくに役立ちます。
Red Hat JBoss Data Grid では、トランザクションはライブラリーモードでのみ利用可能です。

23.1.1. トランザクションマネージャーについて

Red Hat JBoss Data Grid では、トランザクションマネージャーは、単一または複数のリソースにまたがってトランザクションを調整します。トランザクションマネージャーの役割には以下が含まれます。
  • トランザクションの開始および終了
  • 各トランザクションについての情報の管理
  • トランザクションが複数リソースにまたがって動作する際のトランザクションの調整
  • 変更のロールバックによる、失敗したトランザクションからのリカバリー

23.1.2. XA リソースおよび同期

XA リソースは本格的なトランザクション参加者です。準備段階で、XA リソースは、値が OK または ABORT のいずれかの投票を返します。トランザクションマネージャーがすべての XA リソースから OK 投票を受信する場合、トランザクションはコミットされ、それ以外の場合にはロールバックされます。
同期は、トランザクションのライフサイクルにつながるイベントについての通知を受信するリスナーの 1 つのタイプです。同期は、操作の終了前後にイベントを受信します。
リカバリーが必要ではない場合、完全な XA リソースとして登録する必要はありません。同期の利点には、同期により、トランザクションマネージャーが、その他の 1 つのリソースのみがそのトランザクションでリストされる 1 相コミット (1PC) で 2 相コミット (2PC) を最適化できる点があります (最終リソースコミット最適化)。これにより、同期をより効率的にすることができます。
ただし、Red Hat JBoss Data Grid 内の準備段階で操作が失敗する場合、トランサクションはロールバックされず、トランザクションにより多くの参加者が存在する場合、それらはその失敗を無視し、コミットできます。さらに、コミット段階で発生するエラーは、トランザクションをコミットするアプリケーションコードに伝搬されません。
デフォルトで、JBoss Data Grid は同期としてトランザクションに登録されます。

23.1.3. 楽観的トランザクションと悲観的トランザクション

悲観的トランザクションは、キー上で最初の書き込み操作が実行される際にロックを取得します。キーがロックされた後は、このトランザクションがコミットされるか、またはロールバックされるまでその他のトランザクションはキーを変更することができません。デッドロックを回避するために正しい順番でロックを取得できるかどうかは、アプリケーションコードによります。
楽観的トランザクションの場合、ロックはトランザクションの準備時間に取得され、トランザクションがコミット (またはロールバック) するまで保持されます。さらに、Red Hat JBoss Data Grid は、トランザクション内の変更されたすべてのエントリーについてキーを自動的にソートし、ロックされているキーの順序が正しくないために生じるデッドロックを回避します。この結果は以下のようになります。
  • トランザクションの実行時に送信されるメッセージが少なくなる
  • ロックの保持期間が短くなる
  • スループットが改善する

注記

読み取り操作ではロックを一切取得しません。オンデマンドで読み取り操作のロックを取得することは、この操作と共に FORCE_WRITE_LOCK フラグを使用した場合の悲観的トランザクションでのみ可能になります。

23.1.4. 書き込みスキューのチェック

エントリーの共通のユースケースとして、エントリーはまず読み取られ、その後トランザクションで書き込みが行なわれます。ただし、3 つ目のトランザクションが、これら 2 つの操作の間にエントリーを変更する可能性があります。このような状況を検出し、トランザクションをロールバックするために、Red Hat JBoss Data Grid は、エントリーのバージョン管理と書き込みスキューのチェックを行います。変更されたバージョンがトランザクション時に最後に読み取られたバージョンと同じでない場合、書き込みスキューチェックは例外をスローし、トランザクションはロールバックされます。
書き込みスキューのチェックを有効にするには、REPEATABLE_READ の分離レベルが必要です。さらに、クラスターモード (ディストリビューションモードまたはレプリケーションモード) で、エントリーのバージョン管理をセットアップします。ローカルモードの場合、エントリーのバージョン管理は不要です。

重要

楽観的トランザクションの場合、書き込みスキューのチェックは、(アトミックな) 条件操作で必要になります。

23.1.5. 複数のキャッシュインスタンスにわたるトランザクション

各キャッシュは個別のスタンドアロン Java Transaction API (JTA) リソースとして動作します。ただし、コンポーネントは最適化のために Red Hat JBoss Data Grid で内部的に共有できますが、この共有は、キャッシュの Java Transaction API (JTA) Manager との対話方法には影響を与えません。

23.2. トランザクションの設定

23.2.1. トランザクションの設定 (ライブラリーモード)

Red Hat JBoss Data Grid では、ライブラリーモードのトランザクションは、同期化およびトランザクションリカバリーと共に設定できます。トランザクションは全体として (同期化およびトランザクションリカバリーを含む)、リモートクライアントサーバーモードで使用することはできません。
ライブラリーモードでは、トランザクションは以下のように設定されます。

手順23.1 ライブラリーモードでのトランザクションの設定 (XML 設定)

  1. トランザクションモードを設定します。

    以下のテーブルで、利用可能なルックアップクラスのリストについての手順を確認します。
    <namedCache ...>
    	<transaction transactionMode="{TRANSACTIONAL,NON_TRANSACTIONAL}">
            ...
    </namedCache>
    
    Copy to Clipboard Toggle word wrap
  2. トランザクションマネージャーを設定します。

    transactionMode 要素は、キャッシュがトランザクションであるかどうかを設定します。
    <namedCache ...>
    	<transaction transactionMode="TRANSACTIONAL"
    		     transactionManagerLookupClass="{TransactionManagerLookupClass}">
    </namedCache>
    
    Copy to Clipboard Toggle word wrap
  3. ロックモードを設定します。

    lockingMode パラメーターは、楽観的ロックまたは悲観的ロックのメソッドが使用されるかどうかを決定します。キャッシュが非トランザクションの場合、ロックモードは無視されます。このパラメーターのデフォルト値は OPTIMISTIC です。
    <namedCache ...>
    	<transaction transactionMode="TRANSACTIONAL"
    		     transactionManagerLookupClass="{TransactionManagerLookupClass}"
    		     lockingMode="{OPTIMISTIC,PESSIMISTIC}">
    </namedCache>
    
    Copy to Clipboard Toggle word wrap
  4. 同期化を指定します。

    useSynchronization 要素は、トランザクションマネージャーを使って同期化を登録するようにキャッシュを設定するか、またはキャッシュ自体を XA リソースとして登録するようにキャッシュを設定します。この要素のデフォルト値は true (同期化の使用) です。
    <namedCache ...>
    	<transaction transactionMode="TRANSACTIONAL"
    		     transactionManagerLookupClass="{TransactionManagerLookupClass}"
    		     lockingMode="{OPTIMISTIC,PESSIMISTIC}"
    		     useSynchronization="{true,false}">
    </namedCache>
    
    Copy to Clipboard Toggle word wrap
  5. リカバリーを設定します。

    recovery 要素は、true に設定されるとキャッシュのリカバリーを有効にします。
    recoveryInfoCacheName パラメーターは、リカバリー情報が保持されるキャッシュの名前を設定します。キャッシュのデフォルト名は __recoveryInfoCacheName__ です。
    <namedCache ...>
    	<transaction transactionMode="TRANSACTIONAL"
    		     transactionManagerLookupClass="{TransactionManagerLookupClass}"
    		     lockingMode="{OPTIMISTIC,PESSIMISTIC}"
    		     useSynchronization="{true,false}">
    		<recovery enabled="true" 
    			  recoveryInfoCacheName="{CacheName}" />
    </namedCache>
    
    Copy to Clipboard Toggle word wrap
  6. 書き込みスキューチェックを設定します。

    writeSkew チェックは、異なるトランザクションからのエントリーに対する変更によりトランザクションがロールバックされるべきかどうかを判別します。true に設定された書き込みスキューにより、isolation_levelREPEATABLE_READ に設定する必要があります。writeSkew および isolation_level のデフォルト値はそれぞれ falseREAD_COMMITTED です。
    <namedCache ...>   
    	<transaction ...>
    	<locking isolation_level="{READ_COMMITTED,REPEATABLE_READ}" 
    	 	 writeSkew="{true,false}" />
            ...
    </namedCache>
    
    Copy to Clipboard Toggle word wrap
  7. エントリーのバージョン管理を設定します。

    クラスター化されたキャッシュについては、エントリーのバージョン管理を有効にし、その値を SIMPLE に設定することにより書き込みスキューのチェックを有効にします。
    <namedCache ...>
    	<transaction ...>
    	<locking ...>
    	<versioning enabled="{true,false}" 
    		    versioningScheme="{NONE|SIMPLE}"/>
            ...
    </namedCache>
    
    Copy to Clipboard Toggle word wrap

手順23.2 ライブラリーモード (プログラムを用いた設定) でトランザクションを設定します。

  1. トランザクションモードを設定します。

    以下のようにトランザクションモードを設定します。
    Configuration config = new ConfigurationBuilder()/* ... */.transaction()
            .transactionMode(TransactionMode.TRANSACTIONAL);
    
    Copy to Clipboard Toggle word wrap
  2. トランザクションマネージャーを設定します。

    以下のテーブルで、利用可能なルックアップクラスのリストについての手順を確認します。
    Configuration config = new ConfigurationBuilder()/* ... */.transaction()
            .transactionMode(TransactionMode.TRANSACTIONAL)
            .transactionManagerLookup(new GenericTransactionManagerLookup());
    
    Copy to Clipboard Toggle word wrap
  3. ロックモードを設定します。

    lockingMode 値は、楽観的または悲観的ロックを使用するかどうかを決定します。キャッシュが非トランザクションの場合、ロックモードは無視されます。デフォルト値は OPTIMISTIC です。
    Configuration config = new ConfigurationBuilder()/* ... */.transaction()
            .transactionMode(TransactionMode.TRANSACTIONAL)
            .transactionManagerLookup(new GenericTransactionManagerLookup());
            .lockingMode(LockingMode.OPTIMISTIC);
    
    Copy to Clipboard Toggle word wrap
  4. 同期化を指定します。

    useSynchronization 値は、トランザクションマネージャーを使って同期化を登録するようにキャッシュを設定するか、またはキャッシュ自体を XA リソースとして登録するようにキャッシュを設定します。デフォルト値は true (同期の使用) です。
    Configuration config = new ConfigurationBuilder()/* ... */.transaction()
            .transactionMode(TransactionMode.TRANSACTIONAL)
            .transactionManagerLookup(new GenericTransactionManagerLookup());
            .lockingMode(LockingMode.OPTIMISTIC)
            .useSynchronization(true);
    
    Copy to Clipboard Toggle word wrap
  5. リカバリーを設定します。

    recovery パラメーターは、true に設定されるとキャッシュのリカバリーを有効にします。
    recoveryInfoCacheName は、リカバリー情報が保持されるキャッシュの名前を設定します。キャッシュのデフォルト名は RecoveryConfiguration.DEFAULT_RECOVERY_INFO_CACHE によって指定されます。
    Configuration config = new ConfigurationBuilder()/* ... */.transaction()
            .transactionMode(TransactionMode.TRANSACTIONAL)
            .transactionManagerLookup(new GenericTransactionManagerLookup());
            .lockingMode(LockingMode.OPTIMISTIC)
            .useSynchronization(true)
            .recovery()
                .recoveryInfoCacheName("anotherRecoveryCacheName");
    
    Copy to Clipboard Toggle word wrap
  6. 書き込みスキューチェックを設定します。

    writeSkew チェックは、異なるトランザクションからのエントリーに対する変更によりトランザクションがロールバックされるべきかどうかを判別します。true に設定された書き込みスキューにより、isolation_levelREPEATABLE_READ に設定する必要があります。writeSkew および isolation_level のデフォルト値はそれぞれ falseREAD_COMMITTED です。
    Configuration config = new ConfigurationBuilder()/* ... */.locking()
            .isolationLevel(IsolationLevel.REPEATABLE_READ).writeSkewCheck(true);
    
    Copy to Clipboard Toggle word wrap
  7. エントリーのバージョン管理を設定します。

    クラスター化されたキャッシュについては、エントリーのバージョン管理を有効にし、その値を SIMPLE に設定することにより書き込みスキューのチェックを有効にします。
    Configuration config = new ConfigurationBuilder()/* ... */.versioning()
            .enable()
            .scheme(VersioningScheme.SIMPLE);
    
    Copy to Clipboard Toggle word wrap
Expand
表23.1 トランザクションマネージャーのルックアップクラス
クラス名 説明
org.infinispan.transaction.lookup.DummyTransactionManagerLookup テスト環境で主に使用されます。このテスト向けのトランザクションマネージャーは実稼働環境では使用されず、特に並列トランザクションやリカバリーなどの機能は厳しく制限されます。
org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup Red Hat JBoss Data Grid がスタンドアロン環境で実行される場合のデフォルトのトランザクションマネージャーです。これにより、JBoss Transactions ベースの完全に機能するトランザクションマネージャーで、DummyTransactionManager の機能上の制限が解消されます。
org.infinispan.transaction.lookup.GenericTransactionManagerLookup GenericTransactionManagerLookup は、トランザクションルックアップクラスが指定されていない場合にデフォルトで使用されます。このルックアップクラスは、TransactionManager インターフェースを提供する Java EE 互換環境で JBoss Data Grid を使用する場合に推奨され、ほとんどの Java EE アプリケーションサーバーでトランザクションマネージャーを見つけるために使用できます。トランザクションマネージャーが見つからない場合、デフォルトは DummyTransactionManager になります。
org.infinispan.transaction.lookup.JBossTransactionManagerLookup JbossTransactionManagerLookup は、アプリケーションサーバーで実行中の標準的なトランザクションマネージャーを見つけます。このルックアップクラスは JNDI を使用して TransactionManager インスタンスを検索します。これは、カスタムキャッシュが JTA トランザクションで使用されている場合に推奨されます。

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

Red Hat JBoss Data Grid は、リモートクライアントサーバーモードでトランザクションを提供しません。デフォルトで、唯一サポートされている設定は、以下のようなトランザクションではない設定です。
<cache>
	...
 	<transaction mode="NONE" />
	...
</cache>
Copy to Clipboard Toggle word wrap

23.3. トランザクションリカバリー

トランザクションマネージャーはリカバリー処理を調整し、操作の完了に手作業の介入が必要となるトランザクションを判断するため Red Hat JBoss Data Grid と共に動作します。この処理はトランザクションリカバリーと呼ばれます。
JBoss Data Grid は、トランザクションのコミットまたはロールバックを明示的に強制する操作に対して JMX を使用します。これらのメソッドは関連するトランザクションに関連付けられた数の代わりに XID を定義するバイトアレイを受け取ります。
システム管理者はこのような JMX 操作を使用して、手動介入が必要なトランザクションに対して自動的にジョブを完了できます。このプロセスでは、トランザクションマネージャーのトランザクションリカバリープロセスを使用し、トランザクションマネージャーの XID オブジェクトにアクセスできます。

23.3.1. トランザクションリカバリーのプロセス

次のプロセスは、Red Hat JBoss Data Grid のトランザクションリカバリーのプロセスを簡単に説明しています。

手順23.3 トランザクションリカバリーのプロセス

  1. トランザクションマネージャーは介入が必要なトランザクションの一覧を作成します。
  2. 電子メールまたはログを使用して、JMX を使用して JBoss Data Grid に接続するシステム管理者へトランザクション (トランザクション ID を含む) の一覧を提供します。各トランザクションの状態は COMMITTEDPREPARED になります。COMMITTEDPREPARED の両方の状態であるトランザクションがある場合、トランザクションがあるノード上でコミットされている一方、他のノードで準備状態のトランザクションがあることを示しています。
  3. システム管理者は、トランザクションマネージャーより受信した XID を JBoss Data Grid の内部 ID へ視覚的にマッピングします。XID (バイトアレイ) を JMX ツールに渡し、このマッピングがない状態で JBoss Data Grid によって再アセンブルすることはできないため、この手順が必要となります。
  4. マッピングされた内部 ID を基に、システム管理者はトランザクションに対してコミットまたはロールバックプロセスを強制します。

23.3.2. トランザクションリカバリーの例

以下の例は、現金がデータベースに格納された口座から Red Hat JBoss Data Grid に格納された口座に転送される状況でどのようにトランザクションが使用されるかを示しています。

例23.1 データベースに格納された口座から JBoss Data Grid 内の口座への送金

  1. 送信元 (データベース) と送信先 (JBoss Data Grid) リソース間の 2 フェーズコミットプロトコルを実行するために、TransactionManager.commit() メソッドが呼び出されます。
  2. TransactionManager が、準備フェーズ (2 フェーズコミットの最初のフェーズ) を開始するようデータベースと JBoss Data Grid に指示します。
コミットフェーズ中、データベースは変更を適用しますが、JBoss Data Grid はトランザクションマネージャーのコミット要求を受け取る前に失敗します。結果として、不完全なトランザクションのため、システムは不整合な状態になります。特に、送金される金額はデータベースから引かれますが、準備された変更を適用できないため、JBoss Data Grid に表示されません。
ここでは、トランザクションリカバリーは、データベースと JBoss Data Grid エントリー間の不整合を調整するために使用されます。

注記

JMX を使用してトランザクションリカバリーを管理するには、JMX サポートを明示的に有効にする必要があります。

23.4. デッドロックの検出

デッドロックは、複数のプロセスまたはタスクが他のプロセスまたはタスクが相互に必要なリソースを解放するまで待つときに発生します。デッドロックにより、特に複数のトランザクションが 1 つのキーセットに対して動作する場合にシステムのスループットが大幅に短縮されることがあります。
Red Hat JBoss Data Grid は、このようなデッドロックを識別するデッドロック検出を提供します。デッドロック検出は、デフォルトで disabled に設定されます。

23.4.1. デッドロック検出を有効にする

Red Hat JBoss Data Grid のデッドロック検出はデフォルトでは disabled に設定されていますが、以下を追加して namedCache 設定要素を使用すると、デッドロック検出を有効にし、各キャッシュに対して設定を行うことが可能です。
<deadlockDetection enabled="true" spinDuration="100"/>
Copy to Clipboard Toggle word wrap
spinDuration 属性は、特定ロックの取得が許可される時間 (ミリ秒単位) 内にロックの取得を試行する頻度を定義します。
デッドロック検出は個別のキャッシュにのみ適用できます。JBoss Data Grid は複数のキャッシュに適用されたデッドロックを検出できません。

第24章 JGroups の設定

24.1. JGroups について

JGroups は、Red Hat JBoss Data Grid インスタンスに接続するために使用される基礎となるグループ通信ライブラリーです。

24.2.1. インターフェース

Red Hat JBoss Data Grid では、ユーザーは特定の (不明の) IP アドレスではなくインターフェースタイプを指定することができます。
  • link-local: 169.x.x.x または 254.x.x.x アドレスを使用します。これは、1 つのボックス内のトラフィックに適しています。
    <interfaces>
        <interface name="link-local">
            <link-local-address/>
        </interface>
        ...
    </interfaces>
    
    Copy to Clipboard Toggle word wrap
  • site-local: たとえば 192.168.x.x などのプライベート IP アドレスを使用します。これにより、GoGrid や同様のプロバイダーから追加の帯域幅についてチャージされることを避けられます。
    <interfaces>
        <interface name="site-local">
            <site-local-address/>
        </interface>
        ...
    </interfaces>
    
    Copy to Clipboard Toggle word wrap
  • global: パブリック IP アドレスを選択します。これは、レプリケーショントラフィックの場合は避ける必要があります。
    <interfaces>
        <interface name="global">
            <any-address/>
        </interface>
        ...
    </interfaces>
    
    Copy to Clipboard Toggle word wrap
  • non-loopback: 127.x.x.x アドレスではないアクティブなインターフェースにある最初のアドレスを使用します。
    <interfaces>
        <interface name="non-loopback">
            <not>
    	    <loopback />
    	</not>
        </interface>
    </interfaces>
    
    Copy to Clipboard Toggle word wrap

24.2.2. ソケットのバインディグ

ソケットのバインディングにより、インターフェースとポートの名前付きの組み合わせが提供されます。ソケットは、個別にまたはソケットのバインディンググループを使用するかのいずれかにより、インターフェースにバインドできます。
24.2.2.1. 単一のソケットをバインドする例
以下は、JGroups インターフェースのソケットバインディングを使用し、socket-binding 要素を用いて個別のソケットをバインドする例を表しています。
<socket-binding name="jgroups-udp" ... interface="site-local"/>

Copy to Clipboard Toggle word wrap
24.2.2.2. ソケットのグループをバインドする例
以下は、JGroups インターフェースのソケットバインディングを使用し、socket-binding-group 要素を用いてグループをバインドする例を表しています。
<socket-binding-group name="ha-sockets" default-interface="global"> 
	...
	<socket-binding name="jgroups-tcp" port="7600"/>
	<socket-binding name="jgroups-tcp-fd" port="57600"/>
	...
</socket-binding-group>
Copy to Clipboard Toggle word wrap
この例の 2 つのサンプルのソケットバインディングは、同じ default-interface (global) にバインドされます。そのため、インターフェース属性を指定する必要はありません。

24.2.3. JGroups ソケットバインディングの設定

JGroups サブシステムで設定されるそれぞれの JGroups スタックでは、特定のソケットバインディングを使用します。以下のようにソケットバインディングをセットアップします。
<subsystem xmlns="urn:jboss:domain:jgroups:1.2" default-stack="udp">
    <stack name="udp">
        <transport type="UDP" socket-binding="jgroups-udp">
            ...
        </transport>
        <!-- rest of protocols -->
    </stack>
</subsystem>
Copy to Clipboard Toggle word wrap

重要

UDP を JGroups トランスポートとして使用する場合、ソケットバインディングは、通常の (ユニキャスト) ポート、マルチキャストアドレス、およびマルチキャストポートを指定する必要があります。

24.3. JGroups の設定 (ライブラリーモード)

Red Hat JBoss Data Grid がクラスターモードで動作するには、適切な JGroups 設定が必要になります。
プログラムを用いて JGroups を設定するには、次を使用します。
GlobalConfiguration gc = new GlobalConfigurationBuilder()
  .transport()
  .defaultTransport()
  .addProperty("configurationFile","jgroups.xml")
  .build();
Copy to Clipboard Toggle word wrap
XML を使用して JGroups を設定するには、次を使用します。
<infinispan>
  <global>
    <transport>
      <properties>
        <property name="configurationFile" value="jgroups.xml" />
      </properties>
    </transport>
  </global>
 
  ...
 
</infinispan>
Copy to Clipboard Toggle word wrap
プログラムによる設定か、または XML 設定のいずれの場合でも、JBoss Data Grid はクラスパスに見つからない場合は絶対パス名を検索する前にクラスパスの jgroups.xml を検索します。

24.3.1. JGroups トランスポートプロトコル

トランスポートプロトコルは、プロトコルスタックの底辺にあるプロトコルです。トランスポートプロトコルは、ネットワークとのメッセージの送受信を行います。
Red Hat JBoss Data Grid には、UDP と TCP トランスポートプロトコルの両方が同梱されています。
24.3.1.1. UDP トランスポートプロトコル
UDP は、以下を使用するトランスポートプロトコルです。
  • クラスターのすべてのメンバーにメッセージを送信する IP マルチキャスト。
  • 単一メンバーに送信されるユニキャストメッセージの UDP データグラム。
UDP トランスポートが開始すると、トランスポートはユニキャストソケットとマルチキャストソケットを開きます。ユニキャストソケットは、ユニキャストメッセージの送受信に使用され、マルチキャストソケットは、マルチキャストソケットの送受信を行います。チャネルの物理アドレスは、ユニキャストソケットのアドレスおよびポート番号と同じです。
24.3.1.2. TCP トランスポートプロトコル
TCP/IP は、IP マルチキャストが使用できなくなる状況で使用できる UDP の代替トランスポートです。このような状況には、ルーターが IP マルチキャストパケットを破棄する可能性のある WAN 上の操作が実行される場合などが含まれます。
TCP は、ユニキャストおよびマルチキャストメッセージを送信するために使用されるトランスポートプロトコルです。
  • マルチキャストメッセージを送信する場合に、TCP は複数のユニキャストメッセージを送信します。
  • TCP を使用する場合に、すべてのクラスターメンバーに対するそれぞれのメッセージが複数のユニキャストメッセージとして送信されるか、または各メンバーに対して 1 つのメッセージが送信されます。
IP マルチキャストは初期メンバーを検出するために使用することができないため、初期メンバーを見つけるには別のメカニズムを使用する必要があります。
Red Hat JBoss Data Grid の Hot Rod はカスタム TCP クライアント/サーバープロトコルです。
24.3.1.3. TCPPing プロトコルの使用
一部のネットワークでは、TCP のみが使用できます。事前に設定された jgroups-tcp.xml には、検出に UDP マルチキャストを使用する MPING プロトコルが含まれます。UDP マルチキャストが使用できない場合、MPING プロトコルは異なるメカニズムによって置き換えられる必要があります。推奨される代替案は、TCPPING プロトコルの使用です。TCPPING 設定には、ノード検出のために接続される IP アドレスの静的なリストが含まれます。
以下は、TCPPING を使用するように JGroups サブシステムを設定する方法の例です。
<TCP bind_port="7800" />
<TCPPING timeout="3000"
         initial_hosts="${jgroups.tcpping.initial_hosts:HostA[7800],HostB[7801]}"
         port_range="1"
         num_initial_members="3"/>
Copy to Clipboard Toggle word wrap

24.3.2. 事前設定された JGroups ファイル

Red Hat JBoss Data Grid では、事前設定された複数の JGroups ファイルが infinispan-core.jar にパッケージ化され、デフォルトでクラスパス上にて使用可能です。これらのファイルの 1 つを使用するには、jgroups.xml を使用する代わりに使用するファイルの名前を指定します。
JBoss Data Grid に含まれる JGroups 設定ファイルは、プロジェクトの基礎として使用することを目的としています。通常 JGroups では、ネットワークのパフォーマンスを最適化するのに細かな調整が必要となります。
使用可能な設定は次の通りです。
  • jgroups-udp.xml
  • jgroups-tcp.xml
  • jgroups-ec2.xml
24.3.2.1. jgroups-udp.xml
jgroups-udp.xml は Red Hat JBoss Data Grid の事前設定された JGroups ファイルです。jgroups-udp.xml 設定には次のような特徴があります。
  • UDP をトランスポートとして使用し、UDP マルチキャストをディスカバリーに使用します。
  • 大型のクラスター (9 以上のノード) に適しています。
  • インバリデーションまたはレプリケーションモードを使用する場合に適しています。
起動時に特定のシステムプロパティーを JVM に追加すると、一部の設定の挙動を変更することが可能です。変更可能な設定は以下の表の通りです。
Expand
表24.1 jgroups-udp.xml システムプロパティー
システムプロパティー 説明 デフォルト 必要性
jgroups.udp.mcast_addr マルチキャスト (通信とディスカバリーの両方) に使用する IP アドレス。IP マルチキャストに適した有効なクラス D IPアドレスでなければなりません。 228.6.7.8 いいえ
jgroups.udp.mcast_port マルチキャストに使用するポート 46655 いいえ
jgroups.udp.ip_ttl IP マルチキャストパケットの TTL (有効期間) を指定します。この値は、パケットがドロップされる前に許可されるネットワークホップの数になります。 2 いいえ
24.3.2.2. jgroups-tcp.xml
jgroups-tcp.xml は Red Hat JBoss Data Grid の事前設定された JGroups ファイルです。jgroups-tcp.xml 設定には次のような特徴があります。
  • TCP をトランスポートとして使用し、UDP マルチキャストをディスカバリーに使用します。
  • 通常は、マルチキャスト UDP がオプションではない場合にのみ使用されます。
  • 8 つ以上のノードから構成されるクラスターの場合、TCP は UDP ほどパフォーマンスがよくありません。4 つ以下のノードで構成されるクラスターの場合、UDP と TCP のパフォーマンスはほとんど同じレベルになります。
事前設定された他の JGroups ファイルと同様に、起動時に特定のシステムプロパティーを JVM に追加することで一部の設定の挙動を変更することが可能です。変更可能な設定は以下の表の通りです。
Expand
表24.2 jgroups-udp.xml システムプロパティー
システムプロパティー 説明 デフォルト 必要性
jgroups.tcp.address TCP トランスポートに使用する IP アドレス。 127.0.0.1 いいえ
jgroups.tcp.port TCP ソケットに使用するポート 7800 いいえ
jgroups.udp.mcast_addr マルチキャスト (ディスカバリー) に使用する IP アドレス。IP マルチキャストに適した有効なクラス D IP アドレスでなければなりません。 228.6.7.8 いいえ
jgroups.udp.mcast_port マルチキャストに使用するポート 46655 いいえ
jgroups.udp.ip_ttl IP マルチキャストパケットの TTL (有効期間) を指定します。この値は、パケットがドロップされる前に許可されるネットワークホップの数になります。 2 いいえ
24.3.2.3. jgroups-ec2.xml
jgroups-ec2.xml は Red Hat JBoss Data Grid の事前設定された JGroups ファイルです。jgroups-ec2.xml 設定には次のような特徴があります。
  • TCP をトランスポートとして使用し、ディスカバリーに S3_PING を使用します。
  • UDP マルチキャストが使用できない Amazon EC2 ノードに適しています。
他の事前設定された JGroups ファイルと同様に、起動時に特定のシステムプロパティーを JVM に追加すると一部の設定の挙動を変更することが可能です。変更可能な設定は以下の表の通りです。
Expand
表24.3 jgroups-ec2.xml システムプロパティー
システムプロパティー 説明 デフォルト 必要性
jgroups.tcp.address TCP トランスポートに使用する IP アドレス。 127.0.0.1 いいえ
jgroups.tcp.port TCP ソケットに使用するポート 7800 いいえ
jgroups.s3.access_key S3 バケットのアクセスに使用される Amazon S3 アクセスキー はい
jgroups.s3.secret_access_key S3 バケットのアクセスに使用される Amazon S3 の秘密キー。 はい
jgroups.s3.bucket 使用する Amazon S3 バケットの名前。一意の名前で、すでに存在している必要があります。 はい

24.4. JGroups を使用したマルチキャストのテスト

システムがクラスター内でマルチキャストを正しく設定していることを確認する方法について学習します。

24.4.1. 異なる Red Hat JBoss Data Grid バージョンを使用したテスト

以下の表は、このマルチキャストテストと互換性のある Red Hat JBoss Data Grid バージョンの詳細を示しています。
Expand
表24.4 異なる JBoss Data Grid バージョンを使用したテスト
バージョン テストケース 説明
JBoss Data Grid 6.0 使用不可 JBoss Data Grid のこのバージョンには、このテストで使用されるテストクラスが含まれない JBoss Enterprise Application Server 6.0 をベースにしています。
JBoss Data Grid 6.0.1 使用不可 JBoss Data Grid のこのバージョンには、このテストで使用されるテストクラスが含まれない JBoss Enterprise Application Platform 6.0 をベースにしています。
JBoss Data Grid 6.1 利用可能 JBoss Data Grid のこのバージョンは、JBoss Enterprise Application Platform 6.0.1 をベースとしていますが、JBoss Enterprise Application Platform に含まれる JAR ファイルよりも新しいバージョンの JGroups JAR ファイルが含まれます。そのため、このテストに必要なテストクラスは、JBoss Data Grid 6.1 用の $JBOSS_HOME/modules/org/jgroups/main ディレクトリーで入手できます。
JBoss Data Grid 6.2 利用可能 JBoss Data Grid のこのバージョンは、JBoss Enterprise Application Platform 6.1 をベースにしています。JAR ファイルの名前はバージョンに基づいて指定されます。たとえば、jgroups-3.2.7.Final-redhat-1.jar という名前になり、$JBOSS_HOME/modules/system/layers/base/org/jgroups/main ディレクトリーで入手できます。

24.4.2. JGroups を使用したマルチキャストのテスト

以下の手順は、Red Hat JBoss Data Grid 6.2 を使用している場合に JGroups を使用したマルチキャストのテストを実行するための手順を詳細に示しています。
前提条件

テストの手順を開始する前に以下の要件を満たしていることを確認してください。

  1. bind_addr 値をインスタンスの適切な IP アドレスに設定します。
  2. 精度を高めるために、クラスター通信の値と同じ mcast_addrport の値を設定します。
  3. 2 つのコマンドラインターミナルウィンドウを起動します。最初のターミナルで 2 つのノードの内の 1 つの JGroups JAR ファイルのロケーションと、2 番目のターミナルで 2 つ目のノードの同じロケーションにナビゲートします。

手順24.1 JGroups を使用したマルチキャストのテスト

  1. 1 つ目のノードでのマルチキャストサーバーの実行

    最初のノードについて、コマンドラインターミナルで以下のコマンドを実行します。
    java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.1.2.3 -port 5555 -bind_addr $YOUR_BIND_ADDRESS
    Copy to Clipboard Toggle word wrap
  2. 2 つ目のノードでのマルチキャストサーバーの実行

    2 つ目のノードについて、コマンドラインターミナルで以下のコマンドを実行します。
    java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr  230.1.2.3 -port 5555 -bind_addr $YOUR_BIND_ADDRESS
    Copy to Clipboard Toggle word wrap
  3. 情報パケットを送信します。

    2 つ目のノード (パケットを送信するノード) のインスタンスに情報を入力し、Enter を押して情報を送信します。
  4. 受信情報パケットを表示します。

    1 番目のノードのインスタンスで受信された情報を表示します。直前の手順で入力した情報がここに表示されます。
  5. 情報転送を確認します。

    パケットがドロップされずに、送信情報がすべて受信されていることを確認するために、手順 3 と 4 を繰り返します。
  6. 他のインスタンスのテストを繰り返します。

    送信者と受信者のそれぞれを確認するために、手順 1 から 4 を繰り返します。テストを繰り返すことにより、誤って設定された他のインスタンスが特定されます。
結果

送信者ノードから送信されるすべての情報パケットは、受信者ノードに表示される必要があります。送信された情報が予想どおりに表示されない場合、マルチキャストがオペレーティングシステムまたはネットワークで誤って設定されていることになります。

第25章 Red Hat Data Grid の Amazon Web サービスとの使用

25.1. S3_PING JGroups 検出プロトコル

Amazon の Elastic Compute Cloud (EC2) ではマルチキャストをサポートされず、MPING が許可されないため、S3_PING は EC2 と一緒に使用するのに最適な検出プロトコルです。
それぞれの EC2 インスタンスは小さいファイルをバケットとして知られる S3 データコンテナーに追加します。その後、各インスタンスはバケット内のファイルを読み込み、クラスターの他のメンバーを検出します。

25.2. S3_PING 設定オプション

Red Hat JBoss Data Grid は Amazon Web Services と 2 通りの方法で連動します。
  • ライブラリーモードでは、JGroups の jgroups-ec2.xml ファイル (さらに詳しくは 「jgroups-ec2.xml」 を参照してください) または S3_PING プロトコルを使用します。
  • リモートクライアントサーバーモードでは、JGroups の S3_PING プロトコルを使用します。
ライブラリーおよびリモートクライアントサーバーモードでは、Amazon AWS で機能するようにクラスター化するために S3_PING プロトコルを設定する方法として 3 つの方法があります。
  • プライベート S3 バケットを使用します。これらのバケットは Amazon AWS の認証情報を使用します。
  • 事前署名付き URL を使用します。これらの事前に割り当てられる URL は、プライベートの書き込みアクセスとパブリックの読み取りアクセスを持つバケットに割り当てられます。
  • パブリック S3 バケットを使用します。これらのバケットには認証情報がありません。

25.2.1. プライベート S3 バケットの使用

この設定には、適切な AWS 認定情報によってのみアクセスできるプライベートバケットへのアクセスが必要です。適切な権限が利用できることを確認するには、ユーザーにバケットの以下の権限があることを確認してください。
  • List
  • Upload/Delete
  • View Permissions
  • Edit Permissions
S3_PING 設定には以下のプロパティーが含まれることを確認してください。
  • バケットを指定するための location または prefix プロパティーのいずれか(これら両方ではない)。prefix プロパティーが設定される場合、S3_PING はプレフィックス値で始まる名前を持つバケットを検索します。名前の先頭にプレフィックスのあるバケットが見つかる場合、S3_PING はそのバケットを使用します。プレフィックスのあるバケットが見つからない場合、S3_PING は AWS 認証情報を使用してバケットを作成し、その名前をプレフィックスと UUID に基づいて設定します (名前の形式は {prefix value}-{UUID})。
  • AWS ユーザーには access_keysecret_access_key プロパティー。

注記

この設定の使用時に 403 エラーが表示される場合、プロパティーに正しい値があることを検証してください。問題が存続する場合、EC2 ノードのシステム時間が正しいことを確認してください。Amazon S3 は、セキュリティー上の理由により、サーバーの時間よりも 15 分を超える遅れがあるタイムスタンプを持つ要求を拒否します。

例25.1 プライベートバケットの使用による Red Hat JBoss Data Grid サーバーの起動

サーバーディレクトリーの上位レベルから次のコマンドを実行して、プライベート S3 バケットを使用して Red Hat JBoss Data Grid サーバーを起動します。
bin/clustered.sh -Djboss.bind.address={server_ip_address} -Djboss.bind.address.management={server_ip_address} -Djboss.default.jgroups.stack=s3 -Djgroups.s3.bucket={s3_bucket_name} -Djgroups.s3.access_key={access_key} -Djgroups.s3.secret_access_key={secret_access_key}
Copy to Clipboard Toggle word wrap
  1. {server_ip_address} をサーバーの IP アドレスに置き換えます。
  2. {s3_bucket_name} を適切なバケット名に置き換えます。
  3. {access_key} をユーザーのアクセスキーに置き換えます。
  4. {secret_access_key} をユーザーの秘密アクセスキーに置き換えます。

25.2.2. 事前署名付き URL の使用

この設定では、List 権限を Everyone に設定し、パブリックの読み取りアクセスを許可することにより、S3 の一般に読み取り可能なバケットを作成します。クラスター内の各ノードは、S3_PING プロトコルで要求される場合に、put および delete 操作用に事前署名付き URL を生成します。この URL は固有のファイルを参照し、バケット内のフォルダーパスを組み込むことができます。

注記

パスが長くなると、S3_PING にエラーが発生します。たとえば、my_bucket/DemoCluster/node1 のようなパスは機能しますが、my_bucket/Demo/Cluster/node1 のようにパスが長くなると機能しません。
25.2.2.1. 事前署名付き URL の生成
JGroup の S3_PING クラスには、事前署名付き URL を生成するためのユーティリティーメソッドが含まれます。このメソッドの最後の引数は、Unix epoch (1970 年 1 月 1 日) からの秒数で表される URL の有効期間です。
事前署名付き URL を生成する構文は次のようになります。
String Url = S3_PING.generatePreSignedUrl("{access_key}", "{secret_access_key}", "{operation}", "{bucket_name}", "{path}", {seconds});
Copy to Clipboard Toggle word wrap
  1. {operation}PUT または DELETE のいずれかに置き換えます。
  2. {access_key} をユーザーのアクセスキーに置き換えます。
  3. {secret_access_key} をユーザーの秘密アクセスキーに置き換えます。
  4. {bucket_name} をバケットの名前に置き換えます。
  5. {path} をバケット内のファイルへの必要なパスに置き換えます。
  6. {seconds} を、Unix epoch (1970 年 1 月 1 日) からのパスの有効期間を表す秒数に置き換えます。

例25.2 事前署名付き URL の生成

String putUrl = S3_PING.generatePreSignedUrl("access_key", "secret_access_key", "put", "my_bucket", "DemoCluster/node1", 1234567890);
Copy to Clipboard Toggle word wrap
S3_PING 設定に、S3_PING.generatePreSignedUrl() の呼び出しで生成された pre_signed_put_url および pre_signed_delete_url プロパティーが含まれていることを確認してください。この設定の場合、AWS 認証情報がクラスター内の各ノードに保存されないため、プライベート S3 バケットを使用する設定よりも安全度が高くなります。

注記

事前署名付き URL が XML ファイルに入力される場合、URL 内の & 文字をその XML エンティティー (&amp;) に置き換える必要があります。
25.2.2.2. コマンドラインを使用した事前署名付き URL の設定
コマンドラインを使用して事前署名付き URL を設定するには、以下のガイドラインを使用します。
  • URL を二重引用符 ("") で囲みます。
  • URL では、アンパーサンド (&) 文字の各出現箇所はバックスラッシュ (\) でエスケープする必要があります。

例25.3 事前署名付き URL による JBoss Data Grid サーバーの起動

bin/clustered.sh -Djboss.bind.address={server_ip_address} -Djboss.bind.address.management={server_ip_address} -Djboss.default.jgroups.stack=s3 -Djgroups.s3.pre_signed_put_url="http://{s3_bucket_name}.s3.amazonaws.com/ node1?AWSAccessKeyId={access_key}\&Expires={expiration_time}\&Signature={signature}"-Djgroups.s3.pre_signed_delete_url="http://{s3_bucket_name}.s3.amazonaws.com/ node1?AWSAccessKeyId={access_key}\&Expires={expiration_time}\&Signature={signature}"
Copy to Clipboard Toggle word wrap
上記の例では、{signatures} 値は S3_PING.generatePreSignedUrl() メソッドによって生成されます。さらに、{expiration_time} 値は、S3_PING.generatePreSignedUrl() メソッドに渡される URL の有効期間です。

25.2.3. パブリック S3 バケットの使用

この設定には、パブリックの読み書き権限のある S3 バケットが関係します。つまり、Everyone には、バケットの ListUpload/Delete の権限、View Permissions、および Edit Permissions が設定されます。
location プロパティーは、この設定のバケット名で指定する必要があります。この設定メソッドは、バケットの名前を知っているいずれのユーザーもバケットにデータをアップロードしたり、保存したりでき、バケット作成者のアカウントはこのデータについてチャージされるため、安全度は最も低くなります。
Red Hat JBoss Data Grid サーバーを起動するには、以下のコマンドを使用します。
bin/clustered.sh -Djboss.bind.address={server_ip_address} -Djboss.bind.address.management={server_ip_address} -Djboss.default.jgroups.stack=s3 -Djgroups.s3.bucket={s3_bucket_name}
Copy to Clipboard Toggle word wrap

25.2.4. S3_PING 警告のトラブルシューティング

使用される S3_PING 設定タイプにより、以下の警告が JBoss Data Grid サーバーの起動時に表示される場合があります。
15:46:03,468 WARN  [org.jgroups.conf.ProtocolConfiguration] (MSC service thread 1-7) variable "${jgroups.s3.pre_signed_put_url}" in S3_PING could not be substituted; pre_signed_put_url is removed from properties
Copy to Clipboard Toggle word wrap
15:46:03,469 WARN  [org.jgroups.conf.ProtocolConfiguration] (MSC service thread 1-7) variable "${jgroups.s3.prefix}" in S3_PING could not be substituted; prefix is removed from properties
Copy to Clipboard Toggle word wrap
15:46:03,469 WARN  [org.jgroups.conf.ProtocolConfiguration] (MSC service thread 1-7) variable "${jgroups.s3.pre_signed_delete_url}" in S3_PING could not be substituted; pre_signed_delete_url is removed from properties
Copy to Clipboard Toggle word wrap
それぞれの場合に、警告により不足しているものとしてリストされるプロパティーが S3_PING 設定では不要であることを確認してください。

第26章 サーバーヒンティングを用いた高可用性

Red Hat JBoss Data Grid では、サーバーヒンティングによってデータのバックアップコピーが元データと同じ物理サーバー、ラック、またはデータセンター上に保存されないようにします。トータルレプリケーションはすべてのサーバー、ラックおよびデータセンター上で完全なレプリカの作成を強制するため、サーバーヒンティングはトータルレプリケーションには適用されません。
複数のノードにまたがるデータ分散が一貫したハッシュメカニズムによって制御されます。JBoss Data Grid は、一貫したハッシュアルゴリズムを指定するためのプラグ可能なポリシーを提供します。さらに詳しくは、「ConsistentHashFactories」を参照してください。
machineIdrackId、または siteId を transport 設定に設定することにより、TopologyAwareConsistentHashFactory の使用がトリガーされます。これは、サーバーヒンティングが有効にされた状態の DefaultConsistentHashFactory に相当します。
サーバーヒンティングは、JBoss Data Grid 実装の高可用性を確実に実現する場合に特に重要になります。

26.1. JGroups によるサーバーヒンティングの設定

Red Hat JBoss Data Grid でクラスター化環境を設定する場合、JGroups の設定時にサーバーヒンティングが設定されます。
JBoss Data Grid には、クラスターモード向けに事前設定され、サーバーヒンティングを使用する複数の JGroups ファイルが含まれています。JBoss Data Grid にクラスターモードを設定する際に、始めにこれらのファイルを使用することができます。

26.2. サーバーヒンティングの設定 (リモートクライアントサーバーモード)

Red Hat JBoss Data Grid のリモートクライアントサーバーモードでは、サーバーヒンティングは、次のようにデフォルトスタックについて transport 要素の JGroup サブシステムで設定されます。

手順26.1 リモートクライアントサーバーモードでのサーバーヒンティングの設定

  1. JGroups サブシステム設定を検索します。

    <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
    	   default-stack="${jboss.default.jgroups.stack:udp}">
    	<stack name="udp">
    
    Copy to Clipboard Toggle word wrap
  2. transport 要素でサーバーヒンティングを有効にします。

    1. サイト ID を設定します。

      <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
      	   default-stack="${jboss.default.jgroups.stack:udp}">
      	<stack name="udp">
      	<transport type="UDP" 
      		   socket-binding="jgroups-udp" 
      		   site="${jboss.jgroups.transport.site:s1}">
      
      Copy to Clipboard Toggle word wrap
    2. ラック ID を設定します。

      <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
      	   default-stack="${jboss.default.jgroups.stack:udp}">
      	<stack name="udp">
      		<transport type="UDP" 
      			   socket-binding="jgroups-udp" 
      			   site="${jboss.jgroups.transport.site:s1}" 
      			   rack="${jboss.jgroups.transport.rack:r1}">
      
      Copy to Clipboard Toggle word wrap
    3. マシン ID を設定します。

      <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
      	   default-stack="${jboss.default.jgroups.stack:udp}">
      	<stack name="udp">
      		<transport type="UDP" 
      			   socket-binding="jgroups-udp" 
      			   site="${jboss.jgroups.transport.site:s1}" 
      			   rack="${jboss.jgroups.transport.rack:r1}" 
      			   machine="${jboss.jgroups.transport.machine:m1}">
      			   ...                    
      		</transport>
      	</stack>
      </subsystem>
      
      Copy to Clipboard Toggle word wrap

26.3. サーバーヒンティングの設定 (ライブラリーモード)

Red Hat JBoss Data Grid のライブラリーモードでは、トランスポートレベルでサーバーヒンティングが設定されます。以下はサーバーヒンティングの設定例になります。

手順26.2 ライブラリーモードでのサーバーヒンティングの設定

次の設定属性を使用して、JBoss Data Grid にサーバーヒンティングを設定します。
  1. clusterName 属性を設定します。

    clusterName 属性はクラスターに割り当てられた名前を指定します。
    <transport clusterName = "MyCluster" />
    
    Copy to Clipboard Toggle word wrap
  2. machineId を追加します。

    machineId 属性は、元データを格納する JVM インスタンスを指定します。これは、複数の JVM があるノードや複数の仮想ホストを持つ物理ホストに対して特に有用な属性です。
    <transport clusterName = "MyCluster"
               machineId = "LinuxServer01" />
    
    Copy to Clipboard Toggle word wrap
  3. rackId を追加します。

    rackId パラメーターは、元データが含まれるラックを指定します。これにより、別のラックがバックアップに使用されるようにします。
    <transport clusterName = "MyCluster"
               machineId = "LinuxServer01"
               rackId = "Rack01" />
    
    Copy to Clipboard Toggle word wrap
  4. siteId を追加します。

    siteId パラメーターは、相互にレプリケーションを行っている異なるデータセンターのノードを区別します。
    <transport clusterName = "MyCluster"
               machineId = "LinuxServer01"
               rackId = "Rack01"
               siteId = "US-WestCoast" />
    
    Copy to Clipboard Toggle word wrap
リストされているパラメーターは、JBoss Data Grid 設定ではオプションです。
machineIdrackId、または siteId が設定に含まれている場合、TopologyAwareConsistentHashFactory が自動的に選択され、サーバーヒンティングを有効にします。ただし、サーバーヒンティングが設定されていない場合、JBoss Data Grid の分散アルゴリズムにより元データと同じ物理マシン/ラック/データセンターにレプリケーションを保存することができます。

26.4. ConsistentHashFactories

Red Hat JBoss Data Grid は、一貫したハッシュアルゴリズムを選択するためのプラグ可能なメカニズムを提供します。これは 4 つの実装に同梱されていますが、カスタム実装を使用することもできます。
JBoss Data Grid には次の 4 つの ConsistentHashFactory 実装が同梱されています。
  • DefaultConsistentHashFactory - あらゆるノード全体でセグメントの均等な分散を図りますが、キーマッピングは、各キャッシュの履歴に依存するので、複数のキャッシュ間で同じであることは保証されません。
  • SyncConsistentHashFactory - 現在のメンバーシップが同じである場合、キーマッピングが各キャッシュについて同一であることを保証します。ただし、この欠点として、キャッシュに参加するノードが既存ノードによるセグメントの交換を生じさせる可能性があり、その結果、追加の状態転送のトラフィックが発生するか、またはデータ分散が少なくなるかのいずれか、またはそれらの両方が生じる場合があります。
  • TopologyAwareConsistentHashFactory - DefaultConsistentHashFactory と同等であるが、サーバーヒンティングが有効にされます。
  • TopologyAwareSyncConsistentHashFactory - SyncConsistentHashFactory と同等であるが、サーバーヒンティングが有効にされます。
一貫したハッシュ実装をハッシュ設定で選択できます。
<hash consistentHashFactory="org.infinispan.distribution.ch.TopologyAwareSyncConsistentHashFactory"/>

Copy to Clipboard Toggle word wrap
この設定は、同じメンバーを持つキャッシュに同一の一貫したハッシュがあることを保証し、さらに machineIdrackId、または siteId 属性がトランスポート設定で指定される場合、バックアップコピーを複数の物理マシン/ラック/データセンターにまたがって分散させます。
想定される欠点として、この設定により、バランスの再調整時に必要とする以上の数のセグメントが移動する可能性があります。ただし、この影響は、多数のセグメントを使用することによって軽減できます。
もう 1 つの想定される欠点として、セグメントが均等に分散されないことや、さらには多数のセグメントを実際に使用することによりセグメントの分散状況が悪化することなどがあります。

26.4.1. ConsistentHashFactory の実装

カスタム ConsistentHashFactory は、以下のメソッド (これらすべては org.infinispan.distribution.ch.ConsistentHash の実装を返します) を使って、org.infinispan.distribution.ch.ConsistenHashFactory インターフェースを実装する必要があります。
create(Hash hashFunction, int numOwners, int numSegments, List<Address>
members,Map<Address, Float> capacityFactors)
updateMembers(ConsistentHash baseCH, List<Address> newMembers, Map<Address,
Float> capacityFactors)
rebalance(ConsistentHash baseCH)
union(ConsistentHash ch1, ConsistentHash ch2)
Copy to Clipboard Toggle word wrap
現在のところ、カスタムパラメーターを ConsistentHashFactory 実装に渡すことはできません。

第27章 データセンター間のレプリケーションのセットアップ

27.1. データセンター間レプリケーションについて

Red Hat JBoss Data Grid では、データセンター間レプリケーションにより、管理者は複数のクラスターでデータバックアップを作成することができます。3 つのクラスターを同じ物理ロケーションまたは異なるロケーションに置くことができます。JBoss Data Grid のサイト間レプリケーションの実装は JGroups の RELAY2 プロトコルをベースとします。
データセンター間レプリケーションにより、複数のクラスター間のデータ冗長性が保証されます。理想的には、これらのクラスターをそれぞれ他のロケーションとは異なる物理サイトに置くべきです。

27.2. データセンター間レプリケーションの操作

Red Hat JBoss Data Grid のデータセンター間レプリケーションの操作は、以下のような例を使用して説明できます。
データセンター間レプリケーションの例

図27.1 データセンター間レプリケーションの例

この例では、LONNYC および SFO の 3 つのサイトが設定されます。それぞれのサイトは、3 つから 4 つの物理ノードから構成される実行中の JBoss Data Grid クラスターをホストします。
Users キャッシュは、3 つのすべてのサイトでアクティブです。LON サイトでの Users キャッシュへの変更は、他の 2 つのサイトでレプリケートされます。ただし、Orders キャッシュは、他のサイトにレプリケートされないので LON サイトのローカルでのみ利用可能です。
Users キャッシュは各サイトで異なるレプリケーションメカニズムを使用できます。たとえば、データのバックアップを SFO に同期的に、NYCLON に非同期的に行います。
さらに Users キャッシュにはあるサイトから別のサイトへとそれぞれ異なる設定を持たせることもできます。たとえば、これを LON サイトで numOwners2 に設定した分散キャッシュとして、NYC サイトではレプリケートされたキャッシュとして、さらに SFO サイトでは numOwners1 に設定した分散キャッシュとして設定することができます。
JGroups はサイト間通信と共に各サイト内の通信のために使用されます。とくに、RELAY2 という JGroups プロトコルは、サイト間の通信を容易にします。さらに詳しくは、「RELAY2 について」を参照してください。

27.3. データセンター間レプリケーションの設定

27.3.1. データセンター間レプリケーションの設定 (リモートクライアントサーバーモード)

Red Hat JBoss Data Grid のリモートクライアントサーバーモードでは、データセンター間のレプリケーションは次のようにセットアップされます。

手順27.1 データセンター間のレプリケーションのセットアップ

  1. RELAY のセットアップ

    RELAY をセットアップするには、以下の設定を standalone.xml ファイルに追加します。
    <subsystem xmlns="urn:jboss:domain:jgroups:1.2" 
    	   default-stack="udp">
    	<stack name="udp">
    		<transport type="UDP" 
    			   socket-binding="jgroups-udp"/>
    		...
    		
    		<relay site="LON">
    		   <remote-site name="NYC" stack="tcp" cluster="global"/>
    		   <remote-site name="SFO" stack="tcp" cluster="global"/>
    		   <property name="relay_multicasts">false</property>
    		</relay>
    	</stack>
    </subsystem>
    
    Copy to Clipboard Toggle word wrap
    RELAY プロトコルは、リモートサイトと通信するために追加のスタック (既存の TCP スタックと並行して実行される) を作成します。TCP ベースのスタックがローカルクラスターに使用される場合、2 つの TCP ベースのスタック設定が必要になります。1 つはローカル通信用で、もう 1 つはリモートサイトへの接続用になります。さらに詳しい説明は、「データセンター間レプリケーションの操作」を参照してください。
  2. サイトのセットアップ

    クラスター内のそれぞれの分散キャッシュに対してサイトをセットアップするには、standalone.xml ファイルで以下の設定を使用します。
    <distributed-cache>
         ...
         <backups>
            <backup site="{FIRSTSITENAME}" strategy="{SYNC/ASYNC}" />
            <backup site="{SECONDSITENAME}" strategy="{SYNC/ASYNC}" />
         </backups>
    </distributed-cache>
    
    Copy to Clipboard Toggle word wrap
  3. ローカルサイトトランスポートの設定

    トランスポートを設定するには、transport 要素にローカルサイトの名前を追加します。
    <transport executor="infinispan-transport" 
               lock-timeout="60000" 
               cluster="LON" 
               stack="udp"/>
    
    Copy to Clipboard Toggle word wrap

27.3.2. データセンター間レプリケーション (ライブラリーモード) の設定

27.3.2.1. データセンター間レプリケーションを宣言的に設定する
データセンター間のレプリケーションを設定する際、relay.RELAY2 プロトコルは、リモートサイトと通信するために追加のスタック (既存の TCP スタックと並行して実行される) を作成します。TCP ベースのスタックがローカルクラスターに使用される場合、2 つの TCP ベースのスタック設定が必要になります。1 つはローカル通信用で、もう 1 つはリモートサイトへの接続用です。
JBoss Data Grid のライブラリーモードでは、データセンター間のレプリケーションは次のようにセットアップされます。

手順27.2 データセンター間のレプリケーションのセットアップ

  1. ローカルサイトを設定します。

    site 要素を global 要素に追加してローカルサイト (この例では、ローカルサイトの名前は LON です) を追加します。
    <infinispan>
       <global>
          ...
          <site local="LON" />
          ...   
       </global>
    </infinispan>
    
    Copy to Clipboard Toggle word wrap
  2. ローカルサイト用に JGroups を設定します。

    サイト間のレプリケーションには、デフォルト以外の JGroups 設定が必要です。transport 要素を追加し、設定ファイルへのパスを configurationFile プロパティーとしてセットアップします。この例では、JGroups 設定ファイルの名前は jgroups-with-relay.xml です。
    <infinispan>
       <global>
          ...
          <site local="LON" />
          <transport clusterName="default"> 
             <properties> 
                 <property name="configurationFile" value="jgroups-with-relay.xml" />     
              </properties> 
          </transport> 
          ...   
       </global>
    </infinispan>
    
    Copy to Clipboard Toggle word wrap
  3. LON キャッシュを設定します。

    NYC および SFO サイトにバックアップするには、LON サイトでキャッシュを設定します。
    <infinispan>
       <global>      
          <site local="LON" />
          ...   
       </global>
       ...
       <namedCache name="lon">
          <sites>
             <backups>
                <backup site="NYC" 
    		    strategy="SYNC" 
    		    backupFailurePolicy="WARN" />
                <backup site="SFO" 
    		    strategy="ASYNC" 
    		    backupFailurePolicy="IGNORE"/>
             </backups>
          </sites>
       </namedCache>
    </infinispan>
    
    Copy to Clipboard Toggle word wrap
  4. バックアップキャッシュを設定します。

    1. LON からバックアップデータを受信するには、NYC サイトでキャッシュを設定します。
      <infinispan>
         <global>      
            <site local="NYC" />
            ...   
         </global>
         ...
         <namedCache name="lonBackup">
            <sites>
               <backupFor remoteSite="LON" 
      		    remoteCache="lon" />
            </sites>
         </namedCache>
      </infinispan>
      
      Copy to Clipboard Toggle word wrap
    2. LON からバックアップデータを受信するには、SFO サイトでキャッシュを設定します。
      <infinispan>
         <global>      
            <site local="SFO" />
            ...   
         </global>
         ...
         <namedCache name="lonBackup">
            <sites>
               <backupFor remoteSite="LON" 
      		    remoteCache="lon" />
            </sites>
         </namedCache>
      </infinispan>
      
      Copy to Clipboard Toggle word wrap
  5. 設定ファイルの内容を追加します。

    デフォルトでは、Red Hat JBoss Data Grid には infinispan-core-{VERSION}.jar パッケージ内の jgroups-tcp.xml および jgroups-udp.xml などの JGroups 設定ファイルが含まれます。
    JGroups 設定を新規ファイル (この例では、ファイル名は jgroups-with-relay.xml) にコピーし、指定される設定情報をこのファイルに追加します。relay.RELAY2 プロトコル設定は、設定スタックの最新のプロトコルである必要があります。
    <config> 
        ... 
        <relay.RELAY2 site="LON" 
                  config="relay.xml"
                  relay_multicasts="false" />
    </config>
    
    Copy to Clipboard Toggle word wrap
  6. relay.xml ファイルを設定します。

    relay.xml ファイルで relay.RELAY2 設定をセットアップします。このファイルは、グローバルクラスター設定について説明するものです。
    <RelayConfiguration> 
        <sites> 
            <site name="LON" 
                  id="0"> 
                <bridges> 
                    <bridge config="jgroups-global.xml" 
                            name="global"/> 
                    </bridges> 
            </site>  
            <site name="NYC" 
                  id="1"> 
                <bridges> 
                    <bridge config="jgroups-global.xml" 
                            name="global"/> 
                    </bridges> 
            </site>  
            <site name="SFO" 
                  id="2"> 
                <bridges> 
                    <bridge config="jgroups-global.xml" 
                            name="global"/> 
                </bridges> 
            </site> 
        </sites> 
    </RelayConfiguration>
    
    Copy to Clipboard Toggle word wrap
  7. グローバルクラスターを設定します。

    relay.xml で参照されるファイル jgroups-global.xml には、グローバルクラスター、つまりサイト間の通信で使用される別の JGroups 設定が含まれます。
    グローバルクラスター設定は、通常は TCP ベースであり、TCPPING プロトコル (PING または MPING ではない) を使用してメンバーを検出します。jgroups-tcp.xml の内容を jgroups-global.xml にコピーし、TCPPING を設定するために次の設定を追加します。
    <config> 
        <TCP bind_port="7800" ... /> 
        <TCPPING initial_hosts="lon.hostname[7800],nyc.hostname[7800],sfo.hostname[7800]"     
                 num_initial_members="3" 
                 ergonomics="false" /> 
              <!-- Rest of the protocols --> 
    </config>
    
    Copy to Clipboard Toggle word wrap
    TCPPING.initial_hosts のホスト名 (または IP アドレス) をサイトマスターに使用されるものに置き換えます。ポート (この場合は 7800) は TCP.bind_port に一致している必要があります。
    TCPPING プロトコルについてさらに詳しくは、「TCPPing プロトコルの使用」を参照してください。
27.3.2.2. データセンター間レプリケーションをプログラムを用いて設定する
Red Hat JBoss Data Grid におけるデータセンター間のレプリケーションを設定するプログラムを用いたメソッドは以下になります。

手順27.3 データセンター間レプリケーションをプログラムを用いて設定する

  1. ノードの場所を特定します。

    ノードが所属するサイトを宣言します。
    globalConfiguration.site().localSite("LON");
    
    Copy to Clipboard Toggle word wrap
  2. JGroups を設定します。

    RELAY プロトコルを使用するように JGroups を設定します。
    globalConfiguration.transport().addProperty("configurationFile", jgroups-with-relay.xml);
    
    Copy to Clipboard Toggle word wrap
  3. リモートサイトをセットアップします。

    リモートサイトにレプリケートするために JBoss Data Grid キャッシュをセットアップします。
    ConfigurationBuilder lon = new ConfigurationBuilder();
    lon.sites().addBackup()
          .site("NYC")
          .backupFailurePolicy(BackupFailurePolicy.WARN)
          .strategy(BackupConfiguration.BackupStrategy.SYNC)
          .replicationTimeout(12000)
          .sites().addInUseBackupSite("NYC")
        .sites().addBackup()
          .site("SFO")
          .backupFailurePolicy(BackupFailurePolicy.IGNORE)
          .strategy(BackupConfiguration.BackupStrategy.ASYNC)
          .sites().addInUseBackupSite("SFO")
    
    Copy to Clipboard Toggle word wrap
  4. オプション: バックアップクラッシュを設定します。

    JBoss Data Grid は、リモートサイトと同じ名前を使って、データをキャッシュに暗黙的にレプリケートします。リモートサイトのバックアップキャッシュが異なる名前を持つ場合、ユーザーは、データが正しいキャッシュにレプリケートされていることを確認するために backupFor キャッシュを指定する必要があります。

    注記

    この手順は任意であり、リモートサイトのキャッシュの名前が元のキャッシュとは異なるものに設定される場合にのみ必要になります。
    1. LON からのバックアップデータを受信できるようにサイト NYC のキャッシュを設定します。
      ConfigurationBuilder NYCbackupOfLon = new ConfigurationBuilder();
      lonBackup.sites().backupFor().remoteCache("lon").remoteSite("LON");
      
      Copy to Clipboard Toggle word wrap
    2. LON からバックアップデータを受信できるようにサイト SFO のキャッシュを設定します。
      ConfigurationBuilder SFObackupOfLon = new ConfigurationBuilder();
      lonBackup.sites().backupFor().remoteCache("lon").remoteSite("LON");
      
      Copy to Clipboard Toggle word wrap
  5. 設定ファイルの内容を追加します。

    デフォルトでは、Red Hat JBoss Data Grid には、infinispan-core-{VERSION}.jar パッケージ内の jgroups-tcp.xml および jgroups-udp.xml などの JGroups 設定ファイルが含まれます。
    JGroups 設定を新規ファイル (この例では、ファイル名は jgroups-with-relay.xml) にコピーし、指定される設定情報をこのファイルに追加します。relay.RELAY2 プロトコル設定は、設定スタックの最新のプロトコルである必要があります。
    <config> 
        ... 
        <relay.RELAY2 site="LON" 
                  config="relay.xml"
                  relay_multicasts="false" /> 
    </config>
    
    Copy to Clipboard Toggle word wrap
  6. relay.xml ファイルを設定します。

    relay.xml ファイルで relay.RELAY2 設定をセットアップします。このファイルは、グローバルクラスター設定について説明するものです。
    <RelayConfiguration> 
        <sites> 
            <site name="LON" 
                  id="0"> 
                <bridges> 
                    <bridge config="jgroups-global.xml" 
                            name="global"/> 
                    </bridges> 
            </site>  
            <site name="NYC" 
                  id="1"> 
                <bridges> 
                    <bridge config="jgroups-global.xml" 
                            name="global"/> 
                    </bridges> 
            </site>  
            <site name="SFO" 
                  id="2"> 
                <bridges> 
                    <bridge config="jgroups-global.xml" 
                            name="global"/> 
                </bridges> 
            </site> 
        </sites> 
    </RelayConfiguration>
    
    Copy to Clipboard Toggle word wrap
  7. グローバルクラスターを設定します。

    relay.xml で参照されるファイル jgroups-global.xml には、グローバルクラスター、つまりサイト間の通信で使用される別の JGroups 設定が含まれます。
    グローバルクラスター設定は、通常は TCP ベースであり、TCPPING プロトコル (PING または MPING ではない) を使用してメンバーを検出します。jgroups-tcp.xml の内容を jgroups-global.xml にコピーし、TCPPING を設定するために以下の設定を追加します。
    <config> 
        <TCP bind_port="7800" ... /> 
        <TCPPING initial_hosts="lon.hostname[7800],nyc.hostname[7800],sfo.hostname[7800]"     
                 num_initial_members="3" 
                 ergonomics="false" /> 
              <!-- Rest of the protocols --> 
    </config>
    
    Copy to Clipboard Toggle word wrap
    TCPPING.initial_hosts のホスト名 (または IP アドレス) をサイトマスターに使用されるものに置き換えます。ポート (この場合は 7800) は TCP.bind_port に一致している必要があります。
    TCPPING プロトコルについてさらに詳しくは、「TCPPing プロトコルの使用」を参照してください。

27.4. サイトをオフラインにする

Red Hat JBoss Data Grid のデータセンター間レプリケーション設定では、一定の期間内にあるサイトへのバックアップが複数回失敗すると、そのサイトをオフラインとして自動的にマークできます。この機能により、サイトをオフラインとマークする管理者の手動の介入は不要になります。
指定される条件を満たす場合にサイトを自動的に停止させたり、管理者がサイトを手動で停止させたりできるように JBoss Data Grid を設定することができます。
  • サイトの自動的なオフライン設定:
    • リモートクライアントサーバーモードで宣言的に実行。
    • ライブラリーモードで宣言的に実行。
    • プログラムを用いたメソッドの使用。
  • サイトの手動によるオフライン設定:
    • JBoss Operations Network (JON) の使用。
    • JBoss Data Grid コマンドラインインターフェース (CLI) の使用。

27.4.1. サイトをオフラインに設定する (リモートクライアントサーバーモード)

Red Hat JBoss Data Grid のリモートクライアントサーバーモードでは、サイトが自動的にオフラインにする設定を行うために、take-offline 要素が backup 要素に追加されます。この設定例は以下になります。
<backup>
	<take-offline after-failures="${NUMBER}" 
		      min-wait="${PERIOD}" />
</backup>
Copy to Clipboard Toggle word wrap
take-offline 要素は、いつサイトをオフラインにするかを設定するために以下のパラメーターを使用します。
  • after-failures パラメーターは、サイトがオフラインになる前にサイトへの接続の試行を失敗できる回数を指定します。
  • min-wait パラメーターは、応答しないサイトをオフラインとしてマークするために待機する時間 (秒数単位) を指定します。このサイトは、min-wait 期間が最初の試行後に経過した時や after-failures パラメーターで指定される試行の失敗回数に達した時にオフラインになります。

27.4.2. サイトをオフラインにする (ライブラリーモード)

Red Hat JBoss Data Grid のライブラリーモードでは、backups 要素内ですべてのバックアップサイトを定義した後に backupFor 要素を使用します。
<backup>
        <takeOffline afterFailures="${NUM}"
                     minTimeToWait="${PERIOD}"/>
</backup>
Copy to Clipboard Toggle word wrap
サイトを自動的にオフラインにする設定をするには、takeOffline 要素を backup 要素に追加します。
  • afterFailures パラメーターは、サイトがオフラインになる前にサイトへの接続を失敗できる回数を指定します。デフォルト値 (0) は、minTimeToWait0 より小さい値の場合に失敗の回数を無限にすることを許可します。minTimeToWait0 より小さい値でない場合、afterFailures は、その値が負の値であるかのように動作します。つまり、このパラメーターが負の値である場合、minTimeToWait で指定される時間が経過した後にサイトがオフラインになることを示します。
  • minTimeToWait パラメーターは、応答しないサイトをオフラインとしてマークするために待機する時間 (秒数単位) を指定します。サイトは、afterFailures パラメーターで指定される試行回数に達し、最初の失敗後に minTimeToWait で指定される時間が経過した後にオフラインになります。このパラメーターが 0 以下の値に設定される場合、このパラメーターは無視され、サイトは afterFailures パラメーターのみに基づいてオフラインになります。

27.4.3. サイトをオフラインにする (プログラムを用いた場合)

Red Hat JBoss Data Grid において、プログラムを用いてデータセンター間のレプリケーションサイトを自動的にオフラインに設定するには、以下のようにします。
lon.sites().addBackup()
      .site("NYC")
      .backupFailurePolicy(BackupFailurePolicy.FAIL)
      .strategy(BackupConfiguration.BackupStrategy.SYNC)
      .takeOffline()
         .afterFailures(500)
         .minTimeToWait(10000);
Copy to Clipboard Toggle word wrap

27.4.4. JBoss Operations Network (JON) 経由でサイトをオフラインにする

JBoss Operations Network の操作を使用して、Red Hat JBoss Data Grid でサイトをオフラインにすることができます。メトリックスの一覧については、「JBoss Operations Network プラグイン操作」を参照してください。

27.4.5. CLI でサイトをオフラインにする

サイトが応答しない場合、Red Hat JBoss Data Grid のコマンドラインインターフェース (CLI) で site コマンドを使用して、データセンター間のレプリケーション設定からサイトを手動でシャットダウンします。
site コマンドを使用して、以下のようにサイトの状態を確認することができます。
[jmx://localhost:12000/MyCacheManager/namedCache]> site --status ${SITENAME}
Copy to Clipboard Toggle word wrap
このコマンドの結果は、名前付きサイトの現在の状態に応じて、online または offline のいずれかになります。
このコマンドは、以下のように名前を使用してサイトをオンラインまたはオフラインにするように使用できます。
[jmx://localhost:12000/MyCacheManager/namedCache]> site --offline ${SITENAME}
Copy to Clipboard Toggle word wrap
[jmx://localhost:12000/MyCacheManager/namedCache]> site --online ${SITENAME}
Copy to Clipboard Toggle word wrap
コマンドが成功する場合、ok の出力がコマンドの後に表示されます。
JBoss Data Grid CLI とそのコマンドについてさらに詳しくは、『開発者ガイド』の JBoss Data Grid コマンドラインインターフェース (CLI) についての章を参照してください。

27.4.6. サイトをオンラインに戻す

サイトがオフラインになった後に、サイトをオンラインに戻すために現在できる唯一の方法は、JMX コンソールを使用して XSiteAdmin MBean 上で bringSiteOnline(siteName) 操作を起動することです。この MBean についてさらに詳しくは、「XSiteAdmin」を参照してください。

27.5. 複数サイトマスターの設定

標準的な Red Hat JBoss Data Grid のデータセンター間のレプリケーション設定には、サイトごとに 1 つのマスターノードが含まれます。マスターノードは、他のサイトのマスターノードと通信するための他のノードのゲートウェイです。
この標準設定は、単純なデータセンター間のレプリケーション設定の場合に機能します。ただし、サイト間のトラフィック量が増えると、単一マスターノードを経由して渡されるトラフィックによりボトルネックが発生する可能性があり、その場合はノード間の通信が遅くなります。
JBoss Data Grid では、複数サイト間のトラフィックを最適化するために、各サイトに対して複数のマスターノードを設定します。

27.5.1. 複数サイトマスターの操作

複数サイトマスターが有効な状態で設定されている場合、各サイトのマスターノードは、グローバルクラスター (複数サイトのメンバーであるノードが含まれる) と共に、ローカルクラスター (つまりローカルサイト) に加わります。
各ノードは、サイトマスターとして機能し、ターゲットサイトとサイトマスターのリストから構成されるルーティングテーブルを維持します。メッセージが到着すると、送信先サイトのランダムなマスターノードが選択されます。次にメッセージがランダムなマスターノードに転送され、そこで送信先ノードに送信されます (ランダムに選択されたノードが送信先ではない場合)。

27.5.2. 複数サイトマスターの設定 (リモートクライアントサーバーモード)

前提条件

Red Hat JBoss Data Grid のリモートクライアントサーバーモード用にデータセンター間レプリケーションを設定します。

手順27.4 リモートクライアントサーバーモードで複数のサイトマスターを設定します。

  1. ターゲット設定の特定

    clustered-xsite.xml の設定ファイル例でターゲットサイトの設定を見つけます。この設定例は、以下のようになります。
    <relay site="LON">
    	<remote-site name="NYC" stack="tcp" cluster="global"/>
    	<remote-site name="SFO" stack="tcp" cluster="global"/>
    	<property name="relay_multicasts">false</property>
    </relay>
    
    Copy to Clipboard Toggle word wrap
  2. 最大サイトの設定

    サイト内のマスターノードの最大数を決定するには max_site_masters プロパティーを使用します。すべてのノードをマスターにするために、この値をサイト内のノード数に設定します。
    <relay site="LON">
    	<remote-site name="NYC" stack="tcp" cluster="global"/>
    	<remote-site name="SFO" stack="tcp" cluster="global"/>
    	<property name="relay_multicasts">false</property>
    	<property name="max_site_masters">16</property>
    </relay>
    
    Copy to Clipboard Toggle word wrap
  3. サイトマスターの設定

    ノードをサイトマスターにすることを許可するには、can_become_site_master プロパティーを使用します。このフラグはデフォルトで true に設定されます。このフラグを false に設定することにより、ノードがサイトマスターになることを防ぐことができます。これは、ノードが外部ネットワークに接続されたネットワークインターフェースを持たない状況で必要になります。
    <relay site="LON">
    	<remote-site name="NYC" stack="tcp" cluster="global"/>
    	<remote-site name="SFO" stack="tcp" cluster="global"/>
    	<property name="relay_multicasts">false</property>
    	<property name="max_site_masters">16</property>
    	<property name="can_become_site_master">true</property>
    </relay>
    
    Copy to Clipboard Toggle word wrap

27.5.3. 複数サイトマスターの設定 (ライブラリーモード)

Red Hat JBoss Data Grid のライブラリーモードで複数サイトマスターを設定するには、以下を実行します。

手順27.5 複数サイトマスターの設定 (ライブラリーモード)

  1. データセンター間レプリケーションを設定します。

    JBoss Data Grid でデータセンター間レプリケーションを設定します。XML 設定については 「データセンター間レプリケーションを宣言的に設定する」 の手順を使用し、プログラミングによる設定の場合は 「データセンター間レプリケーションをプログラムを用いて設定する」 の手順を使用します。
  2. 設定ファイルの内容を追加します。

    以下のように can_become_site_master および max_site_masters パラメーターを設定に追加します。
    <config> 
        ... 
        <relay.RELAY2 site="LON" 
                  config="relay.xml" 
                  relay_multicasts="false"
                  can_become_site_master="true" 
                  max_site_masters="16"/>
    </config>
    
    Copy to Clipboard Toggle word wrap
    すべてのノードをマスターにするために、max_site_masters 値をクラスター内のノード数に設定します。

付録A Red Hat JBoss Data Grid における JMX MBeans

A.1. アクティベーション

org.infinispan.eviction.ActivationManagerImpl
エントリーをメモリーにロードすることにより、CacheStore にパッシベートされたエントリーをアクティベートします。
Expand
表A.1 属性
名前 説明 タイプ 書き込み可能
activations アクティベーションイベントの数です。 文字列 いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.2 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.2. キャッシュ

org.infinispan.CacheImpl
Cache コンポーネントは、個別のキャッシュインスタンスを表します。
Expand
表A.3 属性
名前 説明 タイプ 書き込み可能
cacheName キャッシュ名を返します。 文字列 いいえ
cacheStatus キャッシュの状態を返します。 文字列 いいえ
configurationAsProperties プロパティーの形式でキャッシュの設定を返します。 java.util.Properties いいえ
version Infinispan のバージョンを返します。 java.lang.String いいえ
Expand
表A.4 操作
名前 説明 署名
start キャッシュを起動します。 void start()
stop キャッシュを停止します。 void stop()
clear キャッシュをクリアにします。 void clear()

A.3. CacheLoader

org.infinispan.interceptors.CacheLoaderInterceptor
このコンポーネントは、エントリーを CacheStore からメモリーにロードします。
Expand
表A.5 属性
名前 説明 タイプ 書き込み可能
cacheLoaderLoads キャッシュストアからロードされるエントリーの数です。 long いいえ
cacheLoaderMisses キャッシュストアに存在しなかったエントリーの数です。 long いいえ
stores 設定済みの有効にされているキャッシュローダーのコレクションを返します。 コレクション いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.6 操作
名前 説明 署名
disableStore 指定されるタイプのすべてのキャッシュローダーを無効にします。このタイプは、無効にするキャッシュローダーの完全修飾クラス名です。 void disableStore(String storeType)
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.4. CacheManager

org.infinispan.manager.DefaultCacheManager
CacheManager コンポーネントは、システム内のキャッシュのマネージャー、ファクトリー、およびコンテナーとして動作します。
Expand
表A.7 属性
名前 説明 タイプ 書き込み可能
cacheManagerStatus キャッシュマネージャーのインスタンスの状態です。 文字列 いいえ
clusterMembers クラスターのメンバーを一覧表示します。 文字列 いいえ
clusterName クラスター名。 文字列 いいえ
clusterSize ノードの数で表されるクラスターのサイズです。 int いいえ
createdCacheCount デフォルトキャッシュを含む、作成されたキャッシュの合計数です。 文字列 いいえ
definedCacheCount デフォルトキャッシュを除く、定義されたキャッシュの合計数です。 文字列 いいえ
definedCacheNames 定義されたキャッシュ名とそれらのキャッシュの状態です。デフォルトのキャッシュはこの表示には含まれません。 文字列 いいえ
name このキャッシュマネージャーの名前です。 文字列 いいえ
nodeAddress このインスタンスに関連付けられたネットワークアドレスです。 文字列 いいえ
physicalAddresses このインスタンスに関連付けられた物理ネットワークアドレスです。 文字列 いいえ
runningCacheCount デフォルトキャッシュを含む、実行中のキャッシュの合計数です。 文字列 いいえ
version Infinispan のバージョンです。 文字列 いいえ
Expand
表A.8 操作
名前 説明 署名
startCache キャッシュマネージャーに関連付けられたデフォルトのキャッシュを起動します。 void startCache()
startCache このキャッシュマネージャーから名前付きキャッシュを起動します。 void startCache (String p0)

A.5. CacheStore

org.infinispan.interceptors.CacheWriterInterceptor
CacheStore コンポーネントは、エントリーをメモリーから CacheStore に保存します。
Expand
表A.9 属性
名前 説明 タイプ 書き込み可能
writesToTheStores ストアへの書き込み回数です。 long いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.10 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.6. DeadlockDetectingLockManager

org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager
このコンポーネントは、検出されたデッドロックの数についての情報を提供します。
Expand
表A.11 属性
名前 説明 タイプ 書き込み可能
detectedLocalDeadlocks デッドロックによりロールバックされたローカルトランザクションの数です。 long いいえ
detectedRemoteDeadlocks デッドロックによりロールバックされたリモートトランザクションの数です。 long いいえ
overlapWithNotDeadlockAwareLockOwners デッドロックの判別を試行しているが、他のロックを所有するのがトランザクションでは「ない」状況の数です。このシナリオでは、デッドロック検出メカニズムを実行することはできません。 long いいえ
totalNumberOfDetectedDeadlocks 検出されたローカルデッドロックの合計数です。 long いいえ
concurrencyLevel MVCC ロックマネージャーについて設定された平行性レベルです。 int いいえ
numberOfLocksAvailable 利用可能な排他ロックの数です。 int いいえ
numberOfLocksHeld 保持されている排他ロックの数です。 int いいえ
Expand
表A.12 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.7. DistributionManager

org.infinispan.distribution.DistributionManagerImpl
DistributionManager コンポーネントは、クラスター間のコンテンツの分散を処理します。

注記

DistrubutionManager コンポーネントはクラスターモードのみで利用可能です。
Expand
表A.13 操作
名前 説明 署名
isAffectedByRehash 指定されたキーが進行中のリハッシュによって影響を受けるかどうかを決定します。 boolean isAffectedByRehash(Object p0)
isLocatedLocally 指定されたキーがキャッシュのこのインスタンスに対してローカルであるかどうかを示します。文字列キーでのみ機能します。 boolean isLocatedLocally(String p0)
locateKey クラスター内のオブジェクトを見つけます。文字列キーでのみ機能します。 List locateKey(String p0)

A.8. インタープリター

org.infinispan.cli.interpreter.Interpreter
Interpreter コンポーネントは、コマンドラインインターフェース (CLI 操作) を実行します。
Expand
表A.14 属性
名前 説明 タイプ 書き込み可能
cacheNames キャッシュマネージャーのキャッシュのリストを取得します。 String[] いいえ
Expand
表A.15 操作
名前 説明 署名
createSessionId 新規のインタープリターセッションを作成します。 String createSessionId(String cacheName)
execute IspnCliQL ステートメントを解析し、実行します。 String execute(String p0, String p1)

A.9. インバリデーション

org.infinispan.interceptors.InvalidationInterceptor
Invalidation コンポーネントは、エントリーがローカルに作成される場合にリモートキャッシュのエントリーを無効にします。
Expand
表A.16 属性
名前 説明 タイプ 書き込み可能
invalidations インバリデーションの数です。 long いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.17 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.10. LockManager

org.infinispan.util.concurrent.locks.LockManagerImpl
LockManager コンポーネントは、エントリーの MVCC ロックを処理します。
Expand
表A.18 属性
名前 説明 タイプ 書き込み可能
concurrencyLevel MVCC ロックマネージャーが設定される平行性レベル 整数 いいえ
numberOfLocksAvailable 利用可能な排他ロックの数。 整数 いいえ
numberOfLocksHeld 保留にされている排他ロックの数。 整数 いいえ

A.11. LocalTopologyManager

org.infinispan.topology.LocalTopologyManagerImpl
LocalTopologyManager コンポーネントは、Red Hat JBoss Data Grid におけるキャッシュのメンバーシップと状態の転送を制御します。

注記

LocalTopologyManager コンポーネントは、クラスターモードでのみ利用可能です。
Expand
表A.19 属性
名前 説明 タイプ 書き込み可能
rebalancingEnabled false の場合、新規に起動したノードは既存のクラスターに参加せず、状態もそれらに転送されません。現在のクラスターメンバーのいずれかが再調整が無効にされている状態で停止した場合、ノードがそのクラスターを離れ、状態の再調整は残りのノード間で行なわれません。これにより、再調整が再び有効にされるまで、コピーの数は numOwners 属性で指定される数よりも少なくなります。 ブール値 はい

A.12. MassIndexer

org.infinispan.query.MassIndexer
MassIndexer コンポーネントは、キャッシュされたデータを使用してインデックスを再構築します。
Expand
表A.20 操作
名前 説明 署名
start インデックスの再構築を開始します。 void start()

注記

この操作は、インデックス化を有効にしたキャッシュの場合にのみ利用できます。さらに詳しくは、Red Hat JBoss Data Grid 『Infinispan Query Guide』 を参照してください。

A.13. パッシベーション

org.infinispan.interceptors.PassivationInterceptor
パッシベーションコンポーネントは、エビクションの CacheStore へのエントリーのパッシベーションを処理します。
Expand
表A.21 属性
名前 説明 タイプ 書き込み可能
passivations パッシベーションイベントの数です。 文字列 いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.22 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.14. RecoveryAdmin

org.infinispan.transaction.xa.recovery.RecoveryAdminOperations
RecoveryAdmin コンポーネントは、トランザクションリカバリーを処理するためのツールを公開します。
Expand
表A.23 操作
名前 説明 署名
forceCommit 不明なトランザクションのコミットを強制します。 String forceCommit(long p0)
forceCommit 不明なトランザクションのコミットを強制します。 String forceCommit(int p0, byte[] p1, byte[] p2)
forceRollback 不明なトランザクションのロールバックを強制します。 String forceRollback(long p0)
forceRollback 不明なトランザクションのロールバックを強制します。 String forceRollback(int p0, byte[] p1, byte[] p2)
forget 指定されるトランザクションのリカバリー情報を削除します。 String forget(long p0)
forget 指定されるトランザクションのリカバリー情報を削除します。 String forget(int p0, byte[] p1, byte[] p2)
showInDoubtTransactions 発進されるノードがクラッシュする準備されたトランザクションをすべて表示します。 String showInDoubtTransactions()

A.15. RollingUpgradeManager

org.infinispan.upgrade.RollingUpgradeManager
RollingUpgradeManager コンポーネントは、Red Hat JBoss Data Grid の 1 つのバージョンから別のバージョンへのデータ移行を行うために制御フックを処理します。
Expand
表A.24 操作
名前 説明 署名
disconnectSource 指定される移行プログラムに従って、ターゲットクラスターをソースクラスターから切り離します。 void disconnectSource(String p0)
recordKnownGlobalKeyset アップグレードプロセスで取得するために、グローバルな既知のキーセットを既知のキーにダンプします。 void recordKnownGlobalKeyset()
synchronizeData 指定された移行プログラムを使用して、古いクラスターのデータをこれに同期します。 long synchronizeData(String p0)

A.16. RpcManager

org.infinispan.remoting.rpc.RpcManagerImpl
RpcManager コンポーネントは、クラスター内のリモートキャッシュインスタンスへのリモート呼び出しをすべて管理します。

注記

RpcManager コンポーネントは、クラスターモードでのみ利用可能です。
Expand
表A.25 属性
名前 説明 タイプ 書き込み可能
averageReplicationTime トランスポート層で費やされた平均時間 (ミリ秒単位) です。 long いいえ
committedViewAsString コミット済みのビューを取得します。 文字列 いいえ
pendingViewAsString 保留中のビューを取得します。 文字列 いいえ
replicationCount 正常なレプリケーションの数です。 long いいえ
replicationFailures 失敗したレプリケーションの数です。 long いいえ
successRatio レプリケーションの合計数に対する正常なレプリケーションの比率です。 文字列 いいえ
successRatioFloatingPoint 数値 (double) 形式でのレプリケーションの合計数に対する正常なレプリケーションの比率です。 double いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.26 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()
setStatisticsEnabled 統計を有効または無効にするかを設定します (true/false)。 void setStatisticsEnabled(boolean enabled)

A.17. StateTransferManager

org.infinispan.statetransfer.StateTransferManager
StateTransferManager コンポーネントは Red Hat JBoss Data Grid における状態の転送を処理します。

注記

StateTransferManager コンポーネントは、クラスターモードでのみ利用可能です。
Expand
表A.27 属性
名前 説明 タイプ 書き込み可能
joinComplete true の場合、ノードはグリッドに正常に加わっており、保留状態であると見なされます。false の場合、join プロセスは依然として進行中です。 ブール値 いいえ
stateTransferInProgress このクラスターメンバーに保留中のインバウンドの状態転送があるかどうかをチェックします。 ブール値 いいえ

A.18. 統計

org.infinispan.interceptors.CacheMgmtInterceptor
このコンポーネントは、タイミング、読み取り/書き込み比率などの一般的な統計を処理します。
Expand
表A.28 属性
名前 説明 タイプ 書き込み可能
averageReadTime キャッシュの読み取り操作にかかる平均のミリ秒数です。 long いいえ
averageWriteTime キャッシュの書き込み操作にかかる平均のミリ秒数です。 long いいえ
elapsedTime キャッシュの開始以降の秒数です。 long いいえ
evictions キャッシュエビクション操作の数です。 long いいえ
hitRatio キャッシュのヒット/(ヒット+ミス) 比率 (パーセンテージ) です。 double いいえ
hits キャッシュ属性のヒット数です。 long いいえ
misses キャッシュ属性の失敗回数です。 long いいえ
numberOfEntries 現在キャッシュにあるエントリーの数です。 整数 いいえ
readWriteRatio キャッシュの読み取り/書き込み比率です。 double いいえ
removeHits キャッシュ除去のヒット数です。 long いいえ
removeMisses キーが見つからなかった場合のキャッシュ除去の回数です。 long いいえ
stores キャッシュ属性 PUT 操作の数です。 long いいえ
timeSinceReset キャッシュ統計が最後にリセットされてからの秒数です。 long いいえ
Expand
表A.29 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.19. トランザクション

org.infinispan.interceptors.TxInterceptor
Transactions コンポーネントは、JTA トランザクションでのキャッシュの参加を管理します。
Expand
表A.30 属性
名前 説明 タイプ 書き込み可能
commits 最終リセット時から実行されるトランザクションのコミット数です。 long いいえ
prepares 最終リセット時から実行されるトランザクションの準備回数です。 long いいえ
rollbacks 最終リセット時から実行されるトランザクションのロールバック回数です。 long いいえ
statisticsEnabled このコンポーネントにより、統計の収集を有効または無効にします。 ブール値 はい
Expand
表A.31 操作
名前 説明 署名
resetStatistics このコンポーネントによって収集される統計をリセットします。 void resetStatistics()

A.20. トランスポート

org.infinispan.server.core.transport.NettyTransport
Transport コンポーネントは、サーバーへの/からの読み取りおよび書き込み操作を管理します。
Expand
表A.32 属性
名前 説明 タイプ 書き込み可能
hostName トランスポートがバインドされるホストを戻します。 文字列 いいえ
idleTimeout アイドル状態のタイムアウトを戻します。 文字列 いいえ
numberOfGlobalConnections クラスター内のアクティブな接続の数を戻します。この操作は、結果を集約するためのリモート呼び出しを行うため、待ち時間がこの属性の計算スピードに影響を与える場合があります。 整数 false
numberOfLocalConnections このサーバーのアクティブな接続の数を戻します。 整数 いいえ
numberWorkerThreads ワーカースレッドの数を戻します。 文字列 いいえ
port トランスポートがバインドされるポートを戻します。 文字列  
receiveBufferSize 受信バッファーサイズを戻します。 文字列 いいえ
sendBufferSize 送信バッファーサイズを戻します。 文字列 いいえ
totalBytesRead プロトコルおよびユーザー情報の両方を含む、サーバーがクライアントから読み取るバイト数の合計を戻します。 文字列 いいえ
totalBytesWritten プロトコルおよびユーザー情報の両方を含む、サーバーがクライアントに書き戻すバイト数の合計を戻します。 文字列 いいえ
tcpNoDelay TCP no delay (TCP 遅延なし) が設定されているかどうかの情報を戻します。 文字列 いいえ

A.21. XSiteAdmin

org.infinispan.xsite.XSiteAdminOperations
XSiteAdmin コンポーネントは、データをリモートサイトにバックアップするためのツールを公開します。
Expand
表A.33 操作
名前 説明 署名
bringSiteOnline すべてのクラスターで指定されたサイトをオンラインに戻します。 String bringSiteOnline(String p0)
amendTakeOffline クラスター内のすべてのノードで 'TakeOffline' 機能の値を修正します。 String amendTakeOffline(String p0, int p1, long p2)
getTakeOfflineAfterFailures 'TakeOffline' 機能に対して 'afterFailures' の値を戻します。 String getTakeOfflineAfterFailures(String p0)
getTakeOfflineMinTimeToWait 'TakeOffline' 機能に対して 'minTimeToWait' の値を戻します。 String getTakeOfflineMinTimeToWait(String p0)
setTakeOfflineAfterFailures クラスター内のすべてのノードで 'TakeOffline' 機能について 'afterFailures' の値を修正します。 String setTakeOfflineAfterFailures(String p0, int p1)
setTakeOfflineMinTimeToWait クラスター内のすべてのノードで 'TakeOffline' 機能について 'minTimeToWait' の値を修正します。 String setTakeOfflineMinTimeToWait(String p0, long p1)
siteStatus 指定されるバックアップサイトがオフラインかどうかをチェックします。 String siteStatus(String p0)
状態 設定されたすべてのバックアップサイトについて、ステータス (オフライン/オンライン) を戻します。 String status()
takeSiteOffline クラスター内のすべてのノードでこのノードをオフラインにします。 String takeSiteOffline(String p0)

付録B 参照

B.1. 一貫性について

一貫性とは、あるノード上のデータ記録が他のノード上の同じデータ記録と異なることが可能であるかどうかを記述するポリシーのことです。
たとえば、ネットワークの速度が原因で、マスターノード上で実行された書き込み操作がストアの他のノードでは実行されていない場合があります。強い一貫性保証があると、完全にレプリケートされていないデータがアプリケーションに返されることはありません。

B.2. 一貫性保証について

全所有者ではなく単一所有者のロックであるにも関わらず、Red Hat JBoss Data Grid の一貫性保証は維持されます。一貫性とは次のようなことを言います。
  1. キー K はノード {A,B} へハッシュ化されます。トランザクション TX1 は、たとえばノード A 上の K ロックを取得します。
  2. 他のキャッシュへのアクセスが、ノード B または他のノードで発生すると、TX2K をロックしようとしますが、トランザクション TX1 がすでに K のロックを保持しているため、タイムアウトが発生してこのアクセスの試行は失敗します。
キー K のロックはトランザクションの発生元に関係なく、常にクラスターの同じノード上で取得されるため、このロックの取得は常に失敗します。

B.3. JBoss Cache について

Red Hat JBoss Cache は、ツリー構造のクラスター化されたトランザクションキャッシュで、スタンドアロンのクラスター化されていない環境でも使用できます。頻繁にアクセスされるデータをインメモリーでキャッシュし、Java Transactional API (JTA) との互換、エビクション、および永続性などのエンタープライズ機能の提供中に、データの読み出しや計算のボトルネックが発生しないようにします。
JBoss Cache は Infinispan と Red Hat JBoss Data Grid の前身となるものです。

B.4. RELAY2 について

RELAY プロトコルは、各サイトの 1 つのノード間の接続を作成することによって 2 つのリモートクラスターをブリッジします。これにより、1 つのサイトに送信されたマルチキャストメッセージが他のサイトにリレーされ、他のサイトからそのサイトにもリレーさせることができます。
JGroups には、Red Hat JBoss Data Grid のサイト間レプリケーションにおけるサイト間の通信に使用される RELAY2 プロトコルが含まれます。
RELAY2 プロトコルは RELAY と同様に機能しますが、若干の相違点があります。RELAY とは異なり、RELAY2 プロトコルは以下を実行します。
  • 3 つ以上のサイトを接続します。
  • 自律的に機能し、相互に認識しないサイトに接続します。
  • サイト間のユニキャストとマルチキャストのルーティングの両方を提供します。

B.5. 戻り値について

キャッシュ操作によって返される値は戻り値と呼ばれます。Red Hat JBoss Data Grid では、使用されるキャッシュモードや同期または非同期通信が使用されるかどうかに関係なく、これらの戻り値は信頼性を維持します。

B.6. 実行可能インターフェースについて

実行可能インターフェースは、クラスのコードのアクティブな部分を実行する単一の run() メソッドを宣言します。実行可能オブジェクトは、スレッドコンストラクターに渡された後、独自のスレッドでの実行が可能です。

B.7. 2 相コミット (2PC) について

2 相コミットプロトコル (2PC) は、分散トランザクションをアトミックにコミットまたはロールバックするために使用される合意プロトコルです。ネットワークノードや通信の障害など一時的なシステム障害が発生しても正常に動作するため、幅広く使用されています。

B.8. キーバリューペアについて

キーバリューペア (KVP) とは、キーと値で構成されるデータセットのことです。
  • キーは特定のデータエントリーに一意であり、関連する特定エントリーのデータ属性によって構成されます。
  • バリュー (値) は、キーによって割り当てられ、キーによって識別されるデータです。

B.9. エクスターナライザー

B.9.1. エクスターナライザーについて

Externalizer クラスは、以下のことを行えるクラスです。
  • 該当するオブジェクトタイプをバイトアレイにマーシャリングします。
  • バイトアレイの内容をオブジェクトタイプのインスタンスにマーシャリング解除します。
エクスターナライザーは Red Hat JBoss Data Grid により使用され、ユーザーはオブジェクトタイプをどのようにシリアライズするかを指定できます。JBoss Data Grid で使用されるマーシャリングインフラストラクチャーは、JBoss Marshalling に基づいて構築され、効率的なペイロード配信を提供し、ストリームをキャッシュすることを可能にします。ストリームキャッシングを使用すると、データに複数回アクセスできますが、通常はストリームは 1 度だけ読み取ることができます。

B.9.2. 内部エクスターナライザー実装アクセス

Externalizable オブジェクトは Red Hat JBoss Data Grids エクスターナライザー実装にアクセスしないようにする必要があります。間違った使用法の例を以下に示します。
public static class ABCMarshallingExternalizer implements AdvancedExternalizer<ABCMarshalling> {
   @Override
   public void writeObject(ObjectOutput output, ABCMarshalling object) throws IOException {
      MapExternalizer ma = new MapExternalizer();
      ma.writeObject(output, object.getMap());
   }
 
   @Override
   public ABCMarshalling readObject(ObjectInput input) throws IOException, ClassNotFoundException {
      ABCMarshalling hi = new ABCMarshalling();
      MapExternalizer ma = new MapExternalizer();
      hi.setMap((ConcurrentHashMap<Long, Long>) ma.readObject(input));
      return hi;
   }

   ...
Copy to Clipboard Toggle word wrap
エンドユーザーエクスターナライザーは内部のエクスターナライザークラスと対話する必要がありません。正しい使用法の例を以下に示します。
public static class ABCMarshallingExternalizer implements AdvancedExternalizer<ABCMarshalling> {
   @Override
   public void writeObject(ObjectOutput output, ABCMarshalling object) throws IOException {
      output.writeObject(object.getMap());
   }
 
   @Override
   public ABCMarshalling readObject(ObjectInput input) throws IOException, ClassNotFoundException {
      ABCMarshalling hi = new ABCMarshalling();
      hi.setMap((ConcurrentHashMap<Long, Long>) input.readObject());
      return hi;
   }

   ... 
}
Copy to Clipboard Toggle word wrap

B.10. ハッシュ領域の割り当て

B.10.1. ハッシュ領域の割り当てについて

Red Hat JBoss Data Grid は、使用可能なハッシュ領域全体の一部を各ノードに割り当てる役割があります。エントリーを格納する必要がある後続の操作中、JBoss Data Grid は関連するキーのハッシュを作成し、その部分のハッシュ領域を所有するノード上にエントリーを格納します。

B.10.2. ハッシュ領域におけるキーの検索

Red Hat JBoss Data Grid は常にアルゴリズムを使用してハッシュ領域のキーを見つけます。そのため、キーを格納するノードを手動で指定することはありません。このスキームにより、キーの所有者情報を配信しなくても、すべてのノードが特定のキーを所有するノードを判断することができます。このスキームによりオーバヘッドの量が削減されます。さらに重要なことに、ノードの障害時に所有者情報をレプリケートする必要がないため、冗長性が向上します。

B.10.3. 完全なバイトアレイの要求

バイトアレイの部分的な内容ではなく、完全なバイトアレイを Red Hat JBoss Data Grid が返すように要求する方法はあるのでしょうか。

デフォルトでは、必要のない巨大なバイトアレイを出力しないように、JBoss Data Grid はバイトアレイの一部のみをログに出力します。以下の場合にバイトアレイがログに出力されます。

  • JBoss Data Grid のキャッシュにレイジーデシリアライゼーションが設定されている場合。レイジーデシリアライゼーションは JBoss Data Grid のリモートクライアントサーバーモードでは使用できません。
  • Memcached または Hot Rod サーバーが実行されている場合。
このような場合、最初から 10 ポジションまでのバイトアレイがログに表示されます。バイトアレイの全内容をログに表示するには、起動時に -Dinfinispan.arrays.debug=true システムプロパティーを渡します。

例B.1 部分的なバイトアレイのログ

2010-04-14 15:46:09,342 TRACE [ReadCommittedEntry] (HotRodWorker-1-1) Updating entry 
(key=CacheKey{data=ByteArray{size=19, hashCode=1b3278a, 
array=[107, 45, 116, 101, 115, 116, 82, 101, 112, 108, ..]}} 
removed=false valid=true changed=true created=true value=CacheValue{data=ByteArray{size=19, 
array=[118, 45, 116, 101, 115, 116, 82, 101, 112, 108, ..]}, 
version=281483566645249}]
And here's a log message where the full byte array is shown:
2010-04-14 15:45:00,723 TRACE [ReadCommittedEntry] (Incoming-2,Infinispan-Cluster,eq-6834) Updating entry 
(key=CacheKey{data=ByteArray{size=19, hashCode=6cc2a4, 
array=[107, 45, 116, 101, 115, 116, 82, 101, 112, 108, 105, 99, 97, 116, 101, 100, 80, 117, 116]}} 
removed=false valid=true changed=true created=true value=CacheValue{data=ByteArray{size=19, 
array=[118, 45, 116, 101, 115, 116, 82, 101, 112, 108, 105, 99, 97, 116, 101, 100, 80, 117, 116]}, 
version=281483566645249}]
Copy to Clipboard Toggle word wrap

付録C 改訂履歴

改訂履歴
改訂 6.2.1-5Tue Mar 11 2014Mandar Joshi
BZ-1072723: 「エビクションストラテジー」トピックのタイプミスを修正。
BZ-1072749: 「LRU エビクションアルゴリズムの制限」トピックをより明確にするために書き直す。
BZ-1073911: 「ローカルモードの設定 (リモートクライアントサーバーモード)」トピックのコードスニペットを更新。
BZ-1075278: 文章中の抜けていた単語を追加。
BZ-1075559: 「Centre」の例を「Center」に変更。
改訂 6.2.1-2Thu Mar 06 2014Rakesh Ghatvisave
BZ-997230: クラスターモードのみの JMX 属性についての注記を追加。LocalTopologyManager MBean を付録に追加。
BZ-1071900: データセンター間レプリケーションの relay_multicasts=false 属性を追加。
BZ-1063532: CLI を使用した JBoss Data Grid インスタンスの停止に関するトピックを追加。
BZ-1069361: S3_PING と JBoss Data Grid の使用についての章を追加。
BZ-1069143: JON についてのトピックを変更し、いくつかのセクションを再配置。
BZ-1061671: JON の使用法について修正。
改訂 6.2.1-1Wed Feb 26 2014Misha Husnain Ali
BZ-1069920: 新規 FileCacheStore についての一貫していない行を削除。
BZ-1068769: CLI ツール部分を追加。この部分を開発者ガイドから移行。
BZ-1069143: JON の内容を削除。
BZ-1061684: 表現を改善。

法律上の通知

Copyright © 2014 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る