GH-3444: Add Custom TTL support for RedisLock, and JdbcLock #9053

EddieChoCho · 2024-03-30T14:00:22Z

Add DistributedLock interface which is implemented by RedisLock and JdbcLock.
Modify LockRegistry, ExpirableLockRegistry, RenewableLockRegistry interfaces.
Modify implementation of DefaultLockRepository, JdbcLockRegistry, RedisLockRegistry`
Modify ddl of INT_LOCK table.
Maintain test cases and documents.

artembilan

Thanks for looking into this!

I still think it has to be called a DistributedLock from the beginning: we may come up eventually with other API, not only TTL.

I think the LockRegistry must be modified for a generic arg: LockRegistry<L extends Lock>.
And no need in the extra CustomTtlLockRegistry abstraction.

Can you elaborate, please, why do we need a result from delete()?

Since this is a huge braking change (as it is expected according to the discussion in the issue), we are going to look into this in details in the next 6.4 version, which we are going to start this June.

EddieChoCho · 2024-04-01T19:53:25Z

Can you elaborate, please, why do we need a result from delete()?

If the result(row count) is 0, which means that the lock is not owned by current process.

For example:
ProcessA and processB are in the same region.
ProcessA acquired the distributed lock. //{REGION: r, LOCK_KEY: lock, CLIENT_ID: processA}
But the work takes too long and the ownership of the lock has been expired.
Before processA release the lock, processB acquired the same distributed lock. //{REGION: r, LOCK_KEY: lock, CLIENT_ID: processB}
When processA try to release the distributed lock. //DELETE FROM INT_LOCK WHERE REGION='r' AND LOCK_KEY='lock' AND CLIENT_ID='processA'
The result from delete() would be 0.

In this case, an IllegalStateException should be thrown to info the process that the integrity of data protected by this lock may have been compromised.

artembilan · 2024-04-01T20:01:15Z

...tegration-jdbc/src/main/java/org/springframework/integration/jdbc/lock/JdbcLockRegistry.java

 					}
 					catch (TransientDataAccessException | TransactionTimedOutException | TransactionSystemException e) {
 						// try again
 					}
+					catch (IllegalStateException e) {
+						throw new IllegalStateException("Lock was released in the store due to expiration. " +


OK. I see why you use boolean for delete() now.
I wonder if we can use a ConcurrentModificationException instead.
Or something from the org.springframework.dao package, like ConcurrencyFailureException

RedisLock throw IllegalStateException when it face this scenario.
Should we also modify the implementation of RedisLock?

I see. Well, that was just a suggestion if that is makes sense to rely on some specific exception instead of this common.
Might be the fact that ConcurrentModificationException does not fit in our locks scenario.
However that ConcurrencyFailureException might be OK.

catch (TransientDataAccessException | TransactionTimedOutException | TransactionSystemException e) { // try again }

In the current implementation, TransientDataAccessException, TransactionTimedOutException, and TransactionSystemException will be caught, and then the delete() method will be invoked again.

Since ConcurrencyFailureException extends TransientDataAccessException, I think we should not throw it for this scenario.

I will change it to throw ConcurrentModificationException instead if you think ConcurrentModificationException fits better.

I see. Thanks. Missed that.

So, yeah, this ConcurrentModificationException fits in my brain because its name means exactly what happens here for us.
But I'm not sure if this is a correct scenario where we can use it from Java perspective.
That's why I'm reaching you for other opinion, arguments and so on.
Just want to be sure that we are on the same page with a decision to move on.

I see,
I agree that changing from IllegalStateException to ConcurrentModificationException can improve the readability.
But I'm also not sure if this is a correct scenario where we can use it from Java perspective.

How about we create our own exception -LockOwnershipExpiredException for Spring distributed locks?
It can be used by both RedisLock, and JdbcLock.

artembilan · 2024-06-10T19:35:32Z

This is good stuff.
Thank you very much for looking into that!

As I expected this is really huge breaking change in the API, so I'm afraid we cannot accept it right now according to our migration policies.
We have to wait until the next major version 7.0 next year.
Of course we might be able to start it in the end of this year, when Spring Framework 6.2 release train is out this November.

Please, keep in touch meanwhile.

Thank you for understanding!

Pavankn18 · 2024-10-27T03:25:15Z

...tion-jdbc/src/main/java/org/springframework/integration/jdbc/lock/DefaultLockRepository.java

-	public void delete(String lock) {
-		this.defaultTransactionTemplate.executeWithoutResult(
-				transactionStatus -> this.template.update(this.deleteQuery, this.region, lock, this.id));
+	public boolean delete(String lock) {


This also presents an opportunity to check for template.update() > 1 to throw exception, this will help prevent incorrect constraint on Table.

This is possible only if table is created without constraint INT_LOCK_PK primary key (LOCK_KEY, REGION).

This is actually outside the scope of the PR. (my bad, I should not include this change).
The method has been maintained in PR #9292.
I think business logic should not address cases of misconfiguration or incorrect settings.
If you'd like to discuss this method further, it would be great to create a new issue.

Pavankn18 · 2024-10-27T03:40:19Z

Any new on this? Spring 7 will be out soon right? Will these changes be included 7.0?

Spring framework will become GA in Nov 2024 -https://spring.io/blog/2024/10/01/from-spring-framework-6-2-to-7-0.

artembilan · 2024-10-27T14:23:21Z

Thank you both for keeping an eye on this! So, in November we are releasing 6.4. After that we are good to start 7.0. But that is going to be released only next November 2025. So, not soon enough, but we still don’t have a choice with such a breaking change.

artembilan · 2025-06-03T15:36:06Z

We are now at 7.0 development timeline.
I wonder if it is still OK for you to reinstate the work over here.
Thanks

EddieChoCho · 2025-06-09T17:42:17Z

I have rebased the branch, here is the summary of the changes:

RedisLock and JdbcLock now implement DistributedLock interface to support the feature of customized time-to-live for the lock status data.
RenewableLockRegistry now provides new renewLock(Object lockKey, long customTtl, TimeUnit customTtlTimeUnit) method, allowing user to renew the lock with a custom time-to-live value.
The APIs of LockRepository and DefaultLockRepository are also modified to support the feature.
The CREATED_DATE column in the INT_LOCK table has been replaced with EXPIRED_AFTER to support the feature.

…cLock Fixes: spring-projects#3444 * Add `DistributedLock` interface which is implemented by `RedisLock` and `JdbcLock`. * Modify `LockRegistry`, `ExpirableLockRegistry`, `RenewableLockRegistry` interfaces. * Modify implementation of `DefaultLockRepository, `JdbcLockRegistry`, `RedisLockRegistry` * Modify ddl of `INT_LOCK` table. * Maintain test cases and documents. Signed-off-by: Eddie Cho <[email protected]>

cppwfs

Thank you for the contribution.

Only had a couple of small requests.

...tegration-jdbc/src/main/java/org/springframework/integration/jdbc/lock/JdbcLockRegistry.java

cppwfs · 2025-06-10T11:51:03Z

src/reference/antora/modules/ROOT/pages/jdbc/lock-registry.adoc

+[IMPORTANT]
+====
+The `CREATED_DATE` column in the `INT_LOCK` table has been replaced with `EXPIRED_AFTER` to support the custom time-to-live feature.


Need to have a note that states that the users will have to update their table definitions, if they are already using this feature.

I wonder if CREATED_DATE column could still be useful...

I think so as well. i.e. how long has this lock been around (Not just renewed).

If we keep the CREATED_DATE column, it now provides information about the time the lock was acquired, rather than the TTL.
Then we need to consider these two cases:

A process acquires same lock multiple times before it releases the lock.
In this case, once the value of CREATED_DATE column has been set during the first acquisition and should not be updated by subsequent acquisitions before the lock is released.

The TTL of a lock is expires and the lock is now acquired by another process.
In this case, sine the expired lock's data still existed in the table, we should not only update the CLIENT_ID but also the value of CREATED_DATE column.

I will modify the implementation of acquire() to cover this scenario.

I think this one is typical for any RDBD data: when it was inserted. And we really don’t update it on subsequent acquisitions.

artembilan

This is really great!
Please, take a look into distributed-locks.adoc to mention this our new DistributedLock abstraction and fix code snippet for a new style: LockRegistry<Lock> and so.

Thank you!

artembilan · 2025-06-10T16:53:45Z

...ration-core/src/main/java/org/springframework/integration/support/locks/DistributedLock.java

+import java.util.concurrent.locks.Lock;
+
+/**
+ * A {@link Lock} implementing for spring distributed locks


How about just to say:

A distributed {@link Lock} extension.

No need to mention Spring especially not from capital latter.

artembilan · 2025-06-10T16:54:30Z

...ration-core/src/main/java/org/springframework/integration/support/locks/DistributedLock.java

+	 * @param customTtl the specific time-to-live for the lock status data
+	 * @param customTtlTimeUnit the time unit of the {@code customTtl} argument
+	 */
+	void lock(long customTtl, TimeUnit customTtlTimeUnit);


Can we use a Duration API instead?

artembilan · 2025-06-10T16:55:07Z

...ration-core/src/main/java/org/springframework/integration/support/locks/DistributedLock.java

+	 *         while acquiring the lock (and interruption of lock
+	 *         acquisition is supported)
+	 */
+	boolean tryLock(long time, TimeUnit unit, long customTtl, TimeUnit customTtlTimeUnit) throws InterruptedException;


Especially here where we have so many method arguments...
I mean Duration instead.

artembilan · 2025-06-10T16:57:12Z

...-core/src/main/java/org/springframework/integration/support/locks/RenewableLockRegistry.java

+	 * @param customTtlTimeUnit the time unit of the {@code customTtl} argument
+	 *
+	 */
+	void renewLock(Object lockKey, long customTtl, TimeUnit customTtlTimeUnit);


Same here about Duration.
I know tryLock(long time, TimeUnit unit) is there in Lock API, but that one has been done long time ago before java.time API.
Make sense?

artembilan · 2025-06-10T16:59:17Z

...tion-jdbc/src/main/java/org/springframework/integration/jdbc/lock/DefaultLockRepository.java

-	 * Specify the time (in milliseconds) to expire deadlocks.
-	 * @param timeToLive the time to expire deadlocks.
-	 */
-	public void setTimeToLive(int timeToLive) {


What is a justification of the removal of this public API?
If we are really strong enough then let's deprecate it first!

I moved the default TTL constant from DefaultLockRepository to JdbcLockRegistry.
The TTL value can now be set through the constructor of JdbcLockRegistry, which aligns with the design of RedisLockRegistry.
As a result, I removed the setTimeToLive() method from DefaultLockRepository.

However, should I also keep a default TTL in DefaultLockRepository to support developers who use DefaultLockRepository directly without using JdbcLockRegistry?

That's the point.
The DefaultLockRepository really could be used (not sure why) out of JdbcLockRegistry.
This one is a public API, so as less distraction as possible.

artembilan · 2025-06-10T17:00:45Z

...tegration-jdbc/src/main/java/org/springframework/integration/jdbc/lock/JdbcLockRegistry.java

+		this.ttl = DEFAULT_TTL;
+	}
+
+	public JdbcLockRegistry(LockRepository client, long expireAfter) {


Let's see if we can rely on Duration instead!

Let's also update the constructor of RedisLockRegistry from
public RedisLockRegistry(RedisConnectionFactory connectionFactory, String registryKey, long expireAfter)
to
public RedisLockRegistry(RedisConnectionFactory connectionFactory, String registryKey, Duration expireAfter)
to align with the API design.

Do you agree?

Sure! We can do that, but as a new constructor and deprecation of existing one.
Remember, we develop here a library, therefore compatibility in API should be honored as much as possible.
Since we can still keep an old constructor here with simple adaptation, no reason to introduce another breaking change.

artembilan · 2025-06-10T17:02:30Z

spring-integration-jdbc/src/main/resources/org/springframework/integration/jdbc/schema-db2.sql

@@ -30,7 +30,7 @@ CREATE TABLE INT_LOCK  (
 	LOCK_KEY CHAR(36) NOT NULL,
 	REGION VARCHAR(100) NOT NULL,
 	CLIENT_ID CHAR(36),
-	CREATED_DATE TIMESTAMP NOT NULL,
+    EXPIRED_AFTER TIMESTAMP NOT NULL,


Something is off with indents.
Has to be tab.

artembilan · 2025-06-10T17:03:56Z

...jdbc/src/test/java/org/springframework/integration/jdbc/lock/DefaultLockRepositoryTests.java

 		// Make sure a transaction is active
 		assertThat(TransactionSynchronizationManager.isActualTransactionActive()).isTrue();

 		TransactionSynchronization transactionSynchronization = spy(TransactionSynchronization.class);
 		TransactionSynchronizationManager.registerSynchronization(transactionSynchronization);

-		this.client.acquire("foo"); // 1
-		this.client.renew("foo"); // 2
+		this.client.acquire("foo", Duration.ofMillis(10000)); // 1


Feels like Duration.ofSeconds(10).
Much easier to read and less typing.
No? 😉

src/reference/antora/modules/ROOT/pages/jdbc/lock-registry.adoc

…cLock Fixes: spring-projects#3444 * Modify `LockRegistry`, `DistributedLock` interfaces. * Modify implementation of `DefaultLockRepository, `JdbcLockRegistry`, `RedisLockRegistry` * Modify ddl of `INT_LOCK` table. * Maintain test cases and documents. Signed-off-by: Eddie Cho <[email protected]>

EddieChoCho · 2025-06-12T15:32:27Z

I just pushed another commit, please review

artembilan

I don't see too many problem now.
Thank you for the great update!
After the next round of changes according to our review, we are going to look into merging this.

artembilan · 2025-06-12T15:51:39Z

...ration-core/src/main/java/org/springframework/integration/support/locks/DistributedLock.java

+	void lock(Duration ttl);
+
+	/**
+	 * Acquires the lock with a specific time-to-live if it is free within the


Method JavaDocs have to be imperative, like a command: do this, do that.
And no blank lines in method JavaDocs, please.

artembilan · 2025-06-12T15:53:31Z

...ration-core/src/main/java/org/springframework/integration/support/locks/DistributedLock.java

+	 *         while acquiring the lock (and interruption of lock
+	 *         acquisition is supported)
+	 */
+	boolean tryLock(long time, TimeUnit unit, Duration ttl) throws InterruptedException;


Why the first arg is not a Duration?
We always can covert it back to millis internally.
This is a new API, so let's make it consistent with end-user expectations!

artembilan · 2025-06-12T15:54:34Z

...-core/src/main/java/org/springframework/integration/support/locks/RenewableLockRegistry.java

+	 * @param ttl the specific time-to-live for the lock status data
+	 *
+	 */
+	void renewLock(Object lockKey, Duration ttl);


Since you have added a new API to the class, please, add your name to the @author list.

artembilan · 2025-06-12T15:55:54Z

...tegration-jdbc/src/main/java/org/springframework/integration/jdbc/lock/JdbcLockRegistry.java

+		this.ttl = DEFAULT_TTL;
+	}
+
+	public JdbcLockRegistry(LockRepository client, Duration expireAfter) {


New public API, therefore @since 7.0 and some simple JavaDoc.

artembilan · 2025-06-12T15:56:12Z

...tegration-jdbc/src/main/java/org/springframework/integration/jdbc/lock/JdbcLockRegistry.java

@@ -85,16 +86,29 @@ protected boolean removeEldestEntry(Entry<String, JdbcLock> eldest) {

 	private int cacheCapacity = DEFAULT_CAPACITY;

+	/**
+	 * Default value for the time-to-live property.


@since 7.0 here as well, please

artembilan · 2025-06-12T15:58:02Z

...ration-redis/src/main/java/org/springframework/integration/redis/util/RedisLockRegistry.java

+	 * Constructs a lock registry with the supplied lock expiration.
+	 * @param connectionFactory The connection factory.
+	 * @param registryKey The key prefix for locks.
+	 * @param expireAfter The expiration in {@link Duration}.


@since 7.0

artembilan · 2025-06-12T15:58:42Z

...ration-redis/src/main/java/org/springframework/integration/redis/util/RedisLockRegistry.java

+	}
+
+	/**
+	 * Constructs a lock registry with the supplied lock expiration.


Imperative:

Create a lock registry with the supplied lock expiration.

artembilan · 2025-06-12T16:01:11Z

src/reference/antora/modules/ROOT/pages/jdbc/lock-registry.adoc

+[source,sql]
+----
+ALTER TABLE INT_LOCK ADD EXPIRED_AFTER TIMESTAMP NOT NULL;


This is great tip!
We will add it into a Migration Guide: https://github.com/spring-projects/spring-integration/wiki

artembilan · 2025-06-12T16:02:50Z

src/reference/antora/modules/ROOT/pages/whats-new.adoc

Please, add a sentence in this New Components section about a DistributedLock API and a link to respective distributed-locks.adoc chapter.

…cLock Fixes: spring-projects#3444 * Modify DistributedLock` interfaces. * Modify implementation of `JdbcLockRegistry`, `RedisLockRegistry`. * Modify JavaDoc. Signed-off-by: Eddie Cho <[email protected]>

EddieChoCho · 2025-06-12T21:18:15Z

Thanks for your feedbacks, I pushed another commit.

…cLock Fixes: spring-projects#3444 * Maintain document Signed-off-by: Eddie Cho <[email protected]>

@deprecated

…cLock Fixes: spring-projects#3444 * Add @deprecated Signed-off-by: Eddie Cho <[email protected]>

artembilan requested changes Apr 1, 2024

View reviewed changes

EddieChoCho marked this pull request as draft June 26, 2024 12:54

EddieChoCho force-pushed the GH-3444 branch from 5875522 to efd9305 Compare June 26, 2024 13:28

Pavankn18 reviewed Oct 27, 2024

View reviewed changes

EddieChoCho force-pushed the GH-3444 branch 2 times, most recently from 79a1268 to 2bab334 Compare June 9, 2025 17:20

EddieChoCho marked this pull request as ready for review June 9, 2025 17:42

EddieChoCho force-pushed the GH-3444 branch 2 times, most recently from 03b9570 to 55747ed Compare June 9, 2025 17:56

artembilan requested a review from cppwfs June 9, 2025 19:46

EddieChoCho force-pushed the GH-3444 branch from 55747ed to 0b1cf83 Compare June 10, 2025 06:19

cppwfs requested changes Jun 10, 2025

View reviewed changes

artembilan requested changes Jun 10, 2025

View reviewed changes

artembilan requested changes Jun 12, 2025

View reviewed changes

EddieChoCho marked this pull request as draft June 12, 2025 20:52

spring-projectsGH-3444: Add Custom TTL support for RedisLock, and Jdb…

9b9ecbc

…cLock Fixes: spring-projects#3444 * Modify DistributedLock` interfaces. * Modify implementation of `JdbcLockRegistry`, `RedisLockRegistry`. * Modify JavaDoc. Signed-off-by: Eddie Cho <[email protected]>

EddieChoCho force-pushed the GH-3444 branch from d0d9e88 to 9b9ecbc Compare June 12, 2025 21:04

EddieChoCho marked this pull request as ready for review June 12, 2025 21:05

spring-projectsGH-3444: Add Custom TTL support for RedisLock, and Jdb…

01afa36

…cLock Fixes: spring-projects#3444 * Maintain document Signed-off-by: Eddie Cho <[email protected]>

spring-projectsGH-3444: Add Custom TTL support for RedisLock, and Jdb…

6c9f3ce

…cLock Fixes: spring-projects#3444 * Add @deprecated Signed-off-by: Eddie Cho <[email protected]>

GH-3444: Add Custom TTL support for RedisLock, and JdbcLock #9053

Are you sure you want to change the base?

GH-3444: Add Custom TTL support for RedisLock, and JdbcLock #9053

Uh oh!

Conversation

EddieChoCho commented Mar 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

EddieChoCho commented Apr 1, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

artembilan commented Jun 10, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pavankn18 commented Oct 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

artembilan commented Oct 27, 2024

Uh oh!

artembilan commented Jun 3, 2025

Uh oh!

EddieChoCho commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cppwfs left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EddieChoCho Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EddieChoCho commented Mar 30, 2024 •

edited

Loading

Pavankn18 commented Oct 27, 2024 •

edited

Loading

EddieChoCho commented Jun 9, 2025 •

edited

Loading

EddieChoCho Jun 10, 2025 •

edited

Loading