Gavion,

A question in terms of integration of Hibernate into transaction infrastructures: concretely, into the Spring Framework, obviously :-) Everything's fine with Hibernate's own transaction handling, and thus with Spring's HibernateTransactionManager. However, Spring's support for Hibernate with its JtaTransactionManager has an issue:

We currently invoke SessionImplementor.afterTransactionCompletion and then close the Session in Spring's own transaction synchronization mechanism, after the transaction has completed. This works nicely with all JTA implementations that allow to close a JDBC Connection after transaction completion. Unfortunately, WebLogic's JTA subsystem (for an example) is very restrictive in that respect: You must close the Connection before transaction completion there. So Spring's default synchronization strategy doesn't work: We'd need to close the Session before completion here, and invoke SessionImplementor.afterTransactionCompletion afterwards.

Currently, I'm not aware of a way to invoke SessionImplementor.afterTransactionCompletion after Session.close. Session.disconnect, invoked by close, will always call afterTransactionCompletion itself, with status "false" (rollback semantics), except when the internal "isCurrentTransaction" flag is set. That SessionImpl flag cannot be manipulated from the outside but is just implicitly set by Hibernate's own transaction management or in case of JTA TransactionManager participation. So what does work currently with Spring is to configure Hibernate's TransactionManagerLookup: We specifically check for this to close the Session before completion then.

However, it would be nice if Spring's own transaction synchronization could also work for such restrictive JTA implementations [i]without[i] a Hibernate TransactionManagerLookup, just like it is able to for other JTA impls. To achieve that, we'd simply need a way to turn SessionImpl to isCurrentTransaction=true from the outside, just like its JTA TransactionManagerLookup auto-detection does. What do you think about adding such a method to SessionImplementor? A way to invoke close without implicitly triggering afterTransactionCompletion would be good enough too, maybe via an overloaded "close" method?

Juergen