From d5d9f754c81dd7e4869d8b9ec9d259a25f7bfff0 Mon Sep 17 00:00:00 2001 From: SSHINE OF BORG Date: Tue, 10 Sep 2024 22:11:58 +0200 Subject: [PATCH] Fix `LockRegistrty` typo in the `distributed-locks.adoc` --- src/reference/antora/modules/ROOT/pages/distributed-locks.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/reference/antora/modules/ROOT/pages/distributed-locks.adoc b/src/reference/antora/modules/ROOT/pages/distributed-locks.adoc index fca279b8f4..c4266b7b6b 100644 --- a/src/reference/antora/modules/ROOT/pages/distributed-locks.adoc +++ b/src/reference/antora/modules/ROOT/pages/distributed-locks.adoc @@ -7,7 +7,7 @@ For this purpose Java provides an API with `java.util.concurrent.locks.Lock` imp However, the problem becomes more complex when an application is distributed and/or run in the cluster. The locking in this case is challenging and requires some shared state and its specific approach to achieve the exclusivity requirement. -Spring Integration provides a `LockRegistrty` abstraction with an in-memory `DefaultLockRegistry` implementation based on the `ReentrantLock` API. +Spring Integration provides a `LockRegistry` abstraction with an in-memory `DefaultLockRegistry` implementation based on the `ReentrantLock` API. The `obtain(Object)` method of the `LockRegistrty` requires a `lock key` for specific context. For example, an aggregator uses a `correlationKey` to lock operations around its group. This way different locks can be used concurrently.