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

9.2. 設定

JBoss Cacheの XML ファイルではキャッシュローダーは次のように設定されます。 1 つのチェーンに複数のキャッシュローダーを定義することができます。 キャッシュは、 null 以外の有効なデータ要素を見つけるまで、 設定された順序ですべてのキャッシュローダーを参照します。書き込みを実行すると、 すべてのキャッシュローダーに書き込まれます (特定のキャッシュローダーに対して ignoreModifications 要素が true に設定されている場合を除きます)。 詳細は次の設定セクションを参照してください。 
...

<!-- Cache loader config block -->
<!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
<loaders passivation="false" shared="false">
      <preload>
         <!-- Fqns to preload -->
         <node fqn="/some/stuff"/>
      </preload>
      <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
      <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="true"
              ignoreModifications="false" purgeOnStartup="false">
         <properties>
            cache.jdbc.driver=com.mysql.jdbc.Driver
            cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb
            cache.jdbc.user=root
            cache.jdbc.password=
         </properties>
      </loader>
  </loaders>
class 要素はキャッシュローダー実装のクラスを定義します (JBoss AS のプロパティエディタに存在するバグにより、 Windows ファイル名の変数のバックスラッシュが正常に展開されない場合があります。 このような場合、 「replace="false"」 と指定する必要があります)。 キャッシュローダーの実装には空のコンストラクタが存在しなければなりません。
properties 要素は該当する実装に固有する設定を定義します。 たとえば、 ファイルシステムベースの実装は使用するルートディレクトリを定義し、 データベースの実装はデータベース接続を確立するデータベース URL、 名前、 パスワードを定義できます。 この設定は CacheLoader.setConfig(Properties) よりキャッシュローダー実装に渡されます。 バックスペースをエスケープ処理しなければならないことがあります。
preload は、 起動時にキャッシュによってビジットされるノードやサブツリー全体のリストを定義し、 これらのノードに関連するデータを事前ロードできるようにします。 デフォルト ("/") では、 バックエンドストアにある全データをキャッシュへロードしますが、 バックエンドストアのデータが大きい場合もあるため、 不適切である場合も多いでしょう。 例えば、 /a, /product/catalogue はサブツリー /a と /product/catalogue をキャッシュにロードしますが、 それ以外はロードしません。 それ以外はアクセスされた時にレイジーにロードされます。 事前ロードは、 あるサブツリー下の要素を頻繁に使用することが予想される場合に適しています。
fetchPersistentState は、 クラスタへ参加した時にキャッシュの永続ステートをフェッチするかどうかを決定します。 このプロパティを true に設定できるキャッシュローダーは 1 つだけです。 複数のキャッシュローダーに true を設定すると、 キャッシュサービスの起動時に設定例外がスローされます。
async は、 キャッシュローダーへの書き込み完了するまでブロックするか、 書き込みが即座に返すよう別のスレッドで実行するかを決定します。 true に設定すると、 org.jboss.cache.loader.AsyncCacheLoader のインスタンスが、 使用される実際のキャッシュローダーインスタンスで構築されます。 次に、 AsyncCacheLoader は、 必要に応じて別のスレッドを使用してすべての要求を基礎となるキャッシュローダーに委譲します。 詳細については、 AsyncCacheLoader に関する Javadoc を参照してください。 指定がない場合、 async 要素のデフォルトは false になります。

注記

すべての書き込みが非同期的に実行されるため、 常にダーティな読み取りが発生する可能性があります。 したがって、 書き込みの成功は保証できません。 これを念頭に置いて async 要素を true に設定するようにしてください。
ignoreModifications は書き込みメソッドを特定のキャッシュローダーにプッシュするかどうかを決定します。 ネットワークの全サーバーによって使用される JDBCCacheLoader など、 インメモリキャッシュと同じサーバー上にあるファイルベースのキャッシュローダーのみに一時アプリケーションデータが存在しなければならない場合などが該当します。 この機能により、 共有される JDBCCacheLoader へ書き込みせずに 「ローカル」 のファイルキャッシュローダーへ書き込みすることが可能になります。 このプロパティはデフォルトで false に設定されているため、 設定された全キャッシュローダーへ書き込みが伝播されます。
purgeOnStatup は、キャッシュローダーが起動した時に指定されたキャッシュローダーを空にします (ignoreModifications が false に設定されている場合)。
shared は異なるキャッシュインスタンスによってキャッシュローダーが共有されることを表しています。 例えば、 クラスタのすべてのインスタンスが同じ JDBC 設定を使用して同じリモートの共有データベースと通信する場合などがこれに該当します。 true を設定すると、 異なるキャッシュインスタンスによって同じデータがキャッシュに繰り返し書き込まれないようにし、 不必要な書き込みが発生しないようにします。 デフォルト値は false になります。

9.2.1. シングルトンストアの設定
リンクのコピー

 <loaders passivation="false" shared="true">
    <preload>
       <node fqn="/a/b/c"/>
       <node fqn="/f/r/s"/>
    </preload>

    <!-- we can now have multiple cache loaders, which get chained -->
    <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="false" fetchPersistentState="false"
         ignoreModifications="false" purgeOnStartup="false">
       <properties>
         cache.jdbc.datasource=java:/DefaultDS
       </properties>
       <singletonStore enabled="true" class="org.jboss.cache.loader.SingletonStoreCacheLoader">
          <properties>
             pushStateWhenCoordinator=true
             pushStateWhenCoordinatorTimeout=20000
          </properties>
       </singletonStore>
    </loader>
 </loaders>
singletonStore 要素は、 クラスタのノードであるコーディネータのみが変更を保存できるようにします。 データがノードに入力されると、 キャッシュのインメモリステートを同期に保つため、 データがレプリケートされます。 このステートをディスクにプッシュすることのみがコーディネータの役目となります。 すべてのノードに enabled サブ要素を設定してこの機能を有効にすることができますが、 クラスタのコーディネータのみが loader 要素で定義された基礎のキャッシュローダーへ変更を保存することができます。 singletonStore が有効になっている状態でキャッシュローダーを shared として定義することはできません。 enabled のデフォルト値は false です。
シングルトンストア機能を提供する実装クラスを指定する class 要素を singletonStore 要素内で定義することもできます。 このクラスは org.jboss.cache.loader.AbstractDelegatingCacheLoader を拡張する必要があり、 指定がない場合は org.jboss.cache.loader.SingletonStoreCacheLoader がデフォルトとなります。
properties サブ要素は、 シングルトンストア機能を提供するクラスの動作を変更できるプロパティを定義します。 デフォルトでは、 pushStateWhenCoordinator プロパティと pushStateWhenCoordinatorTimeout プロパティが定義されていますが、 シングルトンストア機能を提供するユーザー定義クラスの必要に応じて追加することができます。
pushStateWhenCoordinator は、 クラスタトポロジの変更によりコーディネータが新たに選出された場合に、 ノードがコーディネータとなった際にインメモリステートをキャッシュストアへプッシュできるようにします。 これは、 コーティネータがクラッシュし、 新しいコーディネータが選出されるまでに時間の隔たりがある場合に大変便利です。 この場合、 プロパティが false に設定され、 キャッシュが更新されると、 変更は永続化されません。 各ノードのキャッシュローダーが異なる場所に設定されている場合、 このプロパティを true に設定した方がよいでしょう。 デフォルト値は true です。
pushStateWhenCoordinatorTimeout は pushStateWhenCoordinator が true に設定されている場合のみ該当します。 この場合、 インメモリステートを基礎のキャッシュローダーへプッシュする処理の最大時間 (ミリ秒単位) を設定し、 この時間を超過すると PushStateException が報告されます。 デフォルト値は 20000 です。

注記

キャッシュローダーをシングルトンとして設定し、 キャッシュパッシベーションを使用すると (エビクションより)、 悪影響を与える可能性があります。 クラスタが新しいコーディネータを選出している間に、 エビクションが原因でノードがパッシベートされると、 データが損失されます。 これは、 この時点ではアクティブなコーティネータが存在せず、 パッシベートされたノードを保存するノードがクラスタに存在しないからです。 コーディネータがクラスタから退去したり、 クラッシュしたり応答しなくなった場合に新しいコーディネータがクラスタで選出されます。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る