Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

管理および設定ガイド

Red Hat JBoss Data Grid 6

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

エディッション 1

Misha Husnain Ali

Red Hat Engineering Content Services

Darrin Mison

Gemma Sheldon

Red Hat Engineering Content Services

概要

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

前書き

第1章 JBoss Data Grid
リンクのコピー

1.1. JBoss Data Grid について
リンクのコピー

JBoss Data Grid は分散インメモリーデータグリッドで、次の機能を提供します。
  • スキーマレスなキーバリューストア – Red Hat JBoss Data Grid は、固定のデータモデルを用いずに異なるオブジェクトを格納するフレキシブルな NoSQL データベースです。
  • グリッドベースのデータストレージ – Red Hat JBoss Data Grid は、複数のノードにまたがったデータのレプリケートが簡単に行えるよう設計されています。
  • エラスティックスケーリング – シンプルに混乱を起こさずノードの追加と削除を行えます。
  • 複数のアクセスプロトコル – REST、Memcached、Hot Rod または簡単なマップのような API を使用して簡単にデータグリッドへアクセスできます。
バグを報告する

1.2. JBoss Data Grid の使用モード
リンクのコピー

JBoss Data Grid には 2 つの使用モードがあります。
リモートクライアントサーバーモード
リモートクライアントサーバーモードは、管理分散されたクラスター化可能なデータグリッドサーバーを提供します。アプリケーションは Hot Rod、Memcached、または REST クライアント API を使用して、データグリッドにリモートアクセスできます。
ライブラリーモード
ライブラリーモードは、カスタムランタイム環境の構築やデプロイに必要なすべてのバイナリを提供します。ライブラリー使用モードでは、分散クラスターの 1 つのノードへローカルアクセスでできます。この使用モードでは、使用されるコンテナの仮想マシン内でアプリケーションがデータグリッドの機能にアクセスできます。サポート対象のコンテナには、Tomcat 7 や JBoss Enterprise Application Platform 6 などがあります。
バグを報告する

1.3. JBoss Data Grid の利点
リンクのコピー

JBoss Data Grid の利点

巨大なヒープと高可用性
JBoss Data Grid では、パフォーマンス向上のためにアプリケーションがデータのルックアップ処理のほとんどを大型のサーバーデータベースへ委譲する必要がありません。JBoss Data Grid は、現在のエンタープライズアプリケーションの大部分に存在するボトルネックを完全に取り除きます。

例1.1 巨大なヒープと高可用性の例

100 個のブレードサーバーを持つグリッドの例として、各ノードがレプリケートされたキャッシュ専用の 2 GB のストレージ領域を持っているとします。この場合、グリッドの全データが 2 GB のデータのコピーとなります。逆に、分散グリッド (データ項目ごとに 1 つのコピーが必要であることを仮定した場合) では、メモリーがサポートする仮想ヒープに 100 GB のデータが含まれます。グリッドのどこからでも効果的にこのデータへアクセスできるようになります。サーバーに障害が発生した場合、グリッドによって損失データの新しいコピーが即座に作成され、グリッドの運用サーバーに置かれます。
スケーラビリティー
JBoss Data Grid ではデータが均一に分散されるため、グリッドサイズの唯一の上限はネットワーク上でのグループ通信になります。ネットワークのグループ通信は最小限で、新規ノードの発見のみに制限されています。すべてのデータアクセスパターンは、ノードによるピアツーピア接続を介した直接通信を許可するため、スケーラビリティーの更なる向上を容易にします。JBoss Data Grid のクラスターは、リアルタイムでスケールアップまたはスケールダウンすることが可能ですが、インフラストラクチャーの再起動を必要としません。スケーリングポリシーへの変更をリアルタイムで適用できるため、非常にフレキシブルな環境を実現することができます。
データ分散
JBoss Data Grid は一貫したハッシュアルゴリズムを使用して、クラスターにおけるキーの場所を判断します。一貫したハッシュに関する利点には次のようなものがあります。
  • コスト効果
  • 速度
  • 更なるメタデータやネットワークトラフィックの必要がない、決定論的なキーの場所
データ分散は、永続性とフォールトトラレンスを提供するため、余分のない十分なコピーがクラスター内に確実に存在するようにします。余分なコピーは環境のスケーラビリティーを低下させます。
永続性
JBoss Data Grid は、CacheStore インターフェースと複数の高パフォーマンス実装 (JDBC キャッシュストアやファイルシステムベースのキャッシュストアなど) を公開します。キャッシュストアはキャッシュをシードし、関連データを安全に保持し、破損しないようにします。また、キャッシュストアはプロセスがメモリー不足になると、データをディスクへオーバーフローします。
言語のバインディング
JBoss Data Grid は、既に多くの一般的なプログラミング言語向けに使用されている Memcached プロトコルと、Hot Rod と呼ばれる最適化された JBoss Data Grid 固有のプロトコルの両方をサポートします。そのため、Java Data Grid は Java に限定されず、すべての主要な Web サイトやアプリケーションに使用できます。
管理
数百個またはそれ以上のサーバーが存在するグリッド環境では、管理の実行は重要な機能になります。エンタープライズネットワーク管理ソフトウェアである JBoss Operations Network は、複数の JBoss Data Grid インスタンスを管理するのに最適なツールです。JBoss Operations Network の機能を使用すると、キャッシュマネージャーやキャッシュインスタンスを簡単かつ効率的に監視できます。
バグを報告する

1.4. JBoss Data Grid の前提条件
リンクのコピー

JBoss Data Grid の実行には、Java 6.0 およびそれ以降のバージョンと互換性を持つ Java 仮想マシン (JVM) のみが必要となります。JBoss Data Grid にはアプリケーションサーバーは必要ありません。
バグを報告する

1.5. JBoss Data Grid のバージョン情報
リンクのコピー

JBoss Data Grid は、データグリッドソフトウェアのオープンソースコミュニティー版である Infinispan が基盤となっています。Infinispan は、高ストレス環境で試行やテストを行い証明された JBoss Cache のコード、設計、およびアイデアを使用します。このようなデプロイメントの前歴があるため、JBoss Data Grid の初版リリースはバージョン 6.0 になっています。
バグを報告する

1.6. JBoss Data Grid のキャッシュアーキテクチャー
リンクのコピー

JBoss Data Grid のキャッシュアーキテクチャー

図1.1 JBoss Data Grid のキャッシュアーキテクチャー

JBoss Data Grid のキャッシュアークテクチャーは個々の要素と要素同士の対話を表現します。明確にするため、キャッシュアーキテクチャーの図は以下の 2 つの部分に分割されています。
  • ユーザーが直接対話できない要素 (背景が灰色の部分)。これにはキャッシュ、キャッシュマネージャー、1 次キャッシュ、永続ストアインターフェース、永続ストアなどが含まれます。
  • ユーザーが直接対話できる要素 (背景が白の部分)。これにはキャッシュインターフェースやアプリケーションなどが含まれます。
キャッシュアーキテクチャーの要素

JBoss Data Grid のキャッシュアーキテクチャーには次の要素が含まれます。

  1. キャッシュインスタンスやエントリーを永久的に格納する永続ストア。
  2. JBoss Data Grid は、永続ストアのアクセスに 2 つの永続ストアインターフェースを提供します。永続ストアインターフェースは以下のいずれかになります。
    • キャッシュローダーは永続データストアへの接続を提供する読み取り専用インターフェースです。キャッシュローダーは、キャッシュインスタンスおよび永続ストアよりデータの場所を見つけ、読み出すことができます。詳細は 「キャッシュローダー」 を参照してください。
    • キャッシュストアは、キャッシュローダーによるステートのロードおよび格納を許可するメソッドを公開し、キャッシュローダーの機能に書き込み機能が含まれるようにします。詳細は 10章キャッシュストアとキャッシュローダー を参照してください。
  3. 1 次キャッシュ (L1 キャッシュ) は、リモートキャッシュエントリーが最初にアクセスされた後にそれらのエントリーを格納し、同じエントリーがその後使用される度に不必要なリモートフェッチ操作が行われないようにします。詳細は 14章1 次キャッシュ を参照してください。
  4. キャッシュマネージャーは JBoss Data Grid のキャッシュインスタンスを読み出すために使用される主なメカニズムで、キャッシュを使用する時の開始点とすることができます。詳細は 11章キャッシュマネージャー を参照してください。
  5. キャッシュはキャッシュマネージャーによって読み出されたキャッシュインスタンスを格納します。
  6. キャッシュインターフェースは Memcached や Hot Rod などのプロトコルを使用します。キャッシュを持つインターフェースには REST を使用することもできます。リモートインターフェースに関する詳細は『開発者ガイド』を参照してください。
    • Memcached は、データベースドライバー Web サイトの応答時間や操作時間を改善するために使用されるインメモリーキャッシングシステムです。Memcached キャッシングシステムは、Memached プロトコルと呼ばれるテキストベースのクライアントサーバーキャッシングプロトコルを定義します。
    • Hot Rod は JBoss Data Grid で使用されるバイナリ TCP クライアントサーバープロトコルです。Memchached などの他のクライアントサーバープロトコルに不足している機能を補うために作成されました。Hot Rod は、パーティション化または分散化された JBoss Data Grid サーバークラスターの要求を、クライアントがスマートルーティングできるようにします。
    • REST プロトコルは、密結合のクライアントライブラリおよびバインディングを不要にします。REST API ではオーバーヘッドが発生し、REST 呼び出しの理解と作成に REST クライアントまたはカスタムコードを必要とします。
  7. アプリケーションは、キャッシュインターフェースを介してユーザーがキャッシュとやりとりできるようにします。このようなエンドユーザーアプリケーションの一般的な例がブラウザーです。
バグを報告する

1.7. JBoss Data Grid の API
リンクのコピー

1.7.1. JBoss Data Grid の API
リンクのコピー

JBoss Data Grid は次の API を提供します。
  • キャッシュ
  • バッチ処理
  • グループ化
  • CacheStore
  • 外部化
JBoss Data Grid のリモートクライアントサーバーモードでは、データグリッドとの対話に次の API のみを使用できます。
  • 非同期 API (リモートクライアントサーバーモードで Hot Rod クライアントを併用する場合のみ使用可能）
  • REST インターフェース
  • Memcached インターフェース
  • Hot Rod インターフェース
    • RemoteCache API
バグを報告する

1.7.2. 非同期 API について
リンクのコピー

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

1.7.3. バッチ化 API について
リンクのコピー

JBoss Data Grid クラスターがトランザクションの唯一の参加者である場合にバッチ化 API が使用されます。トランザクションに複数のシステムが参加している場合は、トランザクション API (JTA) のトランザクション (トランザクションマネージャーを使用) が使用されるはずです。

注記

バッチ化 API は JBoss Data Grid の リモートクライアントサーバーモードでは使用できません。
バグを報告する

1.7.4. キャッシュ API について
リンクのコピー

キャッシュインターフェースは、エントリーの追加、呼び出し、および削除に対する簡単なメソッドを提供します。これには JDK の ConcurrentMap インターフェースによって公開されるアトミックメカニズムが含まれます。エントリーが格納される方法は、使用されるキャッシュモードによって異なります。例えば、エントリーがリモートノードへレプリケートされたり、キャッシュストアでルックアップされたりすることもあります。
基本的な作業では、キャッシュ API は JDK マップ API と同様に使用されます。そのため、マップベースの簡単なインメモリーキャッシュを JBoss Data Grid のキャッシュへ移行する処理が簡単になります。

注記

この API は JBoss Data Grid のリモートクライアントサーバーモードでは使用できません。
バグを報告する

1.7.5. RemoteCache インターフェースについて
リンクのコピー

RemoteCache インターフェースは、JBoss Data Grid 外部のクライアントが JBoss Data Grid 内の Hot Rod サーバーモジュールにアクセスできるようにします。RemoteCache インターフェースは、ディストリビューションやエビクションなどのオプション機能を提供します。
バグを報告する

1.8. ツールと操作
リンクのコピー

1.8.1. 管理ツールについて
リンクのコピー

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

関連トピック:

バグを報告する

1.8.2. URL 経由のデータアクセス
リンクのコピー

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

注記

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

1.8.3. Map メソッドの制限
リンクのコピー

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

第2章 JBoss Data Grid でのロギング
リンクのコピー

2.1. JBoss Data Grid におけるロギングの概要
リンクのコピー

JBoss Data Grid 6 は、独自の内部使用とデプロイされたアプリケーションによる使用のために設定可能な高度なロギング機能を提供します。ロギングサブシステムは JBoss LogManager を基盤とし、JBoss Logging 以外にも複数のサードパーティーアプリケーションのロギングフレームワークをサポートします。
ロギングサブシステムは、ログカテゴリーとログハンドラーのシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義し、ログハンドラーはこれらのメッセージの処理方法を定義します (ディスクへの書き込みやコンソールへの送信など)。
バグを報告する

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

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

JBoss LogManager は次のロギングフレームワークをサポートします。
バグを報告する

2.2.2. JBoss Logging について
リンクのコピー

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

2.2.3. JBoss のロギング機能
リンクのコピー

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

2.3. ロギングの設定
リンクのコピー

2.3.1. ブートロギングについて
リンクのコピー

ブートログは、サーバーの起動中 (または「ブート中」) に発生したイベントの記録です。JBoss Data Grid 6 には、サーバーがブート処理を完了した後に生成されるログエントリーが含まれるサーバーログも付属されます。
バグを報告する

2.3.2. ブートロギングの設定
リンクのコピー

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

2.3.3. デフォルトのログファイルの場所
リンクのコピー

JBoss Data Grid のログファイルとログファイルの場所は次の表の通りです。
Expand
表2.1 デフォルトのログファイルの場所
ログファイル 場所 説明
boot.log $JDG_HOME/standalone/log/ サーバールートログ。サーバーの起動に関連するログメッセージが含まれます。
server.log $JDG_HOME/standalone/log/ サーバーログ。サーバー起動後のすべてのログメッセージが含まれます。
バグを報告する

2.4. ロギング属性
リンクのコピー

2.4.1. ログレベルについて
リンクのコピー

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

2.4.2. サポートされているログレベル
リンクのコピー

以表は JBoss Data Grid でサポートされるログレベルの一覧になります。ログレベル、ログレベルの値、および説明が記載されています。ログレベルの値は、他のログレベルに対して相対的な値になります。ネットワークが異なるとログレベルの名前が異なることがありますが、ログの値はこの一覧と一致します。
Expand
表2.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 発生したエラーの中で、現在のアクティビティや要求の完了を妨げる可能性があるが、アプリケーション実行の妨げにはならないエラーを表示するために使用されます。
FATAL 1100 重大なサービス障害やアプリケーションのシャットダウンをもたらしたり、JBoss Enterprise Application Platform 6 のシャットダウンを引き起こす可能性があるイベントを表示するのに使用されます。
バグを報告する

2.4.3. ログカテゴリーについて
リンクのコピー

ログカテゴリーは、キャプチャーするログメッセージのセットと、メッセージを処理する単一または複数のログハンドラーを定義します。
キャプチャーするログメッセージは、元の Java パッケージとログレベルによって定義されます。そのパッケージ内のクラスおよびそのログレベル以下のメッセージがログカテゴリーによってキャプチャーされ、指定のログハンドラーに送信されます。たとえば、DEBUG ログレベルでは、300、400、500 のログの値がキャプチャーされます。
ログカテゴリーは任意で独自のハンドラーの代わりにルートロガーのログハンドラーを使用することができます。
バグを報告する

2.4.4. ルートロガーについて
リンクのコピー

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

2.4.5. ログハンドラーについて
リンクのコピー

ログハンドラーは、キャプチャーされたログメッセージがどのように JBoss Data Grid によって記録されるかを定義します。JBoss Data Grid で設定可能な 6 種類のログハンドラーは次の通りです。
  • Console
  • File
  • Periodic
  • Size
  • Async
  • Custom
バグを報告する

2.4.6. ログハンドラーのタイプ
リンクのコピー

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

2.4.7. ログフォーマッターについて
リンクのコピー

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

2.5. ロギング設定プロパティー
リンクのコピー

2.5.1. ルートロガーのプロパティー
リンクのコピー

Expand
表2.4 ルートロガーのプロパティー
プロパティー データタイプ 説明
level 文字列
ルートロガーが記録するログメッセージの最大レベル。
handlers 文字列の一覧
ルートロガーによって使用されるログハンドラーの一覧。
バグを報告する

2.5.2. ログカテゴリーのプロパティ
リンクのコピー

Expand
表2.5 ログカテゴリーのプロパティ
プロパティー データタイプ 詳細
level 文字列
ログカテゴリーが記録するログメッセージの最大レベル。
handlers 文字列の一覧
ルートロガーによって使用されるログハンドラーの一覧。
use-parent-handlers ブール値
true に設定した場合、割り当てられた他のハンドラーだけでなく、ルートロガーのログハンドラーを使用します。
category 文字列
ログメッセージがキャプチャーされるログカテゴリー。
バグを報告する

2.5.3. コンソールログハンドラーのプロパティー
リンクのコピー

Expand
表2.6 コンソールログハンドラーのプロパティー
プロパティー データタイプ 説明
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
encoding 文字列
出力に使用される文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
target 文字列
ログハンドラーの出力先となるシステム出力ストリーム。これは システムエラーストリームの場合は System.err、標準出力ストリームの場合は System.out とすることができます。
autoflush ブール値
true に設定すると、ログメッセージは受信直後にハンドラーのターゲットに送信されます。
name 文字列
このログハンドラーの一意の ID。
バグを報告する

2.5.4. ファイルログハンドラープロパティー
リンクのコピー

Expand
表2.7 ファイルログハンドラープロパティー
プロパティー データタイプ 詳細
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
encoding 文字列
出力に使用される文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル (すでに存在する場合) に追加されます。false に設定された場合、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append に対する変更を反映するには、サーバーを再起動する必要があります。
autoflush ブール値
true に設定された場合は、受信直後にハンドラーにより割り当てられたファイルに送信されます。autoflush に対する変更を反映するには、サーバーを再起動する必要があります。
name 文字列
このログハンドラーの一意の ID。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。このオブジェクトには、relative-to と path の 2 つの設定プロパティーが含まれます。
relative-to 文字列
ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは、JBoss Enterprise Application Platform 6 のファイルパス変数を指定できます。jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを示します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために、relative-to プロパティーの値に追加されます。
バグを報告する

2.5.5. 周期ログハンドラープロパティー
リンクのコピー

Expand
表2.8 周期ログハンドラープロパティー
プロパティー データタイプ 説明
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル (すでに存在する場合) に追加されます。false に設定された場合、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append に対する変更を反映するには、サーバーを再起動する必要があります。
autoflush ブール値
true に設定された場合は、受信直後にハンドラーにより割り当てられたファイルに送信されます。autoflush に対する変更を反映するには、サーバーを再起動する必要があります。
encoding 文字列
出力に使用する文字エンコーディングスキーム
formatter 文字列
このログハンドラーで使用するログフォーマッター。
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
name 文字列
このログハンドラーの一意の ID。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。このオブジェクトには、relative-to と path の 2 つの設定プロパティーが含まれます。
relative-to 文字列
ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを示します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。完全パスを決定するために、relative-to プロパティーの値に追加される相対パス名です。
suffix 文字列
ローテーションされたログのファイル名に追加され、ローテーションの周期を決定するために使用される文字列です。この接尾辞の形式では、ドット (.) の後に、java.text.SimpleDateFormat クラスで解析できる日付文字列が指定されます。ログは接尾辞で定義された最小時間単位に基づいてローテーションされます。たとえば、接尾辞が .yyyy-MM-dd の場合は、毎日ログがローテーションされます。
http://docs.oracle.com/javase/6/docs/api/index.html?java/text/SimpleDateFormat.html を参照してください。
バグを報告する

2.5.6. サイズログハンドラープロパティー
リンクのコピー

Expand
表2.9 サイズログハンドラープロパティー
プロパティー データタイプ 説明
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル (すでに存在する場合) に追加されます。false に設定された場合、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append に対する変更を反映するには、サーバーを再起動する必要があります。
autoflush ブール値
true に設定された場合は、受信直後にハンドラーにより割り当てられたファイルに送信されます。autoflush に対する変更を反映するには、サーバーを再起動する必要があります。
encoding 文字列
出力に使用する文字エンコーディングスキーム
formatter 文字列
このログハンドラーで使用するログフォーマッター。
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
name 文字列
このログハンドラーの一意の ID。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。このオブジェクトには、relative-to と path の 2 つの設定プロパティーが含まれます。
relative-to 文字列
ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを示します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために、relative-to プロパティーの値に追加されます。
rotate-size 整数
ログファイルがローテーションされる前に到達可能な最大サイズ。数字に追加された単一の文字はサイズ単位を示します。バイトの場合は b、キロバイトの場合は k、メガバイトの場合は m、ギガバイトの場合は g になります。たとえば、50 メガバイトの場合は、50m になります。
max-backup-index 整数
保持されるローテーションログの最大数。この数字に達すると、最も古いログが再利用されます。
バグを報告する

2.5.7. 同期ログハンドラープロパティー
リンクのコピー

Expand
表2.10 同期ログハンドラープロパティー
プロパティー データタイプ 詳細
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
name 文字列
このログハンドラーの一意の ID。
Queue-length 整数
サブハンドラーが応答するときに、このハンドラーが保持するログメッセージの最大数。
overflow-action 文字列
キューの長さを超えたときにこのハンドラーがどのように応答するか。これは BLOCK または DISCARD に設定できます。BLOCK により、キューでスペースが利用可能になるまでロギングアプリケーションが待機します。これは、非同期でないログハンドラーと同じ動作です。DISCARD により、ロギングアプリケーションは動作し続けますが、ログメッセージは削除されます。
subhandlers 文字列の一覧
これは、この非同期ハンドラーがログメッセージを渡すログハンドラーの一覧です。
バグを報告する

2.6. ロギングの設定例
リンクのコピー

2.6.1. Root Logger の XML 設定例
リンクのコピー

<subsystem xmlns="urn:jboss:domain:logging:1.1">

   <root-logger>
      <level name="INFO"/>
      <handlers>
         <handler name="CONSOLE"/>
         <handler name="FILE"/>
      </handlers>
   </root-logger>

</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する

2.6.2. ログカテゴリーの XML 設定例
リンクのコピー

<subsystem xmlns="urn:jboss:domain:logging:1.1">

   <logger category="com.company.accounts.rec">
      <handlers>
         <handler name="accounts-rec"/>
      </handlers>
   </logger>

</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する

2.6.3. コンソールログハンドラーの XML 設定例
リンクのコピー

<subsystem xmlns="urn:jboss:domain:logging:1.1">

   <console-handler name="CONSOLE">
      <level name="INFO"/>
      <formatter>
         <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
      </formatter>
   </console-handler>

</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する

2.6.4. ファイルログハンドラーの XML 設定例
リンクのコピー

<file-handler name="accounts-rec-trail" autoflush="true">
    <level name="INFO"/>
    <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/>
    <append value="true"/>
</file-handler>
Copy to Clipboard Toggle word wrap
バグを報告する

2.6.5. 定期ログハンドラーの XML 設定例
リンクのコピー

<periodic-rotating-file-handler name="FILE">
   <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
バグを報告する

2.6.6. サイズログハンドラーの XML 設定例
リンクのコピー

<size-rotating-file-handler name="accounts_debug" autoflush="false">
   <level name="DEBUG"/>
   <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
   <rotate-size value="500k"/>
   <max-backup-index value="5"/>
   <append value="true"/>
</size-rotating-file-handler>
Copy to Clipboard Toggle word wrap
バグを報告する

2.6.7. 非同期ログハンドラーの XML 設定例
リンクのコピー

<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
バグを報告する

第3章 サーバーヒンティングを用いた高可用性
リンクのコピー

3.1. サーバーヒンティングについて
リンクのコピー

JBoss Data Grid では、サーバーヒンティングによってデータのバックアップコピーが元データと同じ物理サーバー、ラック、またはデータセンター上に保存されないようにします。トータルレプリケーションはすべてのサーバー、ラックおよびデータセンター上で完全なレプリカの作成を強制するため、サーバーヒンティングはトータルレプリケーションには適用されません。
サーバーヒンティングは、JBoss Data Grid 実装の高可用性を確実に実現する場合に特に重要になります。
バグを報告する

3.2. JGroups によるサーバーヒンティングの確立
リンクのコピー

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

関連トピック:

バグを報告する

3.3. リモートクライアントサーバーモードでのサーバーヒンティングの設定
リンクのコピー

JBoss Data Grid のリモートクライアントサーバーモードでは、次のようにサブシステムタグを使用してサーバーヒンティングが設定されます。 
<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
バグを報告する

3.4. ライブラリモードでのサーバーヒンティングの設定
リンクのコピー

JBoss Data Grid のライブラリモードでは、トランスポートレベルでサーバーヒンティングが設定されます。以下はサーバーヒンティングの設定例になります。 
<transport clusterName = "MyCluster"
           machineId = "LinuxServer01"
           rackId = "Rack01"
           siteId = "US-WestCoast" />
Copy to Clipboard Toggle word wrap
設定例の通り、次の設定属性が使用して JBoss Data Grid にサーバーヒンティングを設定します。
  • clusterName 属性はクラスターへ割り当てられた名前を指定します。
  • machineId 属性は、元データを格納する JVM インスタンスを指定します。複数の JVM があるノードや複数の仮想ホストを持つ物理ホストに対して有用な属性です。
  • rackId パラメーターは、元データが含まれるラックを指定します。これにより、別のラックがバックアップに使用されるようにします。
  • siteId パラメーターは、相互にレプリケーションを行っている異なるデータセンターのノードを区別します。
JBoss Data Grid の設定では前述のパラメーターの設定は任意ですが、サーバーヒンティングが設定されていない場合、JBoss Data Grid の分散アルゴリズムにより元データと同じノード、データセンターまたはラックにレプリケーションを保存することが許可されます。
バグを報告する

第4章 キャッシュモード
リンクのコピー

4.1. キャッシュモードについて
リンクのコピー

JBoss Data Grid には 2 つモードがあります。
  • ローカル (スタンドアロン) モード
  • クラスターモード
バグを報告する

4.2. ローカルモード
リンクのコピー

4.2.1. ローカルモードについて
リンクのコピー

ローカルモードは、JBoss Data Grid 唯一のクラスターキャッシュモードではないモードです。ローカルモードの JBoss Data Grid は、JBoss Cache や EHCache のように、簡単なインメモリデータキャッシュとして操作します。
バグを報告する

4.2.2. ローカルモードの操作
リンクのコピー

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

4.2.3. ローカルモードの設定
リンクのコピー

ローカルキャッシュはすべてのキャッシュコンテナに追加できます。例は次の通りです。 
<cache-container name="local" 
		 default-cache="default"
 		 listener-executor="infinispan-listener">
	<local-cache name="default" 
		     start="EAGER">
		<locking isolation="NONE" 
			 acquire-timeout="30000"
			 concurrency-level="1000" 
			 striping="false" />
		<transaction mode="NONE" />
	</local-cache>
</cache-container>
Copy to Clipboard Toggle word wrap
この代わりに、引数のないコンストラクターで DefaultCacheManager を作成することもできます。どちらの方法でも、ローカルのデフォルトキャッシュが作成されます。
ローカルキャッシュとクラスター化されたキャッシュは同じキャッシュコンテナで共存できますが、コンテナに <transport/> がない場合はローカルキャッシュのみ格納できます。例で使用されたコンテナには <transport/> がないため、ローカルキャッシュのみを格納できます。
キャッシュインターフェースは ConcurrentMap を拡張し、複数のキャッシュシステムと互換性があります。
バグを報告する

4.3. クラスターモード
リンクのコピー

4.3.1. クラスターモードについて
リンクのコピー

JBoss Data Grid は、ステートの変更をノードの小型のサブセットにレプリケートするクラスターモードを提供します。サブセットのサイズは、フォールトトラレンスを実現するには十分なサイズですが、スケーラビリティーを妨げるほど大きくはありません。クラスターモードを使用する前に、クラスター化された設定に対して JGroup を設定することが重要です。

関連トピック:

バグを報告する

4.3.2. クラスターモードの操作
リンクのコピー

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

4.3.3. 非同期および同期の操作
リンクのコピー

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

4.3.4. キャッシュモードのトラブルシューティング
リンクのコピー

4.3.4.1. ReadExternal の無効なデータ
リンクのコピー
Cache.putAsync() を使用する場合、シリアライズを開始するとオブジェクトが変更される可能性があります。それによってデータストリームが破損されると、無効なデータが readExternal に渡されます。このような場合、オブジェクトへのアクセスを同期化すると、この問題を解決することができます。
バグを報告する
4.3.4.2. 非同期通信について
リンクのコピー
JBoss Data Grid では、ローカルモードは local-cache によって表され、分散されたモードは distributed-cache、レプリケートされたモードは replicated-cache によって表されます。これらの各要素には、mode プロパティーが含まれ、同期通信の場合は SYNC、非同期通信の場合は SYNC に値を設定することができます。
設定例は次の通りです。 
<replicated-cache name="default" 
                  start="EAGER"
                  mode="SYNC"    
                  batching="false" >
                 ...
</replicated-cache>
Copy to Clipboard Toggle word wrap

注記

この設定は、JBoss Data Grid の両方の使用モード (ライブラリーモードとリモートクライアントサーバーモード) に対して有効です。
バグを報告する
4.3.4.3. クラスター物理アドレスの読み出し
リンクのコピー
クラスターの物理アドレスの読み出し方法

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

バグを報告する

第5章 ディストリビューションモード
リンクのコピー

5.1. ディストリビューションモードについて
リンクのコピー

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

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

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

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

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

5.4. ディストリビューションモードの戻り値
リンクのコピー

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

5.5. ディストリビューションモードの設定
リンクのコピー

ディストリビューションモードは JBoss Data Grid のクラスターモードの 1 つです。以下を使用してディストリビューションモードをすべてのキャッシュコンテナへ追加することができます。 
<cache-container name="local" 
		 default-cache="default"
 		 listener-executor="infinispan-listener">
	<distributed-cache name="default" 
		     start="EAGER">
		<locking isolation="NONE" 
			 acquire-timeout="30000"
			 concurrency-level="1000" 
			 striping="false" />
		<transaction mode="NONE" />
	</distributed-cache>
</cache-container>
Copy to Clipboard Toggle word wrap

重要

この設定をロードする前に、JGroups をクラスターモードに対して適切に設定する必要があります。

関連トピック:

バグを報告する

5.6. 同期および非同期の分散
リンクのコピー

5.6.1. 同期および非同期の分散について
リンクのコピー

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

例5.1 通信モードの例

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

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

5.7.1. ディストリビューションモードの GET および PUT 操作について
リンクのコピー

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

5.7.2. 分散された GET および PUT 操作
リンクのコピー

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

第6章 レプリケーションモード
リンクのコピー

6.1. レプリケーションモードについて
リンクのコピー

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

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

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

6.3. レプリケーションモードの戻り値
リンクのコピー

JBoss Data Grid のレプリケーションモードでは、レプリケーションが発生する前にローカルで戻り値を使用できます。
バグを報告する

6.4. レプリケーションモードの設定
リンクのコピー

レプリケーションモードは JBoss Data Grid のクラスターキャッシュモードです。以下を使用すると、レプリケーションモードをキャッシュコンテナに追加することができます。 
<cache-container name="local" 
		 default-cache="default"
 		 listener-executor="infinispan-listener">
	<replicated-cache name="default" 
		     start="EAGER">
		<locking isolation="NONE" 
			 acquire-timeout="30000"
			 concurrency-level="1000" 
			 striping="false" />
		<transaction mode="NONE" />
	</replicated-cache>
</cache-container>
Copy to Clipboard Toggle word wrap

重要

この設定をロードする前に、JGroups をクラスターモードに対して適切に設定する必要があります。

関連トピック:

バグを報告する

6.5. 同期および非同期のレプリケーション
リンクのコピー

6.5.1. 同期および非同期のレプリケーション
リンクのコピー

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

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

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

6.6. レプリケーションキュー
リンクのコピー

6.6.1. レプリケーションキュー
リンクのコピー

レプリケーションモードでは、以下を基にして、JBoss Data Grid はレプリケーションキューを使用しノード全体で変更をレプリケートします。
  • 以前設定された間隔。
  • 要素数を越えるキューサイズ。
  • 以前設定された間隔と要素数を越えるキューサイズの組み合わせ。
レプリケーションキューは、レプリケート中にキャッシュ操作が個別に送信されるのではなく、一括送信されるようにします。そのため、送信されるレプリケーションメッセージの数が減り、使用されるエンベロープも少なくなるため、JBoss Data Grid のパフォーマンスが向上します。
レプリケーションキューは非同期モードと共に使用されます。
バグを報告する

6.6.2. レプリケーションキューの操作
リンクのコピー

レプリケーションキューを使用する場合の主な難点は、時間やキューサイズを基にキューが周期的にフラッシュされることです。このようなフラッシュ操作は、クラスターノード全体のレプリケーション、分散、または無効化の操作を遅延します。レプリケーションキューを無効にすると、データは直接送信されるため、クラスターノードへ達する時間が短くなります。
バグを報告する

6.6.3. レプリケーションキューの使用
リンクのコピー

レプリケーションキューを使用する場合、以下の 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"
                  queue-size="1000"
                  queue-flush-interval="500">   
               ...
</replicated-cache>
Copy to Clipboard Toggle word wrap
レプリケーションキューにより、要求がクライアントへ返されるまでの時間が短縮されるため、レプリケーションキューを非同期マーシャリングと共に使用しても大きな利点はありません。
バグを報告する

6.7. よくある質問
リンクのコピー

6.7.1. レプリケーション保証について
リンクのコピー

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

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

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

第7章 インバリデーションモード
リンクのコピー

7.1. インバリデーションモードについて
リンクのコピー

無効化はクラスターモードで、データを共有しませんが、リモートキャッシュの潜在的に古いデータを削除します。このキャッシュモードを使用するには、データベースなど更に永久的なデータストアが別に必要になります。
バグを報告する

7.2. インバリデーションモードの使用
リンクのコピー

インバリデーションモードにはデータベースなど、2 つ目のデータの永久ストアが必要になります。このような場合では、JBoss Data Grid は読み取りの多いシステムを最適化するために使用され、ステートが必要となる度にデータベースが使用されないようにします。
インバリデーションモードが使用されている場合、キャッシュのデータが変更になると、クラスターの他のキャッシュが古いデータをメモリーからエビクトします。
バグを報告する

7.3. インバリデーションモードの設定
リンクのコピー

インバリデーションモードは JBoss Data Grid のクラスターモードです。以下を使用すると、レプリケーションモードをキャッシュコンテナに追加することができます。 
<cache-container name="local" 
		 default-cache="default"
 		 listener-executor="infinispan-listener">
	<invalidated-cache name="default" 
		     start="EAGER">
		<locking isolation="NONE" 
			 acquire-timeout="30000"
			 concurrency-level="1000" 
			 striping="false" />
		<transaction mode="NONE" />
	</invalidated-cache>
</cache-container>
Copy to Clipboard Toggle word wrap

重要

この設定をロードする前に、JGroups をクラスターモードに対して適切に設定する必要があります。

関連トピック:

バグを報告する

7.4. 同期的 / 非同期的な無効化
リンクのコピー

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

7.5. 1 次キャッシュの無効化
リンクのコピー

7.5.1. 1 次キャッシュと無効化
リンクのコピー

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

第8章 キャッシュ書き込みモード
リンクのコピー

8.1. ライトスルーおよびライトビハインドキャッシング
リンクのコピー

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

8.2. ライトスルーキャッシング
リンクのコピー

8.2.1. ライトスルーキャッシングについて
リンクのコピー

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

8.2.2. ライトスルーキャッシングの利点
リンクのコピー

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

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

ライトスルーまたは同期キャッシュストアの設定には、特別な設定操作は必要ありません。すべてのキャッシュストアは、明示的にライトビハインドまたは非同期とマーク付けされていない限り、ライトスルーまたは同期になります。ライトスルーの共有されないローカルファイルキャッシュストアの設定ファイル例は次の通りです。 
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xmlns="urn:infinispan:config:5.0">
	<global />
	<default />
	<namedCache name="persistentCache">
		<loaders shared="false">
			<loader class="org.infinispan.loaders.file.FileCacheStore" 
	       			fetchPersistentState="true" ignoreModifications="false"
	       			purgeOnStartup="false">
				<properties>
					<property name="location" 
						  value="${java.io.tmpdir}" />
				</properties>
			</loader>
		</loaders>
  	</namedCache>
</infinispan>
Copy to Clipboard Toggle word wrap
バグを報告する

8.3. ライトビハインドキャッシング
リンクのコピー

8.3.1. ライトビハインドキャッシングについて
リンクのコピー

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

8.3.2. ライトビハインドキャッシングの設定
リンクのコピー

キャッシュストアにライトビハインドキャッシングを設定するには、write-behind 要素をキャッシュストアに追加します。以下は、write-behind 要素をリモートキャッシュストアの設定に追加する例になりますが、他のキャッシュストアタイプの場合でも同様になります。 
<remote-store cache="default" 
              socket-timeout="60000" 
              tcp-no-delay="true" 
              fetch-state="false" 
              passivation="true" 
              preload="true" 
              purge="false">
	<remote-server outbound-socket-binding="remote-store-hotrod-server" />
	<write-behind flush-lock-timeout="1" 
                      modification-queue-size="1024" 
                      shutdown-timeout="25000" 
                      thread-pool-size="1" />
</remote-store>
Copy to Clipboard Toggle word wrap

注記

この設定は、JBoss Data Grid のリモートクライアントサーバーモードでのみ使用されます。
バグを報告する

8.3.3. スケジュール外のライトビハインドストラテジーについて
リンクのコピー

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

8.3.4. スケジュール外のライトビハインドストラテジーのライブラリー設定
リンクのコピー

以下は、JBoss Data Grid のライブラリーモードにおけるスケジュール外のライトビハインドストラテジーの設定ファイル例になります。 
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xmlns="urn:infinispan:config:5.0">
	<global />
	<default />
	<namedCache name="persistentCache">
		<loaders shared="false">
			<loader class="org.infinispan.loaders.file.FileCacheStore" 
				fetchPersistentState="true" 
				ignoreModifications="false"
				purgeOnStartup="false">
				<properties>
					<property name="location" 
						  value="${java.io.tmpdir}" />
				</properties>
				<async enabled="true" threadPoolSize="10" />
			</loader>
		</loaders>
	</namedCache>
</infinispan>
Copy to Clipboard Toggle word wrap
ライトビハインドの設定は、この設定の以下の行で設定されます。 
<async enabled="true" threadPoolSize="10" />
Copy to Clipboard Toggle word wrap
バグを報告する

8.3.5. スケジュール外のライトビハインドストラテジーのリモート設定
リンクのコピー

file-store 要素内に write-behind を追加すると、スケジュール外のライトビハインドストラテジーの設定がすべてのキャッシュストアに対して許可されます。
以下は、JBoss Data Grid のリモートクライアントサーバーモードにおけるスケジュール外のライトビハインドストラテジーの設定ファイル例になります。 
<file-store passivation="true" 
	    relative-to="temp" 
	    path="nc" 
	    purge="true" 
	    shared="false">
	<write-behind flush-lock-timeout="1" 
		      modification-queue-size="1024" 
		      shutdown-timeout="25000" 
		      thread-pool-size="1"/>
</file-store>
Copy to Clipboard Toggle word wrap
バグを報告する

第9章 ロック
リンクのコピー

9.1. 楽観的ロックについて
リンクのコピー

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

9.2. 悲観的ロックについて
リンクのコピー

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

9.3. 悲観的ロックのタイプ
リンクのコピー

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

9.4. 明示的な悲観的ロックの例
リンクのコピー

以下は、キャッシュノードの 1 つで実行されるトランザクションの明示的な悲観的ロックの例になります。 
tx.begin()
cache.lock(K)           
cache.put(K,V5)         
tx.commit()
Copy to Clipboard Toggle word wrap
行 cache.lock(K) が実行されると、K でクラスターワイドのロックが取得されます。
行 cache.put(K,V5) が実行されると、取得の成功が保証されます。
行 tx.commit() が実行されると、この処理のために保持されたロックが開放されます。
バグを報告する

9.5. 暗黙的な悲観的ロックの例
リンクのコピー

以下は、キャッシュノードの 1 つで実行されるトランザクションを使用する暗黙的な悲観的ロックの例になります。 
tx.begin()
cache.put(K,V)
cache.put(K2,V2)
cache.put(K,V5)
tx.commit()
Copy to Clipboard Toggle word wrap
  • 行 cache.put(K,V) が実行されると、K でクラスターワイドのロックが取得されます。
  • 行 cache.put(K2,V2) が実行されると、K2 でクラスターワイドのロックが取得されます。
  • 行 cache.put(K,V5) が実行されると、 K のクラスターワイドのロックは以前取得されたため、ロックの取得は実行できませんが、put 操作は発生します。
  • 行 tx.commit() が実行されると、このトランザクションのために保持されたすべてのロックが開放されます。
バグを報告する

9.6. 楽観的ロックと悲観的ロックの設定
リンクのコピー

JBoss Data Grid でロックモードを設定するには、transaction 要素内に locking パラメーターを使用します。
楽観的ロック

次のように楽観的ロックを設定します。 

<transaction locking="OPTIMISTIC" />
Copy to Clipboard Toggle word wrap
悲観的ロック

次のように悲観的ロックを設定します。 

<transaction locking="PESSIMISTIC" />
Copy to Clipboard Toggle word wrap
バグを報告する

9.7. ロック操作
リンクのコピー

9.7.1. LockManager について
リンクのコピー

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

関連トピック:

バグを報告する

9.7.2. ロックの取得について
リンクのコピー

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

9.7.3. 平行性レベルについて
リンクのコピー

JBoss Data Grid では、平行性レベルがストライピングされたロックコンテナのサイズを決定します。さらに、平行性レベルは DataContainers 内部のコレクションなど、関連するすべての JDK ConcurrentHashMap ベースのコレクションを調整します。
バグを報告する

9.8. ロックストライピング
リンクのコピー

9.8.1. ロックストライピングについて
リンクのコピー

ロックストライピングは、キャッシュにあるロック (固定サイズ) の共有コレクションよりロックを割り当てます。ロック割り当ては各エントリーのキーに対するハッシュコードが基になります。ロックストライピングは、オーバーヘッドが固定された非常にスケーラブルなロックメカニズムを提供しますが、同じロックによって無関連なエントリーがブロックされる可能性があります。
JBoss Data Grid では、ロックストライピングはデフォルトで無効になっています。無効の場合、各エントリーに対して新しいロックが作成されます。
バグを報告する

9.8.2. ロックストライピングの設定
リンクのコピー

JBoss Data Grid のロックストライピングを有効にするには、striping 要素を true に設定します。
例は次の通りです。 
<locking isolation="REPEATABLE_READ"
	 acquire-timeout="20000"
	 concurrency-level="500"
	 striping="true" />
Copy to Clipboard Toggle word wrap
バグを報告する

9.8.3. ロックストライピングの代替
リンクのコピー

JBoss Data Grid のロックストライピングが無効になっていると、各エントリーに対して新しいロックが作成されます。この代替の方法を用いると、より大きな平行スループットが提供されますが、メモリーの追加使用やガベージコレクションのチャーンなどのデメリットも発生します。
バグを報告する

9.8.4. 共有ロックコレクションのサイズ設定
リンクのコピー

JBoss Data Grid では、ロックストライピングがデフォルトで無効になっています。ロックストライピングによって使用される共有ロックコレクションのサイズは、locking 設定要素の平行性レベル属性を使用して調整することができます。
バグを報告する

9.9. 分離レベル
リンクのコピー

9.9.1. 分離レベルについて
リンクのコピー

分離レベルは、リーダーが平行書き込みを見ることができるタイミングを決定します。JBoss Data Grid で提供される分離モードは READ_COMMITTED と REPEATABLE_READ の 2 つです。
  • READ_COMMITTED は、幅広い要件に適用できるデフォルトの分離レベルです。
  • REPEATABLE_READ は locking 設定要素を使用して設定できます。
バグを報告する

9.9.2. READ_COMMITTED について
リンクのコピー

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

9.9.3. REPEATABLE_READ について
リンクのコピー

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

第10章 キャッシュストアとキャッシュローダー
リンクのコピー

10.1. キャッシュストアについて
リンクのコピー

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

10.2. ファイルシステムベースのキャッシュストアについて
リンクのコピー

JBoss Data Grid には、ファイルシステムベースのキャッシュストアの 1 つである FileCacheStore が含まれています。
FileCacheStore はシンプルなファイルシステムベースの実装です。
FileCacheStore には制限があるため、実稼働環境では制限内での使用が可能です。適切なファイルロックがなく、データが破損する原因となるため、共有ファイルシステム (NFS や Windows の共有など) 上では使用しないでください。また、ファイルシステムは本質的にトランザクションではないため、トランザクションコンテキストでキャッシュが使用されると、コミットフェーズ中にファイルが障害を書き込む原因となります。
FileCacheStore はテストでの使用に適していますが、高度な平行性やトランザクション、ストレスベースの環境における使用には適していません。
バグを報告する

10.3. ファイルキャッシュストアの設定
リンクのコピー

ファイルキャッシュストアの設定例は次の通りです。 
<local-cache name="default">
    <file-store />
</local-cache>
Copy to Clipboard Toggle word wrap
  • キャッシュの名前を指定するため、local-cache 属性の name パラメーターが使用されます。
  • file-store 要素はファイルキャッシュストアの設定情報を指定します。この要素の属性には、名前付きパスを定義するために使用される relative-to パラメーターや、relative-to 内のディレクトリを指定するために使用される path パラメーターが含まれます。
バグを報告する

10.4. リモートキャッシュストア
リンクのコピー

10.4.1. リモートキャッシュストアについて
リンクのコピー

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

10.4.2. リモートキャッシュストアの設定 （リモートクライアントサーバーモード)
リンクのコピー

JBoss Data Grid のリモートクライアントサーバーモードにおけるリモートキャッシュストアの設定例は次の通りです。 
<remote-store cache="default" 
	      socket-timeout="60000" 
              tcp-no-delay="true" 
              fetch-state="false" 
              passivation="true" 
              preload="true" 
              purge="false">
	<remote-server outbound-socket-binding="remote-store-hotrod-server" />
</remote-store>
Copy to Clipboard Toggle word wrap
バグを報告する

10.4.3. リモートキャッシュストアの設定 （ライブラリモード)
リンクのコピー

前提条件

hotrod.properties という名前のファイルを作成し、関連するクラスパスに含まれるようにします。

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

JBoss Data Grid のライブラリモードにおけるリモートキャッシュストアの設定例は次の通りです。 

<loaders shared="true" 
	 preload="true" 
	 purge="false">
	<loader class="org.infinispan.loaders.remote.RemoteCacheStore">
		<properties>
			<property name="remoteCacheName" 
				  value="default"/>
			<property name="hotRodClientPropertiesFile" 
				  value="hotrod.properties" />
		</properties>
	</loader>
</loaders>
Copy to Clipboard Toggle word wrap

重要

この設定を使用する場合、リモートキャッシュストアのアウトバウンドソケットを定義します。適切に hotRodClientPropertiesFile と命名されたリモートキャッシュストアは、hotrod.properties ファイルを参照します。適切に操作するには、このファイルをリモートキャッシュストアに対して定義する必要があります。
バグを報告する

10.4.4. リモートキャッシュストア設定の属性
リンクのコピー

リモートキャッシュ設定に固有する設定要素は次の通りです。
リモートストア要素

remote-store 要素は、Hot Rod を使用してアクセスされるリモートキャッシュストアの設定情報を指定します。remote-store 要素内に定義されるプロパティーは Hot Rod のクライアントプロパティーとして処理されます。

  • cache パラメーターは使用されているキャッシュの名前を指定します。
  • socket-timeout パラメーターは、リモートキャッシュのソケットタイムアウトの時間を指定します。
  • tcp-no-delay パラメーターは、TCP パケットが遅延され一括して送信されるかを指定します。このパラメーターの有効な値は true と false になります。
  • fetch-state パラメーターは、クラスターへ参加する時に永続ステートが取り込まれるかを決定します。このパラメーターの有効な値は true と false になります。
  • passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
  • preload パラメーターは、起動中にエントリーをキャッシュにロードするかを指定します。このパラメーターの有効な値は true と false になります。
  • purge パラメーターは、キャッシュストアの起動時にキャッシュストアがパージされるかどうかを指定します。このパラメーターの有効な値は true と false になります。
リモートサーバー要素

remote-server 要素はリモートキャッシュストアによって使用されるリモートサーバーに関する情報を提供します。

  • outbound-socket-binding パラメーターは、リモートキャッシュストアのアウトバウンドソケットを指定します。

重要

リモートキャッシュストアを使用するには、リモートキャッシュストアのアウトバウンドソケットを standalone.xml ファイルにも定義します。
バグを報告する

10.4.5. hotrod.properties ファイル
リンクのコピー

リモートキャッシュストアの設定を使用するには、hotrod.properties ファイルを作成し、リモートキャッシュストアの設定に関連するクラスパスに含まれるようにする必要があります。
hotrod.properties ファイルにはプロパティーが １ つ以上含まれます。最も単純な hotrod.properties ファイルには以下が含まれます。 
infinispan.client.hotrod.server_list=remote-server:11222
Copy to Clipboard Toggle word wrap
hotrod.properties に含めることができるプロパティーは次の通りです。
infinispan.client.hotrod.request_balancing_strategy
レプリケートされた Hot Rod サーバークラスターでは、このストラテジーに従ってクライアントがサーバーへの要求のバランスを取ります。
このプロパティーのデフォルト値は org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy です。
infinispan.client.hotrod.server_list
接続する Hot Rod サーバーの初期リストです。「host1:port1;host2:port2」 のような形式で指定されます。最低でも 1 つの host:port を指定する必要があります。
このプロパティーのデフォルト値は 127.0.0.1:11222 です。
infinispan.client.hotrod.force_return_values
すべての呼び出しに対して暗黙的に Flag.FORCE_RETURN_VALUE を行うかどうか。
このプロパティーのデフォルト値は false です。
infinispan.client.hotrod.tcp_no_delay
TCP スタックの TCP NODELAY に影響します。
このプロパティーのデフォルト値は true です。
infinispan.client.hotrod.ping_on_startup
true の場合、クラスターのトポロジーを取り込むため、ping リクエストがバックエンドサーバーへ送信されます。
このプロパティーのデフォルト値は true です。
infinispan.client.hotrod.transport_factory
使用されるトランスポートを制御します。現在、TcpTransport のみがサポートされます。
このプロパティーのデフォルト値は org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory です。
infinispan.client.hotrod.marshaller
ユーザーオブジェクトをシリアライズおよびデシリアライズするため、カスタムマーシャラーの実装を指定できるようにします。
このプロパティーのデフォルト値は org.infinispan.marshall.jboss.GenericJBossMarshaller です。
infinispan.client.hotrod.async_executor_factory
非同期呼び出しのカスタム非同期エクゼキューターを指定できるようにします。
このプロパティーのデフォルト値は org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory です。
infinispan.client.hotrod.default_executor_factory.pool_size
デフォルトのエクゼキューターが使用される場合、エクゼキューターを初期化するスレッド数を設定します。
このプロパティーのデフォルト値は 10 です。
infinispan.client.hotrod.default_executor_factory.queue_size
デフォルトのエクゼキューターが使用される場合、エクゼキューターを初期化するキューサイズを設定します。
このプロパティーのデフォルト値は 100000 です。
infinispan.client.hotrod.hash_function_impl.1
ハッシュ関数のバージョンと使用中の一貫したハッシュアルゴリズムを指定します。使用される Hot Rod サーバーのバージョンと密接に関係しています。
このプロパティーのデフォルト値は Hash function specified by the server in the responses as indicated in ConsistentHashFactory です。
infinispan.client.hotrod.key_size_estimate
このヒントは、キーをシリアライズおよびデシリアライズする時にアレイのサイズ変更を最小限にするため、バイトバッファーのサイズを設定できるようにします。
このプロパティーのデフォルト値は 64 です。
infinispan.client.hotrod.value_size_estimate
このヒントは、値をシリアライズおよびデシリアライズする時にアレイのリサイズを最小限にするため、バイトバッファーをサイジングできるようにします。
このプロパティーのデフォルト値は 512 です。
infinispan.client.hotrod.socket_timeout
このプロパティーは、サーバーからのバイト待ちを断念する前の最大ソケット読み取りタイムアウトを定義します。
The default value for this property is 60000 (equals 60 seconds).
infinispan.client.hotrod.protocol_version
このプロパティーは、クライアントが使用する必要があるプロトコルのバージョンを定義します。他の有効値には 1.0 が含まれます。
このプロパティーのデフォルト値は 1.1 です。
infinispan.client.hotrod.connect_timeout
このプロパティーは、サーバーへの接続を断念する前の最大ソケット接続タイムアウトを定義します。
The default value for this property is 60000 (equals 60 seconds).
バグを報告する

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

リモートキャッシュストアによって使用される Hot Rod サーバーは、standalone.xml ファイルの outbound-socket-binding 要素を使用して定義されます。
standalone.xml ファイルにおけるこの設定の例は次の通りです。 
<outbound-socket-binding name="remote-store-hotrod-server">
	<remote-destination host="127.0.0.1" 
			    port="11322"/>
</outbound-socket-binding>
Copy to Clipboard Toggle word wrap
バグを報告する

10.5. JDBC ベースのキャッシュストア
リンクのコピー

10.5.1. JDBC ベースのキャッシュストアについて
リンクのコピー

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

10.5.2. JDBC キャッシュの選択
リンクのコピー

JdbcStringBasedCacheStore はストレス下でより優れたスループットを提供するため、キータイプを制御する場合に適しています。
JdbcStringBasedCacheStore は、Key2StringMapper を書いてキーを文字列オブジェクトにマップできる場合のみ使用することができます。JdbcStringBasedCacheStore を使用できない場合、JdbcBinaryCacheStore または JdbcMixedCacheStore を代わりに使用できます。JdbcStringBasedCacheStore がほとんどのキーを処理し、Key2StringMapper を使用して一部のキーを変換できない場合に JdbcMixedCacheStore を使用するのがよいでしょう。
バグを報告する

10.5.3. JdbcBinaryCacheStores
リンクのコピー

10.5.3.1. JdbcBinaryCacheStore について
リンクのコピー
JdbcBinaryCacheStore はすべてのキータイプをサポートします。同じテーブル行/Blob の同じハッシュ値 (キー上の hashCode メソッド) を持つすべてのキーを格納します。含まれるキーに共通するハッシュ値が、テーブルの行/Blob の主キーとして設定されます。このハッシュ値により、JdbcBinaryCacheStore は大変優れた柔軟性を提供しますが、平行性とスループットが犠牲になります。
例えば、3 つのキー (k1、k2、k3) のハッシュコードが同じである場合、同じテーブル行に格納されます。3 つの異なるスレッドが k1、k2、k3 を同時に更新しようとすると、すべてのキーが同じ行を共有するため同時には更新できないため、順次更新する必要があります。
バグを報告する
10.5.3.2. パッシベーションを有効にした JdbcBinaryCacheStore リモート設定
リンクのコピー
以下の設定は、Boss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcBinaryCacheStore の設定です。 
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="default" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<local-cache name="default"
			     start="EAGER"
			     batching="false"
			     indexing="NONE">
			<locking isolation="REPEATABLE_READ"
				 acquire-timeout="20000"
				 concurrency-level="500"
				 striping="false" />
			<transaction mode="NONE" />
			<eviction strategy="LRU" 
				  max-entries="2" />
			<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
						 passivation="true" 
						 preload="false" 
						 purge="false">
                        	<property name="databaseType">${database.type}</property>
                        	<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>
	</cache-container>
</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する
10.5.3.3. パッシベーションを無効にした JdbcBinaryCacheStore リモート設定
リンクのコピー
以下の設定は、Boss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを無効にした JdbcBinaryCacheStore の設定です。 
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="default" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<local-cache name="default"
			     start="EAGER"
                    	     batching="false"
                    	     indexing="NONE">
                	<locking isolation="REPEATABLE_READ"
				 acquire-timeout="20000"
				 concurrency-level="500"
				 striping="false" />
			<transaction mode="NONE" />
			<binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
						 passivation="false" 
						 preload="true" 
						 purge="false">
                       	<property name="databaseType">${database.type}</property>
                        	<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>
	</cache-container>
</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する
10.5.3.4. JdbcBinaryCacheStore リモート設定の属性
リンクのコピー
JBoss Data Grid のリモートクライアントサーバーモードで JdbcBinaryCacheStore を設定するために使用される要素とパラメーターの一覧は次の通りです。
cache-container 要素

cache-container 要素は、次のパラメーターを使用してキャッシュコンテナに関する情報を指定します。

  • name パラメーターはキャッシュコンテナの名前を定義します。
  • default-cache パラメーターは、キャッシュコンテナと共に使用されるデフォルトキャッシュの名前を定義します。
  • listener-executor は非同期キャッシュリスナーの通知に使用されるエクゼキューターを定義します。
  • start パラメーターはキャッシュコンテナが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
local-cache 要素

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

  • name パラメーターは使用するローカルキャッシュの名前を指定します。
  • start パラメーターはキャッシュが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
  • batching パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。
  • indexing パラメーターはローカルキャッシュに使用される索引作業のタイプを指定します。このパラメーターの有効な値は NONE、 LOCAL、および ALL です。
locking 要素

locking 要素はローカルキャッシュのロック設定を指定します。

  • isolation パラメーターはローカルキャッシュに使用される分離レベルを定義します。このパラメーターに有効な値は REPEATABLE_READ と READ_COMMITTED です。
  • acquire-timeout パラメーターは取得した操作がタイムアウトするミリ秒単位の値を指定します。
  • concurrency-level パラメーターは LockManager によって使用されるロックストライプの数を定義します。
  • striping パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
transaction 要素

transaction 要素はローカルキャッシュのトランザクション関連の設定を指定します。

  • mode パラメーターはローカルキャッシュに使用されるトランザクションモードを指定します。このパラメーターの有効な値は NONE、 NON_XA (XAResource を使用しない)、 NON_DURABLE_XA (リカバリーを用いずに XAResource を使用する) および FULL_XA (リカバリーを用いて XAResource を使用する) です。
eviction 要素

eviction 要素はローカルキャッシュのエビクション設定情報を指定します。

  • strategy パラメーターは使用されるエビクションストラテジーやアルゴリズムを指定します。このパラメーターの有効な値には NONE、 FIFO、 LRU、 UNORDERED、 LIRS などがあります。
  • max-entries パラメーターはキャッシュインスタンスにおけるエントリーの最大数を指定します。
binary-keyed-jdbc-store 要素

binary-keyed-jdbc-store 要素は、バイナリのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。

  • datasource パラメーターはデータソースの JNDI 名を定義します。
  • passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
  • preload パラメーターは、起動中にエントリーをキャッシュにロードするかを指定します。このパラメーターの有効な値は true と false になります。
  • purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値は true と false です。
property 要素

property 要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。

  • name パラメーターはキャッシュストアの名前を指定します。
  • ${database.type} を有効なデータベースタイプの値 (DB2_390、 SQL_SERVER、 MYSQL、 ORACLE、 POSTGRES、 SYBASE など) に置き換える必要があります。
binary-keyed-table 要素

binary-keyed-table 要素は、バイナリのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。

  • prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
id-column 要素

id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
data-column 要素

data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
timestamp-column 要素

timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
バグを報告する
10.5.3.5. JdbcBinaryCacheStore のライブラリーモード設定
リンクのコピー
JdbcBinaryCacheStore の設定例は次の通りです。 
<loaders>
   <loader class="org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore" fetchPersistentState="false"ignoreModifications="false"
purgeOnStartup="false">
      <properties>
         <property name="bucketTableNamePrefix" value="ISPN_BUCKET_TABLE"/>
         <property name="idColumnName" value="ID_COLUMN"/>
         <property name="dataColumnName" value="DATA_COLUMN"/>
         <property name="timestampColumnName" value="TIMESTAMP_COLUMN"/>
         <property name="timestampColumnType" value="BIGINT"/>
         <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/>
         <property name="connectionUrl" value="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1"/>
         <property name="userName" value="sa"/>
         <property name="driverClass" value="org.h2.Driver"/>
         <property name="idColumnType" value="VARCHAR(255)"/>
         <property name="dataColumnType" value="BINARY"/>
         <property name="dropTableOnExit" value="true"/>
         <property name="createTableOnStart" value="true"/>
      </properties>
   </loader>
</loaders>
Copy to Clipboard Toggle word wrap
バグを報告する

10.5.4. JdbcStringBasedCacheStores
リンクのコピー

10.5.4.1. JdbcStringBasedCacheStore について
リンクのコピー
JdbcStringBasedCacheStore は複数のエントリーを各行にグループ化せずに、各エントリーをテーブルの独自の行に格納するため、平行負荷下でスループットが増加します。また、各キーを String オブジェクトへマッピングする (プラグ可能な) 全単射も使用します。Key2StringMapper インターフェースは全単射を定義します。
JBoss Data Grid には、プリミティブタイプを処理する DefaultTwoWayKey2StringMapper と呼ばれるデフォルトの実装が含まれています。
バグを報告する
10.5.4.2. 複数ノードの JdbcStringBasedCacheStore リモート設定
リンクのコピー
以下は JBoss Data Grid のリモートクライアントサーバーモードの設定になります。この設定は、複数のノードを使用しなければならない場合に使用されます。 
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="memcachedCache" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<transport stack="${stack}" 
			   executor="infinispan-transport" 
			   lock-timeout="240000"/>
                <replicated-cache name="memcachedCache" 
	                          start="EAGER"
              		          mode="SYNC"
                                  batching="false"
              		          indexing="NONE"
                   		  remote-timeout="60000">
			<locking isolation="REPEATABLE_READ" 
	                         acquire-timeout="30000" 
	                         concurrency-level="1000" 
	                         striping="false" />
	                <transaction mode="NONE" />
	                <state-transfer enabled="true"
		                        timeout="60000" />
	                <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS"
	                        		 fetch-state="true"                        
			                         passivation="false"
	                 		         preload="false" 
			                         purge="false" 
	                		         shared="false" 
			                         singleton="true"> 
				<property name="databaseType">${database.type}</property>
		                <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
バグを報告する
10.5.4.3. パッシベーションを有効にした JdbcStringBasedCacheStore リモート設定
リンクのコピー
以下は、Boss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcBinaryCacheStore の例になります。 
  
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="memcachedCache" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<local-cache name="memcachedCache"
	                     start="EAGER"
         	             batching="false"
                   	     indexing="NONE">
			<locking isolation="REPEATABLE_READ"
	                         acquire-timeout="20000"
         	                 concurrency-level="500"
                  	         striping="false" />
			<transaction mode="NONE" />
        		<eviction strategy="LRU" 
	                          max-entries="2" />
          		<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
						 passivation="true" 
						 preload="false" 
						 purge="false">
                        	<property name="databaseType">${database.type}</property>
                        	<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>
	</cache-container>
</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する
10.5.4.4. パッシベーションを無効にした JdbcStringBasedCacheStore リモート設定
リンクのコピー
以下は、Boss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを無効にした JdbcStringBasedCacheStore の設定になります。 
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="memcachedCache" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<local-cache name="memcachedCache"
	                     start="EAGER"
         	             batching="false"
                  	     indexing="NONE">
			<locking isolation="REPEATABLE_READ"
                        	 acquire-timeout="20000"
	                         concurrency-level="500"
         	                 striping="false" />
                    	<transaction mode="NONE" />
                    	<string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
						 passivation="false" 
						 preload="true" 
						 purge="false">
                        	<property name="databaseType">${database.type}</property>
                        	<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>
	</cache-container>
</subsystem>
Copy to Clipboard Toggle word wrap
バグを報告する
10.5.4.5. JdbcStringBasedCacheStore リモート設定の属性
リンクのコピー
JBoss Data Grid のリモートクライアントサーバーモードで JdbcStringBasedCacheStore を設定するために使用される属性とパラメーターの一覧は次の通りです。
cache-container 要素

cache-container 要素はキャッシュコンテナに関する情報を指定します。

  • name パラメーターはキャッシュコンテナの名前を定義します。
  • default-cache パラメーターは、キャッシュコンテナと共に使用されるデフォルトキャッシュの名前を定義します。
  • listener-executor は非同期キャッシュリスナーの通知に使用されるエクゼキューターを定義します。
  • start パラメーターはキャッシュコンテナが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
local-cache 要素

local-cache 要素はキャッシュコンテナと共に使用されるローカルキャッシュに関する情報を指定します。

  • name パラメーターは使用するローカルキャッシュの名前を指定します。
  • start パラメーターはキャッシュが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
  • batching パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。
  • indexing パラメーターはローカルキャッシュに使用される索引作業のタイプを指定します。このパラメーターの有効な値は NONE、 LOCAL、および ALL です。
transport 要素

transport 要素には、キャッシュコンテナによって使用されるトランスポートの説明が含まれます。

  • stack パラメーターはトランスポートに使用される JGroups スタックを指定します。
  • executor パラメーターはトランスポートに使用されるエクゼキューターを指定します。
  • lock-timeout パラメーターはトランスポートのロックに対するタイムアウト値を指定します。
replicated-cache 要素

replicated-cache 要素は使用中のレプリケートされたキャッシュに関する情報を指定します。

  • name パラメーターはレプリケートされたキャッシュの名前を指定します。
  • start パラメーターはキャッシュが要求時または即座に起動するかどうかを指定します。このパラメーターの有効な値は EAGER と LAZY です。
  • mode パラメーターはレプリケートされたキャッシュのキャッシュモードを指定します。このパラメーターの有効な値は SYNC と ASYNC です。
  • batching パラメーターは、レプリケートされたキャッシュにバッチ処理を使用できるかどうかを指定します。
  • indexing パラメーターは、キャッシュに追加されたエントリーが索引付けされるかどうかを指定します。有効な場合、レプリケートされたキャッシュのエントリーが変更または削除された時に索引が更新されます。
  • remote-timeout パラメーターは、リモート呼び出しが受信確認を待機する期間を指定します。指定期間の後、リモート呼び出しは待機を中止し、例外がスローされます。このパラメーターは ASYNC モードパラメーターと共に使用されます。
locking 要素

locking 要素はローカルキャッシュのロック設定を指定します。

  • isolation パラメーターはローカルキャッシュに使用される分離レベルを定義します。このパラメーターに有効な値は REPEATABLE_READ と READ_COMMITTED です。
  • acquire-timeout パラメーターは取得した操作がタイムアウトするミリ秒単位の値を指定します。
  • concurrency-level パラメーターは LockManager によって使用されるロックストライプの数を定義します。
  • striping パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
transaction 要素

transaction 要素はローカルキャッシュのトランザクション関連の設定を指定します。

  • mode パラメーターはローカルキャッシュに使用されるトランザクションモードを指定します。このパラメーターの有効な値は NONE、 NON_XA (XAResource を使用しない)、 NON_DURABLE_XA (リカバリーを用いずに XAResource を使用する) および FULL_XA (リカバリーを用いて XAResource を使用する) です。
eviction 要素

eviction 要素はローカルキャッシュのエビクション設定情報を指定します。

  • strategy パラメーターは使用されるエビクションストラテジーやアルゴリズムを指定します。このパラメーターの有効な値には NONE、 FIFO、 LRU、 UNORDERED、 LIRS などがあります。
  • max-entries パラメーターはキャッシュインスタンスにおけるエントリーの最大数を指定します。
string-keyed-jdbc-store 要素

string-keyed-jdbc-store 要素は、文字列ベースのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。

  • datasource パラメーターはデータソースの JNDI 名を定義します。
  • passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
  • preload パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターで有効な値は true と false です。
  • purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値は true と false です。
  • shared パラメーターは、複数のキャッシュストアインスタンスがキャッシュストアを共有する場合に使用されます。複数のキャッシュインスタンスが同じ変更内容を複数回書き込まないようにするため、このパラメーターを設定することができます。このパラメーターに有効な値は ENABLED と DISABLED です。
  • singleton パラメーターは、クラスターが基盤のストアと対話する場合に使用されるシングルトンストアを有効にします。
property 要素

property 要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。

  • name パラメーターはキャッシュストアの名前を指定します。
  • ${database.type} を有効なデータベースタイプの値 (DB2_390、 SQL_SERVER、 MYSQL、 ORACLE、 POSTGRES、 SYBASE など) に置き換える必要があります。
string-keyed-table 要素

string-keyed-table 要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。

  • prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
id-column 要素

id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
data-column 要素

data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
timestamp-column 要素

timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
バグを報告する
10.5.4.6. JdbcStringBasedCacheStore のライブラリーモード設定
リンクのコピー
JdbcStringBasedCacheStore の設定例は次の通りです。 
<loaders>
 
   <loader class="org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore" fetchPersistentState="false" ignoreModifications="false"
purgeOnStartup="false">
      <properties>
         <property name="stringsTableNamePrefix" value="ISPN_STRING_TABLE"/>
         <property name="idColumnName" value="ID_COLUMN"/>
         <property name="dataColumnName" value="DATA_COLUMN"/>
         <property name="timestampColumnName" value="TIMESTAMP_COLUMN"/>
         <property name="timestampColumnType" value="BIGINT"/>
         <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/>
         <property name="connectionUrl" value="jdbc:h2:mem:string_based_db;DB_CLOSE_DELAY=-1"/>
         <property name="userName" value="sa"/>
         <property name="driverClass" value="org.h2.Driver"/>
         <property name="idColumnType" value="VARCHAR(255)"/>
         <property name="dataColumnType" value="BINARY"/>
         <property name="dropTableOnExit" value="true"/>
         <property name="createTableOnStart" value="true"/>
      </properties>
   </loader>
</loaders>
Copy to Clipboard Toggle word wrap
バグを報告する

10.5.5. JdbcMixedCacheStore
リンクのコピー

10.5.5.1. JdbcMixedCacheStore について
リンクのコピー
JdbcMixedCacheStore は、キーのタイプを基にキーを JdbcBinaryCacheStore または JdbcStringBasedCacheStore に委譲するハイブリッド実装です。
バグを報告する
10.5.5.2. パッシベーションを有効にした JdbcMixedCacheStore リモート設定
リンクのコピー
以下は、Boss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを有効にした JdbcMixedCacheStore の設定になります。 
  
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="memcachedCache" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<local-cache name="memcachedCache"
	                     start="EAGER"
         	             batching="false"
                  	     indexing="NONE">
			<locking isolation="REPEATABLE_READ"
                        	 acquire-timeout="20000"
	                         concurrency-level="500"
         	                 striping="false" />
                    	<transaction mode="NONE" />
                    	<eviction strategy="LRU" 
	                          max-entries="2" />
          		<mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
						passivation="true" 
						preload="false" 
						purge="false">
				<property name="databaseType">${database.type}</property>
	                        <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
バグを報告する
10.5.5.3. パッシベーションを無効にした JdbcMixedCacheStore リモート設定
リンクのコピー
以下は、Boss Data Grid のリモートクライアントサーバーモードを使用し、パッシベーションを無効にした JdbcMixedCacheStore の設定になります。 
  
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default">
	<cache-container name="default" 
			 default-cache="memcachedCache" 
			 listener-executor="infinispan-listener" 
			 start="EAGER">
		<local-cache name="memcachedCache"
                    	     start="EAGER"
                    	     batching="false"
                    	     indexing="NONE">
                    	<locking isolation="REPEATABLE_READ"
                        	 acquire-timeout="20000"
                        	 concurrency-level="500"
                        	 striping="false" />
                    	<transaction mode="NONE" />
                    	<mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" 
						passivation="false" 
						preload="true" 
						purge="false">
                        	<property name="databaseType">${database.type}</property>
                        	<binary-keyed-table prefix="MIX_BKT">
                        		<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_STR">
                            		<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
バグを報告する
10.5.5.4. JdbcMixedCacheStore リモート設定の属性
リンクのコピー
JBoss Data Grid のリモートクライアントサーバーモードで JdbcMixedCacheStore を設定するために使用される要素とパラメーターの一覧は次の通りです。
cache-container 要素

cache-container 要素は、次のパラメーターを使用してキャッシュコンテナに関する情報を指定します。

  • name パラメーターはキャッシュコンテナの名前を定義します。
  • default-cache パラメーターは、キャッシュコンテナと共に使用されるデフォルトキャッシュの名前を定義します。
  • listener-executor は非同期キャッシュリスナーの通知に使用されるエクゼキューターを定義します。
  • start パラメーターはキャッシュコンテナが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
local-cache 要素

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

  • name パラメーターは使用するローカルキャッシュの名前を指定します。
  • start パラメーターはキャッシュが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
  • batching パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。
  • indexing パラメーターはローカルキャッシュに使用される索引作業のタイプを指定します。このパラメーターの有効な値は NONE、 LOCAL、および ALL です。
locking 要素

locking 要素はローカルキャッシュのロック設定を指定します。

  • isolation パラメーターはローカルキャッシュに使用される分離レベルを定義します。このパラメーターに有効な値は REPEATABLE_READ と READ_COMMITTED です。
  • acquire-timeout パラメーターは取得した操作がタイムアウトするミリ秒単位の値を指定します。
  • concurrency-level パラメーターは LockManager によって使用されるロックストライプの数を定義します。
  • striping パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
transaction 要素

transaction 要素はローカルキャッシュのトランザクション関連の設定を指定します。

  • mode パラメーターはローカルキャッシュに使用されるトランザクションモードを指定します。このパラメーターの有効な値は NONE、 NON_XA (XAResource を使用しない)、 NON_DURABLE_XA (リカバリーを用いずに XAResource を使用する) および FULL_XA (リカバリーを用いて XAResource を使用する) です。
eviction 要素

eviction 要素はローカルキャッシュのエビクション設定情報を指定します。

  • strategy パラメーターは使用されるエビクションストラテジーやアルゴリズムを指定します。このパラメーターの有効な値には NONE、 FIFO、 LRU、 UNORDERED、 LIRS などがあります。
  • max-entries パラメーターはキャッシュインスタンスにおけるエントリーの最大数を指定します。
mixed-keyed-jdbc-store 要素

mixed-keyed-jdbc-store 要素は、混合のキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。

  • datasource パラメーターはデータソースの JNDI 名を定義します。
  • passivation パラメーターは、キャッシュのエントリーがパッシベートされるか (true) またはキャッシュストアが内容のコピーをメモリーに保持するか (false) を決定します。
  • preload パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターで有効な値は true と false です。
  • purge パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値は true と false です。
property 要素

property 要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。

  • name パラメーターはキャッシュストアの名前を指定します。
  • ${database.type} を有効なデータベースタイプの値 (DB2_390、 SQL_SERVER、 MYSQL、 ORACLE、 POSTGRES、 SYBASE など) に置き換える必要があります。
mixed-keyed-table 要素

mixed-keyed-table 要素は、混合のキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。

  • prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
string-keyed-table 要素

string-keyed-table 要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。

  • prefix パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
id-column 要素

id-column 要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
data-column 要素

data-column 要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
timestamp-column 要素

timestamp-column 要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。

  • name パラメーターはデータベース列の名前を指定します。
  • type パラメーターはデータベース列のタイプを指定します。
バグを報告する
10.5.5.5. JdbcMixedCacheStore のライブラリーモード設定
リンクのコピー
JdbcMixedCacheStore の設定例は次の通りです。 
<loaders>
   <loader class="org.infinispan.loaders.jdbc.mixed.JdbcMixedCacheStore" 
	   fetchPersistentState="false"
           ignoreModifications="false" 
	   purgeOnStartup="false">
      <properties>
         <property name="tableNamePrefixForStrings" value="ISPN_MIXED_STR_TABLE"/>
         <property name="tableNamePrefixForBinary" value="ISPN_MIXED_BINARY_TABLE"/>
         <property name="idColumnNameForStrings" value="ID_COLUMN"/>
         <property name="idColumnNameForBinary" value="ID_COLUMN"/>
         <property name="dataColumnNameForStrings" value="DATA_COLUMN"/>
         <property name="dataColumnNameForBinary" value="DATA_COLUMN"/>
         <property name="timestampColumnNameForStrings" value="TIMESTAMP_COLUMN"/>
         <property name="timestampColumnNameForBinary" value="TIMESTAMP_COLUMN"/>
         <property name="timestampColumnTypeForStrings" value="BIGINT"/>
         <property name="timestampColumnTypeForBinary" value="BIGINT"/>
         <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/>
         <property name="connectionUrl" value="jdbc:h2:mem:infinispan_mixed_cs;DB_CLOSE_DELAY=-1"/>
         <property name="userName" value="sa"/>
         <property name="driverClass" value="org.h2.Driver"/>
         <property name="idColumnTypeForStrings" value="VARCHAR(255)"/>
         <property name="idColumnTypeForBinary" value="VARCHAR(255)"/>
         <property name="dataColumnTypeForStrings" value="BINARY"/>
         <property name="dataColumnTypeForBinary" value="BINARY"/>
         <property name="dropTableOnExitForStrings" value="false"/>
         <property name="dropTableOnExitForBinary" value="false"/>
         <property name="createTableOnStartForStrings" value="true"/>
         <property name="createTableOnStartForBinary" value="true"/>
         <property name="createTableOnStartForStrings" value="true"/>
         <property name="createTableOnStartForBinary" value="true"/>
      </properties>
   </loader>
</loaders>
Copy to Clipboard Toggle word wrap
バグを報告する

10.5.6. カスタムキャッシュストア
リンクのコピー

10.5.6.1. カスタムキャッシュストアについて
リンクのコピー
カスタムキャッシュストアは JBoss Data Grid のキャッシュストアのカスタマイズされた実装です。
バグを報告する
10.5.6.2. カスタムキャッシュストアの設定 (リモートモード)
リンクのコピー
以下は、JBoss Data Grid のリモートクライアントサーバーモードにおけるカスタムキャッシュストアの設定例になります。 
<local-cache name="default">
     <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 モジュールの依存関係に追加します。
バグを報告する
10.5.6.3. カスタムキャッシュストアの設定 （ライブラリモード)
リンクのコピー
以下は、JBoss Data Grid のライブラリモードにおけるカスタムキャッシュストアの設定例になります。 
<loaders shared="true" 
	 preload="true" 
	 purge="false">
	<loader class="org.infinispan..custom.CustomCacheStore">
		<properties>
			<property name="CustomCacheName" 
				  value="default"/>
		</properties>
	</loader>
</loaders>
Copy to Clipboard Toggle word wrap
バグを報告する

10.6. よくある質問
リンクのコピー

10.6.1. 非同期キャッシュストアの変更について
リンクのコピー

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

10.7. キャッシュストアのトラブルシューティング
リンクのコピー

10.7.1. JdbcStringBasedCacheStore の IOExceptions
リンクのコピー

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

10.8. キャッシュローダー
リンクのコピー

10.8.1. キャッシュローダーについて
リンクのコピー

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

10.8.2. キャッシュローダーとキャッシュストア
リンクのコピー

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

10.8.3. 共有キャッシュローダー
リンクのコピー

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

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
バグを報告する
10.8.3.3. インバリデーションモードと共有キャッシュローダー
リンクのコピー
JBoss Data Grid のインバリデーションモードを共有キャッシュと共に使用すると、リモートキャッシュが共有キャッシュローダーを参照して、変更されたデータを読み出すようになります。
インバリデーションモードを共有キャッシュローダーと共に使用する利点には次のようなものがあります。
  • 更新されたデータが含まれるレプリケーションメッセージよりも無効化メッセージはかなり小型であるため、ネットワークトラフィックが軽減されます。
  • 残りのクラスターキャッシュは、必要な場合のみ変更されたデータを共有キャッシュローダーよりレイジーにルックアップするため、ネットワークトラフィックがさらに軽減されます。
バグを報告する
10.8.3.4. キャッシュローダーとキャッシュパッシベーション
リンクのコピー
JBoss Data Grid では、エントリーのパッシベーションを強制したり、キャッシュでエビクションをアクティベートしたりするためにキャッシュローダーを使用することができます。パッシベーションモードまたはアクティベーションモードが使用されると、設定されたキャッシュローダーがデータストアへ読み書きします。
JBoss Data Grid でパッシベーションが無効になっている場合、要素の変更や追加、削除が実行された後にキャッシュローダーがストアの変更を永続化します。
パッシベーションが有効な場合のキャッシュローダーの挙動例は 「パッシベーションが無効な場合のエビクションの例」、パッシベーションが無効な場合の例は 「パッシベーションが有効な場合のエビクションの例」 を参照してください。
バグを報告する
10.8.3.5. アプリケーションキャッシュローダーの登録
リンクのコピー
分離されたデプロイメントに対してアプリケーションキャッシュローダーを登録する必要はありません。レイジーデシリアライゼーションを使用するとこの問題を回避できるため、JBoss Data Grid では必須ではありません。
バグを報告する

10.8.4. 接続ファクトリー
リンクのコピー

10.8.4.1. 接続ファクトリーについて
リンクのコピー
JBoss Data Grid では、すべての JDBC キャッシュローダーが ConnectionFactory 実装に依存してデータベースへの接続を取得します。このプロセスは接続管理またはプーリングとも呼ばれます。
接続ファクトリーは ConnectionFactoryClass 設定属性を使用して指定することができます。 JBoss Data Grid には次の ConnectionFactory 実装が含まれています。
  • ManagedConnectionFactory
  • SimpleConnectionFactory
バグを報告する
10.8.4.2. ManagedConnectionFactory について
リンクのコピー
ManagedConnectionFactory は、アプリケーションサーバーなど管理された環境内での使用に適した接続ファクトリーです。この接続ファクトリーは JNDI ツリー内の設定された場所を調査でき、接続管理を DataSource へ委譲できます。 ManagedConnectionFactory は DataSource が含まれる管理された環境内で使用されます。この Datasource は接続プーリングへ委譲されます。
バグを報告する
10.8.4.3. SimpleConnectionFactory について
リンクのコピー
SimpleConnectionFactory は呼び出しごとにデータベース接続を作成する接続ファクトリーです。この接続ファクトリーは実稼働環境での使用には向いていません。
バグを報告する

第11章 キャッシュマネージャー
リンクのコピー

11.1. キャッシュマネージャーについて
リンクのコピー

キャッシュマネージャーは JBoss Data Grid のキャッシュインスタンスを読み出すために使用される主なメカニズムで、キャッシュを使用する時の開始点とすることができます。
キャッシュマネージャーはリソースを多く使用するため、複数のキャッシュマネージャーを必要とする特定の設定を使用しない限り、一般的な実装には各 JVM (Java 仮想マシン) に対して 1 つのキャッシュマネージャーが必要となります。
バグを報告する

11.2. 複数のキャッシュマネージャー
リンクのコピー

11.2.1. 単一のキャッシュマネージャーを用いた複数キャッシュの作成
リンクのコピー

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

11.2.2. 複数のキャッシュマネージャーの使用
リンクのコピー

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

第12章 エビクション
リンクのコピー

12.1. エビクションについて
リンクのコピー

エビクションとは、メモリー不足にならないようにするためメモリーからエントリーを削除するプロセスのことです。永久的なデータの損失を防ぐため、メモリーからエビクトされたエントリーはキャッシュストアと残りのクラスターに保留されます。
バグを報告する

12.2. エビクション操作
リンクのコピー

エビクションはクラスター全体の操作として発生せず、ノードごとに個別に発生します。各ノードはエビクションスレッドを使用してインメモリコンテナの内容を分析し、エビクションが必要なエントリーを判定します。Java 仮想マシン (JVM) の空きメモリーはエビクションの分析中には考慮されず、エントリーのエビクションを初期化するしきい値としても考慮されません。
バグを報告する

12.3. エビクションの用途
リンクのコピー

JBoss Data Grid は、すでにデータコンテナと対話しているユーザースレッドを利用してエビクションのタスクを実行します。JBoss Data Grid は別のスレッドを使用して、期限切れのキャッシュエントリーをキャッシュから除去します。

関連トピック:

バグを報告する

12.4. エビクションストラテジー
リンクのコピー

12.4.1. エビクションストラテジーについて
リンクのコピー

JBoss Data Grid は次のエビクションストラテジーを提供します。
  • EvictionStrategy.NONE: 設定されているエビクションストラテジーはありません。
  • EvictionStrategy.FIFO: 先入れ先出しのエビクションストラテジーです。
  • EvictionStrategy.LRU: LRU (Least Recently Used) 方式のエビクションストラテジーです。幅広いデプロイメントの要件と互換性があるため、デフォルトのエビクションアルゴリズムとなっています。
  • EvictionStrategy.UNORDERED: 順番付けのないエビクションストラテジーです。
  • EvictionStrategy.LIRS: LIRS (Low Inter-reference Recency Set) 方式のエビクションストラテジーです。
バグを報告する

12.4.2. LRU エビクションアルゴリズムの制限
リンクのコピー

LRU (Least Recently Used) エビクションアルゴリズムは簡単に理解できるアルゴリズムですが、特定の弱いアクセスローカリティーのユースケースでは最適に実行されません。このようなケースでは、次のような問題が発生する可能性があります。
  • 1 度だけ使用できるアクセスエントリーを時間内に置き換えられない。
  • 最初にアクセスされたエントリーが不必要に置き換えられる。
バグを報告する

12.5. エビクションの使用
リンクのコピー

12.5.1. エビクションの初期化
リンクのコピー

エビクションを初期化するには、エビクション要素の max-entries 属性の値をゼロよりも大きい数に設定します。max-entries の値セットを調整して、使用する設定の最適値を探します。max-entries に設定する値が大きすぎると、JBoss Data Grid のメモリーが不足するため注意してください。
バグを報告する

12.5.2. デフォルトのエビクション設定
リンクのコピー

JBoss Data Grid ではエビクションはデフォルトで無効になっています。空の eviction 要素を使用してエビクションを有効にすると、次のデフォルト値が使用されます。
  • ストラテジー: 指定されたエビクションストラテジーがない場合、 EvictionStrategy.NONE がデフォルトとみなされます。
  • max-entries: 指定された値がない場合、max-entries の値は無制限のエントリーを許可する -1 に設定されます。
    • max-entries の値を 0 に設定するとすべてのエントリーが拒否されます。そのため、エビクションスレッドは空のキャッシュを保持しようとします。
バグを報告する

12.5.3. エビクションの設定例
リンクのコピー

設定 Bean または XML ファイルを使用して JBoss Data Grid のエビクションを設定します。エビクションの設定はキャッシュごとに行います。
XML 設定 (ライブラリモード)

JBoss Data Grid のライブラリーモードに有効なエビクションの XML 設定例は次の通りです。 

<eviction strategy="LRU" maxEntries="2000"/>
Copy to Clipboard Toggle word wrap
プログラムを用いた設定 (ライブラリモード)

以下を使用すると、JBoss Data Grid のライブラリモードでエビクションの設定をプログラムを用いて定義することが可能です。 

Configuration c = new ConfigurationBuilder().eviction().strategy(EvictionStrategy.LRU)
              .maxEntries(2000)
              .build();
Copy to Clipboard Toggle word wrap
XML 設定 (リモートクライアントサーバーモード)

JBoss Data Grid のリモートクライアントサーバーモードで XML を用いたエビクションの設定例は次の通りです。 

<eviction strategy="FIFO" max-entries="20"/>
Copy to Clipboard Toggle word wrap

注記

エビクションの設定では、JBoss Data Grid のライブラリモードは maxEntries パラメーター、リモートクライアントサーバーモードは max-entries パラメーターを使用することに注意してください。
バグを報告する

12.5.4. エビクション設定のトラブルシューティング
リンクのコピー

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

12.6. エビクションとパッシベーション
リンクのコピー

12.6.1. エビクションとパッシベーションについて
リンクのコピー

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

関連トピック:

バグを報告する

第13章 エクスパレーション
リンクのコピー

13.1. エクスパレーションについて
リンクのコピー

JBoss Data Grid は、エクスパレーションを使用して以下の値の 1 つまた両方をエントリーへ付加します。
  • ライフスパンの値。
  • 最大アイドル時間の値。
ライフスパンの値と最大アイドル時間の値の両方には、デフォルト値である -1 が作成時に割り当てられます。
エビクトされたエントリーとは異なり、期限切れのエントリーはグローバルに削除されます。よって、期限切れのエントリーはメモリー、キャッシュストア、およびクラスターより削除されます。
バグを報告する

13.2. エクスパレーションの操作
リンクのコピー

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

13.3. エビクションとエクスパレーションの比較
リンクのコピー

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

13.4. キャッシュエントリーの期限切れ通知
リンクのコピー

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

13.5. エクスパレーションの設定
リンクのコピー

JBoss Data Grid では、エビクションと同様にエクスパレーションが設定されます。
ライブラリモードの設定

次の設定例は、JBoss Data Grid のライブラリモードでエクスパレーションを設定する方法を示しています。 

<expiration lifespan="2000" maxIdle="1000" />
Copy to Clipboard Toggle word wrap
リモートクライアントサーバーモードの設定

次の設定例は、JBoss Data Grid のリモートクライアントサーバーモードでエクスパレーションを設定する方法を示しています。 

<expiration lifespan="2000" max-idle="1000" />
Copy to Clipboard Toggle word wrap
バグを報告する

13.6. 期限つき (mortal) データと期限なし (immortal) データ
リンクのコピー

13.6.1. データ期限について
リンクのコピー

JBoss Data Grid では、エンティティーを格納するだけでなく、データーに期限の情報を添付することが可能です。たとえば、標準的な put(key, value) を使用すると、期限なし (immortal) エントリーと呼ばれる永久に期限切れにならないエントリーが作成されます。また、put(key, value, lifespan, timeunit) を使用して作成されるエントリーは、指定の固定ライフスパンを持つ期限つき (mortal) エントリーで、ライフスパンの後に期限が切れます。
JBoss Data Grid は lifespan パラメーターの他に、エクスパレーションを判断するために使用される maxIdle パラメーターも提供します。maxIdle パラメーターと lifespan パラメーターをさまざまな組み合わせで使用してエントリーのライフスパンを設定することができます。
バグを報告する

13.6.2. デフォルトのデータ期限
リンクのコピー

デフォルトでは、新規作成されたエントリーにはライフスパンや最大アイドル時間値セットがありません。これらの 2 つの値がない場合、データエントリーは永久に期限切れにならないため、期限なし (immortal) データと呼ばれます。
バグを報告する

13.6.3. データ期限の設定
リンクのコピー

エントリーの期限 (またはエクスパレーションの値) を設定するには、エントリーのライフスパンと最大アイドル時間の値を設定します。設定後、これらの値をキャッシュストアで永続化し、エビクションやパッシベーションの後も存続するようにします。
バグを報告する

13.7. トラブルシューティング
リンクのコピー

13.7.1. エクスパレーションのトラブルシューティング
リンクのコピー

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

第14章 1 次キャッシュ
リンクのコピー

14.1. 1 次キャッシュについて
リンクのコピー

1 次 (L1) キャッシュは、最初にアクセスされた後にリモートキャッシュエントリーを格納するため、同じエントリーがその後使用される時に不必要なリモートフェッチ操作が行われないようにします。1 次キャッシュは、JBoss Data Grid のキャッシュモードがディストリビューションモードに設定されている場合に作成され、デフォルトでは disabled になっています。
L1 キャッシュによって使用される一時的な場所のデフォルトは変更することが可能です。
バグを報告する

14.2. 1 次キャッシュエントリー
リンクのコピー

14.2.1. 1 次キャッシュエントリー
リンクのコピー

L1 キャッシュにはリモートキャッシュより読み出されたエントリーが含まれています。クラスターでエントリーの場所が変更になると、対応する L1 キャッシュエントリーが無効化され、古いキャッシュエントリーが発生しないようにします。
L1 が有効になっている場合、キャッシュはリモートの場所からエントリーをフェッチする前に L1 キャッシュを確認し、不必要なフェッチ操作が発生しないようにします。
バグを報告する

14.2.2. 1 次キャッシュエントリーのライフスパン
リンクのコピー

各 L1 キャッシュエントリーのデフォルトのライフスパンは 600,000 ミリ秒 (10 分) です。このライフスパン値はユーザーの要件に合わせて変更することが可能です。
バグを報告する

14.3. 1 次キャッシュの操作
リンクのコピー

14.3.1. 1 次キャッシュと無効化
リンクのコピー

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

14.3.2. GET 操作と用いた 1 次キャッシュの使用
リンクのコピー

同じキーで複数の GET 操作が実行されると、リモート呼び出しが繰り返し生成されます。同じキー上で不必要な GET 操作の数を削減するには、L1 キャッシングを有効にします。
L1 キャッシュは、リモートキャッシュより読み出した値を格納するローカル (および一時的な) キャッシュを提供します。L1 キャッシュに使用する場所は設定可能です。
バグを報告する

第15章 リスナーと通知
リンクのコピー

15.1. リスナー API について
リンクのコピー

JBoss Data Grid は、発生時にイベントの通知を行うリスナー API を提供します。クライアントは、関係する通知に対してリスナー API の登録を選択できます。 この API はアノテーション駆動型で、キャッシュレベルのイベントとキャッシュマネージャーレベルのイベント上で操作します。
バグを報告する

15.2. リスナーの例
リンクのコピー

次の例は、新しいエントリーがキャッシュに追加されるたびに情報を出力する JBoss Data Grid のリスナーを定義します。 
@Listener
public class PrintWhenAdded {
  @CacheEntryCreated
  public void print(CacheEntryCreatedEvent event) {
    System.out.println("New entry " + event.getKey() + " created in the cache");
  }
}
Copy to Clipboard Toggle word wrap
バグを報告する

15.3. キャッシュエントリーが変更されたリスナーの設定
リンクのコピー

キャッシュエントリーが変更されたリスナーでは、isPre が false である場合に、変更された値を Cache.get() より読み出しできません。
代わりに CacheEntryModifiedEvent.getValue() を使用して、変更されたエントリーの新しい値を読み出します。
バグを報告する

15.4. 通知
リンクのコピー

15.4.1. リスナー通知について
リンクのコピー

キャッシュイベントが発生するたびにリスナーに送信される通知が発生します。リスナーは簡単な POJO で @Listener アノテーションが付きます。Listenable は、実装がアタッチするリスナーを持つことを意味するインターフェースです。各リスナーは Listenable で定義されたメソッドを使用して登録されます。
キャッシュレベルまたはマネージャーレベルの通知を受信できるようにするため、リスナーはキャッシュとキャッシュマネージャーの両方にアタッチすることが可能です。
バグを報告する

15.4.2. キャッシュレベルの通知について
リンクのコピー

JBoss Data Grid では、キャッシュレベルのイベントはキャッシュごとに発生し、グローバルでクラスター全体が対象になります。キャッシュレベルイベントの例には、関係するキャッシュで登録されたリスナーへの通知を引き起こすエントリーの追加、削除、および変更などが含まれます。

関連トピック:

バグを報告する

15.4.3. キャッシュマネージャーレベルの通知
リンクのコピー

JBoss Data Grid のキャッシュマネージャーレベルで発生するイベントの例は次の通りです。
  • クラスターに参加または離脱するノード
  • キャッシュの開始および停止
キャッシュマネージャーレベルのイベントはグローバルに位置し、クラスター全体で使用されますが、単一のキャッシュマネージャーによって作成されたキャッシュ内のイベントに制限されます。
バグを報告する

15.4.4. 同期および非同期通知について
リンクのコピー

デフォルトでは、JBoss Data Grid の通知はイベントが生成された同じスレッドで送信されます。そのため、スレッドの進捗を妨げないようにリスナーを書くことが重要となります。
この代わりに、リスナーを非同期としてアノテーション付けし、別のスレッドで通知を送信することで元のスレッドの操作を妨げないようにすることもできます。
以下を使用してリスナーにアノテーションを付けます。 
@Listener (sync = false)public class MyAsyncListener { .... }
Copy to Clipboard Toggle word wrap
設定ファイルの <asyncListenerExecutor/> 要素を使用して、非同期通知を送信するために使用されるスレッドプールを調整します。
バグを報告する

15.5. Futures の通知
リンクのコピー

15.5.1. NotifyingFutures について
リンクのコピー

JBoss Data Grid のメソッドは Java Development Kit (JDK) の Futures を返しませんが、NotifyingFuture と呼ばれるサブインターフェースを返します。JDK の Future とは異なり、終了した future についてユーザーに通知するため、リスナーを NotifyingFuture にアタッチすることが可能です。

注記

JBoss Data Grid では NotifyingFutures はライブラリモードでのみ使用可能です。
バグを報告する

15.5.2. NotifyingFutures の例
リンクのコピー

次の例は、JBoss Data Grid で NotifyingFutures を使用する方法を示しています。 
FutureListener futureListener = new FutureListener() {

public void futureDone(Future future) {
      try {
         future.get();
      } catch (Exception e) {
         // Future did not complete successfully         
         System.out.println("Help!");
      }
   }
};
      
cache.putAsync("key", "value").attachListener(futureListener);
Copy to Clipboard Toggle word wrap
バグを報告する

第16章 アクティベーションモードとパッシベーションモード
リンクのコピー

16.1. アクティベーションモードについて
リンクのコピー

アクティベーションは、エントリーをメモリーへロードし、キャッシュストアから削除する処理のことです。ストアに存在し、メモリーには存在しないエントリー (パッシベートされたエントリー) へスレッドがアクセスしようとした時にアクティベーションが発生します。
バグを報告する

16.2. パッシベーションモードについて
リンクのコピー

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

16.3. パッシベーションモードの利点
リンクのコピー

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

16.4. パッシベーションフラグについて
リンクのコピー

パッシベーションフラグは、パッシベーションモードの切り替えに使用されます。パッシベーションモードは、エントリーがメモリーからエビクトされた後でのみキャッシュストアにエントリーを格納するモードです。
バグを報告する

16.5. エビクションとパッシベーション
リンクのコピー

16.5.1. エビクションとパッシベーションについて
リンクのコピー

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

16.5.2. エビクションとパッシベーションの用途
リンクのコピー

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

16.5.3. パッシベーションが無効な場合のエビクションの例
リンクのコピー

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

16.5.4. パッシベーションが有効な場合のエビクションの例
リンクのコピー

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

第17章 カスタムインターセプター
リンクのコピー

17.1. カスタムインターセプターについて
リンクのコピー

カスタムインターセプターは、宣言したり、プログラミングを行ったりして JBoss Data Grid に追加できます。カスタムインターセプターは、キャッシュの変更に影響を与えたり、キャッシュの変更に応答したりすることにより JBoss Data Grid を拡張します。要素またはトランザクションの追加、削除、または更新がこのようなキャッシュ変更の例になります。
バグを報告する

17.2. カスタムインターセプター設計
リンクのコピー

JBoss Data Grid でカスタムインターセプターを設計するには、次のガイドラインに従います。
  • カスタムインターセプターは CommandInterceptor を拡張しなければなりません。
  • カスタムインターセプターはインスタンス化を可能にするために、パブリックの空のコンストラクターを宣言しなければなりません。
  • カスタムインターセプターでは、property 要素を介して定義されたプロパティーに対して JavaBean スタイルセッターを定義する必要があります。
バグを報告する

17.3. カスタムインターセプターの追加
リンクのコピー

17.3.1. カスタムインターセプターを宣言して追加
リンクのコピー

JBoss Data Grid の各名前付きキャッシュは独自のインターセプタースタックを持ちます。結果として、カスタムインターセプターは名前付きキャッシュごとに追加できます。
カスタムインターセプターは、XML を使用して追加できます。たとえば、以下のようになります。 
<namedCache name="cacheWithCustomInterceptors">
   <!--
   Define custom interceptors.  All custom interceptors need to extend org.jboss.cache.interceptors.base.CommandInterceptor
   -->
   <customInterceptors>
      <interceptor position="FIRST" class="com.mycompany.CustomInterceptor1">
         <properties>
            <property name="attributeOne" value="value1" />
            <property name="attributeTwo" value="value2" />
         </properties>
      </interceptor>
      <interceptor position="LAST" class="com.mycompany.CustomInterceptor2"/>
      <interceptor index="3" class="com.mycompany.CustomInterceptor1"/>
      <interceptor before="org.infinispanpan.interceptors.CallInterceptor" class="com.mycompany.CustomInterceptor2"/>
      <interceptor after="org.infinispanpan.interceptors.CallInterceptor" class="com.mycompany.CustomInterceptor1"/>
   </customInterceptors>
</namedCache>
Copy to Clipboard Toggle word wrap

注記

この設定は、JBoss Data Grid のライブラリーモードに対してのみ有効です。
バグを報告する

17.3.2. カスタムインターセプターをプログラミングにより追加
リンクのコピー

JBoss Data Grid でカスタムインターセプターをプログラミングにより追加するには、最初に AdvancedCache への参照を取得します。
例: 
CacheManager cm = getCacheManager();
Cache aCache = cm.getCache("aName");
AdvancedCache advCache = aCache.getAdvancedCache();
Copy to Clipboard Toggle word wrap
次に、addInterceptor() メソッドを使用してインターセプターを追加します。
例: 
advCache.addInterceptor(new MyInterceptor(), 0);
Copy to Clipboard Toggle word wrap
バグを報告する

第18章 トランザクション
リンクのコピー

18.1. Java トランザクション API のトランザクションについて
リンクのコピー

JBoss Data Grid は、JTA 準拠のトランザクションの設定、使用および参加をサポートします。しかし、トランザクションサポートを無効にすることは JDBC 呼び出しの自動コミット機能を使用することと同等になります。JDBC 呼び出しでは、レプリケーションが有効になっている場合、各変更の後に変更内容が潜在的にレプリケートされます。
JBoss Data Grid は各キャッシュ操作に対して以下を実行します。
  1. 最初に、現在スレッドに関連付けされているトランザクションを読み出します。
  2. XAResource が登録されていない場合は、XAResource をトランザクションマネージャーに登録し、トランザクションがコミットされたりロールバックされた時に通知を受け取るようにします。

重要

JBoss Data Grid 6.0.x では、リモートクライアントサーバーモードでトランザクションを無効にすることが推奨されます。ただし、ExceptionTimeout のエラーが発生し、Unable to acquire lock after {time} on key {key} for requester {thread} という警告が表示された場合は、トランザクションを有効にします。これは、非トランザクションキャッシュが書き込む各ノードに対するロックを取得するため、起こります。トランザクションを使用すると、キャッシュが単一ノードに対するロックを取得するため、デッドロックが回避されます。
この問題は、JBoss Data Grid 6.1 で解決されました。
バグを報告する

18.2. 複数のキャッシュインスタンスにわたるトランザクション
リンクのコピー

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

18.3. トランザクション / バッチ処理および無効化メッセージ
リンクのコピー

バッチ処理またはトランザクションを使用せずにインバリデーションモードで変更を行う場合、各変更が行われた後に無効化メッセージが送信されます。トランザクションまたはバッチ処理が使用される場合、無効化メッセージはコミットが正常実行された後に送信されます。
トランザクションまたはバッチ処理と共に無効化を使用すると、メッセージが一括送信され、ネットワークトラフィックが軽減されるため、効率が良くなります。
バグを報告する

18.4. トランザクションマネージャー
リンクのコピー

18.4.1. JTA トランザクションマネージャーのルックアップクラスについて
リンクのコピー

キャッシュ操作を実行するため、キャッシュは環境のトランザクションマネージャーへの参照が必要となります。TransactionManagerLookup インターフェースの実装に属するクラス名を用いて、キャッシュを設定します。キャッシュが初期化されると、指定クラスのインスタンスが作成されます。そして getTransactionManager() メソッドを呼び出してトランザクションマネージャーへの参照を見つけ、返します。
JBoss Data Grid には次のトランザクションマネージャーのルックアップクラスが含まれています。
  • DummyTransactionManagerLookup はテスト目的でトランザクションマネージャーを提供します。このテスト向けのトランザクションマネージャーは実稼働環境では使用されず、特に並列トランザクションやリカバリーなどの機能は厳しく制限されます。
  • JBossStandaloneJTAManagerLookup は、JBoss Data Grid がスタンドアロン環境を実行する場合のデフォルトのトランザクションマネージャーです。これにより、JBoss Transactions ベースの完全に機能するトランザクションマネージャーで、DummyTransactionManagerLookup の機能制限が解消されます。
  • GenericTransactionManagaerLookup は、ほとんどの Java EE アプリケーションサーバーでトランザクションマネージャーを見つけるために使用されるルックアップクラスです。デフォルトは DummyTransactionManagerLookup です。
  • JBossTransactionManagerLookup は、JBoss Application Server インスタンス内でトランザクションマネージャーを見つけるルックアップクラスです。

注記

リモートクライアントサーバーモードでは、すべての JBoss Data Grid 操作が非トランザクションとなります。そのため、前述の JTA トランザクションマネージャーのルックアップクラスは、JBoss Data Grid のライブラリモードでのみ使用できます。
バグを報告する

18.4.2. トランザクションマネージャーの使用
リンクのコピー

18.4.2.1. キャッシュからのトランザクションマネージャーの取得
リンクのコピー
初期化後に次の設定を使用して、キャッシュより TransactionManager を取得します。

手順18.1 キャッシュからのトランザクションマネージャーの取得

  1. BasicCacheContainer の設定場所プロパティーに次のプロパティーを追加して、transactionManagerLookupClass を定義します。 
    Configuration config = new ConfigurationBuilder()
...
  .transaction().transactionManagerLookup(new GenericTransactionManagerLookup())
    Copy to Clipboard Toggle word wrap
  2. TransactionManagerLookup.getTransactionManager を次のように呼び出します。 
    TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
    Copy to Clipboard Toggle word wrap
バグを報告する
18.4.2.2. トランザクションの設定
リンクのコピー
JBoss Data Grid のトランザクションは、キャッシュレベルで設定されます。トランザクションの設定方法の例は次の通りです。 
<cache>
..
 <transaction mode="NONE"
              stop-timeout="30000"
              locking="OPTIMISTIC" />
...
</cache>
Copy to Clipboard Toggle word wrap
  • mode 属性はキャッシュトランザクションモードを設定します。この属性の有効な値は NONE (デフォルト)、 NON_XA、 NON_DURABLE_XA、 FULL_XA です。
  • stop-timeout 属性は、キャッシュが停止した時に JBoss Data Grid が継続するリモートおよびローカルトランザクションを待機する期間 (ミリ秒数) を示します。
  • locking 属性はキャッシュに対して使用されるロックモードを指定します。この属性に有効な値は OPTIMISTIC (デフォルト) と PESSIMISTIC です。
バグを報告する
18.4.2.3. トランザクションマネージャーと XAResources
リンクのコピー
トランザクションリカバリー処理はトランザクションマネージャーに固有するにも関わらず、XAResource 実装への参照を提供し、XAResource.recover を実行する必要があります。
バグを報告する
18.4.2.4. XAResource の参照の取得
リンクのコピー
JBoss Data Grid の XAResource への参照を取得するには、次の API を使用します。 
XAResource xar = cache.getAdvancedCache().getXAResource();
Copy to Clipboard Toggle word wrap
バグを報告する
18.4.2.5. デフォルトの分散トランザクションの挙動
リンクのコピー
JBoss Data Grid では、XAResource より分散トランザクションで JBoss Data Grid を最初のクラス参加者として登録するのがデフォルトの挙動になります。JBoss Data Grid がトランザクションの参加者になる必要がない場合、同期化を介してトランザクションのライフサイクル状態 (準備、完了など) に関して通知することができます。
バグを報告する

18.5. トランザクションの同期化
リンクのコピー

18.5.1. トランザクション (JTA) 同期化について
リンクのコピー

JTA の同期化は、トランザクションのライフサイクルイベントに関する情報を JBoss Data Grid に提供します。また、同期化を登録すると XAResource として登録しなくても、JBoss Data Grid がトランザクションイベントへ応答できるようになります。その結果、トランザクションマネージャーがトランザクション操作を最適化し、2 相コミット (2PC) アルゴリズムではなく、1 相コミット (1PC) アルゴリズムが必要となります。
JBoss Data Grid では、JTA 同期化はライブラリーモードでのみ使用できます。
バグを報告する

18.5.2. 同期化を有効にする
リンクのコピー

JBoss Data Grid では、モードに非 XA オプションが設定されている場合にトランザクションに対して同期化が自動的に使用されます。
同期化を有効にするには、トランザクション要素のモードパラメーターを以下のいずれかに設定します。
  • NONE (同期)
  • NO_XA (同期)

注記

JBoss Data Grid では、ライブラリーモードにおける同期化を介したトランザクション参加のみが許可されます。
バグを報告する

18.6. ステートの調整
リンクのコピー

18.6.1. ステートの調整について
リンクのコピー

JBoss Data Grid でステートを調整するため、トランザクションマネージャーが、手作業による介入が必要なトランザクションに関する情報をシステム管理者に渡します。
システム管理者は、トランザクションリカバリー作業の要件として、関連するトランザクションの XID を認識している必要があります。トランザクションの XID はバイトアレイとして保存されます。
バグを報告する

18.6.2. トランザクションリカバリーについて
リンクのコピー

トランザクションマネージャーはリカバリー処理を調整し、操作の完了に手作業の介入が必要となるトランザクションを判断するため JBoss Data Grid と共に動作します。この処理はトランザクションリカバリーと呼ばれます。
バグを報告する

18.6.3. トランザクションリカバリーを有効にする
リンクのコピー

JBoss Data Grid では、トランザクションリカバリーがデフォルトで無効になっています。無効にすると、トランザクションマネージャーは手作業による介入が必要なトランザクションを判断できなくなります。
XML の使用

次のように XML 設定を使用し、トランザクションリカバリーを有効にします。 

<transaction useEagerLocking="true" eagerLockSingleNode="true">
    <recovery enabled="true" recoveryInfoCacheName="noRecovery"/>
</transaction>
Copy to Clipboard Toggle word wrap
recoveryInfoCacheName 属性は任意です。
プログラミングによる設定

次のように Fluent Configuration API を介してトランザクションリカバリーを有効にすることもできます。

手順18.2 プログラミングによるトランザクションリカバリーの設定

  1. JBoss Data Grid のトランザクションリカバリーを有効にするには .recovery を呼び出します。 
    configuration.fluent().transaction().recovery();
    Copy to Clipboard Toggle word wrap
  2. トランザクションリカバリーの状態を確認するには、次のプログラミング設定を使用します。 
    boolean isRecoveryEnabled = configuration.isTransactionRecoveryEnabled();
    Copy to Clipboard Toggle word wrap
  3. JBoss Data Grid のトランザクションリカバリーを無効にするには、次のプログラミング設定を使用します。 
    configuration.fluent().transaction().recovery().disable();
    Copy to Clipboard Toggle word wrap
トランザクションリカバリーはキャッシュごとに有効または無効にすることが可能です。例えば、トランザクションはトランザクションリカバリーが有効な状態で 1 つのキャッシュにわたり、トランザクションリカバリーが無効な状態で他のキャッシュにわたることが可能です。
バグを報告する

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

JBoss Data Grid におけるトランザクションリカバリープロセスの概要は次の通りです。

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

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

18.6.5. トランザクションリカバリーの例
リンクのコピー

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

例18.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 エントリー間の不整合を調整するために使用されます。
バグを報告する

18.6.6. トランザクションメモリーおよび JMX サポート
リンクのコピー

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

18.6.7. 強制コミットおよびロールバック操作
リンクのコピー

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

18.6.8. トランザクションおよび例外
リンクのコピー

キャッシュメソッドが JTA トランザクションのスコープ内で CacheException (または、CacheException のサブクラス) を返すと、トランザクションはロールバックするよう自動的にマークされます。
バグを報告する

18.7. デッドロックの検出
リンクのコピー

18.7.1. デッドロックの検出について
リンクのコピー

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

18.7.2. デッドロック検出を有効にする
リンクのコピー

JBoss Data Grid のデッドロック検出はデフォルトでは disabled に設定されていますが、以下を追加して namedCache 設定要素を使用すると、デッドロック検出を有効にし、各キャッシュに対して設定を行うことが可能です。 
<deadlockDetection enabled="true" spinDuration="1000"/>
Copy to Clipboard Toggle word wrap
デッドロック検出は個別のキャッシュへのみ適用できます。JBoss Data Grid は複数のキャッシュに適用されたデッドロックを検出できません。

注記

JBoss Data Grid では、ライブラリモードでのみデッドロック検出を設定できます。この設定はリモートクライアントサーバーモードでは使用できません。
バグを報告する

第19章 マーシャリング
リンクのコピー

19.1. マーシャリングについて
リンクのコピー

マーシャリングとは、Java オブジェクトを回線上で転送可能な形式に変換するプロセスのことです。アンマーシャリングはこれとは逆のプロセスで、回線上で転送可能な形式から読み取られたデータを Java オブジェクトに変換することを言います。
バグを報告する

19.2. マーシャリングの利点
リンクのコピー

JBoss Data Grid は、次の目的でマーシャリングとアンマーシャリングを使用します。
  • クラスター内の他の JBoss Data Grid ノードへ送信するため、データを変換します。
  • 基礎のキャッシュストアに格納するためデータを変換します。
バグを報告する

19.3. マーシャリングフレームワークについて
リンクのコピー

JBoss Data Grid は JBoss Marshalling Framework を使用して Java POJO をマーシャリングおよびアンマーシャリングします。JBoss Marshalling Framework は優れたパフォーマンスを提供するため、Java のシリアライゼーションの代わりに使用されます。さらに、JBoss Marshalling Framework は Java クラスを含む Java POJO を効率的にマーシャリングできます。
Java Marshalling Framework は、標準的な java.io.ObjectOutputStream および java.io.ObjectInputStream よりも高パフォーマンスな java.io.ObjectOutput および java.io.ObjectInput 実装を使用します。
バグを報告する

19.4. シリアライズ不可能なオブジェクトのサポート
リンクのコピー

JBoss Data Grid がシリアライズ不可能なオブジェクトのストレージをサポートするかどうかはユーザーに共通する懸念事項です。JBoss Data Grid では、シリアライズ不可能なキーと値のオブジェクトに対してマーシャリングはサポートされます。ユーザーはシリアライズ不可能なオブジェクトにエクスタナライザー実装を提供できます。
Serializable または Externalizable サポートをクラスに導入できない場合、一例として XStream を使用してシリアライズ不可能なオブジェクトを JBoss Data Grid に格納できる文字列に変換し、対応することもできます。

注記

XStream では、必要となる XML 変換のため、キーと値のオブジェクトを格納する処理が遅くなります。
バグを報告する

19.5. トラブルシューティング
リンクのコピー

19.5.1. マーシャリングのトラブルシューティング
リンクのコピー

JBoss Data Grid では、ユーザーオブジェクトをマーシャリングまたはアンマーシャリングする時にマーシャリングレイヤーと JBoss Marshalling によってエラーが発生することがあります。問題をデバッグできるようにするため、例外スタックトレースに詳細情報が含まれます。
このようなスタックトレースの例は次の通りです。 
java.io.NotSerializableException: java.lang.Object
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:857)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:407)
at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeObject(ReplicableCommandExternalizer.java:54)
at org.infinispan.marshall.jboss.ConstantObjectTable$ExternalizerAdapter.writeObject(ConstantObjectTable.java:267)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:143)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:407)
at org.infinispan.marshall.jboss.JBossMarshaller.objectToObjectStream(JBossMarshaller.java:167)
at org.infinispan.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:92)
at org.infinispan.marshall.VersionAwareMarshaller.objectToByteBuffer(VersionAwareMarshaller.java:170)
at org.infinispan.marshall.VersionAwareMarshallerTest.testNestedNonSerializable(VersionAwareMarshallerTest.java:415)
Caused by: an exception which occurred:
in object java.lang.Object@b40ec4
in object org.infinispan.commands.write.PutKeyValueCommand@df661da7
... Removed 22 stack frames
Copy to Clipboard Toggle word wrap
オブジェクトメッセージとスタックトレースは同様に読み取りされます。最も高いオブジェクトは最も内側にあるオブジェクトで、最も低いオブジェクトは最も外側にあるオブジェクトです。
上記の例は、java.lang.Object@b40ec4 はシリアライズ可能でないため、org.infinispan.commands.write.PutKeyValueCommand インスタンス内の java.lang.Object インスタンスはシリアライズできないことを示しています。
しかし、DEBUG または TRACE ロギングレベルが有効である場合、スタックトレースにあるオブジェクトの toString() 表現がマーシャリング例外に含まれます。このような状況を表す例は次の通りです。 
java.io.NotSerializableException: java.lang.Object
...
Caused by: an exception which occurred:
in object java.lang.Object@b40ec4
-> toString = java.lang.Object@b40ec4
in object org.infinispan.commands.write.PutKeyValueCommand@df661da7
->  toString = PutKeyValueCommand{key=k, value=java.lang.Object@b40ec4,  putIfAbsent=false, lifespanMillis=0, maxIdleTimeMillis=0}
Copy to Clipboard Toggle word wrap
アンマーシャリング例外に対するこのレベルの情報を表示するのは、リソース的に高価になります。しかし、可能な場合、JBoss Data Grid はクラスタイプの情報を表示します。以下は、このようなレベルの情報が表示された例を表しています。 
java.io.IOException: Injected failue!
at org.infinispan.marshall.VersionAwareMarshallerTest$1.readExternal(VersionAwareMarshallerTest.java:426)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1172)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:273)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:210)
at org.jboss.marshalling.AbstractUnmarshaller.readObject(AbstractUnmarshaller.java:85)
at org.infinispan.marshall.jboss.JBossMarshaller.objectFromObjectStream(JBossMarshaller.java:210)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:104)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:177)
at org.infinispan.marshall.VersionAwareMarshallerTest.testErrorUnmarshalling(VersionAwareMarshallerTest.java:431)
Caused by: an exception which occurred:
in object of type org.infinispan.marshall.VersionAwareMarshallerTest$1
Copy to Clipboard Toggle word wrap
上記の例では、内部クラス org.infinispan.marshall.VersionAwareMarshallerTest$1 のインスタンスがアンマーシャリングされた時に IOException がスローされます。
DEBUG または TRACE ロギングレベルが有効な場合、マーシャリング例外と似た方法で、クラスタイプのクラスローダー情報が提供されます。このクラスローダー情報の例は次の通りです。 
java.io.IOException: Injected failue!
...
Caused by: an exception which occurred:
in object of type org.infinispan.marshall.VersionAwareMarshallerTest$1
-> classloader hierarchy:
-> type classloader = sun.misc.Launcher$AppClassLoader@198dfaf
->...file:/opt/eclipse/configuration/org.eclipse.osgi/bundles/285/1/.cp/eclipse-testng.jar
->...file:/opt/eclipse/configuration/org.eclipse.osgi/bundles/285/1/.cp/lib/testng-jdk15.jar
->...file:/home/galder/jboss/infinispan/code/trunk/core/target/test-classes/ 
->...file:/home/galder/jboss/infinispan/code/trunk/core/target/classes/ 
->...file:/home/galder/.m2/repository/org/testng/testng/5.9/testng-5.9-jdk15.jar
->...file:/home/galder/.m2/repository/net/jcip/jcip-annotations/1.0/jcip-annotations-1.0.jar
->...file:/home/galder/.m2/repository/org/easymock/easymockclassextension/2.4/easymockclassextension-2.4.jar
->...file:/home/galder/.m2/repository/org/easymock/easymock/2.4/easymock-2.4.jar
->...file:/home/galder/.m2/repository/cglib/cglib-nodep/2.1_3/cglib-nodep-2.1_3.jar
->...file:/home/galder/.m2/repository/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar
->...file:/home/galder/.m2/repository/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar
->...file:/home/galder/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar
->...file:/home/galder/.m2/repository/jgroups/jgroups/2.8.0.CR1/jgroups-2.8.0.CR1.jar
->...file:/home/galder/.m2/repository/org/jboss/javaee/jboss-transaction-api/1.0.1.GA/jboss-transaction-api-1.0.1.GA.jar
->...file:/home/galder/.m2/repository/org/jboss/marshalling/river/1.2.0.CR4-SNAPSHOT/river-1.2.0.CR4-SNAPSHOT.jar
->...file:/home/galder/.m2/repository/org/jboss/marshalling/marshalling-api/1.2.0.CR4-SNAPSHOT/marshalling-api-1.2.0.CR4-SNAPSHOT.jar
->...file:/home/galder/.m2/repository/org/jboss/jboss-common-core/2.2.14.GA/jboss-common-core-2.2.14.GA.jar
->...file:/home/galder/.m2/repository/org/jboss/logging/jboss-logging-spi/2.0.5.GA/jboss-logging-spi-2.0.5.GA.jar
->...file:/home/galder/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar
->...file:/home/galder/.m2/repository/com/thoughtworks/xstream/xstream/1.2/xstream-1.2.jar
->...file:/home/galder/.m2/repository/xpp3/xpp3_min/1.1.3.4.O/xpp3_min-1.1.3.4.O.jar
->...file:/home/galder/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.3/jaxb-impl-2.1.3.jar
-> parent classloader = sun.misc.Launcher$ExtClassLoader@1858610
->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/localedata.jar
->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/sunpkcs11.jar
->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/sunjce_provider.jar
->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/dnsns.jar
... Removed 22 stack frames
Copy to Clipboard Toggle word wrap
バグを報告する

19.5.2. ステートレシーバーの EOFExceptions
リンクのコピー

ステート転送中、ステートレシーバーが Read past end of file であるという内容の EOFException がログに記録された場合、ステートプロバイダーがステートを生成する時にエラーが発生するかどうかによって対応することが可能です。例えば、ステートプロバイダーが現在ステートをノードに提供している場合、他のノードがステートを要求すると、ステートジェネレーターのログには以下が含まれる可能性があります。 
2010-12-09 10:26:21,533 20267 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (STREAMING_STATE_TRANSFER-sender-1,Infinispan-Cluster,NodeJ-2368:) Caught while responding to state transfer request
org.infinispan.statetransfer.StateTransferException: java.util.concurrent.TimeoutException: Could not obtain exclusive processing lock
     at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:175)
     at org.infinispan.remoting.InboundInvocationHandlerImpl.generateState(InboundInvocationHandlerImpl.java:119)
     at org.infinispan.remoting.transport.jgroups.JGroupsTransport.getState(JGroupsTransport.java:586)
     at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:691)
     at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:772)
     at org.jgroups.JChannel.up(JChannel.java:1465)
     at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:954)
     at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:478)
     at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderHandler.process(STREAMING_STATE_TRANSFER.java:653)
     at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderThreadSpawner$1.run(STREAMING_STATE_TRANSFER.java:582)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
     at java.lang.Thread.run(Thread.java:680)
Caused by: java.util.concurrent.TimeoutException: Could not obtain exclusive processing lock
     at org.infinispan.remoting.transport.jgroups.JGroupsDistSync.acquireProcessingLock(JGroupsDistSync.java:71)
     at org.infinispan.statetransfer.StateTransferManagerImpl.generateTransactionLog(StateTransferManagerImpl.java:202)
     at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:165)
     ... 12 more
Copy to Clipboard Toggle word wrap
この例外は、ステートジェネレーターがトランザクションログを生成できなかったため、書き込み中の出力が閉じられたことを意味しています。このような状況で、送信側によって書き込まれなかったトランザクションログの読み取りに失敗した場合、ステートレシーバーは通常次のような EOFException をログに表示します。 
2010-12-09 10:26:21,535 20269 TRACE [org.infinispan.marshall.VersionAwareMarshaller] (Incoming-2,Infinispan-Cluster,NodeI-38030:) Log exception reported
java.io.EOFException: Read past end of file
     at org.jboss.marshalling.AbstractUnmarshaller.eofOnRead(AbstractUnmarshaller.java:184)
     at org.jboss.marshalling.AbstractUnmarshaller.readUnsignedByteDirect(AbstractUnmarshaller.java:319)
     at org.jboss.marshalling.AbstractUnmarshaller.readUnsignedByte(AbstractUnmarshaller.java:280)
     at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:207)
     at org.jboss.marshalling.AbstractUnmarshaller.readObject(AbstractUnmarshaller.java:85)
     at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:175)
     at org.infinispan.marshall.VersionAwareMarshaller.objectFromObjectStream(VersionAwareMarshaller.java:184)
     at org.infinispan.statetransfer.StateTransferManagerImpl.processCommitLog(StateTransferManagerImpl.java:228)
     at org.infinispan.statetransfer.StateTransferManagerImpl.applyTransactionLog(StateTransferManagerImpl.java:250)
     at org.infinispan.statetransfer.StateTransferManagerImpl.applyState(StateTransferManagerImpl.java:320)
     at org.infinispan.remoting.InboundInvocationHandlerImpl.applyState(InboundInvocationHandlerImpl.java:102)
     at org.infinispan.remoting.transport.jgroups.JGroupsTransport.setState(JGroupsTransport.java:603)
        ...
Copy to Clipboard Toggle word wrap
このエラーが発生すると、ステートレシーバーは正常に完了するまで毎数秒ごとにこの操作を試行します。ほとんどの場合、最初の試行後にステートジェネレーターは 2 つ目のノードの処理を完了し、想定通りステートを完全に受け入れます。
バグを報告する

第20章 JGroups インターフェース
リンクのコピー

20.1. JGroups インターフェースについて
リンクのコピー

JGroups は、JBoss Data Grid インスタンスを接続するために使用される基礎のグループ通信ライブラリです。JGroups では、特定 (未知の) IP アドレスではなく、インターフェースタイプへユーザーがバインドできるようにします。
バグを報告する

20.2. JGroups インターフェースの設定
リンクのコピー

JGroups インターフェースを設定する前に、次のように JGroups 設定ファイルの bind_addr プロパティーをキーワードに設定します。ドット付き 10 進法または記号の IP アドレスは用いません。 
<socket-binding name="jgroups-udp" ...  interface="site-local"/>
Copy to Clipboard Toggle word wrap
その後、次のように JGroups インターフェースを設定します。 
<interfaces>
 <interface name="link-local"><link-local-address/></interface>
 <interface name="site-local"><site-local-address/></interface>
 <interface name="global"><any-address/></interface>
 <interface name="non-loopback"><not><loopback/></not></interface>
</interfaces>
Copy to Clipboard Toggle word wrap
例に使用される設定値は次の通りです。
  • link-local: 169.x.x.x または 254.x.x.x アドレスを使用します。1 つのボックス内のトラフィックに適しています。
  • site-local: 192.168.x.x のようなプライベート IP アドレスを使用します。これにより、GoGrid や同様のプロバイダーより課金される追加の帯域幅が発生しないようにします。
  • global: パブリック IP アドレスを選択します。レプリケーショントラフィックへ使用しないようにしてください。
  • non-loopback: 127.x.x.x 以外のアドレスで、アクティブなインターフェースで最初に見つかったアドレスを使用します。
バグを報告する

20.3. ソケットのバインディグについて
リンクのコピー

20.3.1. グループおよび個別のソケットバインディングについて
リンクのコピー

グループインターフェースを使用すると、指定のソケットバインディンググループ内の全ソケットバインディングをバインドしたり、個別のソケットをバインドしたりすることができます。
バグを報告する

20.3.2. 単一のソケットをバインドする例
リンクのコピー

以下は、JGroups インターフェースのソケットバインディングを使用し、socket-binding 要素を用いて個別のソケットをバインドする例を表しています。 
<socket-binding name="jgroups-udp" ... interface="site-local"/>
Copy to Clipboard Toggle word wrap
バグを報告する

20.3.3. ソケットのグループをバインドする例
リンクのコピー

以下は、JGroups インターフェースのソケットバインディングを使用し、socket-binding-group 要素を用いてグループをバインドする例を表しています。 
<socket-binding-group name="ha-sockets" default-interface="global"> ... </socket-binding-group>
Copy to Clipboard Toggle word wrap
バグを報告する

20.4. クラスターモードの JGroups
リンクのコピー

20.4.1. クラスタモードにおける JGroups の設定
リンクのコピー

JBoss Data grid がクラスターモードで動作するには、適切な JGroups 設定が必要になります。
プログラミングで JGroups を設定するには、次を使用します。 
GlobalConfiguration gc = new GlobalConfigurationBuilder()
  .transport()
  .defaultTransport() // <<< This call is missing...
  .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 を探します。
バグを報告する

20.4.2. 事前設定された JGroups ファイル
リンクのコピー

20.4.2.1. 事前設定された JGroups ファイルの使用
リンクのコピー
JBoss Data Grid では、事前設定された複数の JGroups ファイルが infinispan-core.jar にパッケージ化され、デフォルトでクラスパス上にて使用可能です。これらのいずれかのファイルを使用するには、jgroups.xml を使用する代わりに使用するファイルの名前を指定します。
JBoss Data Grid に含まれる JGroups 設定ファイルは、プロジェクトの基礎として使用することを目的としています。通常、ネットワークのパフォーマンスを最適化するには、細かな調整が必要となります。
使用可能な設定は次のとおりです。
  • jgroups-udp.xml
  • jgroups-tcp.xml
バグを報告する
20.4.2.2. jgroups-udp.xml
リンクのコピー
jgroups-udp.xml は JBoss Data Grid の事前設定された JGroups ファイルです。
  • jgroups-udp.xml 設定は UDP をトランスポートとして使用し、UDP マルチキャストをディスカバリーに使用します。
  • jgroups-udp.xml 設定は大型のクラスター (101 以上のノード) に適しています。
  • jgroups-udp.xml 設定は、無効化またはレプリケーションモードを使用する場合に適しています。
  • ソケットの非効率な使用を最小限にします。
起動時に特定のシステムプロパティーを JVM に追加すると、一部設定の挙動を変更することが可能です。変更可能な設定は下表の通りです。
Expand
表20.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 不要
バグを報告する
20.4.2.3. jgroups-tcp.xml
リンクのコピー
jgroups-tcp.xml は JBoss Data Grid の事前設定された JGroups ファイルです。
  • jgroups-tcp.xml 設定は TCP をトランスポートとして使用し、UDP マルチキャストをディスカバリーに使用します。
  • jgroups-tcp.xml 設定は、ディストリビューションモードを使用している場合のみ、小型のクラスター (100 ノード未満) への使用に適しています。これは、TCP はポイントツーポイントプロトコルとしての方が効率が良いからです。
他の事前設定された JGroups ファイルと同様に、起動時に特定のシステムプロパティーを JVM に追加すると一部設定の挙動を変更することが可能です。変更可能な設定は下表の通りです。
Expand
表20.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 不要
バグを報告する

第21章 JBoss Data Grid の管理ツール
リンクのコピー

21.1. JMX (Java Management Extensions)
リンクのコピー

21.1.1. Java Management Extensions (JMX) について
リンクのコピー

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

21.1.2. JBoss Data Grid における JMX の使用
リンクのコピー

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

21.1.3. JMX 統計レベル
リンクのコピー

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

21.1.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
バグを報告する

21.1.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
バグを報告する

21.1.6. 複数の 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
バグを報告する

21.1.7. MBean について
リンクのコピー

MBean は、サービス、コンポーネント、デバイス、またはアプリケーションなどの管理可能なリソースを表します。
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
バグを報告する

21.1.8. MBean を理解する
リンクのコピー

キャッシュマネージャーまたはキャッシュレベルで JMX レポートが有効になっている場合、JConsole や VisualVM などの標準的な JMX GUI を使用して 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
ユーザー定義の名前でサポートされていない文字が使用されないようにするため、キャッシュおよびキャッシュマネージャーの名前は引用符で囲まれています。
バグを報告する

21.1.9. デフォルトでない MBean サーバーでの MBean の登録
リンクのコピー

使用されるすべての MBean がデフォルトで登録される場所は、標準の JVM MBeanServer プラットフォームです。ユーザーは代替の MBeanServer インスタンスを設定することもできます。MBeanServerLookup インターフェースを実装して、確実に getMBeanServer() メソッドが希望の (デフォルト以外の) MBeanServer を返すようにします。
デフォルト以外の場所を設定して MBean を登録するには、実装を作成し、クラスの完全修飾名を用いて 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
バグを報告する

21.2. JON (JBoss Operations Network)
リンクのコピー

21.2.1. JBoss Operations Network (JON) について
リンクのコピー

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

21.2.2. JBoss Operations Network (JON) および JMX
リンクのコピー

管理の目的で、JBoss Data Grid は JBoss Operations Network が使用するためにフォーマットされた JMX 統計情報を公開します。
バグを報告する

21.2.3. JBoss Operations Network (JON) の設定
リンクのコピー

JBoss Operations Network を設定して JBoss Data Grid インスタンスを監視には、次の手順に従います。

手順21.1 JBoss Operations Network の設定

  1. JBoss Operations Network をダウンロードしてインストールし、1 つ以上の JBoss Operations Network エージェントを初期化します。JBoss Operations Network エージェントは、JBoss Data Grid インスタンスに関する情報をサーバーへ送信する役割があります。サーバーは受信した情報を GUI を使用して表示します。JBoss Data Grid を実行するマシンに JBoss Operations Network エージェントをインストールすることが推奨設定となります。複数のマシンが使用できる場合、エージェントは各マシン上に存在することができます。
  2. 最新の JBoss Data Grid のバージョンをダウンロードします。 modules/rhq-plugin ディレクトリで JBoss Operations Network のプラグイン jar ファイル (infinispan-rhq-plugin.jar) を見つけます。
  3. これで、JBoss Operations Network が JBoss Data Grid インスタンスを監視できるようにします。
  4. JBoss Operations Network は各 JBoss Data Grid インスタンスを見つけた後、各キャッシュマネージャーに対して新しいリソースを JBoss Operations Network サーバーのインベントリー / ディスカバリーキューに表示します。
  5. 表示されたリソースをインポートします。キャッシュマネージャーはキャッシュマネージャーで実行されているキャッシュの数だけ、子キャッシュリソースを表示します。
結果

JBoss Operations Network を使用して JBoss Data Grid を監視できるようになります。

バグを報告する

21.2.4. JBoss Operations Network のプラグインクイックスタート
リンクのコピー

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

21.2.5. リモート JMX ポートの値
リンクのコピー

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

付録A 参照
リンクのコピー

A.1. Apache Lucene Index について
リンクのコピー

Apache Lucene は、検索可能なデータを使用して索引を作成するテキストベースの検索フレームワークです。データに対して Apache Lucene Index がクエリされます。
バグを報告する

A.2. 一貫性について
リンクのコピー

一貫性とは、あるノード上のデータ記録が他のノード上の同じデータ記録と異なることが可能であるかどうかを記述するポリシーのことです。
例えば、ネットワークの速度が原因で、マスターノード上で実行された書き込み操作がストアの他のノードでは実行されていない場合があります。強い一貫性保証は、完全にレプリケートされていないデータがアプリケーションに返されないようにします。
バグを報告する

A.3. 一貫性保証について
リンクのコピー

全所有者ではなく単一所有者のロックであるにも関わらず、JBoss Data Grid の一貫性保証は維持されます。一貫性保証とは次のようなことを言います。
  1. キー K はノード {A,B} へハッシュ化されます。トランザクション TX1 は、例えばノード A 上の K ロックを取得します。
  2. 他のキャッシュへのアクセスが、ノード B または他のノードで発生すると、TX2 が K をロックしようとしますが、トランザクション TX1 が既に K のロックを保持しているため、タイムアウトが発生しロックの取得に失敗します。
キー K のロックはトランザクションの発生元に関係なく、常にクラスターの同じノード上で取得されるため、このロックの取得は常に失敗します。
バグを報告する

A.4. Java Management Extensions (JMX) について
リンクのコピー

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

A.5. JBoss Cache について
リンクのコピー

JBoss Cache は、ツリー構造のクラスター化されたトランザクションキャッシュで、スタンドアロンのクラスター化されていない環境でも使用できます。頻繁にアクセスされるデータをインメモリでキャッシュし、Java Transactional API (JTA) との互換、エビクション、および永続性などのエンタープライズ機能の提供中に、データの読み出しや計算のボトルネックが発生しないようにします。
JBoss Cache は Infinispan と JBoss Data Grid の前身となるものです。
バグを報告する

A.6. JSON について
リンクのコピー

JavaScript Object Notation (JSON) はライトウェイトなデータ交換形式です。人間と機械の両方が JSON を読み書きできます。JSON は JavaScript から派生していますが、言語に依存しません。
バグを報告する

A.7. 戻り値について
リンクのコピー

キャッシュ操作によって返される値は戻り値と呼ばれます。JBoss Data Grid では、使用されるキャッシュモードや同期または非同期通信が使用されるかどうかに関係なく、これらの戻り値は信頼性を維持します。
バグを報告する

A.8. 実行可能インターフェースについて
リンクのコピー

実行可能インターフェースは、クラスのコードのアクティブな部分を実行する単一の run() メソッドを宣言します。実行可能オブジェクトは、スレッドコンストラクターに渡された後、独自のスレッドでの実行が可能です。
バグを報告する

A.9. 2 相コミット (2PC) について
リンクのコピー

2 相コミットプロトコル (2PC) は、分散トランザクションをアトミックにコミットまたはロールバックするために使用される合意プロトコルです。ネットワークノードや通信の障害など一時的なシステム障害が発生しても正常に動作するため、幅広く使用されています。
バグを報告する

A.10. キーバリューペアについて
リンクのコピー

キーバリューペア (KVP) とは、キーと値で構成されるデータセットのことです。
  • キーは特定のデータエントリーに一意であり、関連する特定エントリーのデータ属性によって構成されます。
  • バリュー (値) は、キーによって割り当てられ、キーによって識別されるデータです。
バグを報告する

A.11. エクスターナライザー
リンクのコピー

A.11.1. エクスターナライザーについて
リンクのコピー

Externalizer クラスは、以下のことを行えるクラスです。
  • 該当するオブジェクトタイプをバイトアレイにマーシャリングします。
  • バイトアレイの内容をオブジェクトタイプのインスタンスにマーシャリング解除します。
エクスターナライザーは JBoss Data Grid により使用され、ユーザーはオブジェクトタイプをどのようにシリアライズするかを指定できます。JBoss Data Grid で使用されるマーシャリングインフラストラクチャーは、JBoss Marshalling に基づいて構築され、効率的なペイロード配信を提供し、ストリームをキャッシュすることを可能にします。ストリームキャッシングを使用すると、データに複数回アクセスできますが、通常はストリームは 1 度だけ読み取ることができます。
バグを報告する

A.11.2. 内部エクスターナライザー実装アクセス
リンクのコピー

Externalizable オブジェクトは JBoss Data Grid エクスターナライザー実装にアクセスしないようにする必要があります。このための間違ったメソッドの例を以下に示します。 
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
バグを報告する

A.12. ハッシュ領域の割り当て
リンクのコピー

A.12.1. ハッシュ領域の割り当てについて
リンクのコピー

JBoss Data Grid は、使用可能なハッシュ領域全体の一部を各ノードに割り当てる役割があります。エントリーを格納する必要がある後続の操作中、JBoss Data Grid は関連するキーのハッシュを作成し、その部分のハッシュ領域を所有するノード上にエントリーを格納します。
バグを報告する

A.12.2. ハッシュ領域におけるキーの検索
リンクのコピー

JBoss Data Grid は常にアルゴリズムを使用してハッシュ領域のキーを見つけます。そのため、キーを格納するノードを手動で指定することはありません。このスキームにより、キーの所有者情報を配信しなくても、すべてのノードが特定のキーを所有するノードを判断することができます。このスキームによりオーバヘッドの量が削減されます。さらに重要なことに、ノードの障害時に所有者情報をレプリケートする必要がないため、冗長性が向上されます。
バグを報告する

A.12.3. 完全なバイトアレイの要求
リンクのコピー

バイトアレイの部分的な内容ではなく、完全なバイトアレイを JBoss Data Grid が返すように要求する方法はあるのでしょうか。

デフォルトでは、必要のない巨大なバイトアレイを出力しないように、JBoss Data Grid はバイトアレイの一部のみをログに出力します。以下の場合にバイトアレイがログに出力されます。

  • JBoss Data Grid のキャッシュにレイジーデシリアライゼーションが設定されている場合。レイジーデシリアライゼーションは JBoss Data Grid のリモートクライアントサーバーモードでは使用できません。
  • Memcached または Hot Rod サーバーが実行されている場合。
このような場合、最初から 10 ポジションまでのバイトアレイがログに表示されます。バイトアレイの全内容をログに表示するには、起動時に -Dinfinispan.arrays.debug=true システムプロパティーを渡します。

例A.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
バグを報告する

付録B 改訂履歴
リンクのコピー

改訂履歴
改訂 1.0.0-29Mon Feb 03 2014Misha Husnain Ali
Built from Content Specification: 11621, Revision: 581903 by mhusnain

法律上の通知
リンクのコピー

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トップに戻る