Alternative OpenSessionInView Semantics

[johndstein]

As I understand it, using Hibernate/Spring with declarative tx management, there are three options for session management. The first is that each transaction gets its own session which is closed when the transaction block ends.

The second is to use one of the OpenSessionInView classes to bind a Hibernate session to the current thread, and each transaction block uses that thread.

The third (again with OpenSessionInView) is each transaction block gets its own session which is left open after the transaction block ends.

The ideal I would like to get to is yet another option. All methods that get data share a single read only Hibernate session, and all write methods get their own Hibernate session which is committed and closed when the tx ends.

All transactional methods will receive data (could be hibernate objects tied to a session or just copies of data from request params), with their own Hib session they will load hib objects and copy data from input to those objects and commit transaction. In this way you have total control over what is saved and you can see it all explicitly in a single transactional method.

I am currently trying to get this to work with Hibernate 3.0.5 and Spring 1.2.2. Any ideas or help would be appreciated.

Thanks!

[Juergen Hoeller]

That's not quite gonna work, I'm afraid. It's not natural to make a distinction between read and write operations in Hibernate: Keep in mind that Hibernate automatically detects changes to loaded objects within the same transaction, etc. And when loading objects, you often don't know whether they're gonna get modified...

I haven't heard of anyone doing such separation yet, neither with Spring/Hibernate nor with pure Hibernate. While you might be able to get it to work to some degree, the approach is always gonna remain somewhat unnatural. In particular, it might lead to some weird, unexpected side effects that you won't find much help on.

Juergen

[johndstein]

Thanks Juergen for the reply.

My idea would solve both the "duplicate object problem" and the problem of "if a single persistent object becomes involved in multiple transactions" mentioned on page 283 of Professional Java Development with the Spring Framework.

Methods that read data from the database solely for the purpose of passing the data on to web views or other business objects could all share a single Hibernate thread-bound session. They don't need to participate in any transaction. Ideally the session/connection would be read only, or they could all participate in a single transaction that gets rolled back in the end.

Methods that update data would be transactional, and have their own Hibernate session tied to the transaction. They would not lock or attach objects passed into them to be updated, rather they would load or query objects to be updated.

Data from objects passed into these methods (they could be persistent objects or not) would be copied to objects bound to the transaction's session.

My goal here is to solve both the problems you mention in your book as well as to insure that you can explicitly tell by looking at a transactional method exactly what data will be updated.

Any time you pass in a hibernated object to an update method whether it's attached to a session or whether you attach it inside the method, you can never tell by looking at the method exactly what members will be updated, which makes the whole point of demarcating a transaction pointless.