| Name | Type | Default | Description |
|---|---|---|---|
| relative-to | string | jboss.server.data.dir | The base directory in which to store the cache state. |
| path | string | The path within "relative-to" in which to store the cache state. If undefined, the path defaults to the cache container name. | |
| block-size | integer | ${RocksDBStore.blockSize} | Cache store block size. |
| cache-size | long | ${RocksDBStore.cacheSize} | Cache size for the cache store. |
expiration?
Defines the expiration settings for the rocksdb cache store.
| Name | Type | Default | Description |
|---|---|---|---|
| path | string | The base directory in which to store expired cache state. |
compression?
Defines the data compression to use in the rocksdb store.
| Name | Type | Default | Description | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| type |
| NONE | The type of compression to be used by rocksdb store. |
| Name | Type | Default | Description |
|---|---|---|---|
| shared | boolean | false | This 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. |
| transactional | boolean | false | This 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. |
| preload | boolean | false | If 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. Likewise in some cases you cannot pre-load data in caches stores, such as when using shared remote stores. |
| purge | boolean | false | Empties the specified cache loader at startup. Values are true / false (default). This property takes effect only if read-only is false. |
| read-only | boolean | false | Prevents data from being persisted to cache stores. Values are true / false (default). If true, cache stores load entries only. Any modifications to data in the cache do not apply to cache stores. |
| write-only | boolean | false | Prevents data from being loaded from cache stores. Values are true / false (default). If true, cache stores write entries only. Any retrievals of data in the cache do not read from the cache store. |
| max-batch-size | int | 100 | Sets the maximum size of a batch to insert or delete from the cache store. If the value is less than one, no upper limit applies to the number of operations in a batch. |
| segmented | boolean | true | Configures cache stores to store data in hash space segments, with the cache's "segments" attribute defining the number of segments. |
write-behind?
Configures cache stores as write-behind instead of write-through.
| Name | Type | Default | Description |
|---|---|---|---|
| modification-queue-size | int | 1024 | Specifies the maximum number of entries in the asynchronous modification queue. When the queue is full, write-through mode is used until the queue can accept new entries. |
| thread-pool-size | int | 1 | Specifies the number of threads to apply modifications to the cache store. |
| fail-silently | boolean | false | Controls how asynchronous write operations take place when cache stores become unavailable. If "true", asynchronous write operations that fail are re-attempted with the number of times specified in the "connection-attempts" parameter. If all attempts fail, errors are ignored and write operations are not executed on the cache store. If "false", asynchronous write operations that fail are re-attempted 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 asynchronous store is stopped, queued modifications are lost. |
property*
Defines a cache store property with name and value.