此内容没有您所选择的语言版本。
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.
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
Add the Cache Name
Thename
parameter of thelocal-cache
attribute is used to specify a name for the cache.<local-cache name="default">
<local-cache name="default">
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Per-cache Statistics
Ifstatistics
are enabled at the container level, per-cache statistics can be selectively disabled for caches that do not require monitoring by setting thestatistics
attribute tofalse
.<local-cache name="default" statistics="true">
<local-cache name="default" statistics="true">
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configure the
file-store
ElementThefile-store
element specifies configuration information for the single file store.Thename
parameter of thefile-store
element is used to specify a name for the file store.<local-cache name="default" statistics="true"> <file-store name="myFileStore" />
<local-cache name="default" statistics="true"> <file-store name="myFileStore" />
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the passivation Parameter
Thepassivation
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" />
<local-cache name="default" statistics="true"> <file-store name="myFileStore" passivation="true" />
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the
purge
ParameterThepurge
parameter specifies whether or not the cache store is purged when it is started. Valid values for this parameter aretrue
andfalse
.<local-cache name="default" statistics="true"> <file-store name="myFileStore" passivation="true" purge="true" />
<local-cache name="default" statistics="true"> <file-store name="myFileStore" passivation="true" purge="true" />
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the
shared
ParameterTheshared
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 aretrue
andfalse
. However, theshared
parameter is not recommended forfile-store
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Specify the Directory Path Within the
relative-to
ParameterTherelative-to
property is the directory where thefile-store
stores the data. It is used to define a named path.Thepath
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 therelative-to
property to determine the complete path.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Specify the maximum number of entries
ThemaxEntries
parameter provides maximum number of entries allowed. The default value is -1 for unlimited entries.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the fetch-state Parameter
Thefetch-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.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the preload Parameter
Thepreload
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.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the singleton Parameter
Thesingleton
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 forfile-store
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
.
- Add the name value to the
namedCache
element. The following is an example of this step:<namedCache name="writeThroughToFile">
<namedCache name="writeThroughToFile">
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - In the
persistence
element, set thepassivation
parameter tofalse
. Possible values are true and false.<namedCache name="writeThroughToFile"> <persistence passivation="false" />
<namedCache name="writeThroughToFile"> <persistence passivation="false" />
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Set up a single file configuration using the
singleFile
element:fetchPersistentState
- If set totrue
, the persistent state is fetched when joining a cluster. If multiple cache stores are chained, only one cache store can have this property set totrue
. The default for this value isfalse
.- 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 totrue
when multiple cache instances share a cache store, which prevents multiple cache instances writing the same modification individually. The default for this attribute isfalse
. However, theshared
parameter is not recommended forfile-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 isfalse
. - 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 themaxKeysInMemory
parameter. The default value for this parameter is -1.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 is5
. - 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 is1
. - 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 is1024
elements. - The
shutdownTimeout
parameter specifies the time to stop the cache store. Default value for this parameter is25
seconds.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.