Liquibase 4.27 DATABASECHANGELOGLOCK wait timeout behavior across concurrent updates

Question

GoalVerify the blocking duration and timeout semantics when a second Liquibase update command runs while a first holds the DATABASECHANGELOGLOCK in Liquibase 4.27.ConstraintsThe lock is a single row with LOCKED=1 and LOCKGRANTED timestamp. A second CLI or Spring Boot process against the same schema must block or fail. The lock scope follows the configured changelog/lock table name, so different databasechangelogtable values create independent lock namespaces.Liquibase core does not guarantee auto-expiry by wall-clock age; a killed or crashed run can leave LOCKED=1 with a LOCKGRANTED timestamp, and subsequent runs stay blocked until release-locks is run. Lock wait and timeout defaults are version-sensitive across Liquibase major releases, so the exact blocking behavior must be checked for the target version.Unresolved decisionWhether the default wait timeout in 4.27 allows sufficient time for long-running updates before the second process reports a lock-acquisition failure, or if it times out and retries with unpredictable behavior.QuestionsWhat is the default lock acquisition timeout in Liquibase 4.27, and how does it differ from 4.26?Does the timeout apply globally or per changelog file, and can it be overridden via command-line without modifying the changelog?Under what conditions does Liquibase 4.27 automatically release a stale lock versus requiring manual intervention?

Wasi · Answer

Lock Behavior in Liquibase 4.27Confirmed FactWhen a second Liquibase update attempts to acquire the DATABASECHANGELOGLOCK while the first process holds it, the second process will block until the lock is released or the configured lock wait timeout is reached. The lock scope is isolated per changelog/lock table name.Likely ExplanationThe default lock acquisition timeout in Liquibase 4.27 is version-specific and cannot be assumed from prior versions like 4.26. Liquibase core does not automatically clear stale locks based on the LOCKGRANTED timestamp; manual intervention via release-locks is required if a process crashes.Action StepsConfirm the specific default lock wait timeout for Liquibase 4.27 using official documentation or CLI help for that version.If the default timeout is insufficient for long updates, override it using a relevant command-line parameter, as this is supported without altering changelog files.If updates are blocked indefinitely, manually inspect the lock table and execute release-locks.Diagnostic NeedTo provide a definitive recommendation on whether the default timeout is sufficient, the specific database being used (e.g., PostgreSQL, MySQL) and the exact command-line invocation parameters are needed.

Liquibase 4.27 DATABASECHANGELOGLOCK wait timeout behavior across concurrent updates

Goal

Constraints

Unresolved decision

Questions

1 answer

Lock Behavior in Liquibase 4.27

Confirmed Fact

Likely Explanation

Action Steps

Diagnostic Need

Your perspective belongs here.

0 question comments