Support lease renewal for distributed locks

[stefanvassilev]

Expected Behavior

One should be able to renew lock obtained from lockRegistry, as if one wants to hold onto a lock for longer than TTL.

Current Behavior

Calling jdbcLockRegistry.tryLock() from current thread would update the lock, which seems to renew it, however it would increase the hold's count as well, causing jdbcLock.unlock()' not to release the lock as it would only decrease delegate's hold's by one see:

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

Line 236 in 62d472f

this.delegate.unlock();

One can workaround this by using the 'DefaultLockRepository' to require a lock re-acquire a lock, which would update CREATED_DATE of the lock without increasing delegate's hold count.

Context

It would be great if this is supported from jdbcRegistry rather than going over the workaround I mentioned above.

[artembilan]

Hi @stefanvassilev !

I'm not sure that I fully understood how you workaround it and what the change you would like to do, but it looks more like you are looking for something like this: #3095.
In other words a contract like this: tryLock(long time, TimeUnit unit, long leaseTime, TimeUnit leaseUnit) and lock(long leaseTime, TimeUnit timeUnit);

Please, share more info how we should fix it from your perspective.

Thanks

[stefanvassilev]

hi @artembilan,

thanks for the quick response.

The problem that I'm describing is the following:

Imagine you have two instances which use 'lockRegistry', instance A and instance B.

Instance 'A' acquires lock with name lockA and does some work, which takes more time than the TTL, so when instance 'B' tries to acquire lockA to acquire it it will succeed, as lockA would be expired and will get deleted.

My proposal would be to include a method to renew to the lock from instance A so that instance B won't be able to acquire it, as it won't be expired. The issue you linked would probably solve to a degree my problem, however, from API standpoint one should be probably be able to decide for how long the lock should is maintained.

I hope this clarifies what I'm trying to describe.

[artembilan]

Hm. Probably it sounds like an addition to the mentioned tryLock(long time, TimeUnit unit, long leaseTime, TimeUnit leaseUnit)API - renewLease(long leaseTime)...

[stefanvassilev]

seems reasonable to me :-)