此内容没有您所选择的语言版本。

16.2.2. Configure the Cache Loader using XML


The following example demonstrates cache loader configuration using XML.

Procedure 16.1. Configure the Cache Loader Using XML

  1. Create a New Cache Loader

    Create a new cache loader, specifying passivation, shared, and preload settings.
    1. passivation affects the way in which Red Hat JBoss Data Grid interacts with loaders. Passivation removes an object from in-memory cache and writes it to a secondary data store, such as a system or database. Passivation is false by default.
    2. shared indicates that the cache loader is shared by different cache instances. For example, where all instances in a cluster use the same JDBC settings to talk to the same remote, shared database. shared is false by default. When set to true, it prevents duplicate data being written to the cache loader by different cache instances.
    3. preload is set to false by default. When set to true the data stored in the cache loader is preloaded into the memory when the cache starts. This allows data in the cache loader to be available immediately after startup and avoids cache operations delays as a result of loading data lazily. Preloaded data is only stored locally on the node, and there is no replication or distribution of the preloaded data. Red Hat JBoss Data Grid will only preload up to the maximum configured number of entries in eviction.
    <persistence passivation="false" shared="false" preload="true">
    
    Copy to Clipboard Toggle word wrap
  2. Set Up Persistence and Purging

    1. fetchPersistentState determines whether or not to fetch the persistent state of a cache and apply it to the local cache store when joining the cluster. If the cache store is shared the fetch persistent state is ignored, as caches access the same cache store. A configuration exception will be thrown when starting the cache service if more than one cache loader has this property set to true. The fetchPersistentState property is false by default.
    2. purgeSynchronously controls whether expiration occurs in the eviction thread. When set to true, the eviction thread will block until the purge is finished, rather than bring returned immediately. The purgeSychronously property is set to false by default. If the cache loader supports multi-thread purge, purgeThreads are used to purge expired entries. purgeThreads is set to 1 by default. Check cache loader configuration to determine if multi-thread purge is supported.
    3. ignoreModifications determines whether write methods are pushed to the specific cache loader by allowing write operations to the local file cache loader, but not the shared cache loader. In some cases, transient application data should only reside in a file-based cache loader on the same server as the in-memory cache. For example, this would apply with a further JDBC based cache loader used by all servers in the network. ignoreModifications is false by default.
    <persistence passivation="false" shared="false" preload="true">
       <fileStore
               fetchPersistentState="true"
               purgerThreads="3"
               purgeSynchronously="true"
               ignoreModifications="false"
               purgeOnStartup="false"
               location="${java.io.tmpdir}" />
    
    Copy to Clipboard Toggle word wrap
  3. Asynchronous Settings

    These attributes configure aspects specific to each cache loader. For example, the location attribute points to where the SingleFileStore keeps files containing data. Other loaders may require more complex configuration.
    <persistence passivation="false" shared="false" preload="true">
       <fileStore
               fetchPersistentState="true"
               purgerThreads="3"
               purgeSynchronously="true"
               ignoreModifications="false"
               purgeOnStartup="false"
               location="${java.io.tmpdir}" >
          <async
               enabled="true"
               flushLockTimeout="15000"
               threadPoolSize="5" />
       </fileStore>
    
    Copy to Clipboard Toggle word wrap
  4. Configure Singletons and Push States

    1. singletonStore enables modifications to be stored by only one node in the cluster. This node is called the coordinator. The coordinator pushes the caches in-memory states to disk. This function is activated by setting the enabled attribute to true in all nodes. The shared parameter cannot be defined with singletonStore enabled at the same time. The enabled attribute is false by default.
    2. pushStateWhenCoordinator is set to true by default. If true, this property will cause a node that has become the coordinator to transfer in-memory state to the underlying cache loader. This parameter is useful where the coordinator has crashed and a new coordinator is elected.
    <persistence passivation="false" shared="false" preload="true">
       <fileStore
               fetchPersistentState="true"
               purgerThreads="3"
               purgeSynchronously="true"
               ignoreModifications="false"
               purgeOnStartup="false"
               location="${java.io.tmpdir}" >
          <async
               enabled="true"
               flushLockTimeout="15000"
               threadPoolSize="5" />
          <singletonStore
               enabled="true"
               pushStateWhenCoordinator="true"
               pushStateTimeout="20000" />
       </fileStore>
    </persistence>
    
    Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat