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

第28章 JBoss Cache の設定とデプロイメント

JBoss Cache は、 JBoss Enterprise Application クラスタの標準クラスタ化サービスの多くで使用される分散キャッシュサポートの基盤を提供します。カスタムキャッシュの要件に対応するようにアプリケーションに JBoss Cache をデプロイすることもできます。 本章では、 JBoss Cache で使用できる主な設定オプションについて説明し、 これらのオプションが Enterprise Appliation Platform によって提供される標準クラスタ化サービスが使用する JBoss Cache にどのように関連するかについて焦点を置きます。 また、 Enterprise Application Platform にカスタムキャッシュをデプロイするためのオプションについても説明します。
独自のアプリケーションによる直接利用を目的に JBoss Cache をデプロイしたい場合は、 Red Hat Documentation portalにある JBoss Cache ドキュメントを読んでからデプロイすることが強く推奨されます。
また、 標準の JBoss Enterprise Application Platform のクラスター化サービスがどのように JBoss Cache を使用するかについては、 「JBoss Cache による分散キャッシング」 を参照してください。

28.1. 主な JBoss Cache 設定オプション
リンクのコピー

JBoss Enterprise Application Platform には、 標準のクラスター化サービスのユースケースに適したデフォルトの JBoss Cache 設定が同梱されます (Web セッションレプリケーションや JPA/Hibernate キャッシングなど)。 標準のクラスター化サービスに関係するほとんどのアプリケーションは、同梱されている状態のままデフォルト設定で動作します。 ネットワークやパフォーマンスの要件が特別なアプリケーションをデプロイする場合のみ調整が必要になります。 本項では、選択できる主な設定の概要を説明します。 ここでは包括的な内容は取り上げないため、デフォルト設定以外も確認されたいユーザーは、 http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/ の JBoss Cache ドキュメントを参照してください。
本項の JBoss Cache 設定例の多くは、 XML より org.jboss.cache.config.Configuration オブジェクトグラフをビルドするのに JBoss Microcontainer スキーマを使用します。 JBoss Cache は独自のカスタム XML スキーマを持っていますが、 他の内部 Enterprise Application Platform サービスとの整合性を保つため、 標準 JBoss Enterprise Application Platform の CacheManager サービスは JBoss Microcontainer スキーマを使用します。
主な設定オプションについて説明する前に、それらのオプションを使用するような場合について見てみましょう。

28.1.1. CacheManager 設定の編集
リンクのコピー

「JBoss Enterprise Application Platform の CacheManager サービス」 の通り、 標準の JBoss Enterprise Application Platform のクラスター化サービスは CacheManager サービスを JBoss Cache インスタンスのファクトリとして使用します。 そのため、 キャッシュ設定を変更する場合、 CacheManager サービスの編集が必要になるでしょう。

注記

CacheManager を、 ユーザー独自のアプリケーションが直接使用するカスタムキャッシュのファクトリとして使用することもできます。 詳細は 「CacheManager サービスによるデプロイメント」 を参照してください。
CacheManager は $JBOSS_HOME/server/PROFILE/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml f ファイルにて設定できます。編集する可能性の高い要素は、 「CacheConfigurationRegistry」 Bean でしょう。この Bean は CacheManager が認識する名前付きの JBC 設定すべてのレジストリを保持しています。このファイルへの編集の多くは、 新しい JBoss Cache 設定の追加や既存設定のプロパティの変更が関係します。
以下は、 編集された「CacheConfigurationRegistry」Bean 設定になります。 
<bean name="CacheConfigurationRegistry" 
      class="org.jboss.ha.cachemanager.DependencyInjectedConfigurationRegistry">
   
      <!-- If users wish to add configs using a more familiar JBC config format
           they can add them to a cache-configs.xml file specified by this property.
           However, use of the microcontainer format used below is recommended.
      <property name="configResource">META-INF/jboss-cache-configs.xml</property>      
      -->
      
      <!-- The configurations. A Map<String name, Configuration config> -->
      <property name="newConfigurations">
        <map keyClass="java.lang.String" valueClass="org.jboss.cache.config.Configuration">
   
   <!-- The standard configurations follow.  You can add your own and/or edit these. -->   
      
   <!-- Standard cache used for web sessions -->
   <entry><key>standard-session-cache</key>
   <value>      
      <bean name="StandardSessionCacheConfig" class="org.jboss.cache.config.Configuration">
         
         <!-- Provides batching functionality for caches that don't want to 
              interact with regular JTA Transactions -->
         <property name="transactionManagerLookupClass">
            org.jboss.cache.transaction.BatchModeTransactionManagerLookup
         </property>
               
         <!-- Name of cluster. Needs to be the same for all members -->
         <property name="clusterName">${jboss.partition.name:DefaultPartition}-SessionCache</property>
         <!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
              because we are using asynchronous replication. -->
         <property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
         <property name="fetchInMemoryState">true</property>
         
         <property name="nodeLockingScheme">PESSIMISTIC</property>
         <property name="isolationLevel">REPEATABLE_READ</property>
         <property name="cacheMode">REPL_ASYNC</property>
      
          .... more details of the standard-session-cache configuration
      </bean>      
   </value>
   </entry>
   
   <!-- Appropriate for web sessions with FIELD granularity -->
   <entry><key>field-granularity-session-cache</key>
   <value>      
      
      <bean name="FieldSessionCacheConfig" class="org.jboss.cache.config.Configuration">              
           .... details of the field-granularity-standard-session-cache configuration
      </bean>      

   </value>

   </entry>

   ... entry elements for the other configurations

  </map>
  </property>
</bean>
Copy to Clipboard Toggle word wrap
実際の JBoss Cache 設定は、 標準の JBoss Cache 設定形式でなく 、JBoss Microcontainer のスキーマを使用して指定されます。 JBoss Cache が標準設定形式の 1 つを構文分析すると、 org.jboss.cache.config.Configuration タイプの Java Bean と、 さらに複雑なサブ設定 (キャッシュローティング、 エビクション、 バディレプリケーションなど) に対する子 Java Bean のツリーを作成します。 このような XML の構文分析や Java Bean の作成を JBCに 委譲する代わりに、 Enterprise Application Platform のマイクロコンテナーに直接このタスクを実行してもらいます。 これにより、 マイクロコンテナーは設定 Bean を認識します。 今後の Enterprise Application Platform 5.x リリースでは、 外部管理ツールで JBC 設定を管理できるようにするため便利です。
設定形式は、 Enterprise Application Platform に同梱される標準の設定を見ればすぐ理解できるはずです。 設定には主な要素がすべて含まれています。 JBoss Cache 設定を構成する 様々なJava Bean のタイプやプロパティについては JBoss Cache の javadoc を参照してください。 ここで、包括的な例を紹介します： 
<bean name="StandardSFSBCacheConfig" class="org.jboss.cache.config.Configuration">

   <!--  No transaction manager lookup -->
         
   <!-- Name of cluster. Needs to be the same for all members -->
   <property name="clusterName">${jboss.partition.name:DefaultPartition}-SFSBCache</property>
   <!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
        because we are using asynchronous replication. -->
   <property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
   <property name="fetchInMemoryState">true</property>
   
   <property name="nodeLockingScheme">PESSIMISTIC</property>
   <property name="isolationLevel">REPEATABLE_READ</property>
   <property name="cacheMode">REPL_ASYNC</property>
   
   <property name="useLockStriping">false</property>

   <!-- Number of milliseconds to wait until all responses for a
        synchronous call have been received. Make this longer 
        than lockAcquisitionTimeout.-->
   <property name="syncReplTimeout">17500</property>
   <!-- Max number of milliseconds to wait for a lock acquisition -->
   <property name="lockAcquisitionTimeout">15000</property>
   <!-- The max amount of time (in milliseconds) we wait until the
    state (ie. the contents of the cache) are retrieved from
    existing members at startup. -->
   <property name="stateRetrievalTimeout">60000</property>

   <!--
    SFSBs use region-based marshalling to provide for partial state
    transfer during deployment/undeployment.
   -->
   <property name="useRegionBasedMarshalling">false</property>
   <!-- Must match the value of "useRegionBasedMarshalling" -->
   <property name="inactiveOnStartup">false</property>
   
   <!-- Disable asynchronous RPC marshalling/sending -->
   <property name="serializationExecutorPoolSize">0</property>        
   <!-- We have no asynchronous notification listeners -->
   <property name="listenerAsyncPoolSize">0</property>
     
   <property name="exposeManagementStatistics">true</property>

   <property name="buddyReplicationConfig">
      <bean class="org.jboss.cache.config.BuddyReplicationConfig">
         
         <!--  Just set to true to turn on buddy replication -->
         <property name="enabled">false</property>
         
         <!-- A way to specify a preferred replication group.  We try
              and pick a buddy who shares the same pool name (falling 
              back to other buddies if not available). -->
         <property name="buddyPoolName">default</property>
         
         <property name="buddyCommunicationTimeout">17500</property>
         
         <!-- Do not change these -->
         <property name="autoDataGravitation">false</property>
         <property name="dataGravitationRemoveOnFind">true</property>
         <property name="dataGravitationSearchBackupTrees">true</property>
         
         <property name="buddyLocatorConfig">
            <bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
               <!-- The number of backup nodes we maintain -->
               <property name="numBuddies">1</property>
               <!-- Means that each node will *try* to select a buddy on 
                    a different physical host. If not able to do so 
                    though, it will fall back to colocated nodes. -->
               <property name="ignoreColocatedBuddies">true</property>
             </bean>
         </property>
      </bean>
   </property>
   <property name="cacheLoaderConfig">
      <bean class="org.jboss.cache.config.CacheLoaderConfig">
             <!-- Do not change these -->
             <property name="passivation">true</property>
             <property name="shared">false</property>
             
             <property name="individualCacheLoaderConfigs">
               <list>
                  <bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
                     <!-- Where passivated sessions are stored -->
                     <property name="location">${jboss.server.data.dir}${/}sfsb</property>
                     <!-- Do not change these -->
                     <property name="async">false</property>
                     <property name="fetchPersistentState">true</property>
                     <property name="purgeOnStartup">true</property>
                     <property name="ignoreModifications">false</property>
                     <property name="checkCharacterPortability">false</property>
                  </bean>
               </list>
             </property>
      </bean>
   </property>
  
   <!-- EJBs use JBoss Cache eviction -->
   <property name="evictionConfig">
       <bean class="org.jboss.cache.config.EvictionConfig">
         <property name="wakeupInterval">5000</property>
         <!--  Overall default -->
         <property name="defaultEvictionRegionConfig">
            <bean class="org.jboss.cache.config.EvictionRegionConfig">
               <property name="regionName">/</property>
               <property name="evictionAlgorithmConfig">
                  <bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
               </property>
            </bean>
         </property>
         <!-- EJB3 integration code will programatically create
              other regions as beans are deployed -->
      </bean>
   </property>
</bean>
Copy to Clipboard Toggle word wrap
基本的に、 XML は org.jboss.cache.config.Configuration Java Bean の作成と、 この Bean のプロパティ数の設定を指定します。 ほとんどのプロパティは単純なタイプですが、 buddyReplicationConfig や cacheLoaderConfig などは、 複数タイプの Java Bean を値とします。
次に、主な設定オプションの一部を見てみましょう。

28.1.2. キャッシュモード
リンクのコピー

JBoss Cache の cacheMode 設定属性は、2 つの関連アスペクトを 1 つのプロパティにします。
クラスター更新の処理
1 ノード上のキャッシュインスタンスがローカルステートを変更する際にどのように他のクラスターへ通知するかを制御します。 これには、 3 つのオプションがあります。
  • 同期 では、 キャッシュインスタンスがピアへメッセージを送信して変更を通知し、ピアが同じ変更を適用したか確認できるまで待機してから返信します。 JTA トランザクションの一部として変更された場合、 トランザクションコミット中の 2 フェーズコミットプロセスの一部として実行されます。 確認が受信されるまでロックは保留されます。 すべてのノードからの確認を待つと遅延が発生しますが、 クラスター周囲の整合性が保たれます。 クラスターのすべてのノードがキャッシュデータにアクセスする可能性があるため 整合性を維持する必要性が高い場合、同期モードが必要となります。
  • 非同期では、キャッシュインスタンスがピアにメッセージを送信し変更を通知すると同じ変更を適用したか確認する前に即座に返答します。キャッシュコンテンツを変更したスレッド以外のスレッドが送信メッセージを処理するわけではありません。変更を行うスレッドはクラスターへのメッセージ送信処理を行いますが、処理時間が同期の通信よりも短いだけです。送信を行うキャッシュのみがデータへアクセスし、クラスターメッセージを使い送信ノードに問題があった場合などバックアップコピーを提供するといった、セッション複製などの場合に、非同期モードは最も有用です。非同期のメッセージングは、後に別のノードにフェールオーバーするユーザー要求が期限切れステートになるリスクがありますが、同期モードよりも非同期モードの方がパフォーマンス的に利点が多いため、多くのセッションタイプアプリケーションでこのリスクは受け入れられています。
  • ローカルでは、キャッシュインスタンスは全くメッセージを送信しません。 JGroups チャネルもキャッシュによって使用されません。 JBoss Cache にはクラスタリング以外にも多くの便利な機能を持っており、 クラスタで使用されなくても大変有用なキャッシングライブラリとして機能します。また、 クラスター内でもキャッシュされたデータの一部で整合性を保つ必要がありません。 このような場合、 Local モードはパフォーマンスを改善することができます。 JPA/Hibernate クエリ結果セットのキャッシングがこの例となります。 Hibernate の 2 次キャッシングロジックは、 別のメカニズムを使用して 2 次キャッシュの陳腐化したクエリ結果セットを無効にするため、 JBoss Cache はクエリ結果セットキャッシュに対してクラスターの周囲でメッセージを送信する必要はありません。
レプリケーションと無効化
この側面は、 キャッシュがローカルステートを変更した時にクラスターの周囲へ送信されたメッセージの内容に対処します (クラスターの他のキャッシュがどのようにして変更を反映するかなど)。
  • レプリケーション では、 送信ノードの新しいステートを反映するため、 他のノードがステートを更新する必要があります。 送信ノードは変更されたステート含める必要があるため、 メッセージの負荷が大きくなります。 他のノードが別の方法でステートを取得できない場合、 レプリケーションが必要となります。
  • 無効化 では、 他のノードがローカルステートより変更されたステートを削除する必要があります。 無効化は、 ステート自体ではなく変更されたステートのキャッシュキーのみを送信する必要があるため、 クラスター更新メッセージの負荷を軽減します。 しかし、 削除されたステートを別のソースから取り出すことができる場合のみのオプションとなります。 キャッシュされたステートをデータベースより再読み取りできるため、 クラスター化された JPA/Hibernate エンティティキャッシュに最適なオプションです。
これら 2 つの側面が組み合わされ、 cacheMode 設定属性に対する 5 つの有効な値が形成されます。
  • LOCAL はクラスターメッセージが必要ないことを意味します。
  • REPL_SYNC は同期されたレプリケーションメッセージが送信されることを意味します。
  • REPL_ASYNC は、非同期のレプリケーションメッセージが送信されることを意味します。
  • INVALIDATION_SYNC は、 同期された無効化メッセージが送信されることを意味します。
  • INVALIDATION_ASYNC は、 非同期の無効化メッセージが送信されることを意味します。

28.1.3. トランザクションの処理
リンクのコピー

JBoss Cache は JTA トランザクションマネージャーと統合し、 キャッシュへのトランザクションのアクセスを許可します。 JBossCache がトランザクションの存在を検出すると、トランザクションが存在する間ロックが保持され、トランザクションがロールバックするとキャッシュへの変更が元に戻されます。 他のノードに変更を知らせるために送信されたクラスター全体へのメッセージは延期され、トランザクションコミットの一部としてバッチで送信されます (チャティネスを低減します)。
トランザクションマネージャーと統合するには、transactionManagerLookupClass 設定属性を設定します。 この属性は、 ローカルトランザクションマネージャーを検索するために JBoss Cache が使用できるクラスの完全修飾クラス名を指定します。 JBoss Enterprise Application Platform 内では、 この属性は次の 2 つの値のいずれかを持ちます。
  • org.jboss.cache.transaction.JBossTransactionManagerLookup
    この値は、 アプリケーションサーバーで実行されている標準のトランザクションマネージャーを検索します。 JTA トランザクションにキャッシングを参加させたい場合、 デプロイするカスタムキャッシュにこの値を使用します。
  • org.jboss.cache.transaction.BatchModeTransactionManagerLookup
    Web セッションと EJB SFSB キャッシングに使用されるキャッシュ設定にこの値が使用されます。 JBoss Cache に同梱される、 BatchModeTransactionManager と呼ばれる疑似の TransactionManager を指定します。 このトランザクションマネージャーは真の JTAト ランザクションマネージャーではないため、 JBoss Cache 以外には使用しないでください。 JBoss Enterprise Application Platform で使用すると、 要求中に実行されるエンドユーザートランザクションに絡まることなくセッションレプリケーションのユースケースに対して JBoss Cache のトランザクション動作の利点を提供することができます。

28.1.4. 並行アクセス
リンクのコピー

JBoss Cache はスレッドセーフのキャッシング API で、 独自の効率的なメカニズムを使用して並行アクセスを制御します。 並行アクセスは nodeLockingScheme 設定属性と isolationLevel 設定属性によって設定されます。
nodeLockingScheme には次の 3 つを選択できます。
  • MVCC (多版型同時実行制御: multi-versioned concurrency control) は、最新のデータベース実装が利用するロッキングスキームで、共有データへの高速で安全な並行アクセスを管理します。JBoss Cache 3.x は MVCC の革新的な実装をデフォルトのロッキングスキームとして使用します。MVCC は並行アクセスに対して次の機能を提供します。
    • ライターをブロックしないリーダー
    • 高速で失敗するライター
    並行ライターにデータのバージョン化やコピー化を使用して実現します。 ライターが共有ステートをコピーする間、 リーダーが共有ステートの読み取りを継続し、バージョン ID の値を上げます。 バージョンがまだ有効であることを確認してから (別の並行ライターが先にステートを変更しなかった場合など)、 共有ステートを書き戻します。
    JPA/Hibernate エントリキャッシングには MVCC の選択が推奨されます。
  • PESSIMISTIC (悲観的) ロッキングでは、 読み取りや書き込みを行う前にスレッドやトランザクションがノード上で排他的ロックか非排他的ロックを取得します。 どちらのロックが取得されるかは、 isolationLevel (下記参照) によって決まりますが、 ほとんどの場合で読み取りには非排他的ロック、 書き込みには排他的ロックが取得されます。 ライターが排他的ロックを完了してリリースするまでリーダースレッドがブロックされるため (書き込みがトランザクションの一部である場合は長期化する可能性があります)、 悲観的ロッキングは MVCC よりかなり多くのオーバヘッドを必要にし、 並行性も低下します。 また、 読み取りが継続することにより、 書き込みの遅延が発生します。
    JBoss Cache 3.0 で廃止された PESSIMISTIC より MVCC の方が通常は適切ですが、 JBoss Enterprise Application Platform 5.0.0 では PESSIMISTIC がデフォルトとなっています。 これは、 セッションのユースケースには同じキャッシュの場所へアクセスする並行スレッドがなく、 MVCC を使用する利点があまりないからです。
  • OPTIMISTIC (楽観的) ロッキングは、 キャッシュにアクセスする各リクエストやトランザクションの「ワークスペース」を作成して PESSIMISTIC の並行性を向上しようとします。リクエストやトランザクションによるデータへのアクセスは (読み取りも含む)、ワークスペースへコピーされるため、 オーバーヘッドが増加します。すべてのデータがバージョン化され、非トランザクションリクエストやトランザクションのコミットが終了すると、ワークスペースのデータバージョンがメインキャッシュと比較され、合致しない場合は例外が発行されます。合致する場合は、ワークスペースへの変更がメインキャッシュに適用されます。
    OPTIMISTIC ロッキングは廃止されましたが、 後方互換性を維持するために提供されます。 ユーザーは低負荷で同じ利点を持つ MVCC を使用することが推奨されます。
isolationLevel 属性には、 データベーススタイルの分離レベルのセマンティックに対応する READ_COMMITTED と REPEATABLE_READ の 2 つの値が使用できます。 旧バージョンの JBoss Cache は 5 つのデータベース分離レベルすべてをサポートしていました。 サポート対象外の分離レベルを設定すると、 もっとも近いサポート対象レベルにアップブレードまたはダウングレードされます。
REPEATABLE_READ はデフォルトの分離レベルで、 旧バージョンのJBoss Cache との互換性を維持します。 READ_COMMITTED の分離は若干弱くなりますが、 パフォーマンス面では REPEATABLE_READ よりも優れています。

28.1.5. JGroups の統合
リンクのコピー

各JBoss Cache インスタンスは内部で JGroups Channel を使用してグループ通信を処理します。 JBoss Enterprise Application Platform 内部では、 Enterprise Application Platform の JGroups Channel ファクトリサービスをキャッシュの Channel のソースとして使用することが強く推奨されます。 本項では、 チャネルファクトリよりチャネルを取得するようキャッシュを設定する方法について説明します。 別の方法でチャネルを設定したい場合は、 JBoss Cache のドキュメントを参照してください。
CacheManager サービスより取得したキャッシュ
最も簡単な方法になります。 CacheManager サービスは既にチャネルファクトリへの参照を持っているため、 使用する JGroups プロトコルスタック設定の名前のみを設定する必要があります。
jboss-cache-manager-jboss-beans.xml ファイル (「CacheManager サービスによるデプロイメント」 を参照) よりキャッシュを設定する場合は、 次をキャッシュ設定に追加します。 値はプロトコルスタック設定の名前になります。 
<property name="multiplexerStack">udp</property>
Copy to Clipboard Toggle word wrap
-jboss-beans.xml ファイルよりデプロイされたキャッシュ
JBoss Microcontainer の -jboss-beans.xml ファイル (「-jboss-beans.xml ファイルからのデプロイメント」 を参照) よりキャッシュをデプロイする場合は、 チャネルファクトリサービスへの参照を挿入し、 プロトコルスタック設定を指定する必要があります。 
<property name="runtimeConfig">
   <bean class="org.jboss.cache.config.RuntimeConfig">
      <property name="muxChannelFactory"><inject bean="JChannelFactory"/></property>
   </bean>
</property>
<property name="multiplexerStack">udp</property>
Copy to Clipboard Toggle word wrap
-service.xml ファイルよりデプロイされたキャッシュ
キャッシュ MBean を -service.xml ファイル (「-service.xml ファイルからのデプロイメント」 を参照) よりデプロイする場合は、 CacheJmxWrapper が MBean のクラスになります。 このクラスは、 MuxChannelFactory MBean 属性を公開します。 この属性へチャネルファクトリサービスの依存関係を挿入し、 MultiplexerStack 属性よりプロトコルスタック名を設定します。 
<attribute name="MuxChannelFactory"><inject bean="JChannelFactory"/></attribute>
<attribute name="MultiplexerStack">udp</attribute>
Copy to Clipboard Toggle word wrap

28.1.6. エビクション
リンクのコピー

エビクションは、 キャッシュがデータ (通常、頻繁に使用されないデータ) を削除してメモリ制御を行えるようにします。 カスタムキャッシュにエビクションを設定するには、 使用できるオプションすべてを JBoss Cache ドキュメントで確認してください。 JPA/Hibernate キャッシングへの設定は、 http://www.jboss.org/jbossclustering/docs/hibernate-jbosscache-guide-3.pdf の 「Using JBoss Cache as a Hibernate Second Level Cache」 ガイドにあるエビクションの章を参照してください。Web セッションキャッシュにはエビクションを設定しないでください。 分散可能セッションマネージャがエビクションに対応します。 EJB 3 SFSB キャッシュに対しては、 Enterprise Application Platform の標準の sfsb-cache 設定 (「JBoss Enterprise Application Platform の CacheManager サービス」 参照) にあるエビクション設定を使用してください。 各 Bean の設定に含まれている値を使用して EJB コンテナがエビクションを設定します。

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

キャッシュローディングは、 JBoss Cache がデータをメモリだけなく永続ストアに保存できるようにします。 データは 、永続ストアのデータがメモリに反映されないオーバーフローか、 メモリに保存されているデータのスーパセットとなります。 スーパーセットとなる場合、 メモリにあるデータやメモリからエビクトされたデータは永続ストアに反映されます。 どちらが使用されるかは、 JBoss Cache のキャッシュローダ設定にある passivation フラグの設定によって決まります。 値が true の場合、デ ータがメモリ内キャッシュからエビクトされた時書き込まれるオーバーフロー領域として永続ストアが機能します。
カスタムキャッシュにキャッシュローディングを設定したい場合は、 使用できるすべてのオプションを JBoss Cache ドキュメントで確認してください。 JPA/Hibernate キャッシュにキャッシュローディングを設定しないでください。 データベース自体が永続ストアとして機能するため、 キャッシュローダーの追加は不要になります。
Web セッションと EJB3 SFSB のキャッシングに使用されるキャッシュは非活性化を使用します。 次に、 これらのキャッシュに対するキャッシュローダー設定について説明します。

28.1.7.1. Web セッションキャッシュと SFSB キャッシュの CacheLoader 設定
リンクのコピー

HttpSession と SFSB の非活性化は、 JBoss Cache のキャッシュローダー非活性化に依存して、 非活性化されたセッションを保存し読み出します。そのため、Web アプリケーションのクラスター化セッションマネージャーや Bean の EJB コンテナーによって使用されるキャッシュインスタンスを設定し、 キャッシュローダーの非活性化を有効にしなければなりません。
ほとんどの場合、標準の Web セッションキャッシュや SFSB キャッシュに対してキャッシュローダーを変更する必要はありません 。標準の JBoss Enterprise Application Platform の設定で適切なはずです。 次は、 デフォルトを変更したいユーザー向けの内容になります。
standard-session-cache 設定のキャッシュローダー設定を例にします。 
<property name="cacheLoaderConfig">
   <bean class="org.jboss.cache.config.CacheLoaderConfig">
          <!-- Do not change these -->
          <property name="passivation">true</property>
          <property name="shared">false</property>
          
          <property name="individualCacheLoaderConfigs">
            <list>
               <bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
                  <!-- Where passivated sessions are stored -->
                  <property name="location">${jboss.server.data.dir}${/}session</property>
                  <!-- Do not change these -->
                  <property name="async">false</property>
                  <property name="fetchPersistentState">true</property>
                  <property name="purgeOnStartup">true</property>
                  <property name="ignoreModifications">false</property>
                  <property name="checkCharacterPortability">false</property>
               </bean>
            </list>
          </property>
   </bean>
</property>
Copy to Clipboard Toggle word wrap
説明
  • passivation プロパティは true でなければなりません。
  • shared プロパティは false でなければなりません。 共有の永続ストアにセッションを非活性化しないでください。非活性化すると、 別のノードがセッションをアクティベートした時にセッションが永続ストアより削除され、 以前同じセッションを非活性化した別のノードにあるメモリからも削除されます。 バックアップコピーを紛失します。
  • individualCacheLoaderConfigs プロパティはキャッシュローダ設定のリストを許可します。 JBC によって、 キャッシュローダーをチェーンできるようになります。 詳細は JBoss Cache のドキュメントを参照してください。 セッション非活性化のユースケースでは、 単一のキャッシュローダーで十分です。
  • キャッシュローダー設定 Bean 上の class 属性は、 キャッシュローダー実装の設定クラスを参照しなければなりません (org.jboss.cache.loader.FileCacheLoaderConfig または org.jboss.cache.loader.JDBCCacheLoaderConfig)。 使用できる CacheLoader 実装の詳細は JBoss Cache のドキュメントを参照してください。 JDBCCacheLoader を使用したい場合 (FileCacheLoader が使用するファイルシステムではなくデータベースへ永続させるため)、 前述の shared プロパティに関するコメントを参照してください。 共有データベースは使用しないようにしてください。 最低でもデータベースの共有テーブルは使用しないでください。 クラスタの各ノードは独自の保存場所が必要です。
  • FileCacheLoaderConfig の location プロパティは、 非活性化されたセッションが保存されるファイルシステムツリーのルートノードを定義します。 デフォルトでは、 JBoss Enterprise Application Platform 設定の data ディレクトリに保存されます。
  • 非活性化されたセッションが迅速に永続ストアへ書き込まれるようにするため、 async を false にしなければなりません。
  • キャッシュの開始時に別のノードより転送されるセッションバックアップコピーのセットに非活性化されたセッションが含まれるようにするため、 fetchPersistentState プロパティを true にしなければなりません。
  • 過去にサーバーがシャットダウンした時に残存した期限切れのセッションデータが現在のデータセットを破損しないようにするため、 purgeOnStartup を true にしなければなりません。
  • ignoreModifications を false にする必要があります。
  • マイナーなパフォーマンスの最適化を行うため、 checkCharacterPortability をfalse にしなければなりません。

28.1.8. バディレプリケーション
リンクのコピー

バディレプリケーションは、 クラスターの全てのインスタンスへのデータレプリケーションを抑制えきるようにする JBoss Cache の機能です。 各インスタンスはクラスターで 1 つ以上の「バディ」を選択し、 特定のバディのみをレプリケートします。 他のインスタンスがクラスターへ追加された時にメモリやネットワークトラフィックへの影響がないため、 スケーラビリティが向上します。
他のノードにあるキャッシュがローカルにないデータを必要とする場合、クラスターの別のノードに提供を求めることができます。 コピーを持っているノードは、 「データグラビテーション」と呼ばれるプロセスの一部としてデータを提供します。 新しいノードがデータの所有者となり、 データのバックアップコピーをバディへ置きます。 データをグラビテーションできるということは、 データへの全要求がコピーを持っているノード上で発生しなくてもよいことを意味します。 すべてのノードがデータへの要求を処理できます。 しかし、 データグラビテーションは負荷が高いため、 頻繁に発生しないようにしなければなりません。 同じデータを使用しているノードが障害を起こすか、シャットダウンして、 対象のクライアントが別ノードへのフェールオーバーを強制された場合のみデータグラビテーションが発生するようにするのが理想的です。 これにより、 特定セッションへのすべての要求が通常単一のサーバーによって処理される場合、セッションアフィニティを持つセッションタイプのアプリケーション (スティッキーセッション) に対するバディレプリケーションが有用になります。
バディアプリケーションを Web セッションキャッシュと EJB3 SFSB キャッシュに対して有効にすることができます。 他の標準クラスタ化サービス (JPA/Hibernate キャッシングなど) が使用するキャッシュ設定にバディレプリケーションを追加しないようにしてください。 バディレプリケーション向けに特別設計されていないサービスでは、 バディレプリケーションが導入されてもまず適切に動作することはないでしょう。
バディレプリケーションの設定は比較的単純です。 例として、 CacheManager サービスの standard-session-cache 設定より、 バディレプリケーション設定のセクションを見てみましょう。 
<property name="buddyReplicationConfig">
   <bean class="org.jboss.cache.config.BuddyReplicationConfig">
               
      <!--  Just set to true to turn on buddy replication -->
      <property name="enabled">true</property>
               
      <!-- A way to specify a preferred replication group.  We try
           and pick a buddy who shares the same pool name (falling 
           back to other buddies if not available). -->
      <property name="buddyPoolName">default</property>
               
      <property name="buddyCommunicationTimeout">17500</property>
               
      <!-- Do not change these -->
      <property name="autoDataGravitation">false</property>
      <property name="dataGravitationRemoveOnFind">true</property>
      <property name="dataGravitationSearchBackupTrees">true</property>
               
      <property name="buddyLocatorConfig">
         <bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
            <!-- The number of backup copies we maintain -->
            <property name="numBuddies">1</property>
            <!-- Means that each node will *try* to select a buddy on 
                 a different physical host. If not able to do so 
                 though, it will fall back to colocated nodes. -->
            <property name="ignoreColocatedBuddies">true</property>
          </bean>
      </property>
   </bean>
</property>
Copy to Clipboard Toggle word wrap
設定対象となる主な項目は次の通りです。
  • buddyReplicationEnabled — バディレプリケーションを実行したい場合は true、 クラスターのすべてのノードでデータをレプリケートする場合は false を設定します。 false の場合、バディレプリケーションの他の設定は関係ありません。
  • numBuddies — 各ノードがステートをレプリケートするバックアップノードの数です。
  • buddyPoolName — クラスター内でノードの論理サブグループ化を有効にします。 可能な場合、 同じバディプール内のノードよりバディが選択されます。
ignoreColocatedBuddies スイッチは、 キャッシュがバディを検索する時に、 可能な場合はキャッシュと同じ物理ホスト上にあるバディを選択しないようにします。 同じマシン上で稼働しているサーバーのみが見つかった場合、 そのサーバーバディとして使用します。
autoDataGravitation、 dataGravitationRemoveOnFind、 dataGravitationSearchBackupTrees の設定は変更しないでください。 これらの変更を変更すると、 セッションレプリケーションが正しく動作しません。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat