Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Configurable Lock Timeout

Description

There are reasons that a lock can be left after liquibase exits unexpectedly. We don't know how long to reasonably expect liquibase to take in general, but add a configurable option for a time when a lock older than the timeout is ignored and the lock is re-granted

Environment

All

Activity

Show:

Former userJanuary 28, 2019 at 6:24 PM

Hey Tom,

about 1): I do believe I'm very careful with the update of the existing table, see

ProlongingLockService#checkAndUpdateLockTableWithLockExpiresAndById()

The problem is that I had to integrate this into an older branch of Liquibase, as I was unable to get the current master even to compile. Is it possible that you used a newer version (that maybe has a different lock table structure)? Or did you work with version 3.5.x?

about 2) We only use postgres, and I didn't have any issue with this. Really strange it works in the client, I would not have expected that then. And why invalid character? Is it a problem maybe when sending SQL via JDBC to Oracle to have the line end with semicolon? And just to be sure - the colon at the end is part of the error message, and not part of the generated SQL, is it? Near

WHERE ID = 1;:

Problem is, since I don't have an Oracle database available, I cannot debug it from here. Do you see a way to debug this and verify that what you see is really what got sent to the server? Maybe there is another invalid character like a tab or newline that is not visible in the error message?

Tom AerdenJanuary 28, 2019 at 12:32 PM

I was trying to apply this, but I stumbled across these issues:

  • I had to remove the old changeloglocktable manually, so it could be recreated. Is there a way liquibase could upgrade from the old table structure?

  • initialization fails for this reason "... Caused by: liquibase.exception.DatabaseException: Error executing SQL SELECT SYSTIMESTAMP FROM GTSC.DATABASECHANGELOGLOCK WHERE ID = 1;: ORA-00911: invalid character". However the sql looks ok, and I can succesfully execute it in a sql client (oracle 11 xe). Are there any known issues with this?

Former userNovember 5, 2018 at 11:15 AM

Fixed another small bug, now version 3.5.5.3-LOCKS.

Former userOctober 30, 2018 at 4:49 PM
Edited

Bug fixed, but after trying to make a version (updating poms, tagging manually in git), the circle ci builds are breaking.

And the only difference between the last successful build (b696722) and the current one (4cef610) is the change in the POM...

See https://circleci.com/gh/BernhardBln/liquibase/tree/CORE-2375-actively-prolong-lock-3.5.x

Problem was: we used the same connection for lock prolonging that was used for updates, hence potentially committing or rolling back changes of the updater.

Now creating a separate connection for the lock service. Could be a problem though in case somebody uses a JDBC connection pool with size = 1...

Former userOctober 29, 2018 at 11:22 AM

Do not use for now, we just found a small bug that we will fix now.

Details

Reporter

Fix versions

Affects versions

Priority

Created May 22, 2015 at 1:42 PM
Updated January 28, 2019 at 6:24 PM