If jOOQ is used to interact with a database during application context refresh, migrations performed by Flyway or Liquibase may not have completed. This can happen because there's no guarantee that the Flyway or Liquibase beans will have been created and initialised before any jOOQ beans are created and used. I think we need some AbstractDependsOnBeanFactoryPostProcessor beans so that any jOOQ DSLContext beans depend on the Flyway and Liquibase beans.
Comment From: lukaseder
Interesting, could this be a more general problem? Would a migration-aware DataSource (or connection pool) be interesting, with a mutex that prevents migrations and ordinary access from happening at the same time?
Comment From: wilkinsona
It is a general problem and we have a (fairly) general solution for it. There's a bug here as we've neglected to use that solution for jOOQ's DSLContext. I noticed this as part of a broader reworking of DataSource initialization for Boot 2.5. Part of that may result in a further generalisation of the current solution so that it's more extensible.
a mutex that prevents migrations and ordinary access from happening at the same time
Other than one scenario involved deferred bootstrapping of JPA, everything is single threaded. We need to ensure that things happen in the right order rather than preventing them from happening in parallel.
Comment From: lukaseder
I see, thanks for the explanation!
Comment From: wilkinsona
Closing in favour of #25279.
Comment From: neiser
@wilkinsona I've found this issue while using Spring Boot 2.7.3 probably suffering exactly from the problem that Flyway might not have run during application startup but already using jOOQ's DSLContext within a @Scheduled method. It then fails with an error telling me a database table isn't present, which would have been there if Flyway had run. I'm also using spring.flyway.clean-on-validation-error=true but that shouldn't change much I think.
I've seen this fix here has been forward-ported to 2.4.x, but I can't tell how it's now solved from 2.5.x onwards. Searching org.springframework.boot.autoconfigure.jooq package for keyword flyway and org.springframework.boot.autoconfigure.flyway for keyword jooq makes me wonder how it's ensured that jOOQ's DSLContext bean is only available once Flyway's migration has happened. Can you enlighten me? Or is this a bug which has now re-appeared after the refactoring of DataSources in 2.5.x you've mentioned above?
Comment From: wilkinsona
org.springframework.boot.jooq.JooqDependsOnDatabaseInitializationDetector should ensure that any DSLContext beans depend upon any beans that are responsible for DataSource initialization. Flyway is one such type of bean as identified by org.springframework.boot.flyway.FlywayDatabaseInitializerDetector.
Comment From: neiser
@wilkinsona Thanks a lot for this immediate answer. I'll see if I can reproduce it now that I believe jOOQ is indeed later available than Flyway :+1: