Chapter 13. Cache Stores


The cache store connects Red Hat JBoss Data Grid to the persistent data store. The cache store is used to:
  • fetch data from the data store when a copy is not in the cache.
  • push modifications made to the data in cache back to the data store.
Caches that share the same cache manager can have different cache store configurations, as cache stores are associated with individual caches.

13.1. File System Based Cache Stores

Red Hat JBoss Data Grid includes one file system based cache store: the SingleFileCacheStore.
The SingleFileCacheStore is a simple, file system based implementation and a replacement to the older file system based cache store: the FileCacheStore.
SingleFileCacheStore stores all key/value pairs and their corresponding metadata information in a single file. To speed up data location, it also keeps all keys and the positions of their values and metadata in memory. Hence, using the single file cache store slightly increases the memory required, depending on the key size and the amount of keys stored. Hence SingleFileCacheStore is not recommended for use cases where the keys are too big.
To reduce memory consumption, the size of the cache store can be set to a fixed number of entries to store in the file. However, this works only when Infinispan is used as a cache. When Infinispan used this way, data which is not present in Infinispan can be recomputed or re-retrieved from the authoritative data store and stored in Infinispan cache. The reason for this limitation is because once the maximum number of entries is reached, older data in the cache store is removed, so if Infinispan was used as an authoritative data store, it would lead to data loss which is undesirable in this use case
Due to its limitations, SingleFileCacheStore can be used in a limited capacity in production environments. It can not be used on shared file system (such as NFS and Windows shares) due to a lack of proper file locking, resulting in data corruption. Furthermore, file systems are not inherently transactional, resulting in file writing failures during the commit phase if the cache is used in a transactional context.

13.1.1. Single File Store Configuration (Remote Client-Server Mode)

The following is an example of a Single File Store configuration for Red Hat JBoss Data Grid's Remote Client-Server mode:

Procedure 13.1. Configure the Single File Store

  1. Add the Cache Name

    The name parameter of the local-cache attribute is used to specify a name for the cache.
    <local-cache name="default">
    
    Copy to Clipboard
  2. Per-cache Statistics

    If statistics are enabled at the container level, per-cache statistics can be selectively disabled for caches that do not require monitoring by setting the statistics attribute to false.
    <local-cache name="default" statistics="true">
    
    Copy to Clipboard
  3. Configure the file-store Element

    The file-store element specifies configuration information for the single file store.
    The name parameter of the file-store element is used to specify a name for the file store.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore" />
    
    Copy to Clipboard
  4. Set the passivation Parameter

    The passivation parameter determines whether entries in the cache are passivated (true) or if the cache store retains a copy of the contents in memory (false).
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true" />
    
    Copy to Clipboard
  5. Set the purge Parameter

    The purge parameter specifies whether or not the cache store is purged when it is started. Valid values for this parameter are true and false.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true" />
    
    Copy to Clipboard
  6. Set the shared Parameter

    The shared parameter is used when multiple cache instances share a cache store. This parameter can be set to prevent multiple cache instances writing the same modification multiple times. Valid values for this parameter are true and false. However, the shared parameter is not recommended for file-store.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false" />
    
    Copy to Clipboard
  7. Specify the Directory Path Within the relative-to Parameter

    The relative-to property is the directory where the file-store stores the data. It is used to define a named path.
    The path property is the name of the file where the data is stored. It is a relative path name that is appended to the value of the relative-to property to determine the complete path.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}" />
    </local-cache>
    
    Copy to Clipboard
  8. Specify the maximum number of entries

    The maxEntries parameter provides maximum number of entries allowed. The default value is -1 for unlimited entries.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"/>
    </local-cache>
    
    Copy to Clipboard
  9. Set the fetch-state Parameter

    The fetch-state parameter when set to true fetches the persistent state when joining a cluster. If multiple cache stores are chained, only one of them can have this property enabled. Persistent state transfer with a shared cache store does not make sense, as the same persistent store that provides the data will just end up receiving it. Therefore, if a shared cache store is used, the cache does not allow a persistent state transfer even if a cache store has this property set to true. It is recommended to set this property to true only in a clustered environment. The default value for this parameter is false.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"
                    fetch-state="true"/>
    </local-cache>
    
    Copy to Clipboard
  10. Set the preload Parameter

    The preload parameter when set to true, loads the data stored in the cache store into memory when the cache starts. However, setting this parameter to true affects the performance as the startup time is increased. The default value for this parameter is false.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"
                    fetch-state="true"
                    preload="false"/>
    </local-cache>
    
    Copy to Clipboard
  11. Set the singleton Parameter

    The singleton parameter enables a singleton store cache store. SingletonStore is a delegating cache store used when only one instance in a cluster can interact with the underlying store. However, singleton parameter is not recommended for file-store.
    <local-cache name="default" statistics="true">
        <file-store name="myFileStore"
                    passivation="true"
                    purge="true"
                    shared="false"
                    relative-to="{PATH}"
                    path="{DIRECTORY}"
                    max-entries="10000"
                    fetch-state="true"
                    preload="false"
                    singleton="true"/>
    </local-cache>
    
    Copy to Clipboard

13.1.2. Single File Store Configuration (Library Mode)

In Red Hat JBoss Grid's Library mode, configure a Single File Cache Store as follows:.

Procedure 13.2. Configuring the Single File Store in Library Mode

The singleFile element is used to configure the Single File Cache Store. Configure the following in infinispan.xml.
  1. Add the name value to the namedCache element. The following is an example of this step:
    <namedCache name="writeThroughToFile">
    
    Copy to Clipboard
  2. In the persistence element, set the passivation parameter to false. Possible values are true and false.
    <namedCache name="writeThroughToFile">
          <persistence passivation="false" />
    
    Copy to Clipboard
  3. Set up a single file configuration using the singleFile element:
    • fetchPersistentState - If set to true, the persistent state is fetched when joining a cluster. If multiple cache stores are chained, only one cache store can have this property set to true . The default for this value is false.
    • The ignoreModifications parameter determines whether operations that modify the cache (e.g. put, remove, clear, store, etc.) do not affect the cache store. As a result, the cache store can become out of sync with the cache.
    • The purgeOnStartup parameter specifies whether the cache store is purged when initially started.
    • The shared parameter is set to true when multiple cache instances share a cache store, which prevents multiple cache instances writing the same modification individually. The default for this attribute is false. However, the shared parameter is not recommended for file-store.
    • The preload parameter sets whether the cache store data is pre-loaded into memory and becomes immediately accessible after starting up. The disadvantage of setting this to true is that the start up time increases. The default value for this attribute is false.
    • The location parameter points to the location of file store.
    • The maxEntries parameter provides maximum number of entries allowed. The default value is -1 for unlimited entries.
    • The maxKeysInMemory parameter is used to speed up data lookup. The single file store keeps an index of keys and their positions in the file using the maxKeysInMemory parameter. The default value for this parameter is -1.
    <namedCache name="writeThroughToFile">
          <persistence passivation="false">
             <singleFile fetchPersistentState="true" 
                         ignoreModifications="false"
                         purgeOnStartup="false" 
                         shared="false"
                         preload="false"
                         location="/tmp/Another-FileCacheStore-Location"
                         maxEntries="100"
                         maxKeysInMemory="100">
             </singleFile>
          </persistence>
     </namedCache>
    
    Copy to Clipboard
  4. Add the async element to configure the asynchronous settings:
    • The enabled parameter determines whether the file store is asynchronous.
    • The threadPoolSize parameter specifies the number of threads that concurrently apply modifications to the store. The default value for this parameter is 5.
    • The flushLockTimeout parameter specifies the time to acquire the lock which guards the state to be flushed to the cache store periodically. The default value for this parameter is 1.
    • The modificationQueueSize parameter specifies the size of the modification queue for the asynchronous store. If updates are made at a rate that is faster than the underlying cache store can process this queue, then the asynchronous store behaves like a synchronous store for that period, blocking until the queue can accept more elements. The default value for this parameter is 1024 elements.
    • The shutdownTimeout parameter specifies the time to stop the cache store. Default value for this parameter is 25 seconds.
    <namedCache name="writeThroughToFile">
          <persistence passivation="false">
             <singleFile fetchPersistentState="true" 
                         ignoreModifications="false"
                         purgeOnStartup="false" 
                         shared="false"
                         preload="false"
                         location="/tmp/Another-FileCacheStore-Location"
                         maxEntries="100"
                         maxKeysInMemory="100">
                <async enabled="true" 
        	           threadPoolSize="500"
        	           flushLockTimeout="1"
    	           modificationQueueSize="1024"
    	           shutdownTimeout="25000"/>
            </singleFile>
          </persistence>
     </namedCache>
    
    Copy to Clipboard

13.1.3. Migrating data from FileCacheStore to SingleFileCacheStore

Red Hat JBoss Data Grid 6.2 stores data in a different format than previous versions of JBoss Data Grid. As a result, the newer version of JBoss Data Grid cannot read data stored by older versions. Use rolling upgrades to upgrade persisted data from the format used by the old JBoss Data Grid to the new format. Additionally, the newer version of JBoss Data Grid also stores persistence configuration information in a different location.
Rolling upgrades is the process by which a JBoss Data Grid installation is upgraded without a service shutdown. In Library mode, it refers to a node installation where JBoss Data Grid is running in Library mode. For JBoss Data Grid servers, it refers to the server side components. The upgrade can be due to either hardware or software change such as upgrading JBoss Data Grid.
Rolling upgrades are available in JBoss Data Grid's Library and Remote Client-Server modes.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.