connectionstring Defines one or multiple URLs via which the cache loader will connect to other caches via the CLI.
sharedbooleanfalseThis setting should be set to true when multiple cache instances share the same cache store (e.g., multiple nodes in a cluster using a JDBC-based CacheStore pointing to the same, shared database.) Setting this to true avoids multiple cache instances writing the same modification multiple times. If enabled, only the node where the modification originated will write to the cache store. If disabled, each individual cache reacts to a potential remote update by storing the data to the cache store.
transactionalbooleanfalseThis setting should be set to true when the underlying cache store supports transactions and it is desirable for the underlying store and the cache to remain synchronized. With this enabled any Exceptions thrown whilst writing to the underlying store will result in both the store's and cache's transactions rollingback.
preloadbooleanfalseIf true, when the cache starts, data stored in the cache store will be pre-loaded into memory. This is particularly useful when data in the cache store will be needed immediately after startup and you want to avoid cache operations being delayed as a result of loading this data lazily. Can be used to provide a 'warm-cache' on startup, however there is a performance penalty as startup time is affected by this process.
fetch-statebooleanfalseIf true, fetch persistent state when joining a cluster. If multiple cache stores are chained, only one of them can have this property enabled.
purgebooleanfalseIf true, purges this cache store when it starts up.
singletonbooleanfalseIf true, the singleton store cache store is enabled. SingletonStore is a delegating cache store used for situations when only one instance in a cluster should interact with the underlying store. Deprecated: A shared store should be used instead, as this limits store writes to the primary owner of a key
read-onlybooleanfalseIf true, the cache store will only be used to load entries. Any modifications made to the caches will not be applied to the store.
max-batch-sizeint100The maximum size of a batch to be inserted/deleted from the store. If the value is less than one, then no upper limit is placed on the number of operations in a batch.


Configures a cache store as write-behind instead of write-through.

modification-queue-sizeint1024 Maximum number of entries in the asynchronous queue. When the queue is full, the store becomes write-through. until it can accept new entries
thread-pool-sizeint1 Size of the thread pool whose threads are responsible for applying the modifications to the cache store.
fail-silentlybooleanfalse If true, the async store attempts to perform write operations only as many times as configured with `connection-attempts` in the PersistenceConfiguration. If all attempts fail, the errors are ignored and the write operations are not executed on the store. If false, write operations that fail are attempted again when the underlying store becomes available. If the modification queue becomes full before the underlying store becomes available, an error is thrown on all future write operations to the store until the modification queue is flushed. The modification queue is not persisted. If the underlying store does not become available before the Async store is stopped, queued modifications are lost.


A cache store property with name and value.

Expand/Collapse All