You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: spring-integration-redis/src/test/java/org/springframework/integration/redis/util/RedisLockRegistryTests.java
Copy file name to clipboardExpand all lines: src/reference/antora/modules/ROOT/pages/redis.adoc
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -846,7 +846,11 @@ The expiry should be set at a large enough value to prevent this condition, but
846
846
Starting with version 5.0, the `RedisLockRegistry` implements `ExpirableLockRegistry`, which removes locks last acquired more than `age` ago and that are not currently locked.
847
847
848
848
Starting with version 5.5.6, the `RedisLockRegistry` is support automatically clean up cache for redisLocks in `RedisLockRegistry.locks` via `RedisLockRegistry.setCacheCapacity()`.
849
+
The default value is `256`.
849
850
See its JavaDocs for more information.
851
+
This capacity number is also propagated into the `DefaultLockRegistry` used internally in the `RedisLockRegistry` for a pool of shared `ReentrantLock` instances.
852
+
So, if higher concurrent access (the number of unique lock keys used in parallel) is expected (or allowed) for the application, the `cacheCapacity` should be increased respectively, with the closest power of 2 in mind (essentially `Integer.highestOneBit(cacheCapacity + 1)`).
853
+
850
854
851
855
Starting with version 5.5.13, the `RedisLockRegistry` exposes a `setRedisLockType(RedisLockType)` option to determine in which mode a Redis lock acquisition should happen:
852
856
@@ -887,4 +891,4 @@ RedisLockRegistry lockRegistry = new RedisLockRegistry("my-lock-key{choose_your_
0 commit comments