Thread safety of Liquibase classes

General Discussion
1

Hi,

We use Liquibase as a library in our JVM applications to run the same database changesets to many (hundreds / thousands) databases. This happens concurrently.

Is there information available which of the Liquibase classes are thread safe, and can be used concurrently?

Thanks.

2

Concrete example of some concurrency issues that I am hitting:

Reading a DatabaseChangeLog once, and executing new Liquibase(changeLog, ..., database).update(...) many times concurrently. This fails with concurrent ArrayList out of bound errors because the changeSets is shared between the usages of DatabaseChangeLog. The changeSets array itself is copied, but the ChangeSet objects within are modified concurrently (e.g. this.getGeneratedSql().add(sql)).

The above is an example, but this happened over the years with multiple Liquibase versions and multiple workarounds in the application code to deal with concurrency issues in the library.

It would be nice to:

  • have a clear statement which classes / use cases are thread safe and ready for concurrent usage.
  • tests in the Liquibase library that verify these assumptions.
3

hey @HiddeWieN thanks for the idea/issue/example. We re going to dig in a bit and see how we might deal with these issues. Can you describe how are yall dealing with this when it comes up?

thanks!
mario,
Liquibase OSS/DevX PM

4

Hi Mario,
Thanks for the response.
Consider my question to be about the general thread safety of the Liquibase classes, so which classes / use cases clients can expect to be thread-safe.
The above problem is just an example. We work around such problems by either pinning older Liquibase versions that work correctly (for example we currently pin to 4.29.2 instead of version 4.31.1 that Spring Boot prescribes). Otherwise we try to work around the issue by using a different liquibase call to execute the migrations (for example call Liquibase with a the changeset filename String instead of the DatabaseChangeLog object), and more recently switching the resource accessor to a different one (for example the loading of included XML resources broke because of the Spring Resource Accessor).
By now we have built up a test suite that tests Liquibase against both MySQL, Postgres and H2 and invokes Liquibase in concurrently in multiple ways to verify if the expected features work.
If Liquibase would provide a stance on which classes are usable concurrently, we could adapt our use cases to calling only those classes concurrently, and hopefully removing these kind of concurrency issues in the future.
Thanks!