17.2. Cache Store Configuration

17.2.1. Configuring the Cache Store

Cache stores can be configured in a chain. Cache read operations checks each cache store in the order configured until a valid non-null element of data has been located. Write operations affect all cache stores unless the ignoreModifications element has been set to "true" for a specific cache store.
Report a bug

17.2.2. Configure the Cache Store using XML (Library Mode)

The following example demonstrates cache store configuration using XML in JBoss Data Grid's Library mode: 
<persistence passivation="false">
   <singleFile
           shared="false"
           preload="true"
           fetchPersistentState="true"
           ignoreModifications="false"
           purgeOnStartup="false"
           location="${java.io.tmpdir}" >
      <async
           enabled="true"
           flushLockTimeout="15000"
           threadPoolSize="5" />
      <singleton
           enabled="true"
           pushStateWhenCoordinator="true"
           pushStateTimeout="20000" />
   </singleFile>
</persistence>
For details about the elements and parameters used in this sample configuration, see Section 18.2, “Cache Store Configuration Details (Library Mode)”.
Report a bug

17.2.3. Configure the Cache Store Programmatically

The following example demonstrates how to configure the cache store programmatically: 
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.persistence()
    .passivation(false)
    .addSingleFileStore()
        .shared(false)
        .preload(true)
        .fetchPersistentState(true)
        .ignoreModifications(false)
        .purgeOnStartup(false)
        .location(System.getProperty("java.io.tmpdir"))
        .async()
           .enabled(true)
           .flushLockTimeout(15000)
           .threadPoolSize(5)
        .singleton()
           .enabled(true)
           .pushStateWhenCoordinator(true)
           .pushStateTimeout(20000);

Procedure 17.1. Configure the Cache store Programatically

  1. Create a New Configuration Builder

    Use the ConfigurationBuilder to create a new configuration object.

  2. Set Passivation

    passivation affects the way Red Hat JBoss Data Grid interacts with stores. 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.

  3. Configure the Cache Store

    addSingleFileStore() adds the SingleFileStore as the cache store for this configuration. It is possible to create other stores, such as a JDBC Cache Store, which can be added using the addStore method.

  4. Set Up Sharing

    shared indicates that the cache store 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 store by different cache instances.

  5. Set Up Preloading

    preload is set to false by default. When set to true the data stored in the cache store is preloaded into the memory when the cache starts. This allows data in the cache store 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. JBoss Data Grid will only preload up to the maximum configured number of entries in eviction.

  6. Set Up Persistence

    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 store has this property set to true. The fetchPersistentState property is false by default.

  7. Set Modifications

    ignoreModifications determines whether write methods are pushed to the specific cache store by allowing write operations to the local file cache store, but not the shared cache store. In some cases, transient application data should only reside in a file-based cache store on the same server as the in-memory cache. For example, this would apply with a further JDBC based cache store used by all servers in the network. ignoreModifications is false by default.

  8. Set Up Purging

    purgeOnStartup controls whether cache store is purged when it starts up.

  9. Set Up Location

    location configuration element sets a location on disk where the store can write.

  10. Asynchronous Settings

    These attributes configure aspects specific to each cache store. For example, the location attribute points to where the SingleFileStore will keep files containing data. Other stores may require more complex configuration.

  11. Configure Singletons

    singleton 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 singleton enabled at the same time. The enabled attribute is false by default.

  12. Set Up Push States

    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 store. This parameter is useful where the coordinator has crashed and a new coordinator is elected.
Report a bug

17.2.4. About SKIP_CACHE_LOAD Flag

In Red Hat JBoss Data Grid's Remote Client-Server mode, when the cache is preloaded from a cache store and eviction is disabled, read requests go to the memory. If the entry is not found in a memory during a read request, it accesses the cache store which may impact the read performance.
To avoid referring to the cache store when a key is not found in the memory, use the SKIP_CACHE_LOAD flag.
Report a bug