SpringBoot Multi DataSource setup stopped working after upgrading Spring Boot to 3.3.x

Description

After upgrading Spring Boot from 3.2.7 to 3.3.1 our multi-datasource based on the AbstractRoutingDataSource stopped working. We have a test that tests different @Transactional - combinations.

I did read a lot about the LazyConnectionDataSourceProxy in issues like #15480, but nothing really worked: * Use LazyConnectionDataSourceProxy as my primary datasource with the target / readonly datasource feature * Wrapping our AbstractRoutingDataSource in LazyConnectionDataSourceProxy

Versions

OS: macOS 14.5 Java: 17 Spring Boot: * 3.2.7 ✅ * 3.3.0 ❌ * 3.3.1 ❌

How to reproduce the issue

Repository: https://github.com/open-source-issues/spring-multi-datasource Command: https://github.com/open-source-issues/spring-multi-datasource/blob/main/README.md

Comment From: wilkinsona

Thanks for the sample. The change in behaviour is due to Hibernate which Spring Boot 3.3.x upgrades to 6.5.x. If I run the tests with Spring Boot 3.3.1 and Hibernate downgraded to 6.4.9.Final they all pass.

I'm not sure that a fully understand the purpose of the tests, but they appear to be relying on some side-effects of Hibernate's behavior despite not actually using JPA. Specifically, they seem to be relying up Hibernate calling getConnection() on the DataSource. I would guess that some optimisations in Hibernate 6.5.x mean that it no longer gets a connection so eagerly which results in connectionReadOnlyCaptor not capturing anything.

You can see similar failures with Spring Boot 3.2.7 if you change the tests from @DataJpaTest to @JdbcTest. Doing so takes Hibernate out of the picture and means that getConnection() is never called on the DataSource. As far as I can tell, you need to rework your tests to avoid relying upon a side-effect of how Hibernate behaves.

Comment From: philwebb

Just coming here to say the same thing. Adding the following to the build scripts makes the tests pass:

buildscript {
    extra.apply {
        set("hibernate.version", "6.4.9.Final")
    }
}

To cause seems to be a change in org.hibernate.resource.jdbc.internal.AbstractLogicalConnectionImplementor where the commit() method now checks isPhysicallyConnected() which returns false.

Comment From: icepuma

Thanks for the explanation!

I think I got the issue and related commit.

Adding a simple entityManager.createQuery("select 1").getResultList(); to all inner transactions fixes nearly all tests, because it forces a connection acquisition (took it from the test from the linked commit) and hence a call for dataSource.getConnection().