Default connection release mode inconsistent with Hibernate 5.1.1 [SPR-14548]

[spring-projects-issues]

Manuel Dominguez Sarmiento opened SPR-14548 and commented

We're using LocalSessionFactoryBuilder and when upgrading from [Hibernate 5.1.0 + Spring 4.2.5] to [Hibernate 5.2.1 + Spring 4.3.2] the effective connection release mode changed from "after transaction" to "on close". The Hibernate default for non-JTA environments has been "after transaction" for ages, since "on close" holds connections way too long. This caused major connection pool exhaustion which went unnoticed in our preproduction and test environments, but was hit immediately once our apps got real production load.
The defaults should be:
"after transaction" for non-JTA environments
"after statement" for JTA environments
At least this is what connection release mode "auto" (the default) has been doing in Hibernate for a long time.
Otherwise upgrading to latest Spring+Hibernate versions causes a major change in behavior and performance.
This can be resolved by explicitly configuring the following Hibernate property:
hibernate.connection.handling_mode=DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION
(see org.hibernate.resource.jdbc.spi.PhysicalConnectionHandlingMode which is new in Hibernate 5.2 - this used to be handled by the old hibernate.connection.release_mode property)

FYI "on close" ceased to be the default back in 2005:
https://hibernate.atlassian.net/browse/HHH-1038

---

Affects: 4.3.1, 4.3.2

Issue Links:

• JDBC Connection to reset not identical to originally prepared Connection with Hibernate 5.2 [SPR-14393] #18966 JDBC Connection to reset not identical to originally prepared Connection with Hibernate 5.2
• Doc: HibernateJpaVendorAdapter's "prepareConnection" may interfere with Hibernate 5.1+ in a JTA environment [SPR-14957] #19524 Doc: HibernateJpaVendorAdapter's "prepareConnection" may interfere with Hibernate 5.1+ in a JTA environment
• Database.SQL_SERVER should set more recent Hibernate dialect with Spring 4.3.x [SPR-15255] #19820 Database.SQL_SERVER should set more recent Hibernate dialect with Spring 4.3.x

Referenced from: commits 3614369, 7d1c2f1, fad931d

0 votes, 6 watchers

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

This is related to #18966

[spring-projects-issues]

Juergen Hoeller commented

Note that Hibernate did default to ON_CLOSE back in Hibernate ORM 4.2, 4.3 and even 5.0: see https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-core/src/main/java/org/hibernate/engine/transaction/internal/jdbc/JdbcTransactionFactory.java and https://github.com/hibernate/hibernate-orm/blob/5.0/hibernate-core/src/main/java/org/hibernate/resource/transaction/backend/jdbc/internal/JdbcResourceLocalTransactionCoordinatorBuilderImpl.java

Our prepareConnection feature generally needs ON_CLOSE, otherwise we're not able to cleanly reset our transaction state on the underlying JDBC Connection. We've always tried to enforce this one way or the other, or rely on Hibernate defaulting to it.

It seems that it was exactly Hibernate 5.1 where we missed the default change. From my perspective, the correct solution is to enforce ON_CLOSE even there through applying the corresponding connection release mode setting by default. This will at least provide consistency between Hibernate versions that Spring is running with, and you can always opt out through the corresponding Hibernate setting or through switching Spring's prepareConnection flag to false.

Why specifically do you see such a significant difference between after-transaction and on-close? With standard HibernateTransactionManager transactions, there should be a minor difference only since we're closing the Session shortly after commit anyway...

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

Thanks for your feedback Juergen. Upgrading to Hibernate 5.2.x has been so far a nightmare, because of the API changes and compatibility issues (not Spring's fault BTW).

Our tests worked fine after working through all the issues, however our production systems crashed after upgrading.
We narrowed this down to two possible things: one of them was the connection release policy change from Hibernate 5.1.0 + Spring 4.2.5 vs Hibernate 5.2.1 + Spring 4.3.2. However we finally found that even though the connection release mode was inconsistent, this was not the real cause, which seems to be related to https://hibernate.atlassian.net/browse/HHH-10649 which is not related to the Spring integration.

[spring-projects-issues]

Juergen Hoeller commented

You're certainly not the only ones to struggle with Hibernate 5.2 :-( Recent Hibernate upgrades have been rather painful all across the board.

FWIW, our Spring Boot 1.4 curated dependencies stick with Hibernate 5.0.9 for the time being... not with 5.2.1 and not even with 5.1 (where we're not sure where it'll get properly maintained since there isn't any maintenance release yet). Hibernate 5.0.x is part of WildFly 10 / JBoss EAP 7, so it's arguably the current mainstream version.

With Spring Framework 5, we're raising the baseline to Hibernate 5... but even there we're aiming for Hibernate 5.0+ and do not intend to require 5.2+ yet (which we would do if the upgrade story was more seamless and if JBoss EAP 7 would support it at that level).

[spring-projects-issues]

Juergen Hoeller commented

We're enforcing ON_CLOSE with Hibernate 5.1 as well now, closing that gap towards a consistent connection release mode with Spring's JPA setup as well as native Hibernate setup.

[spring-projects-issues]

Yanming Zhou commented

https://hibernate.atlassian.net/browse/HHH-7412
Hibernate 5.1.1 switch back to AFTER_TRANSACTION

[spring-projects-issues]

Juergen Hoeller commented

Indeed, it actually only changed back to AFTER_TRANSACTION in 5.1.1 in that branch... Previously, I checked the latest state in the 5.1 branch which contained that post-GA change, so I mistakingly assumed it was in 5.1.0 already.

In any case, our particular fix here only really applies to 5.1.1+: We seem to run against consistent ON_CLOSE up until 5.1.0 and with 5.2.0 onwards as of Spring 4.3 already, just closing the 5.1.1 gap now (also applying to further 5.1.x releases, if any).