Hot Rod Java クライアントガイド
Hot Rod Java クライアントの設定および使用
概要
Red Hat Data Grid リンクのコピーリンクがクリップボードにコピーされました!
Data Grid は、高性能の分散型インメモリーデータストアです。
- スキーマレスデータ構造
- さまざまなオブジェクトをキーと値のペアとして格納する柔軟性があります。
- グリッドベースのデータストレージ
- クラスター間でデータを分散および複製するように設計されています。
- エラスティックスケーリング
- サービスを中断することなく、ノードの数を動的に調整して要件を満たします。
- データの相互運用性
- さまざまなエンドポイントからグリッド内のデータを保存、取得、およびクエリーします。
Data Grid のドキュメント リンクのコピーリンクがクリップボードにコピーされました!
Data Grid のドキュメントは、Red Hat カスタマーポータルで入手できます。
Data Grid のダウンロード リンクのコピーリンクがクリップボードにコピーされました!
Red Hat カスタマーポータルで Data Grid Software Downloads にアクセスします。
Data Grid ソフトウェアにアクセスしてダウンロードするには、Red Hat アカウントが必要です。
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Hot Rod Java クライアント リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod Java クライアント API を介してリモートで Data Grid にアクセスします。
1.1. Hot Rod プロトコル リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod は、Data Grid が次の機能を備えた高性能のクライアントサーバー相互作用を提供するバイナリー TCP プロトコルです。
- 負荷分散Hot Rod クライアントは、さまざまな戦略を使用して、Data Grid クラスター間でリクエストを送信できます。
- フェイルオーバーHot Rod クライアントは、Data Grid クラスタートポロジーの変更を監視し、使用可能なノードに自動的に切り替えることができます。
- 効率的なデータの場所。Hot Rod クライアントは、主要な所有者を見つけてそれらのノードに直接要求を行うことができるため、待ち時間が短縮されます。
1.1.1. クライアントのインテリジェンス リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod クライアントは、インテリジェンスメカニズムを使用して、Data Grid Server クラスターにリクエストを効率的に送信します。
BASIC インテリジェンス
クライアントは、ノードの参加や離脱など、Data Grid クラスターのトポロジー変更イベントを受け取らず、クライアント設定に追加した Data Grid サーバーネットワークの場所のリストのみを使用します。
TOPOLOGY_AWARE インテリジェンス
クライアントは、Data Grid クラスターのトポロジー変更イベントを受け取って保存し、ネットワーク上の Data Grid サーバーを動的に追跡します。
クラスタートポロジーを受け取るために、クライアントは起動時に少なくとも 1 つの Hot Rod サーバーのネットワークロケーション (IP アドレスまたはホスト名) を必要とします。クライアントが接続した後、Data Grid Server はトポロジーをクライアントに送信します。Data Grid Server ノードがクラスターに参加またはクラスターから離脱すると、Data Grid は更新されたトポロジーをクライアントに送信します。
HASH_DISTRIBUTION_AWARE インテリジェンス
クライアントは、特定のキーを格納しているノードをクライアントが識別できるようにするハッシュ情報に加えて、Data Grid クラスターのトポロジー変更イベントを受け取って格納します。
たとえば、put(k,v) オペレーションについて考えてみましょう。クライアントはキーのハッシュ値を計算して、データが存在する正確な Data Grid Server ノードを見つけられるようにします。その後、クライアントはそのノードに直接接続して、読み取りおよび書き込み操作を実行できます。
HASH_DISTRIBUTION_AWARE インテリジェンスの利点は、Data Grid Server がキーハッシュに基づいて値を検索する必要がないことです。これにより、サーバー側のリソースの使用量が少なくなります。もう 1 つの利点は、クライアントが追加のネットワークラウンドトリップを行う必要がないため、Data Grid Server がクライアントの要求により迅速に応答することです。
設定
ConfigurationBuilder
ConfigurationBuilder builder = new ConfigurationBuilder(); builder.clientIntelligence(ClientIntelligence.BASIC);
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.clientIntelligence(ClientIntelligence.BASIC);
hotrod-client.properties
infinispan.client.hotrod.client_intelligence=BASIC
infinispan.client.hotrod.client_intelligence=BASIC
1.1.2. バランシングの要求 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod Java クライアントは、Data Grid サーバークラスターへの要求のバランスを取り、読み取りおよび書き込み操作がノード全体に分散されるようにします。
BASIC または TOPOLOGY_AWARE インテリジェンスを使用するクライアントは、すべての要求に対して要求バランシングを使用します。HASH_DISTRIBUTION_AWARE インテリジェンスを使用するクライアントは、目的のキーを格納するノードに直接要求を送信します。ノードが応答しない場合、クライアントはフォールバックしてバランシングを要求します。
デフォルトのバランシング戦略はラウンドロビンであるため、Hot Rod クライアントは次の例のようにリクエストバランシングを実行します。ここで、 s1、s2、s3 は Data Grid クラスター内のノードです。
カスタムバランシングポリシー
Hot Rod クライアント設定にクラスを追加する場合は、カスタムの FailoverRequestBalancingStrategy 実装を使用できます。
ConfigurationBuilder
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.addServer()
.host("127.0.0.1")
.port(11222)
.balancingStrategy(new MyCustomBalancingStrategy());
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.addServer()
.host("127.0.0.1")
.port(11222)
.balancingStrategy(new MyCustomBalancingStrategy());
hotrod-client.properties
infinispan.client.hotrod.request_balancing_strategy=my.package.MyCustomBalancingStrategy
infinispan.client.hotrod.request_balancing_strategy=my.package.MyCustomBalancingStrategy
1.1.3. クライアントフェイルオーバー リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod クライアントは、Data Grid クラスタートポロジーが変更されたときに自動的にフェイルオーバーできます。たとえば、トポロジー対応の Hot Rod クライアントは、1 つ以上の Data Grid サーバーに障害が発生したことを検出できます。
クラスター化された Data Grid サーバー間のフェイルオーバーに加えて、HotRod クライアントは Data Grid クラスター間でフェイルオーバーをすることができます。
たとえば、ニューヨーク (NYC) で実行している Data Grid クラスターと、ロンドン (LON) で実行している別のクラスターがあるとします。NYCに要求を送信するクライアントは、使用可能なノードがないことを検出したため、LONのクラスターに切り替えます。その後、クライアントは、手動でクラスターを切り替えるか、フェイルオーバーが再度発生するまで、LONへの接続を維持します。
フェイルオーバーを伴うトランザクションキャッシュ
putIfAbsent()、replace()、remove() などの条件付きオペレーションには、厳密なメソッドの戻り保証があります。同様に、一部のオペレーションでは、以前の値を返さないといけない場合があります。
Hot Rod クライアントはフェイルオーバーが可能ですが、トランザクションキャッシュを使用して、操作が部分的に完了せず、異なるノードに競合するエントリーが残らないようにする必要があります。
1.2. Data Grid Maven リポジトリーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Data Grid Java ディストリビューションは Maven から入手できます。
顧客ポータルから Data Grid Maven リポジトリーをダウンロードするか、パブリック Red Hat Enterprise Maven リポジトリーから Data Grid 依存関係をプルできます。
1.2.1. Data Grid Maven リポジトリーのダウンロード リンクのコピーリンクがクリップボードにコピーされました!
パブリック Red Hat Enterprise Maven リポジトリーを使用しない場合は、ローカルファイルシステム、Apache HTTP サーバー、または Maven リポジトリーマネージャーに Data Grid Maven リポジトリーをダウンロードし、インストールします。
手順
- Red Hat カスタマーポータルにログインします。
- Software Downloads for Data Grid に移動します。
- Red Hat Data Grid 8.2 Maven リポジトリーをダウンロードします。
- アーカイブされた Maven リポジトリーをローカルファイルシステムに展開します。
-
README.mdファイルを開き、適切なインストール手順に従います。
1.2.2. Red Hat Maven リポジトリーの追加 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat GA リポジトリーを Maven ビルド環境に組み込み、Data Grid アーティファクトおよび依存関係を取得します。
手順
Red Hat GA リポジトリーを Maven 設定ファイル (通常は
~/.m2/settings.xml) に追加するか、プロジェクトのpom.xmlファイルに直接追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.2.3. Data Grid POM の設定 リンクのコピーリンクがクリップボードにコピーされました!
Maven は、プロジェクトオブジェクトモデル (POM) ファイルと呼ばれる設定ファイルを使用して、プロジェクトを定義し、ビルドを管理します。POM ファイルは XML 形式であり、モジュールとコンポーネントの依存関係、ビルドの順序、および結果となるプロジェクトのパッケージ化と出力のターゲットを記述します。
手順
-
プロジェクト
pom.xmlを開いて編集します。 -
正しい Data Grid バージョンで
version.infinispanプロパティーを定義します。 dependencyManagementセクションにinfinispan-bomを含めます。BOM(Bill of Materials) は、依存関係バージョンを制御します。これにより、バージョンの競合が回避され、プロジェクトに依存関係として追加する Data Grid アーティファクトごとにバージョンを設定する必要がなくなります。
-
pom.xmlを保存して閉じます。
以下の例は、Data Grid のバージョンと BOM を示しています。
次のステップ
必要に応じて、Data Grid アーティファクトを依存関係として pom.xml に追加します。
1.3. Hot Rod Java クライアントの依存関係の追加 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod Java クライアントの依存関係を追加して、プロジェクトに含めます。
前提条件
- Java 8 または Java 11
手順
-
次のように、
pom.xmlの依存関係としてinfinispan-client-hotrodアーティファクトを追加します。
<dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-client-hotrod</artifactId> </dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-client-hotrod</artifactId>
</dependency>
参照資料
第2章 Hot Rod Java クライアント設定 リンクのコピーリンクがクリップボードにコピーされました!
Data Grid は、設定プロパティーを公開する Hot Rod Java クライアント設定 API を提供します。
2.1. Hot Rod クライアント接続の設定 リンクのコピーリンクがクリップボードにコピーされました!
Data Grid Server への Hot Rod Java クライアント接続を設定します。
手順
-
RemoteCacheManagerに渡すか、アプリケーションのクラスパスのhotrod-client.propertiesファイルを使用できることを不変の設定オブジェクトを生成するConfigurationBuilderをクラス使用します。
ConfigurationBuilder
hotrod-client.properties
infinispan.client.hotrod.server_list = 127.0.0.1:11222,192.0.2.0:11222 infinispan.client.hotrod.auth_username = username infinispan.client.hotrod.auth_password = changeme infinispan.client.hotrod.auth_realm = default infinispan.client.hotrod.sasl_mechanism = SCRAM-SHA-512
infinispan.client.hotrod.server_list = 127.0.0.1:11222,192.0.2.0:11222
infinispan.client.hotrod.auth_username = username
infinispan.client.hotrod.auth_password = changeme
infinispan.client.hotrod.auth_realm = default
infinispan.client.hotrod.sasl_mechanism = SCRAM-SHA-512
Hot Rod URI の設定
次のように、URI を使用して Hot Rod クライアント接続を設定することもできます。
ConfigurationBuilder
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.uri("hotrod://username:changeme@127.0.0.1:11222,192.0.2.0:11222?auth_realm=default&sasl_mechanism=SCRAM-SHA-512");
RemoteCacheManager cacheManager = new RemoteCacheManager(builder.build());
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.uri("hotrod://username:changeme@127.0.0.1:11222,192.0.2.0:11222?auth_realm=default&sasl_mechanism=SCRAM-SHA-512");
RemoteCacheManager cacheManager = new RemoteCacheManager(builder.build());
hotrod-client.properties
infinispan.client.hotrod.uri = hotrod://username:changeme@127.0.0.1:11222,192.0.2.0:11222?auth_realm=default&sasl_mechanism=SCRAM-SHA-512
infinispan.client.hotrod.uri = hotrod://username:changeme@127.0.0.1:11222,192.0.2.0:11222?auth_realm=default&sasl_mechanism=SCRAM-SHA-512
クラスパスの外部へのプロパティーの追加
hotrod-client.properties ファイルがアプリケーションのクラスパスにない場合は、次の例のように場所を指定する必要があります。
2.1.1. クライアント設定での Data Grid クラスターの定義 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod クライアント設定で Data Grid クラスターの場所を指定します。
手順
ClusterConfigurationBuilderクラスを使用して、少なくとも 1 つのノードのホスト名とポートとともに少なくとも 1 つの Data Grid クラスター名を指定します。クラスターをデフォルトとして定義し、クライアントが常に最初にクラスターに接続を試みるようにする場合は、
addServers("<host_name>:<port>; <host_name>:<port>")メソッドを使用してサーバーリストを定義します。
複数のクラスター接続
フェールオーバークラスターを含むデフォルトのサーバーリスト
ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder.addServers("hostA1:11222; hostA2:11222")
.addCluster("siteB")
.addClusterNodes("hostB1:11222; hostB2:11223");
RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder.addServers("hostA1:11222; hostA2:11222")
.addCluster("siteB")
.addClusterNodes("hostB1:11222; hostB2:11223");
RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
2.1.2. Data Grid クラスターの手動切り替え リンクのコピーリンクがクリップボードにコピーされました!
Data Grid クラスター間で Hot Rod Java クライアント接続を手動で切り替えます。
手順
RemoteCacheManagerクラスで次のいずれかのメソッドを呼び出します。switchToCluster(clusterName)は、クライアント設定で定義された特定のクラスターに切り替えます。switchToDefaultCluster()は、Data Grid サーバーのリストとして定義されているクライアント設定のデフォルトクラスターに切り替えます。
2.1.3. 接続プールの設定 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod Java クライアントは、Data Grid サーバーへの永続的な接続のプールを保持して、要求ごとに TCP 接続を作成するのではなく、TCP 接続を再利用します。
手順
- 次の例のように、Hot Rod クライアント接続プール設定を設定します。
ConfigurationBuilder
hotrod-client.properties
2.2. Hot Rod エンドポイント認証メカニズム リンクのコピーリンクがクリップボードにコピーされました!
Data Grid は、Hot Rod コネクターを使用して以下の SASL 認証メカニズムをサポートします。
| 認証メカニズム | 説明 | 関連する詳細 |
|---|---|---|
|
|
プレーンテキスト形式の認証情報を使用します。 |
|
|
|
ハッシュアルゴリズムとナンス値を使用します。ホットロッドコネクターは、強度の順に、 |
|
|
|
ハッシュアルゴリズムとナンス値に加えてソルト値を使用します。ホットロッドコネクターは、 |
|
|
|
Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する |
|
|
|
Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する |
|
|
| クライアント証明書を使用します。 |
|
|
|
OAuth トークンを使用し、 |
|
2.2.1. Hot Rod クライアントの認証メカニズムの設定 リンクのコピーリンクがクリップボードにコピーされました!
Data Grid Server は、さまざまなメカニズムを使用して Hot Rod クライアント接続を認証します。
手順
-
AuthenticationConfigurationBuilderクラスのsaslMechanism()メソッド、またはinfinispan.client.hotrod.sasl_mechanismプロパティーを使用して認証メカニズムを指定します。
SCRAM
DIGEST
PLAIN
OAUTHBEARER
EXTERNAL
GSSAPI
基本的なコールバックハンドラー
BasicCallbackHandler は、GSSAPI の例に示されているように、次のコールバックを呼び出します。
-
NameCallbackおよびPasswordCallbackは、クライアントサブジェクトを構築します。 -
AuthorizeCallbackは、SASL 認証中に呼び出されます。
トークンコールバックハンドラーを備えた OAUTHBEARER
次の例のように、TokenCallbackHandler を使用して、OAuth2 トークンが期限切れになる前に更新します。
カスタムの CallbackHandler
Hot Rod クライアントは、SASL メカニズムに認証情報を渡すためにデフォルトの CallbackHandler を設定します。次の例のように、カスタムの CallbackHandler を提供しないといけない場合があります。
カスタムの CallbackHandler は、使用する認証メカニズムに固有のコールバックを処理する必要があります。ただし、考えられる各コールバックタイプの例を提供することは、このドキュメントの範囲を超えています。
2.2.2. GSSAPI ログインコンテキストの作成 リンクのコピーリンクがクリップボードにコピーされました!
GSSAPI メカニズムを使用するには、LoginContextを作成して、Hot Rod クライアント Ticket Granting Ticket (TGT) を取得できるようにする必要があります。
手順
ログイン設定ファイルでログインモジュールを定義します。
gss.conf
GssExample { com.sun.security.auth.module.Krb5LoginModule required client=TRUE; };GssExample { com.sun.security.auth.module.Krb5LoginModule required client=TRUE; };Copy to Clipboard Copied! Toggle word wrap Toggle overflow IBM JDK の場合:
gss-ibm.conf
GssExample { com.ibm.security.auth.module.Krb5LoginModule required client=TRUE; };GssExample { com.ibm.security.auth.module.Krb5LoginModule required client=TRUE; };Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のシステムプロパティーを設定します。
java.security.auth.login.config=gss.conf java.security.krb5.conf=/etc/krb5.conf
java.security.auth.login.config=gss.conf java.security.krb5.conf=/etc/krb5.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記krb5.confは、KDC の場所を提供します。kinitコマンドを使用して、Kerberos で認証し、krb5.confを確認します。
2.3. Hot Rod クライアントの暗号化の設定 リンクのコピーリンクがクリップボードにコピーされました!
Data Grid Server は、SSL/TLS 暗号化を実施し、Hot Rod クライアントに証明書を提示して、信頼を確立し、安全な接続をネゴシエートできます。
Data Grid Server に発行された証明書を検証するには、Hot Rod クライアントでは、完全な証明書チェーンまたは Root CA で始まる部分的なチェーンのいずれかが必要です。サーバー証明書をトラストストアとして Hot Rod クライアントに提供します。
トラストストアを提供する代わりに、共有システム証明書を使用できます。
前提条件
- Hot Rod クライアントが Data Grid Server アイデンティティーを検証するのに使用できるトラストストアを作成します。
- Data Grid Server を設定してクライアント証明書を検証または認証する場合は、必要に応じてキーストアを作成します。
手順
-
trustStoreFileName()メソッドおよびtrustStorePassword()メソッドまたは対応するプロパティーを使用して、トラストストアをクライアント設定に追加します。 クライアント証明書認証を設定する場合は、次のようにします。
-
keyStoreFileName()メソッドおよびkeyStorePassword()メソッドまたは対応するプロパティーを使用して、クライアント設定にキーストアを追加します。 -
EXTERNAL認証メカニズムを使用するようにクライアントを設定します。
-
ConfigurationBuilder
hotrod-client.properties
次のステップ
クライアントトラストストアを $RHDG_HOME/server/conf ディレクトリーに追加し、必要に応じてそれを使用するように Data Grid Server を設定します。
2.4. Hot Rod クライアント統計の監視 リンクのコピーリンクがクリップボードにコピーされました!
リモートおよびニアキャッシュのヒットとミス、および接続プールの使用状況を含む Hot Rod クライアント統計を有効にします。
手順
-
StatisticsConfigurationBuilderクラスを使用して、Hot Rod クライアント統計を有効にして設定します。
2.5. ニアキャッシュ リンクのコピーリンクがクリップボードにコピーされました!
ニアキャッシュは Hot Rod クライアントに対してローカルであり、最近使用されたデータを格納し、すべての読み取り操作でネットワークを通過する必要がないため、パフォーマンスが大幅に向上します。
ニアキャッシュ:
-
get()またはgetVersioned()の呼び出しで入力されます。 -
クライアントリスナーを登録して、Data Grid Server のリモートキャッシュでエントリーが更新または削除されたときにエントリーを無効にします。
エントリーが無効化された後に要求された場合、クライアントはそれらをリモートキャッシュから再度取得する必要があります。 - クライアントが別のサーバーにフェイルオーバーするとクリアされます。
バインドされているニアキャッシュ
キャッシュに含めることができるエントリーの最大数を指定して、常にバウンドニアキャッシュを使用する必要があります。ニアキャッシュがエントリーの最大数に達すると、古いエントリーを削除するため自動的に削除が行われます。そのため、クライアント JVM の境界内にキャッシュサイズを手動で維持する必要はありません。
ニアキャッシュ読み取りはエントリーの最終アクセス時間を伝播しないため、ニアキャッシュで最大アイドル有効期限を使用しないでください。
Bloom フィルター
Bloom フィルターは、無効化メッセージの総数を減らすことにより、書き込み操作のパフォーマンスを最適化します。
Bloom フィルター:
- Data Grid Server に存在し、クライアントが要求したエントリーを追跡します。
-
サーバーごとに最大 1 つのアクティブな接続があり、
WAIT枯渇アクションを使用する接続プール設定が必要です。 - 無制限のニアキャッシュでは使用できません。
2.5.1. ニアキャッシュの設定 リンクのコピーリンクがクリップボードにコピーされました!
ニアキャッシュで Hot Rod Java クライアントを設定し、最近使用されたデータをクライアント JVM に保存します。
手順
- Hot Rod Java クライアント設定を開きます。
nearCacheMode(NearCacheMode.INVALIDATED)メソッドでニアキャッシュを実行するように各キャッシュを設定します。注記Data Grid は、グローバルニアキャッシュ設定プロパティーを提供します。ただし、これらのプロパティーは非推奨となり、使用すべきではありませんが、代わりにキャッシュごとにニアキャッシュを設定する必要があります。
-
nearCacheMaxEntries()メソッドでエビクションが発生する前に、ニアキャッシュが保持できるエントリーの最大数を指定します。 -
nearCacheUseBloomFilter()メソッドでニアキャッシュの bloom フィルターを有効にします。
2.6. 戻り値の強制 リンクのコピーリンクがクリップボードにコピーされました!
不必要にデータを送信しないようにするために、リモートキャッシュでの書き込み操作は、以前の値ではなく null を返します。
たとえば、以下のメソッド呼び出しでは、キーに対する以前の値は返されません。
V remove(Object key); V put(K key, V value);
V remove(Object key);
V put(K key, V value);
ただし、デフォルトの動作を変更して、呼び出しがキーの以前の値を返すようにすることができます。
手順
- 次のいずれかの方法で、メソッド呼び出しがキーの以前の値を返すように Hot Rod クライアントを設定します。
FORCE_RETURN_VALUE フラグ
cache.withFlags(Flag.FORCE_RETURN_VALUE).put("aKey", "newValue")
cache.withFlags(Flag.FORCE_RETURN_VALUE).put("aKey", "newValue")
キャッシュごと
ConfigurationBuilder builder = new ConfigurationBuilder();
// Return previous values for keys for invocations for a specific cache.
builder.remoteCache("mycache")
.forceReturnValues(true);
ConfigurationBuilder builder = new ConfigurationBuilder();
// Return previous values for keys for invocations for a specific cache.
builder.remoteCache("mycache")
.forceReturnValues(true);
hotrod-client.properties
# Use the "*" wildcard in the cache name to return previous values # for all caches that start with the "somecaches" string. infinispan.client.hotrod.cache.somecaches*.force_return_values = true
# Use the "*" wildcard in the cache name to return previous values
# for all caches that start with the "somecaches" string.
infinispan.client.hotrod.cache.somecaches*.force_return_values = true
2.7. Hot Rod クライアントでのリモートキャッシュの作成 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod Java クライアントが存在しないキャッシュにアクセスしようとすると、remoteCacheManager.getCache("myCache") 呼び出しに対して null を返します。このシナリオを回避するには、キャッシュ設定を使用して最初のアクセス時にキャッシュを作成するように Hot Rod クライアントを設定します。
手順
-
ConfigurationBuilderでremoteCache()メソッドを使用するか、hotrod-client.propertiesでconfigurationおよびconfiguration_uriプロパティーを使用します。
ConfigurationBuilder
hotrod-client.properties
infinispan.client.hotrod.cache.another-cache.configuration=<distributed-cache name=\"another-cache\"/> infinispan.client.hotrod.cache.[my.other.cache].configuration_uri=file:///path/to/infinispan.xml
infinispan.client.hotrod.cache.another-cache.configuration=<distributed-cache name=\"another-cache\"/>
infinispan.client.hotrod.cache.[my.other.cache].configuration_uri=file:///path/to/infinispan.xml
hotrod-client.properties を . 文字が含まれるキャッシュ名と共に使用する場合は、前述の例のように、キャッシュ名を角括弧で囲む必要があります。
また、このような XMLStringConfiguration() メソッドでキャッシュの設定を追加してから getOrCreateCache() メソッドを呼び出す次の例のように、他の方法で RemoteCacheManager API を介してリモートキャッシュを作成することができます。
しかし、Data Grid は、XML の有効性を保証することがより困難になる可能性があり、一般にキャッシュを作成するには厄介な方法であるため、このアプローチを推奨しません。複雑なキャッシュ設定を作成する場合は、それらをプロジェクト内の別々のファイルに保存し、Hot Rod クライアント設定で参照する必要があります。
Hot Rod コードの例
Hot Rod Java クライアントを使用して、さまざまな方法でリモートキャッシュを作成する方法を説明する Data Grid コードチュートリアルをいくつか試してください。
Data Grid code examples にアクセスします。
第3章 Hot Rod クライアント API リンクのコピーリンクがクリップボードにコピーされました!
Data Grid Hot Rod クライアント API は、リモートでのキャッシュ作成、データ操作、クラスター化されたキャッシュのトポロジー監視を行うためのインターフェイスを提供します。
3.1. RemoteCache API リンクのコピーリンクがクリップボードにコピーされました!
コレクションメソッド keySet、entrySet、および values はリモートキャッシュによってサポートされます。つまり、すべてのメソッドが RemoteCache に戻されるということです。これは、さまざまなキー、エントリー、または値を遅延して取得でき、ユーザーが望まない場合にそれらすべてを一度にクライアントメモリーに保存する必要がないため便利です。
これらのコレクションは、add および addAll はサポートされていませんが、他のすべてのメソッドはサポートされているという Map 仕様に準拠しています。
注記の 1 つとして、Iterator.remove メソッドおよび Set.remove メソッドまたは Collection.remove メソッドには、操作するサーバーに 1 つ以上のラウンドトリップが必要です。RemoteCache Javadoc を参照して、これらの詳細と他のメソッドの詳細を確認できます。
イテレーターの使用
これらのコレクションの iterator メソッドは、以下で説明されている retrieveEntries を内部で使用します。retrieveEntries がバッチサイズの引数を取る場合。これをイテレータに提供する方法はありません。そのため、バッチサイズは、RemoteCacheManager の設定時に、システムプロパティー infinispan.client.hotrod.batch_size で設定できます。または、ConfigurationBuilder で設定できます。
また、返される retrieveEntries イテレーターは Closeable です。keySet、entrySet、および values からのイテレーターは AutoCloseable バリアントを返します。したがって、これらの Iterator の使用が終了したら、常に閉じる必要があります。
try (CloseableIterator<Map.Entry<K, V>> iterator = remoteCache.entrySet().iterator()) {
}
try (CloseableIterator<Map.Entry<K, V>> iterator = remoteCache.entrySet().iterator()) {
}
バッキングコレクションではなく、ディープコピーが必要な場合
以前のバージョンの RemoteCache では、keySet のディープコピーの取得が許可されました。これは新しいバッキングマップでも可能です。コンテンツを自分でコピーするだけです。また、これまでサポートしていなかった entrySet および values を使用してこれを行うこともできます。
Set<K> keysCopy = remoteCache.keySet().stream().collect(Collectors.toSet());
Set<K> keysCopy = remoteCache.keySet().stream().collect(Collectors.toSet());
3.1.1. サポートされていないメソッド リンクのコピーリンクがクリップボードにコピーされました!
Data Grid の RemoteCache API は、Cache API で利用可能なすべてのメソッドをサポートしておらず、サポート対象外のメソッドが呼び出されると UnsupportedOperationException を出力します。
これらのメソッドのほとんどはリモートキャッシュ (リスナー管理操作など) では意味を持ちません。または、ローカルキャッシュでサポートされていないメソッドにも対応しません (例: containsValue)。
ConcurrentMap から継承された特定のアトミック操作も、RemoteCache API ではサポートされていません。以下に例を示します。
boolean remove(Object key, Object value); boolean replace(Object key, Object value); boolean replace(Object key, Object oldValue, Object value);
boolean remove(Object key, Object value);
boolean replace(Object key, Object value);
boolean replace(Object key, Object oldValue, Object value);
ただし、RemoteCache は、値オブジェクト全体ではなく、ネットワーク経由でバージョン識別子を送信する、これらのアトミック操作の代替バージョンメソッドを提供します。
3.2. リモート Iterator API リンクのコピーリンクがクリップボードにコピーされました!
Data Grid は、メモリーリソースが制限されているエントリーを取得するため、またはサーバー側のフィルタリングや変換を行う予定がある場合に、リモートイテレータ API を提供します。
3.2.1. Data Grid サーバーへのカスタムフィルターのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
カスタムフィルターを Data Grid サーバーインスタンスにデプロイします。
手順
KeyValueFilterConverterFactoryを拡張するファクトリーを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow META-INF/services/org.infinispan.filter.KeyValueFilterConverterFactoryファイルが含まれる JAR を作成します。このファイルには、フィルターファクトリークラス実装の完全修飾クラス名を含める必要があります。フィルターがカスタムのキー/値クラスを使用する場合は、フィルターがキーや値のインスタンスを正しくアンマーシャリングできるように、それらを JAR ファイルに含める必要があります。
-
JAR ファイルを Data Grid サーバーのインストールディレクトリーの
server/libディレクトリーに追加します。
3.3. MetadataValue API リンクのコピーリンクがクリップボードにコピーされました!
バージョン管理された操作には、MetadataValue インターフェイスを使用します。
次の例は、エントリーの値のバージョンが変更されていない場合にのみ発生する削除操作を示しています。
3.4. ストリーミング API リンクのコピーリンクがクリップボードにコピーされました!
Data Grid は、InputStream および OutputStream のインスタンスを返すメソッドを実装する Streaming API を提供するため、Hot Rod クライアントと Data Grid サーバー間で大きなオブジェクトをストリーミングできます。
大きなオブジェクトの次の例を考えてみましょう。
StreamingRemoteCache<String> streamingCache = remoteCache.streaming();
OutputStream os = streamingCache.put("a_large_object");
os.write(...);
os.close();
StreamingRemoteCache<String> streamingCache = remoteCache.streaming();
OutputStream os = streamingCache.put("a_large_object");
os.write(...);
os.close();
次のように、ストリーミングを通じてオブジェクトを読み取ることができます。
Streaming API は値をマーシャリング しません。つまり、Streaming API と非 Streaming API の両方を同時に使用することはできません。ただし、このケースを処理するためにカスタムマーシャラーを実装することもできます。
RemoteStreamingCache.get(K key) メソッドによって返される InputStream は VersionedMetadata インターフェイスを実装しているため、以下のようにバージョンと有効期限の情報を取得できます。
条件付き書き込みメソッド (putIfAbsent()、replace()) は、値がサーバーに完全に送信されてから、実際の条件チェックを実行します。つまり、close() メソッドが OutputStream で呼び出される場合です。
3.5. カウンター API リンクのコピーリンクがクリップボードにコピーされました!
CounterManager インターフェイスは、カウンターを定義、取得、および削除するエントリーポイントです。
Hot Rod クライアントは、以下の例のように CounterManager インターフェイスを取得できます。
// create or obtain your RemoteCacheManager RemoteCacheManager manager = ...; // retrieve the CounterManager CounterManager counterManager = RemoteCounterManagerFactory.asCounterManager(manager);
// create or obtain your RemoteCacheManager
RemoteCacheManager manager = ...;
// retrieve the CounterManager
CounterManager counterManager = RemoteCounterManagerFactory.asCounterManager(manager);
参照資料
3.6. イベントリスナーの作成 リンクのコピーリンクがクリップボードにコピーされました!
Java Hot Rod クライアントは、リスナーを登録して cache-entry レベルのイベントを受信することができます。キャッシュエントリーの作成、変更、および削除されたイベントがサポートされています。
クライアントリスナーの作成は、異なるアノテーションとイベントクラスが使用される点を除き、組み込みリスナーと非常に似ています。受信した各イベントを出力するクライアントリスナーの例を次に示します。
ClientCacheEntryCreatedEvent および ClientCacheEntryModifiedEvent インスタンスは、影響を受けるキーとエントリーのバージョンに関する情報を提供します。このバージョンは、replaceWithVersion、removeWithVersion などのサーバー上で条件付き操作を呼び出すために使用できます。
ClientCacheEntryRemovedEvent イベントは、削除操作が成功した場合にのみ送信されます。つまり、削除オペレーションが呼び出されても、エントリーが見つからないか、エントリーを削除する必要がない場合は、イベントが生成されません。エントリーが削除されていなくても、削除されたイベントに関心のあるユーザーは、このようなイベントを生成するイベントのカスタマイズロジックを開発できます。詳細は、クライアントイベントのカスタマイズ セクションを参照してください。
ClientCacheEntryCreatedEvent、ClientCacheEntryModifiedEvent、および ClientCacheEntryRemovedEvent のすべてのイベントインスタンスも、トポロジーの変更が原因でこれを引き起こした書き込みコマンドを再度実行する場合に true を返す boolean isCommandRetried() メソッドも提供します。これは、このイベントが重複したか、別のイベントが破棄されて置き換えられた記号になります (例: ClientCacheEntryModifiedEvent が ClientCacheEntryCreatedEvent に置き換えます)。
クライアントリスナーの実装を作成したら、サーバーに登録する必要があります。これを行うには、以下を実行します。
RemoteCache<?, ?> cache = ... cache.addClientListener(new EventPrintListener());
RemoteCache<?, ?> cache = ...
cache.addClientListener(new EventPrintListener());
3.6.1. イベントリスナーの削除 リンクのコピーリンクがクリップボードにコピーされました!
クライアントイベントリスナーが必要ない場合は、以下を削除できます。
EventPrintListener listener = ... cache.removeClientListener(listener);
EventPrintListener listener = ...
cache.removeClientListener(listener);
3.6.2. イベントのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
クライアントにイベントが殺到するのを防ぐために、ユーザーはフィルタリング機能を提供して、特定のクライアントリスナーに対し、サーバーによって発生するイベントの数を制限できます。フィルターを有効にするには、フィルターインスタンスを生成するキャッシュイベントフィルターファクトリーを作成する必要があります。
上記で定義されたキャッシュイベントフィルターファクトリーインスタンスは、キーが 1 であるものを除くすべてのエントリーを静的にフィルターするインスタンスを作成します。
このキャッシュイベントフィルターファクトリーにリスナーを登録できるようにするには、ファクトリーに一意の名前を付ける必要があり、Hot Rod サーバーに名前とキャッシュイベントフィルターファクトリーインスタンスを接続する必要があります。
フィルターの実装を含む JAR ファイルを作成します。
キャッシュがカスタムのキー/値クラスを使用する場合は、コールバックを正しくマーシャリングされていないキー/値インスタンスで実行できるように、これらを JAR に含める必要があります。クライアントリスナーで
useRawDataが有効になっている場合、コールバックのキー/値インスタンスはバイナリー形式で提供されるため、これは必要ありません。-
JAR ファイル内で
META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventFilterFactoryファイルを作成し、フィルタークラス実装の完全修飾クラス名を作成します。 -
JAR ファイルを Data Grid サーバーのインストールディレクトリーの
server/libディレクトリーに追加します。 ファクトリー名を
@ClientListenerアノテーションに追加して、クライアントリスナーをこのキャッシュイベントフィルターファクトリーとリンクします。@ClientListener(filterFactoryName = "static-filter") public class EventPrintListener { ... }@ClientListener(filterFactoryName = "static-filter") public class EventPrintListener { ... }Copy to Clipboard Copied! Toggle word wrap Toggle overflow リスナーをサーバーに登録します。
RemoteCache<?, ?> cache = ... cache.addClientListener(new EventPrintListener());
RemoteCache<?, ?> cache = ... cache.addClientListener(new EventPrintListener());Copy to Clipboard Copied! Toggle word wrap Toggle overflow
リスナーの登録時に提供されたパラメーターに基づいてフィルタリングする動的フィルターインスタンスを登録することもできます。フィルターは、フィルターファクトリーが受け取ったパラメーターを使用してこのオプションを有効にします。以下に例を示します。
リスナーの登録時に、フィルタリングに必要な動的パラメーターが提供されます。
RemoteCache<?, ?> cache = ...
cache.addClientListener(new EventPrintListener(), new Object[]{1}, null);
RemoteCache<?, ?> cache = ...
cache.addClientListener(new EventPrintListener(), new Object[]{1}, null);
フィルターインスタンスは、クラスターにデプロイされるときにマーシャル可能である必要があります。これにより、リスナーの登録先の別のノードで生成された場合でも、イベントが生成される際にフィルターが適切に行われるようにします。それらをマーシャリング可能にするには、Serializable、Externalizable を拡張するか、カスタム Externalizer を提供します。
3.6.3. 通知のスキップ リンクのコピーリンクがクリップボードにコピーされました!
サーバーからイベント通知を取得しなくても、リモート API メソッドを呼び出してオペレーションを実行する際に、SKIP_LISTENER_NOTIFICATION フラグを含めます。たとえば、値を作成または変更する際のリスナーの通知を防ぐには、フラグを以下のように設定します。
remoteCache.withFlags(Flag.SKIP_LISTENER_NOTIFICATION).put(1, "one");
remoteCache.withFlags(Flag.SKIP_LISTENER_NOTIFICATION).put(1, "one");
3.6.4. イベントのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで生成されるイベントには、イベントを関連させるのに十分な情報が含まれていますが、送信コストを削減するために情報を詰め込みすぎないようにしています。必要に応じて、イベントに含まれる情報は、値などの詳細情報を含むか、より少ない情報を含めるためにカスタム化できます。このカスタマイズは、CacheEventConverterFactory によって生成された CacheEventConverter インスタンスを使用して行われます。
上記の例では、コンバーターは、イベント内の値とキーを含む新しいカスタムイベントを生成します。これにより、デフォルトのイベントと比べて大量のイベントペイロードが発生しますが、フィルターと組み合わせると、ネットワークの帯域幅コストを減らすことができます。
コンバーターのターゲットタイプは、Serializable または Externalizable のいずれかである必要があります。この特定のコンバーターの場合、デフォルトの Hot Rod クライアントマーシャラーではサポートされないため、デフォルトで Externalizer を提供しません。
カスタムイベントの処理には、以前に実証されたものに対して、若干異なるクライアントリスナーの実装が必要になります。より正確な状態に戻すには、ClientCacheEntryCustomEvent インスタンスを処理する必要があります。
コールバックで受け取った ClientCacheEntryCustomEvent は、getEventData メソッドを介してカスタムイベントを公開し、getType メソッドは、生成されたイベントがキャッシュエントリーの作成、変更、または削除の結果であったかどうかに関する情報を提供します。
フィルタリングと同様に、リスナーをこのコンバーターファクトリーに登録できるようにするには、ファクトリーに一意の名前を付ける必要があり、Hot Rod サーバーに名前とキャッシュイベントコンバーターファクトリーインスタンスを接続する必要があります。
コンバーターの実装を含む JAR ファイルを作成します。
キャッシュがカスタムのキー/値クラスを使用する場合は、コールバックを正しくマーシャリングされていないキー/値インスタンスで実行できるように、これらを JAR に含める必要があります。クライアントリスナーで
useRawDataが有効になっている場合、コールバックのキー/値インスタンスはバイナリー形式で提供されるため、これは必要ありません。-
JAR ファイル内で
META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactoryファイルを作成し、コンバータークラス実装の完全修飾クラス名を作成します。 -
JAR ファイルを Data Grid サーバーのインストールディレクトリーの
server/libディレクトリーに追加します。 ファクトリー名を
@ClientListenerアノテーションに追加して、クライアントリスナーをこのコンバーターファクトリーとリンクします。@ClientListener(converterFactoryName = "static-converter") public class CustomEventPrintListener { ... }@ClientListener(converterFactoryName = "static-converter") public class CustomEventPrintListener { ... }Copy to Clipboard Copied! Toggle word wrap Toggle overflow リスナーをサーバーに登録します。
RemoteCache<?, ?> cache = ... cache.addClientListener(new CustomEventPrintListener());
RemoteCache<?, ?> cache = ... cache.addClientListener(new CustomEventPrintListener());Copy to Clipboard Copied! Toggle word wrap Toggle overflow
リスナーの登録時に提供されたパラメーターを基に変換する動的コンバーターインスタンスもあります。コンバーターは、コンバーターファクトリーによって受け取ったパラメーターを使用してこのオプションを有効にします。以下に例を示します。
変換を行うために必要な動的パラメーターは、リスナーが登録されたときに提供されます。
RemoteCache<?, ?> cache = ...
cache.addClientListener(new EventPrintListener(), null, new Object[]{1});
RemoteCache<?, ?> cache = ...
cache.addClientListener(new EventPrintListener(), null, new Object[]{1});
コンバーターインスタンスは、クラスターにデプロイされるときにマーシャル可能である必要があります。これにより、リスナーの登録先の別のノードで生成された場合でも、イベントが生成される際に変換が適切に行われるようにします。それらをマーシャリング可能にするには、Serializable、Externalizable を拡張するか、カスタム Externalizer を提供します。
3.6.5. フィルターとカスタムイベント リンクのコピーリンクがクリップボードにコピーされました!
イベントのフィルタリングとカスタマイズの両方を実行する場合、org.infinispan.notifications.cachelistener.filter.CacheEventFilterConverter を実装する方が簡単です。これにより、1 つのステップでフィルターとカスタマイズの両方を実行できます。便宜上、org.infinispan.notifications.cachelistener.filter.CacheEventFilterConverter を直接実装するのではなく、org.infinispan.notifications.cachelistener.filter.AbstractCacheEventFilterConverter を拡張することが推奨されます。以下に例を示します。
フィルターとコンバーターと同様に、この組み合わせたフィルター/変換ファクトリーでリスナーを登録するには、ファクトリーに @NamedFactory アノテーション経由で一意の名前が付与される必要があります。また、Hot Rod サーバーは名前とキャッシュイベントコンバーターファクトリーインスタンスと共にプラグインする必要があります。
コンバーターの実装を含む JAR ファイルを作成します。
キャッシュがカスタムのキー/値クラスを使用する場合は、コールバックを正しくマーシャリングされていないキー/値インスタンスで実行できるように、これらを JAR に含める必要があります。クライアントリスナーで
useRawDataが有効になっている場合、コールバックのキー/値インスタンスはバイナリー形式で提供されるため、これは必要ありません。-
JAR ファイル内で
META-INF/services/org.infinispan.notifications.cachelistener.filter.CacheEventFilterConverterFactoryファイルを作成し、コンバータークラス実装の完全修飾クラス名を作成します。 -
JAR ファイルを Data Grid サーバーのインストールディレクトリーの
server/libディレクトリーに追加します。
クライアントの観点からすると、組み合わせたフィルターとコンバータークラスを使用できるようにするには、クライアントリスナーは同じフィルターファクトリーとコンバーターファクトリー名を定義する必要があります。以下に例を示します。
@ClientListener(filterFactoryName = "dynamic-filter-converter", converterFactoryName = "dynamic-filter-converter")
public class CustomEventPrintListener { ... }
@ClientListener(filterFactoryName = "dynamic-filter-converter", converterFactoryName = "dynamic-filter-converter")
public class CustomEventPrintListener { ... }
上記の例で必要な動的パラメーターは、リスナーが filter パラメーターまたは converter パラメーターのいずれかに登録されている場合に提供されます。フィルターパラメーターが空でない場合は、それらが使用されます。それ以外の場合は、コンバーターパラメーターは以下のようになります。
RemoteCache<?, ?> cache = ...
cache.addClientListener(new CustomEventPrintListener(), new Object[]{1}, null);
RemoteCache<?, ?> cache = ...
cache.addClientListener(new CustomEventPrintListener(), new Object[]{1}, null);
3.6.6. イベントマーシャリング リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod サーバーは、異なる形式でデータを保存できますが、Java Hot Rod クライアントユーザーは、タイプ化されたオブジェクトで機能する CacheEventConverter インスタンスまたは CacheEventFilter インスタンスを開発できます。デフォルトでは、フィルターとコンバーターは、データを POJO (application/x-java-object) として使用しますが、filter/converter からメソッド format() を上書きすることで、希望の形式を上書きすることができます。形式が null を返す場合、フィルター/変換は保存時にデータを受け取ります。
Hot Rod Java クライアントは、異なる org.infinispan.commons.marshall.Marshaller インスタンスを使用するように設定できます。これ CacheEventConverter インスタンスや CacheEventFilter インスタンスをデプロイしたり、コンテンツをマーシャリングしたりするのではなく、Java オブジェクトでフィルター/変換できるようにするには、サーバーはオブジェクトとマーシャラーで生成されるバイナリー形式の間で変換できるようにする必要があります。
Marshaller インスタンスのサーバー側のデプロイするには、CacheEventConverter インスタンスまたは CacheEventFilter インスタンスをデプロイするのに使用されるものと同様の方法に従います。
- コンバーターの実装を含む JAR ファイルを作成します。
-
JAR ファイル内で
META-INF/services/org.infinispan.commons.marshall.Marshallerファイルを作成し、フィルタークラス実装の完全修飾クラス名を作成します。 -
JAR ファイルを Data Grid サーバーのインストールディレクトリーの
server/libディレクトリーに追加します。
Marshaller は個別の jar または CacheEventConverter インスタンスおよび/または CacheEventFilter インスタンスと同じ jar にデプロイできることに注意してください。
3.6.6.1. Protostream マーシャラーのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
キャッシュが Protobuf コンテンツを保存する場合は、Hot Rod クライアントで ProtoStream マーシャラーを使用する際に発生する場合は、サーバーで形式がすでにサポートされているため、カスタムマーシャラーをデプロイする必要はありません。Protobuf 形式から JSON や POJO などの最も一般的な形式に変換するトランスコーダーがあります。
これらのキャッシュでフィルター/変換を使用し、バイナリー Protobuf データではなく Java オブジェクトでフィルター/変換を使用すると、追加の ProtoStream マーシャラーを設定し、フィルタリング/変換の前にデータをアンマーシャリングできるようにする必要があります。これには、Data Grid サーバー設定の一部として、必要な SerializationContextInitializer(s) を設定する必要があります。
詳細は、Cache Encoding and Marshalling を参照してください。
3.6.7. リスナーの状態の処理 リンクのコピーリンクがクリップボードにコピーされました!
クライアントリスナーアノテーションには、リスナーの追加時またはリスナーのフェイルオーバー時に状態がクライアントに送信されるかどうかを指定する任意の includeCurrentState 属性があります。
デフォルトでは、includeCurrentState は false ですが、true に設定され、クライアントリスナーがデータが含まれるキャッシュに追加されると、サーバーはキャッシュの内容を繰り返し処理し、各エントリーのイベント (設定されている場合はカスタムイベント) を ClientCacheEntryCreated としてクライアントに送信します。これにより、クライアントは既存のコンテンツに基づいて一部のローカルデータ構造をビルドできます。コンテンツが繰り返されると、キャッシュの更新を受け取るため、イベントは通常どおり受信されます。キャッシュがクラスター化されている場合、クラスター全体のコンテンツ全体が繰り返し処理されます。
3.6.8. リスナーの障害処理 リンクのコピーリンクがクリップボードにコピーされました!
Hot Rod クライアントがクライアントリスナーを登録すると、クラスターの単一ノードになります。そのノードに障害が発生すると、Java Hot Rod クライアントは透過的に検出し、別のノードに失敗したノードに登録されているすべてのリスナーをフェイルオーバーします。
このフェイルオーバー中に、クライアントはいくつかのイベントを見逃す可能性があります。これらのイベントが不足しないように、クライアントリスナーアノテーションには includeCurrentState という任意のパラメーターが含まれます。これは、フェイルオーバーの実行時に、キャッシュの内容が繰り返し処理され、ClientCacheEntryCreated イベント (設定されている場合はカスタムイベント) が生成されます。デフォルトでは、includeCurrentState は false に設定されています。
コールバックを使用してフェイルオーバーイベントを処理します。
@ClientCacheFailover
public void handleFailover(ClientCacheFailoverEvent e) {
...
}
@ClientCacheFailover
public void handleFailover(ClientCacheFailoverEvent e) {
...
}
これは、クライアントがいくつかのデータをキャッシュしており、フェイルオーバーの結果、いくつかのイベントが見逃される可能性を考慮して、フェイルオーバーイベントを受信したときにローカルにキャッシュされたデータを消去することを決定し、フェイルオーバーイベントの後にキャッシュ全体のコンテンツに対するイベントを受信することを知っているような場合に非常に便利です。
3.7. Hot Rod Java クライアントトランザクション リンクのコピーリンクがクリップボードにコピーされました!
JTA の トランザクション で Hot Rod クライアントを設定および使用できます。
トランザクションに参加するために、Hot Rod クライアントは、相互作用する TransactionManager と、Synchronization インターフェイスまたは XAResource インターフェイスを通じてトランザクションに参加するかどうかを要求します。
トランザクションは、クライアントが準備フェーズでエントリーへの書き込みロックを取得するという点で最適化されます。データの不整合を回避するには、トランザクションとの競合を検出 を必ずお読みください。
3.7.1. サーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
クライアントが JTA トランザクション に参加するには、サーバーのキャッシュもトランザクションである必要があります。
次のサーバー設定が必要です。それ以外の場合、トランザクションはロールバックのみになります。
-
分離レベルは
REPEATABLE_READである必要があります。 -
PESSIMISTICロックモードが推奨されますが、OPTIMISTICを使用できます。 -
トランザクションモードは、
NON_XAまたはNON_DURABLE_XAである必要があります。Hot Rod トランザクションはパフォーマンスが低下するため、FULL_XAを使用しないでください。
以下に例を示します。
<replicated-cache name="hotrodReplTx"> <locking isolation="REPEATABLE_READ"/> <transaction mode="NON_XA" locking="PESSIMISTIC"/> </replicated-cache>
<replicated-cache name="hotrodReplTx">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="NON_XA" locking="PESSIMISTIC"/>
</replicated-cache>
Hot Rod トランザクションには、独自の復旧メカニズムがあります。
3.7.2. Hot Rod クライアントの設定 リンクのコピーリンクがクリップボードにコピーされました!
トランザクションの RemoteCache は、キャッシュごとに設定されます。例外は、単一のトランザクションが複数のRemoteCacheと対話できるため、グローバルなトランザクションの timeout です。
以下の例は、キャッシュ my-cache にトランザクション RemoteCache を設定する方法を示しています。
設定パラメーターに関するドキュメントは、ConfigurationBuilder および RemoteCacheConfigurationBuilder Javadoc を参照してください。
以下の例のように、プロパティーファイルを使用して Java Hot Rod クライアントを設定することもできます。
infinispan.client.hotrod.cache.my-cache.transaction.transaction_manager_lookup = org.infinispan.client.hotrod.transaction.lookup.GenericTransactionManagerLookup infinispan.client.hotrod.cache.my-cache.transaction.transaction_mode = NON_XA infinispan.client.hotrod.transaction.timeout = 60000
infinispan.client.hotrod.cache.my-cache.transaction.transaction_manager_lookup = org.infinispan.client.hotrod.transaction.lookup.GenericTransactionManagerLookup
infinispan.client.hotrod.cache.my-cache.transaction.transaction_mode = NON_XA
infinispan.client.hotrod.transaction.timeout = 60000
3.7.2.1. TransactionManagerLookup インターフェイス リンクのコピーリンクがクリップボードにコピーされました!
TransactionManagerLookup は、TransactionManager を取得するためのエントリーポイントを提供します。
TransactionManagerLookup の の利用可能な実装:
- GenericTransactionManagerLookup
- Java EE アプリケーションサーバーで実行している TransactionManager を検索するルックアップクラス。TransactionManager が見つからなかった場合、デフォルトでは RemoteTransactionManager に設定されます。これは、Hot Rod Java クライアントのデフォルトです。
ほとんどの場合は、GenericTransactionManagerLookup が適しています。しかし、カスタム TransactionManager を統合する必要がある場合は、TransactionManagerLookup インターフェイスを実装できます。
- RemoteTransactionManagerLookup
- 他の実装が利用できない場合は、基本および揮発性の TransactionManager です。この実装には、同時トランザクションと復元を処理するときに重大な制限があることに注意してください。
3.7.3. トランザクションモード リンクのコピーリンクがクリップボードにコピーされました!
TransactionMode は RemoteCache が TransactionManager と相互作用する方法を制御します。
Data Grid サーバーとクライアントアプリケーションの両方でトランザクションモードを設定します。クライアントが非トランザクションキャッシュでトランザクション操作を実行しようとすると、ランタイム例外が発生する可能性があります。
トランザクションモードは、Data Grid 設定とクライアント設定の両方で同じです。クライアントで以下のモードを使用します。サーバーの Data Grid 設定スキーマを参照してください。
NONE- RemoteCache は TransactionManager と対話しません。これはデフォルトのモードであり、非トランザクションです。
NON_XA- RemoteCache は、同期 を介して TransactionManager と対話します。
NON_DURABLE_XA- RemoteCache は、XAResource を介して TransactionManager と対話します。復元機能は無効になっています。
FULL_XA-
RemoteCache は、XAResource を介して TransactionManager と対話します。復元機能が有効になっています。
XaResource.recover()メソッドを呼び出して、リカバリーするトランザクションを取得します。
3.7.4. トランザクションとの競合の検出 リンクのコピーリンクがクリップボードにコピーされました!
トランザクションはキーの初期値を使用して競合を検出します。
たとえば、トランザクションの開始時に k の値は v となります。準備フェーズでは、トランザクションはサーバーから "k" を取得して値を読み取ります。値が変更された場合、トランザクションは競合を回避するためにロールバックします。
トランザクションはバージョンを使用して、値の等価性を確認する代わりに変更を検出します。
forceReturnValue パラメーターは、RemoteCache への書き込み操作を制御し、競合を回避するのに役立ちます。次の値があります。
-
trueの場合、書き込み操作を実行する前に TransactionManager はサーバーから最新の値を取得します。ただし、forceReturnValueパラメーターは、キーの初回アクセスの操作にのみ適用されます。 -
falseの場合、TransactionManager は書き込み操作を実行する前にサーバーから最新の値を取得しません。
このパラメーターは、最新の値が必要なため、replace や putIfAbsent などの 条件付き 書き込み操作には影響しません。
以下のトランザクションは、forceReturnValue パラメーターが競合する書き込み操作を防ぐ例を提供します。
トランザクション 1 (TX1)
トランザクション 2 (TX2)
この例では、TX1 と TX2 が並行して実行されます。k の初期値は v です。
-
forceReturnValue = trueの場合、cache.put()操作はサーバーから TX1 と TX2 の両方のサーバーから k の値を取得します。最初に k のロックを取得するトランザクションはコミットします。他のトランザクションは、k が v 以外の値を持っていることをトランザクションが検出できるため、コミットフェーズ中にロールバックします。 -
forceReturnValue = falseの場合cache.put()オペレーションはサーバーから "k" の値を取得せず、null を返します。TX1 と TX2 の両方が正常にコミットされ、競合が生じます。これは、"k"の初期値が変更されたことをトランザクションが検知できないために発生します。
以下のトランザクションは、cache.put() オペレーションを行う前に K の値を読み取る cache.get() オペレーションが含まれます。
トランザクション 1 (TX1)
トランザクション 2 (TX2)
上記の例では、TX1 および TX2 の両方が鍵を読み取るため、forceReturnValue パラメーターは有効になりません。1 つのトランザクションがコミットし、もう 1 つのトランザクションがロールバックします。ただし、cache.get() 操作には追加のサーバー要求が必要です。サーバーリクエストが非効率な cache.put() オペレーションの戻り値が必要ない場合。
3.7.5. 設定済みトランザクションマネージャーおよびトランザクションモードの使用 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、RemoteCacheManager で設定した TransactionManager および TransactionMode を使用する方法を示しています。