手順2.1 新しい RemoteCacheManager の設定

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

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

1. ConfigurationBuilder() コンストラクターを使用して新しい設定ビルダーを作成します。.addServer() メソッドは、.host(<hostname|ip>) プロパティーと .port(<port>) プロパティーで設定されたリモートサーバーを追加します。
2. 指定された設定を使用して新しい RemoteCacheManager を作成します。
3. リモートサーバーからデフォルトキャッシュを取得します。

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

1. 設定 XML ファイルを作成します。たとえば、クラスパス上 ( resources/ フォルダー内) に my-config-file.xml ファイルを作成し、このファイルに設定情報を追加します。
2. 設定ファイルを使用してキャッシュマネージャーを作成するには、以下のプログラムを使用した設定を使用します。

   EmbeddedCacheManager manager = new DefaultCacheManager("my-config-file.xml");
   Cache defaultCache = manager.getCache();

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

1. 次のようにデフォルト設定を指定します。

   public class Config
      @Produces
      public EmbeddedCacheManager defaultCacheManager() {
         ConfigurationBuilder builder = new ConfigurationBuilder();          
         Configuration configuration = builder.eviction().strategy(EvictionStrategy.LRU).maxEntries(100).build();
         return new DefaultCacheManager(configuration);
      }
   }

2. デフォルトのキャッシュマネージャーを挿入します。

   <!-- Additional configuration information here -->
   @Inject
   EmbeddedCacheManager cacheManager;
   <!-- Additional configuration information here -->

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

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

   <eviction> タグを次のようにプロジェクトの <cache> タグに追加します。

   <eviction />

2. エビクションストラテジーの設定

   使用するエビクションストラテジーを設定するために strategy の値を設定します。使用可能な値は、LRU、UNORDERED および LIRS (またはエビクションが不要な場合は NONE) です。以下は、このステップのサンプルです。

   <eviction strategy="LRU" />

3. 最大エントリー数の設定

   メモリー内で許可されるエントリーの最大数を設定します。無制限のエントリーを許可するためのデフォルト値は -1 です。
   1. ライブラリーモードで、maxEntries パラメーターを次のように設定します。

      <eviction strategy="LRU" maxEntries="200" />

   2. リモートクライアントモードで、max-entries を次のように設定します。

      <eviction strategy="LRU" max-entries="200" />

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

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

   level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。

   <subsystem xmlns="urn:jboss:domain:logging:1.4">
      <root-logger>
         <level name="INFO"/>

2. handlers を一覧表示します

   handlers は、ルートロガーによって使用されるログハンドラーの一覧です。

   <subsystem xmlns="urn:jboss:domain:logging:1.4">
        <root-logger>
           <level name="INFO"/>
           <handlers>
              <handler name="CONSOLE"/>
              <handler name="FILE"/>
           </handlers>
        </root-logger>
     </subsystem>

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

<subsystem xmlns="urn:jboss:domain:logging:1.4">
   <logger category="com.company.accounts.rec" use-parent-handlers="true">
      <level name="WARN"/>
      <handlers>
         <handler name="accounts-rec"/>
      </handlers>
   </logger>
</subsystem>

1. ログメッセージがキャプチャーされるログカテゴリーを指定するために、category プロパティーを使用します。
   use-parent-handlers はデフォルトで "true" に設定されています。"true" に設定した場合、このカテゴリーは、割り当てられた他のハンドラーだけでなく、ルートロガーのログハンドラーを使用します。
2. ログカテゴリーが記録するログメッセージの最大レベルを設定するために、level プロパティーを設定します。
3. handlers 要素には、ログハンドラーのリストが含まれます。

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

<subsystem xmlns="urn:jboss:domain:logging:1.4">
   <console-handler name="CONSOLE" autoflush="true">
      <level name="INFO"/>
      <encoding value="UTF-8"/>
      <target value="System.out"/>
      <filter-spec value="not(match(&quot;JBAS.*&quot;))"/>
      <formatter>
         <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
      </formatter>
   </console-handler>
</subsystem>

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

   name プロパティーは、このログハンドラーの一意の ID を設定します。
   autoflush を "true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。

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

   level プロパティーは、記録されるログメッセージの最大レベルを設定します。

3. encoding 出力を設定します

   出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。

4. target 値を定義します。

   target プロパティーは、ログハンドラーの出力先となるシステム出力ストリームを定義します。これはシステムエラーストリームの場合は System.err、標準出力ストリームの場合は System.out とすることができます。

5. filter-spec プロパティーを定義します。

   filter-spec プロパティーはフィルターを定義する式の値です。以下の例では、not(match("JBAS.*")) はパターンに一致しないフィルターを定義します。

6. formatter を指定します。

   このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。

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

<file-handler name="accounts-rec-trail" autoflush="true">
    <level name="INFO"/>
    <encoding value="UTF-8"/>
    <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/>
    <formatter>
        <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
    </formatter>
    <append value="true"/>
</file-handler>

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

   name プロパティーは、このログハンドラーの一意の ID を設定します。
   autoflush を "true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。

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

   level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。

3. encoding 出力を設定します

   出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。

4. file オブジェクトを設定します。

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

5. formatter を指定します。

   このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。

6. append プロパティーを設定します。

   append プロパティーを "true" に設定した場合、このハンドラーが追加したすべてのメッセージが既存のファイルに追加されます。"false" に設定した場合、アプリケーションサーバーが起動するたびに新規ファイルが作成されます。append への変更を反映させるには、サーバーの再起動が必要です。

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

<periodic-rotating-file-handler name="FILE" autoflush="true">
   <level name="INFO"/>
   <encoding value="UTF-8"/>
   <formatter>
      <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
   </formatter>
   <file relative-to="jboss.server.log.dir" path="server.log"/>
   <suffix value=".yyyy-MM-dd"/>
   <append value="true"/>
</periodic-rotating-file-handler>

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

   name プロパティーは、このログハンドラーの一意の ID を設定します。
   autoflush を "true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。

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

   level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。

3. encoding 出力を設定します

   出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。

4. formatter を指定します。

   このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。

5. file オブジェクトを設定します。

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

6. suffix 値を設定します

   suffix は、ローテーションされたログのファイル名に追加され、ローテーションの周期を決定するために使用されます。suffix の形式では、ドット (.) の後に java.text.SimpleDateFormat クラスで解析できる日付文字列が指定されます。ログは suffix で定義された最小時間単位に基づいてローテーションされます。たとえば、yyyy-MM-dd の場合は、ログが毎日ローテーションされます。http://docs.oracle.com/javase/6/docs/api/index.html?java/text/SimpleDateFormat.html を参照してください。

7. append プロパティーを設定します。

   append プロパティーを "true" に設定した場合、このハンドラーが追加したすべてのメッセージが既存のファイルに追加されます。"false" に設定した場合、アプリケーションサーバーが起動するたびに新規ファイルが作成されます。append への変更を反映させるには、サーバーの再起動が必要です。

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

<size-rotating-file-handler name="accounts_debug" autoflush="false">
   <level name="DEBUG"/>
   <encoding value="UTF-8"/>
   <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
   <rotate-size value="500k"/>
   <max-backup-index value="5"/>
   <formatter>
        <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
    </formatter>
   <append value="true"/>
</size-rotating-file-handler>

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

   name プロパティーは、このログハンドラーの一意の ID を設定します。
   autoflush を "true" に設定すると、ログメッセージは要求直後にハンドラーのターゲットに送信されます。

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

   level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。

3. encoding 出力を設定します

   出力に使用する文字エンコーディングスキームを設定するには、encoding を使用します。

4. file オブジェクトを設定します。

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

5. rotate-size 値を指定します。

   ログファイルがローテーションされる前に到達できる最大サイズです。数字に追加された単一の文字はサイズ単位を示します。バイトの場合は b、キロバイトの場合は k、メガバイトの場合は m、ギガバイトの場合は g になります。たとえば、50 メガバイトの場合は、50m になります。

6. max-backup-index 数を設定します。

   保持されるローテーションログの最大数です。この数字に達すると、最も古いログが再利用されます。

7. formatter を指定します。

   このログハンドラーで使用するログフォーマッターの一覧を表示するには、formatter を使用します。

8. append プロパティーを設定します。

   append プロパティーを "true" に設定した場合、このハンドラーが追加したすべてのメッセージが既存のファイルに追加されます。"false" に設定した場合、アプリケーションサーバーが起動するたびに新規ファイルが作成されます。append への変更を反映させるには、サーバーの再起動が必要です。

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

<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>

1. name プロパティーは、このログハンドラーの一意の ID を設定します。
2. level プロパティーは、ルートロガーが記録するログメッセージの最大レベルを設定します。
3. queue-length は、サブハンドラーの応答を待機する間に、このハンドラーが保持するログメッセージの最大数を定義します。
4. overflow-action は、キューの長さを超えたときにこのハンドラーがどのように応答するかを定義します。これは BLOCK または DISCARD に設定できます。BLOCK の場合、キューでスペースが利用可能になるまでロギングアプリケーションが待機します。これは、非同期ではないログハンドラーと同じ動作です。DISCARD の場合、ロギングアプリケーションは動作を続けますが、ログメッセージは削除されます。
5. subhandlers リストは、この非同期ハンドラーがログメッセージを渡すログハンドラーの一覧です。

手順6.2 local-cache 要素

<cache-container name="local"
                  default-cache="default" 
                  statistics="true">
         <local-cache name="default"
                          start="EAGER"
                          batching="false"
                          statistics="true">
                  <indexing index="NONE">
	                <property name="default.directory_provider">ram</property>
                  </indexing>
         </local-cache>

1. name パラメーターは使用するローカルキャッシュの名前を指定します。
2. start パラメーターはいつキャッシュコンテナーが起動するかを示します (要求時にレイジーに起動するか、またはサーバー起動時に「すぐに (eargerly)」起動するかなど)。このパラメーターの有効な値は EAGER と LAZY です。
3. batching パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。
4. statistics がコンテナーレベルで有効にされている場合、statistics 属性を false に設定することにより、キャッシュごとの統計は、監視を必要としないキャッシュについては選択的に無効にすることができます。
5. indexing パラメーターはローカルキャッシュに使用されるインデックス化のタイプを指定します。このパラメーターの有効な値は NONE、 LOCAL、および ALL です。

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

<subsystem xmlns="urn:infinispan:server:endpoint:6.1">
   <rest-connector virtual-server="default-host"
                 cache-container="local"
                 context-path="${CONTEXT_PATH}"
                 security-domain="${SECURITY_DOMAIN}"
                 auth-method="${METHOD}" 
                 security-mode="${MODE}" /> 
</subsystem>

1. virtual-server パラメーターは、REST コネクターで使用される仮想サーバーを指定します。このパラメーターのデフォルト値は default-host です。これはオプションパラメーターです。
2. cache-container パラメーターは、REST コネクターで使用されるキャッシュコンテナーを指定します。これは必須パラメーターです。
3. context-path パラメーターは、REST コネクターのコンテキストパスを指定します。このパラメーターのデフォルト値は空の文字列 ("") です。これはオプションパラメーターです。
4. security-domain パラメーターは、REST エンドポイントへのアクセスを認証するためにセキュリティーサブシステムで宣言された指定済みドメインを使用することを指定します。これはオプションパラメーターです。このパラメーターが省略されると、認証は実行されません。
5. auth-method パラメーターは、エンドポイントのクレデンシャルを取得するために使用するメソッドを指定します。このパラメーターのデフォルト値は BASIC です。サポートされる別の値には BASIC、DIGEST、および CLIENT-CERT があります。これはオプションパラメーターです。
6. security-mode パラメーターは、書き込み操作 (PUT、POST、DELETE など) または読み取り操作 (GET や HEAD など) に対してのみ認証が必要かどうかを指定します。このパラメーターの有効な値は WRITE (書き込み操作のみを認証する場合) または READ_WRITE (読み書き操作を認証する場合) です。このパラメーターのデフォルト値は READ_WRITE です。

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

1. セキュリティーパラメーターの指定

   rest エンドポイントで security-domain パラメーターおよび auth-method パラメーターの有効な値を指定するようにします。これらのパラメーターの推奨設定は以下のとおりです。

   <subsystem xmlns="urn:infinispan:server:endpoint:6.1">
               <rest-connector virtual-server="default-host" 
                               cache-container="local" 
                               security-domain="other" 
                               auth-method="BASIC"/>
   </subsystem>

2. セキュリティードメイン宣言のチェック

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

3. アプリケーションユーザーの追加

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

4. 作成されたアプリケーションユーザーの確認

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

      user1=2dc3eacfed8cf95a4a31159167b936fc

   2. application-roles.properties ファイル ($JDG_HOME/standalone/configuration/ に存在) にリストされた設定を確認します。以下は、このファイルの正しい設定の例です。

      user1=REST

5. サーバーのテスト

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

   http://localhost:8080/rest/namedCache

   注記

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

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

<subsystem xmlns="urn:infinispan:server:endpoint:6.1">
<memcached-connector socket-binding="memcached" 
                     cache-container="local" 
                     worker-threads="${VALUE}" 
                     idle-timeout="{VALUE}"
                     tcp-nodelay="{TRUE/FALSE}" 
                     send-buffer-size="{VALUE}" 
                     receive-buffer-size="${VALUE}" />
</subsystem>

1. socket-binding パラメーターは、memcached コネクターで使用されるソケットバインディングポートを指定します。これは必須パラメーターです。
2. cache-container パラメーターは、memcached コネクターで使用されるキャッシュコンテナーを指定します。これは必須パラメーターです。
3. worker-threads パラメーターは、memcached コネクターで利用可能なワーカースレッドの数を指定します。このパラメーターのデフォルト値は、160 です。これはオプションパラメーターです。
4. idle-timeout パラメーターは、接続がタイムアウトするまでコネクターがアイドル状態のままになる時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は -1 です (タイムアウト期間が設定されません)。これは、オプションパラメーターです。
5. tcp-no-delay パラメーターは、TCP パケットが遅延され一括して送信されるかを指定します。このパラメーターの有効な値は true と false になります。このパラメーターのデフォルト値は、true です。これはオプションパラメーターです。
6. send-buffer-size パラメーターは、memcached コネクターの送信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
7. receive-buffer-size パラメーターは、memcached コネクターの受信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。

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

<subsystem xmlns="urn:infinispan:server:endpoint:6.1">
	<hotrod-connector socket-binding="hotrod" 
			  cache-container="local" 
			  worker-threads="${VALUE}" 
			  idle-timeout="${VALUE}"
			  tcp-nodelay="${TRUE/FALSE}"
			  send-buffer-size="${VALUE}"
			  receive-buffer-size="${VALUE}" />
	<topology-state-transfer lock-timeout"="${MILLISECONDS}"
				 replication-timeout="${MILLISECONDS}"
				 external-host="${HOSTNAME}"
				 external-port="${PORT}"
				 lazy-retrieval="${TRUE/FALSE}" 
				 await-initial-transfer="${TRUE/FALSE}" /> 
</subsystem>

1. hotrod-connector 要素は、Hot Rod で使用する設定要素を定義します。
   1. socket-binding パラメーターは、Hot Rod コネクターで使用されるソケットバインディングポートを指定します。これは必須パラメーターです。
   2. cache-container パラメーターは、Hot Rod コネクターで使用されるキャッシュコンテナーを指定します。これは必須パラメーターです。
   3. worker-threads パラメーターは、Hot Rod コネクターで利用可能なワーカースレッドの数を指定します。このパラメーターのデフォルト値は、160 です。これはオプションパラメーターです。
   4. idle-timeout パラメーターは、接続がタイムアウトするまでコネクターがアイドル状態のままになる時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は -1 です (タイムアウト期間が設定されません)。これは、オプションパラメーターです。
   5. tcp-no-delay パラメーターは、TCP パケットが遅延され一括して送信されるかを指定します。このパラメーターの有効な値は true と false になります。このパラメーターのデフォルト値は、true です。これはオプションパラメーターです。
   6. send-buffer-size パラメーターは、Hot Rod コネクターの送信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
   7. receive-buffer-size パラメーターは、Hot Rod コネクターの受信バッファーのサイズを指定します。このパラメーターのデフォルト値は TCP スタックバッファーのサイズです。これはオプションパラメーターです。
2. topology-state-transfer 要素は、Hot Rod コネクターのトポロジー状態転送設定を指定します。この要素は hotrod-connector 要素内でのみ使用できます。
   1. lock-timeout パラメーターは、ロックを取得しようとする操作がタイムアウトする時間を指定します。このパラメーターのデフォルト値は 10 秒です。これはオプションパラメーターです。
   2. replication-timeout パラメーターは、レプリケーション操作がタイムアウトする時間 (ミリ秒単位) を指定します。このパラメーターのデフォルト値は 10 秒です。これはオプションパラメーターです。
   3. external-host パラメーターは、トポロジー情報にリストされたクライアントに Hot Rod サーバーが送信するホスト名を指定します。このパラメーターのデフォルト値は、ホストアドレスです。これはオプションパラメーターです。
   4. external-port パラメーターは、トポロジー情報にリストされたクライアントに Hot Rod サーバーが送信するポートを指定します。このパラメーターのデフォルト値は、設定されたポートです。これはオプションパラメーターです。
   5. lazy-retrieval パラメーターは、Hot Rod コネクターが取得操作をレイジーに実行するかどうかを指定します。このパラメーターのデフォルト値は true です。これはオプションパラメーターです。
   6. await-initial-transfer パラメーターは、初期状態の取得を起動時にすぐに行うかどうかを指定します。このパラメーターは、lazy-retrieval が false に設定されている場合のみ適用されます。このパラメーターのデフォルト値は true です。

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

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

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

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

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

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

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

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

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

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

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

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

tx.begin()
cache.lock(K)           
cache.put(K,V5)         
tx.commit()

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

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

tx.begin()
cache.put(K,V)
cache.put(K2,V2)
cache.put(K,V5)
tx.commit()

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

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

1. ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
2. passivation 要素は Red Hat JBoss Data Grid がストアと通信する方法に影響を与えます。パッシベーションは、インメモリーキャッシュからオブジェクトを削除し、システムやデータベースなどの 2 次データストアに書き込みます。パッシベーションはデフォルトで false です。
3. addSingleFileStore() 要素は、この設定用のキャッシュストアとして SingleFileStore を追加します。addStore メソッドを使用して追加できる、JDBC キャッシュストアなどの他のストアを作成することができます。
4. shared パラメーターは、キャッシュストアが異なるキャッシュインスタンスによって共有されていることを示します。たとえば、クラスター内のすべてのインスタンスが、同じリモートの共有データベースと通信するために同じ JDBC 設定を使用する場合があります。shared は、デフォルトで false になります。true に設定すると、異なるキャッシュインスタンスによって重複データがキャッシュストアに書き込まれることが避けられます。
5. preload 要素はデフォルトでは false に設定されます。true に設定されると、キャッシュストアに保存されたデータは、キャッシュの起動時にメモリーにプリロードされます。これにより、キャッシュストアのデータが起動後すぐに利用できるようになり、データのレイジーなロードの結果としてキャッシュ操作の遅延を防ぐことができます。プリロードされたデータは、ノード上でローカルにのみに保存され、プリロードされたデータのレプリケーションや分散は行われません。JBoss Data Grid は、エビクションのエントリーの最大設定数までの数をプリロードします。
6. fetchPersistentState 要素は、キャッシュの永続状態をフェッチするかどうかを決定し、クラスターに参加する際にこれをローカルキャッシュストアに適用します。キャッシュストアが共有される場合、キャッシュが同じキャッシュストアにアクセスする際に、フェッチ永続状態は無視されます。複数のキャッシュストアでこのプロパティーが true に設定された場合にキャッシュサービスを起動すると、設定の例外がスローされます。fetchPersistentState プロパティーはデフォルトでは false です。
7. ignoreModifications 要素は、書き込み操作を共有キャッシュストアではなく、ローカルファイルキャッシュストアに許可することで、書き込みメソッドを特定のキャッシュストアにプッシュするかどうかを決定します。場合によっては、一時的なアプリケーションデータが、インメモリーキャッシュと同じサーバー上のファイルベースのキャッシュストアにのみ存在する必要があります。たとえば、これはネットワーク内のすべてのサーバーによって使用される追加の JDBC ベースのキャッシュストアで適用されます。ignoreModifications はデフォルトではfalse です。
8. purgeOnStartup 要素は、キャッシュストアの起動時にキャッシュストアをパージするかどうかを制御し、デフォルトでは false になります。
9. location 要素設定は、ストアが書き込みできるディスクの場所を設定します。
10. これらの属性は、それぞれのキャッシュストアに固有の側面を設定します。例えば、location 属性は、SingleFileStore がデータが含まれるファイルを維持する場所を指します。他のストアには、さらに複雑な設定が必要な場合があります。
11. singletonStore 要素を使用すると、クラスター内の 1 つのノードのみで変更を保存できます。このノードはコーディネーターと呼ばれます。コーディネーターは、インメモリー状態のキャッシュをディスクにプッシュします。この機能は、すべてのノードの enabled 属性を true に設定することによりアクティベートされます。shared パラメーターは、singleton を同時に有効にした状態で定義することはできません。enabled 属性はデフォルトでは false です。
12. pushStateWhenCoordinator 要素はデフォルトでは true に設定されます。true の場合、このプロパティーにより、コーディネーターになったノードがインメモリー状態を基礎となるキャッシュストアに転送します。このパラメーターは、コーディネーターがクラッシュし、新規のコーディネーターが選択される場合に役に立ちます。

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

• データベースを設定するには、standalone.xml のキャッシュ定義に以下の要素を追加します。

  <leveldb-store path="/path/to/leveldb/data"
      	       passivation="false"
      	       purge="false" >
      <expiration path="/path/to/leveldb/expires/data" />
      <implementation type="JNI" />
  </leveldb-store>

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

1. ConfigurationBuilder を使用して、新規の設定オブジェクトを作成します。
2. LevelDBCacheStoreConfigurationBuilder クラスを使用してストアを追加して、その設定を構築します。
3. LevelDB キャッシュストアのロケーションパスを設定します。指定したパスは、主なキャッシュストアデータを保存します。ディレクトリーがない場合は自動的に作成されます。
4. LevelDB ストアの expiredLocation パラメーターを使用して、期限切れデータのロケーションを指定します。指定されたパスは、パージされる前に期限切れデータを保存します。ディレクトリーがない場合は自動的に作成されます。

手順18.3

1. Red Hat JBoss Operations Network 3.2 以上がインストールされ、起動されていることを確認します。
2. JBoss Operations Network 3.2.0 用 Red Hat JBoss Data Grid プラグインパックをインストールします。
3. JBoss Data Grid がインストールされ、起動されていることを確認します。
4. JBoss Data Grid サーバーをインベントリーにインポートします。
5. JBoss Data Grid 接続設定を実行します。
6. 以下のように新しい LevelDB キャッシュストアを作成します。
   

   図18.1 新しい LevelDB キャッシュストアの作成

   1. default キャッシュを右クリックします。
   2. メニューで、Create Child オプションにカーソルを置きます。
   3. サブメニューで、LevelDB Store をクリックします。
7. 以下のように新しい LevelDB キャッシュストアの名前を指定します。
   

   図18.2 新しい LevelDB キャッシュストアの名前指定

   1. 表示された Resource Create Wizard で、新しい LevelDB キャッシュストアの名前を追加します。
   2. Next をクリックして作業を継続します。
8. 以下のように LevelDB キャッシュストアを設定します。
   

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

   1. 設定ウィンドウのオプションを使用して新しい LevelDB キャッシュストアを設定します。
   2. Finish をクリックして設定を完了します。
9. 以下のように再起動操作をスケジュールします。
   

   図18.4 再起動操作のスケジュール

   1. 画面の左パネルで、JBossAS7 Standalone Servers エントリーを展開します (まだ展開されていない場合)。
   2. 展開されたメニュー項目から JDG (0.0.0.0:9990) をクリックします。
   3. 画面の右パネルに、選択されたサーバーの詳細が表示されます。Operations タブをクリックします。
   4. Operation ドロップダウンボックスで、Restart 操作を選択します。
   5. Now エントリーのラジオボタンを選択します。
   6. Schedule をクリックしてサーバーをすぐに再起動します。
10. 以下のように新しい LevelDB キャッシュストアを検出します。
    

    図18.5 新しい LevelDB キャッシュストアの検出

    1. 画面の左パネルで、指定された順序で次の項目を選択して展開します: JBossAS7 Standalong Servers → JDG (0.0.0.0:9990) → infinispan → Cache Containers → local → Caches → default → LevelDB Stores
    2. 新しい LevelDB キャッシュストアの名前をクリックして右パネルの設定情報を表示します。