HibernateJpaDialect should warn about connection release mode other than ON_CLOSE (when upgrading from 4.0.x) [SPR-13269]

[spring-projects-issues]

Oliver Becker opened SPR-13269 and commented

We have a Spring MVC web application with Hibernate 4.3.10 as JPA provider and HikariCP 2.3.9 as our data source.

After updating Spring to the latest 4.1 version we noticed connection leaks (reported by Hikari). These leaking connections always belong to readonly transactions, more specific the outermost transaction must be readonly (annotated as @Transactional(readonly=true))

After some debugging the relevant code seems to be in org.springframework.orm.jpa.vendor.HibernateJpaDialect, inner class SessionTransactionData, method resetSessionState.

The point is that this method is called from cleanupTransaction, i.e. after the transaction has been committed and the corresponding connection has been released already. resetSessionState then gets again a connection (the same instance), but this time it is never released. This happens only if resetConnection is true, which in turn happens for readonly transactions. So if this transaction is the outermost transaction then nobody closes the connection obtained in resetSessionState.

I cannot really believe that there is such a serious bug present for already 7 minor releases - so what am I doing wrong? Where is the reset connection supposed the be released?

---

Affects: 4.1.7

Issue Links:

• Compatibility with Hibernate ORM 5.0 GA [SPR-13002] #17594 Compatibility with Hibernate ORM 5.0 GA
• readOnly transaction doesn't work with JPA and Hibernate 4 [SPR-8959] #13599 readOnly transaction doesn't work with JPA and Hibernate 4
• Isolation support for JPA with Hibernate EntityManager 4 [SPR-11942] #16559 Isolation support for JPA with Hibernate EntityManager 4
• 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

Referenced from: commits a1107af

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

This is an effect triggered by the changes behind #13599 / #16559. Do you by any chance specify a connection release mode other than ON_CLOSE? In this case you would indeed get a reset executed on the current Connection handle returned by the Hibernate Session, with no explicit close call.

See the javadoc of HibernateJpaDialect.setPrepareConnection for some details. You should be able to switch that flag off to restore the previous behavior (not propagating the read-only status to the Connection to begin with}}, or to configure connection release mode ON_CLOSE to make it work properly.

I suppose we should try to identify such scenarios and not try to set/reset the read-only status on the Connection correspondingly, based on the connection release mode in the current Session handle, analogous to what we do in HibernateTransactionManager for native Hibernate access code.

Juergen

[spring-projects-issues]

Oliver Becker commented

Yes, first we had an explicit AFTER_TRANSACTION configuration, then we tried AUTO, which doesn't solve the problem either.
Thanks for explaining the possible work-arounds.

[spring-projects-issues]

Juergen Hoeller commented

So just double-checking, does it work with ON_CLOSE for you?

Note that Hibernate's JdbcTransactionFactory defaults to ON_CLOSE since Hibernate 4.1. This is why we took that as an assumption in HibernateJpaDialect.

Juergen

[spring-projects-issues]

Oliver Becker commented

Hmm, Hikari keeps reporting "Apparent connection leak detected", even for ON_CLOSE.

[spring-projects-issues]

Juergen Hoeller commented

Could you double-check the effect with ON_CLOSE there? I'm surprised that there would be any kind of connection leak in that case...

Juergen

[spring-projects-issues]

Oliver Becker commented

Sorry for not responding earlier. It turned out that these leaking connections in the case of ON_CLOSE were indeed a bug in our application (hidden by using AFTER_TRANSACTION). We have fixed it and now everything works correct with ON_CLOSE (resp. AUTO) and the latest Spring release.

Nevertheless, with AFTER_TRANSACTION the above-mentioned problems still exist (but they're not a blocker for us anymore).

Oliver

[spring-projects-issues]

Juergen Hoeller commented

HibernateJpaDialect logs a warning now if the freshly retrieved Connection handle to reset is not identical to the Connection that it originally prepared at the beginning of the transaction. This will appear for connection release modes other than ON_CLOSE but also for Hibernate <4.2 where call-specific Connection wrappers were returned; this is alright since we do not support prepared connections on Hibernate <4.2 anyway.

Juergen