HibernateTransactionManager should lazily acquire JDBC Connection (like HibernateJpaDialect) [SPR-17216]

[spring-projects-issues]

mishraawake opened SPR-17216 and commented

We are trying to implement the feature “provider_disables_autocommit” in our application.
Problem context in our application: We have a manager class which has complex business logic. We configured HibernateTransactionManager around the methods of manager class.
In many cases, we simply returns from the manager without touching the database.
This option of hibernate seems very promising to us. However, we observe there are some caveat with the option.
. To implement this is via spring HibernateTransactionManager, we have to set txManager.setPrepareConnection(false), txManager.setAutodetectDataSource(false) , otherwise it tries to acquire connection when transaction is starting. Is there a negative impact of this?

---

Affects: 5.0.8

Issue Links:

• LocalSessionFactoryBean and HibernateTransactionManager for JPA EntityManagerFactory setup [SPR-17002] #21540 LocalSessionFactoryBean and HibernateTransactionManager for JPA EntityManagerFactory setup
• Propagate read-only status to Hibernate Session through setDefaultReadOnly [SPR-16956] #21494 Propagate read-only status to Hibernate Session through setDefaultReadOnly
• HibernateTransactionManager (unintentionally) bound to Hibernate 5.2 SharedSessionContractImplementor [SPR-17557] #22089 HibernateTransactionManager (unintentionally) bound to Hibernate 5.2 SharedSessionContractImplementor
• Notification for db connection acquired when LazyConnectionDataSourceProxy is used [SPR-17278] #21811 Notification for db connection acquired when LazyConnectionDataSourceProxy is used

Referenced from: commits 78cad0f

[spring-projects-issues]

Juergen Hoeller commented

Our recommended solution for such a scenario is to declare your DataSource as a LazyConnectionDataSourceProxy for the actual DataSource, letting HibernateTransactionManager fully initialize the connection settings (read-only, isolation level) when needed through a lazily initializing connection handle.

Otherwise, turning off connection preparation and DataSource detection is an option as well. However, you can't let native JDBC code (e.g. JdbcTemplate based code) participate in a Hibernate transaction then, and you won't get any read-only hint passed to the JDBC driver (which might not matter with your particular driver).

In any case, this should be properly covered in the reference documentation, so I'm turning this into a documentation task.

[spring-projects-issues]

mishraawake commented

Thank you for recommendation. It is exactly what we were looking for. In fact, this is so enticing that it should be the primary recommendation for the datasource in spring. That makes me to ask following question, is there any drawback/hidden problem in using this datasource?

 

 

[spring-projects-issues]

Juergen Hoeller commented

No real drawback as far as I am aware. It's an extra dynamic proxy instance for each decorating connection which involves a little bit of overhead, and the Connection handle exposed from LazyConnectionDataSourceProxy cannot be cast straight to a pool/vendor connection type. The latter doesn't really matter anymore since JDBC 4.0's unwrap is commonly supported now... so the only remaining drawback is unnecessarily decorating a pool when the Connection is commonly needed anyway or when the underlying pool implements lazy retrieval itself internally. I'll reflect this in the documentation.

That said, I'm considering to make HibernateTransactionManager more defensive in terms of Connection access, lazily exposing the Connection for plain JDBC access via a ConnectionHandle along the lines of HibernateJpaDialect... at least not requiring autodetectDataSource=false anymore, and possibly being smarter about the need for prepareConnection as well. This fits nicely with #21540 and #21494, so I'm considering this for 5.1 still.

[spring-projects-issues]

Juergen Hoeller commented

As of 5.1 RC3, we're lazily retrieving JDBC Connections via an on-demand ConnectionHandle. A JDBC Connection will only be acquired at transaction begin if actual connection preparation is needed (isolation level / read-only). As a consequence, for lazy access with full capabilities, we still recommend LazyConnectionDataSourceProxy; otherwise, switching prepareConnection to false is sufficient now (no need to reset the DataSource anymore).