Hibernate 3.1 with connection.release_mode after_transaction [SPR-2022]

[spring-projects-issues]

Michael Fortin opened SPR-2022 and commented

According to Hibernates docs, release mode on_close is 'highly discouraged' yet it seems to be the only option available when using springs transaction manager, after_transaction is the default with jdbc transactions with the current release of hibernate:
http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-connection-release

Having support for after transaction would be helpful not only for 'long conversations' but for other scenarios as well. For example I have a single http request that posts to several outside vendors and I have to wait for their responses. My application currently does not scale well because I have to hold a connection to the database. With hibernate 3.1 I could simply commit before I post to the external sources to release the connection.

---

Affects: 2.0 M5

[spring-projects-issues]

Juergen Hoeller commented

Actually, Spring's HibernateTransactionManager is able to work with a connection release mode other than ON_CLOSE as well. It won't be able to apply custom isolation levels and read-only flags to the underlying JDBC Connection in this case - as long as that's acceptable, you can specify any other connection release mode for your SessionFactory.

Note that you can also call "disconnect()" on a Session explicitly, which will release the underlying JDBC Connection even in case of connection release mode ON_CLOSE.

Thinking of it, we could probably call "disconnect()" at the end of a HibernateTransactionManager transaction even with ON_CLOSE (as of Hibernate 3.1; wasn't an option with Hibernate 3.0). That would provide AFTER_TRANSACTION semantics even with official release mode ON_CLOSE, and still allow for custom isolation levels and read-only flags.

If there's anything we can do to ease your job with other connection release modes, please let us know...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I have added such an automatic "disconnect()" call for a pre-bound Session after a HibernateTransactionManager transaction (when operating on Hibernate 3.1+). So even with Spring's default connection release mode ON_CLOSE, you still get JDBC Connections returned after each Spring-managed transaction.

If there's anything else that we can do, let me know...

Juergen

[spring-projects-issues]

Rik van der Kleij commented

Problem of this solution (disconnect() after end of transaction for pre-bound sessions) is that in combination with OpenSessionInView class/pattern the still open session is not valid anymore after the transaction because the jdbc connection is closed. I do not see a simple solution/workaround.

Rik

[spring-projects-issues]

Juergen Hoeller commented

With Hibernate 3.1 or higher, the Session will automatically reconnect when an operating requires JDBC access during a subsequent request. This has been working fine for more than two years...

Juergen

[spring-projects-issues]

Rik van der Kleij commented

Thanks for you reply.

This is not the case when a Hibernate IteratorImpl is returned to the view. Just try it otherwise I have a Wicket example application to show it.

Rik

[spring-projects-issues]

Juergen Hoeller commented

I see... Why are you exposing a Hibernate Iterator to the view there? It should usually be the lazy-loading capable Collection... What specific reasons led you to choosing an Iterator?

Juergen

[spring-projects-issues]

Rik van der Kleij commented

There is not a specific reason (as far as I know). Maybe it is a pattern used in Wicket to load the model. This code is not written by me but I have to refactor it and I wanted to migrate from Spring 1.2.8 to Spring 2.5. This migration failed because of the disconnect.

Your right, if I return a List then there is no problem because all items are already obtained (so no connection is necessary anymore). That was already mine conclusion also but our concern is that when I return a List with lazy associations would the session with disconnected jdbc connection be a problem.

.

[spring-projects-issues]

Juergen Hoeller commented

A List with lazy associations should work fine, since the Hibernate Session will reconnect automatically whenever database access is triggered... This is the primary reason why we added the disconnect call there: It releases the physical database connection early for the typical case where no further access is needed... and if database access happens to be actually needed, the Session automatically reconnects.

Releasing connections early is strongly recommended by the Hibernate team in general. Hibernate's default connection release mode behaves just like Spring here, releasing the connection eagerly after each transaction. As far as I'm aware, Hibernate also closes all open ResultSets (and hence all Iterators operating on them) in its default connection release mode there.

Juergen

[spring-projects-issues]

Rik van der Kleij commented

Thanks for your answer. I will change the code so Lists instances are returned to the view so we can migrate to Spring 2.5.

Rik

[spring-projects-issues]

Marko Topolnik commented

I would like this issue reconsidered for the following use case:

• generate a REST response from a database result set with O(1) space requirement;
• use the standard MessageConverter API, which operates on the return value of the @RestController;
• use Java 8 Stream as the return value, backed by a live DB cursor (through Hibernate's ScrollableResults).

It is fine if the transaction commits when the service-layer method returns, but the ResultSet must stay open until the whole response is served.

I have already tested that the above approach works when the offending session.disconnect() line is removed.