We have about 100 war-files running in the same Tomcat and connected to the same database. As these have been developed over some time, they use various versions of liquibase. When we made a new one and used the latest version of Liquibase, 3.6.0, it created all sorts of problems.
Once it loads, it StandardChangeLogHistoryService.init() checks the first non-null row it can find in DATABASECHANGELOG and checks the CheckSum-version. This will find version 7, reset *all* to NULL and start the application, using version 8 for the scripts the new application owns.
When any one of the existing war-files are loaded, they will find a lot of NULL's, and rerun all changesets. This will fail if the changesets aren't well enough protected with preconditions. (This is obviously a latent bug in our application, but new checksum-version is the only use case where it will be a problem.)
Occasionally, an application will happen to find the new checksum-version 8, and reset all MD5SUMs to NULL again, restarting the whole process.
The assumption that the current running instance of Liquibase is the only version running against a database is horrible. Changes to DATABASECHANGELOG must be done very carefully and with a clear eye towards backwards compatibility.
Also reported as CORE-3204.
M.