Skip to content

Default JDBC lock repository does not use time zone when storing creation date, causing "lock" #3885

Closed
@lucasvc

Description

@lucasvc

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.
  • 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions