Hibernate session closing

[alelus]

I am developing a Swing application, backed by Spring and Hibernate, and would like to have one session per application, in order to use lazy loading of associations. However, I noticed that SessionFactoryUtils (in behalf of HibernateTransactionManager) always closes the session at the end of a transaction. So, my first question is: is there any means to avoid this behavior?

That made me think about the lifecycles of sessions and transactions. Should not they be unrelated, unless I want they be? If so, the API should give me a way of configuring the desired lifecycle for sessions.

PS: Spring is great! Congratulations, people!

[dejanp]

I don't think it's generally possible to treat transactions and connections as unrelated, that's more or less an implentation detail. For example, RequiresNew is usually implemented by simply opening a new connection, meaning that you can't do it all if you have only one. How do you separate transactions that run in parallel threads if you have only one connection?

You can always use SingleConnectionDataSource. How will it work with transactions and multi-threading - I have no idea.

[Costin Leau]

always closes the session at the end of a transaction.

A session uses a connection but they not the same thing. When you close a session, the connection used will be placed back into the connection pool.

As for session-per-application I would suggest to thing about alternatives - you can keep a connection and open sessions on top of it; the problem with keeping a session open for a long time is that you can run out of memory quickly unless you do memory management with it which can be very easily translated by creating a session per request.

[glestum]

I have similar requirements:
- swing client/server app
- hibernate DOM with single long session and short db transactions
- hibernate session renewed when exception or new application transaction (-> app need control over session lifecycle)
- eventual optimisation using hibernate session disconnect/reconnect if required
- furthermore 2 threads share access to the hibernate persistent objects
.. - worker thread fetches and updates model
.. - swing dispatch thread browses model and its lazy references
.. -> require serialized session/DOM acces (easy)
.. -> but makes usage of Spring thread-bound sessions tricky

Spring is opensource after all so I thought about looking for inspiration in OpenSessionInViewFilter and implement a LocalSessionFactoryBean and HibernateTransactionManager specific to my requirements, but I am far from having understood Spring well enough to do that reliably!

So for now I won't be able to use Spring's great DAO support.

I'd be interested to know about other experiences using Spring/Hibernate in client/server fat clients.

Guillaume

[Costin Leau]

There are some good posts on the Architecture forum. Also Hibernate in Action offers very good advices on how to treat these cases in regard to session management.

[alelus]

Thanks for your comments.

I could not explain the context of my problem in better terms than glestum did.

I followed costin advice and tried the architecture forum, but could not find any solution there. So, I decided to implement a solution based on the open session in view pattern, but gave up using an only session, in order to avoid memory problems (thanks again, costin). Sure, not all Swing GUI have a concept similar to a request, but mine has :-).

My application features several use cases, triggered by menu entries, and all my transactions have REQUIRED propagation, so I could open a session every time a use case started, and close it when another did. In between, I could open as many transactions as I needed. In order to enable this, I would have to create a transaction manager and a session manager. The former could be installed via AOP interceptors.

It is a simple solution for very specific requirements, and it would have to be improved a lot to account for cases such as that raised by dejanp, or one where it was not allowed to maintain a connection with the database opened all the time. However, I guess it covers most of the cases.

Anyway, it would be better if we have support from Spring to manage session lifecycle in a more flexible way, although this does not mean that some transaction lifecycle options would not limit the choices for session lifecycles.

[manifoldronin]

Some thoughts on multithreading sessions (never actually did it so forgive me if I'm missing some point) - what the threads really need to share is not necessarily the same hibernate session, but rather the model. So each thread can have its own thread-local session. The worker thread would populate the model and detach it. The Swing thread then attach it to its own session for lazy loading. There is still synchronization to worry about but it would be on the model and not much different from that in any average Swing app.

[Costin Leau]

This problems is easily by Hibernate - all the session have the same sessionFactory - using versioning/timestamp you can detect and solve any stale data.