Were there changes to the lock mechanism in 4.23.1?

General Discussion
1

I have an integration test that works with liquibase 4.23.0 but fails with 4.23.1 and all versions following it.

The way the test fails is that it waits for 5 minutes to get a changelog lock and fails when that times out, and then immediately after aquires the lock.

Here it fails: Liquibase 4.23.1 failing to load in liquibase karaf feature integration test · GitHub
Here the lock is aquired Liquibase 4.23.1 failing to load in liquibase karaf feature integration test · GitHub

For 4.23.0 the lock is successfully aquired before liquibase starts setting up the schema: Successful load of the liquibase karaf feature integration test feature in karaf 4.4.4 · GitHub

This is the code that is run when starting the schema: https://github.com/steinarb/liquibase-karaf-feature/blob/master/liquibase-integration-test/karaf.liquibase.sample/src/main/java/no/priv/bang/karaf/sample/db/liquibase/test/SampleDbLiquibaseRunner.java#L95

i.e.

        Scope.child(scopeObjects, (ScopedRunner<?>) () -> new CommandScope("update")
                    .addArgumentValue(DbUrlConnectionCommandStep.DATABASE_ARG, database)
                    .addArgumentValue(UpdateCommandStep.CHANGELOG_FILE_ARG, changelistClasspathResource)
                    .addArgumentValue(DatabaseChangelogCommandStep.CHANGELOG_PARAMETERS, new ChangeLogParameters(database))
                    .execute());

Is there something obvious I could do/should change here to make sure that the lock aquisition comes stably before liquibase tries to apply the changeset?

thanks!

  • Steinar
2

Back in June 2023 I replaced use of the Liquibase facade with the ScopedRunner code, because I heard that the Liquibase facade was deprecated.

But all code examples I can google up now used the Liquibase facade.

And the facade had work done in October 2023.

So: would I have more luck replacing the ScopedRunner code (which I frankly find hard to read) with the Liquibase facade?

Thanks!

3

Fun fact: when I bumped the slf4j log level to TRACE, the failing integration test ran green (the lock aquired happened before liquibase started setting up the tables, instead of appearing just after the error message that comes after waiting for the 5 minute time out).

So: a heisenbug…!

The problem does not occur when I run the same code in a unit test (where I can debug).

The problem does not occur when I load the karaf feature from karaf (where I also can debug).

The problem happens in a pax exam karaf test, where I’m unable to debug into a forked VM running the OSGi container used by the test.

(though… I suspect that if I actually was able to debug into the integration test, I would affect the timing so much the heisenbug would not occur…)

Sigh!