Description
In what version(s) of Spring Integration are you seeing this issue?
5.5.13.RELEASE
Describe the bug
The default JDBC lock repository allows locking threads/instances using database. At table <prefix>LOCK
column CREATED_DATE
avoids deadlocks, but that time is stored without time zone knowledge, so when last acquirer has a higher time and it drops the lock, the other members won't get the lock until they reach the same time.
To Reproduce
- Start a first leader-election Spring application using JDBC lock, within a machine with a "higher" time zone, i.e. a CEST (which as for today is +02:00).
- Confirm that
<prefix>LOCK.CREATED_DATE
is being updated with the local date time.
- Confirm that
- Start a second leader-election application, within a machine with a "lesser" time zone, i.e. UTC.
- If this application takes the lock, shutdown and start it again until does not.
- Shutdown first application.
- Second application does not take lock.
Expected behavior
Second application should take lock after the first is shutdown.
Sample
// working on it
Workaround
The table creation SQL scripts use (most of them) the type TIMESTAMP
. But SQL also defines the type TIMESTAMP WITH TIME ZONE
, that at least Oracle supports it. If the column uses this type the issue is not reproducible anymore.