JDBC lock repository fails after entering daylight savings

[Martin-den-Heijer]

In what version(s) of Spring Integration are you seeing this issue?

6.0.0-M5 and later. The bug was introduced in the code change for #3885.

Describe the bug

When the default timezone has daylight savings, then locks can fail after entering daylight savings (and likely also after leaving). The window for this bug to occur depends on the offset of the time zone.

To Reproduce

This problem cannot be reproduced reliably, but it's cause can be demonstrated using jshell.

The problem is caused by the following code in DefaultLockRepository.java

private Timestamp ttlEpochMillis(Duration ttl) {
	return Timestamp.valueOf(currentTime().plus(ttl));
}

private static Timestamp epochMillis() {
	return Timestamp.valueOf(currentTime());
}

private static LocalDateTime currentTime() {
	return LocalDateTime.now(ZoneOffset.UTC);
}

The Timestamp.valueOf method uses the system default time zone, which is Europe/Amsterdam in our case. This does not cause problems most of the time, but some LocalDateTime values are invalid because the forward adjustment of the clock when entering daylight savings. This may cause the timestamp stored in the database to jump back and forth. For example :

jshell> java.time.ZoneId.systemDefault()
$1 ==> Europe/Amsterdam

jshell> java.sql.Timestamp.valueOf(java.time.LocalDateTime.of(2026,3,29,2,59,59,999999999))
$2 ==> 2026-03-29 03:59:59.999999999

jshell> java.sql.Timestamp.valueOf(java.time.LocalDateTime.of(2026,3,29,3,0,0))
$3 ==> 2026-03-29 03:00:00.0

The demonstrated jump back in time breaks the lock temporarily because there is a short window where non-lock-owners may see an expired lock.

Expected behavior

The generated timestamps should be correct, even during daylight savings transitions.

Sample

[artembilan]

Well, I think we should fix it the way it is recommended these days:

Direct usage in JDBC: When using JDBC 4.2 or later, you generally don't need to manually convert to java.sql.Timestamp at all. You can pass the LocalDateTime object directly to a PreparedStatement using setObject().

Just tested on the main - all good.

Makes sense?

[Martin-den-Heijer]

Yes, that would fix the problem. Maybe also try to retrieve the time only once instead of twice for each lock update, but that is not strictly necessary to fix this bug.

[artembilan]

I think the current time calculation is very important at the movement we really need it: there is no guarantee how much time will pass between insert and update.

[Martin-den-Heijer]

I meant thatin this code (and the similar lock insertion code):
return this.template.update(this.insertQuery, this.region, lock, this.id, currentTime(), ttlEpochMillis(ttlDuration)) > 0;
the time is requested twice because ttlEpochMillis also calls currentTime. But with the root cause fixed, it is unlikely that this causes any trouble. Without the fix the backward jump can occur between both requests...
Anyway, thanks for the fix. There is plenty of time left for upgrading before the end of daylight savings ;-).