Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Aug 26, 2018 · 4 comments
Assignees
Labels
in: data type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 26, 2018

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:

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

Referenced from: commits 78cad0f

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 26, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 28, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 29, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 31, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants