@ -437,7 +493,13 @@ Redisson provides JCache implementations with two important features:
**fallback mode** - if set to `true` and Redis or Valkey is down the errors won't be thrown allowing application continue to operate without Redis.
**fallback mode** - if set to `true` and Redis or Valkey is down the errors won't be thrown allowing application continue to operate without Redis.
Below is the complete list of available managers:
**1. Scripted eviction**
Eviction is done on Redisson side through a custom scheduled task which removes expired entries using Lua script. Eviction task is started once per unique cache name at the moment of getting JCache instance. If instance isn't used and has expired entries it should be get again to start the eviction process. This leads to extra Redis or Valkey calls and eviction task per unique cache name.
Entries are cleaned time to time by `org.redisson.eviction.EvictionScheduler`. By default, it removes 100 expired entries at a time. This can be changed through [cleanUpKeysAmount](configuration.md) setting. Task launch time tuned automatically and depends on expired entries amount deleted in previous time and varies between 5 second to 30 minutes by default. This time interval can be changed through [minCleanUpDelay](configuration.md) and [maxCleanUpDelay](configuration.md). For example, if clean task deletes 100 entries each time it will be executed every 5 seconds (minimum execution delay). But if current expired entries amount is lower than previous one then execution delay will be increased by 1.5 times and decreased otherwise.
@ -711,8 +806,15 @@ Follow settings are available per JCache instance:
| | |
| | |
|-|-|
|-|-|
|Parameter| **`implementation`** |
|Parameter| **`implementation`** |
|Description| Cache implementation.<br/>`cache`- standard implementation<br/>`clustered-local-cache` - data partitioning and local cache support <br/>`local-cache` - local cache support<br/>`clustered-cache` - data partitioning support<br/>|
|Description| Cache implementation. |
|Default value| `cache` |
|Default value| `cache` |
|<br/>`cache` - implementation with scripted eviction
<br/>`cache-v2` - implementation with advanced eviction
<br/>`native-cache` - implementation with native eviction
<br/>`clustered-native-cache` - implementation with data partitioning and native eviction
<br/>`local-cache` - implementation with local cache support and scripted eviction
<br/>`clustered-local-cache` - implementation with data partitioning, local cache support and scripted eviction
<br/>`clustered-cache` - implementation with data partitioning and scripted eviction|
RLock object watchdog timeout in milliseconds. This parameter is only used if an RLock object is acquired without the `leaseTimeout` parameter. The lock expires after `lockWatchdogTimeout` if the watchdog didn’t extend it to the next `lockWatchdogTimeout` time interval. This prevents infinity-locked locks due to a Redisson client crash, or any other reason why a lock can’t be released properly.
RLock object watchdog timeout in milliseconds. This parameter is only used if an RLock object is acquired without the `leaseTimeout` parameter. The lock expires after `lockWatchdogTimeout` if the watchdog didn’t extend it to the next `lockWatchdogTimeout` time interval. This prevents infinity-locked locks due to a Redisson client crash, or any other reason why a lock can’t be released properly.
**lockWatchdogBatchSize**
Default value: `100`
Amount of locks used by a single lock watchdog execution. This parameter is only used if lock has been acquired without leaseTimeout parameter definition.
**checkLockSyncedSlaves**
**checkLockSyncedSlaves**
Default value: `true`
Default value: `true`
@ -267,7 +276,10 @@ Programmatic config example:
Config config = new Config();
Config config = new Config();
config.useClusterServers()
config.useClusterServers()
.setScanInterval(2000) // cluster state scan interval in milliseconds
.setScanInterval(2000) // cluster state scan interval in milliseconds