#LOGICWORKS CLEANUP DESIGN HOW TO#

Refactor/centralize the databasechangeloglock table management into the StandardLockService rather than being scattered across special SqlGenerators etc.Refactor LockService API to be in line with new 4.x standards (use Scope, extend PluginService, etc.).

#LOGICWORKS CLEANUP DESIGN HOW TO#

The changes will be an API breaking change for extensions that wrote their own LockService, but we will include documentation on how to update their code. This makes it easier to have a single release note of “We changed the lock service to support heartbeats and is also easier to work with”. While we are adding this feature, we will also do our 4.x work of reviewing the LockService interface in general to make it more extensible and manageable. This supports the “heartbeat.enabled=false” configuration as well as older version of liquibases

This will handle the case where multiple waiting processes try to force an unlock concurrently.ġ.The waiting process cannot take the lock if the heartbeat column is null.

The SQL to take the lock should take the last heartbeat value they knew of into account and check how many rows are updated.

The waiting process will watch for changese to this value rather than comparing dates in the heartbeat column to avoid date arithmetic and/or system time issues.

The heartbeat will update the column to a random number/string based on the rate.

Heartbeat thread must gracefully handle errors, and if the thread stops unexpectedly it should cause the overall liquibase operation to stop.

Existing databasechangelog lock tables should be auto-updated to have an additional, nullable “heartbeat” varchar(255) column.

Update StandardLockService to use a heartbeat thread to update the heartbeat column. Value is in seconds, with a default of “30”.

Add a global configuration value that can be used to control how long to wait until it a separate process can take the lock.

Value is seconds, with a default of “10”.

Add a global configuration value that can be used to control how often to update the heartbeat column.

Future release will change the default to “true” For the first release, set this to “false” as a default.

Add a global configuration value that can be used to enable the heartbeat functionality.

This will allow easier “BYO Locking” (see options section below)

Add a global configuration value that can be used to disable lock service completely.

Moving the overall discussion and design to this ticket. We wrap everything in try/catch blocks, but process killing happens too out-of-band for us to deal with. This problem has been around forever in Liquibase, but has been exasperated in recent years with systems like AWS that auto-kill processes that seem slow to start up. The big problem with this standard implementation is that IF the instance doing the update is killed before it commits the clearing of the record, that value is stuck until liquibase clearLocks is ran. Liquibase inserts a record and commits it at startup time, and if other instances see that record they wait until it is cleared. The StandardLockService is the normal implementation that uses a databasechangeloglock table.

Liquibase runs as part of a build job, and concurrent builds can happen at once.

Liquibase is embedded on startup of an application server, and you have a cluster of machines that may be starting at once.

operations to a database will interfere with each other, Liquibase has a LockService which we use to coordinate access so only one instance can run against a database at time.Įxamples of when you can run into concurrency trouble:

Logicworks cleanup design