diff --git a/reference/en/modules/transactions.xml b/reference/en/modules/transactions.xml index d186e69ff6..922b04f945 100644 --- a/reference/en/modules/transactions.xml +++ b/reference/en/modules/transactions.xml @@ -467,14 +467,15 @@ finally { With CMT, transaction demarcation is done in session bean deployment descriptors, not programatically. - You still have to flush and close the Session yourself, unless you set the properties - hibernate.transaction.flush_before_completion and - hibernate.transaction.auto_close_session to true. Hibernate will - then automatically flush and close the Session for you. The only thing left to rollback - the transaction when an exception occurs. Fortunately, in a CMT bean, even this happens automatically, - since an unhandled RuntimeException thrown by a session bean method tells the container - to set the global transaction to rollback. This means you do not need to use the Hibernate - Transaction API at all in CMT. + If you don't want to manually flush and close the Session yourself, just set + hibernate.transaction.flush_before_completion to true, + hibernate.connection.release_mode to after_statement or + auto and hibernate.transaction.auto_close_session to + true. Hibernate will then automatically flush and close the Session + for you. The only thing left is to rollback the transaction when an exception occurs. Fortunately, in a + CMT bean, even this happens automatically, since an unhandled RuntimeException thrown + by a session bean method tells the container to set the global transaction to rollback. This + means you do not need to use the Hibernate Transaction API at all in CMT. @@ -488,13 +489,13 @@ finally { If you work in a CMT environment, and use automatic flushing and closing of the session, you might also want to use the same session in different parts of your code. Typically, in a non-managed environment you would use a ThreadLocal variable to hold the session, but a - single EJB method might execute in different threads (e.g. session bean calling another session bean). + single EJB request might execute in different threads (e.g. session bean calling another session bean). If you don't want to bother passing your Session instance around, the SessionFactory provides the getCurrentSession() method, which returns a session that is bound to the JTA transaction context. This is the easiest way to integrate Hibernate into an application! The "current" session always has - auto-flush and auto-close enabled (regardless of the above property settings). Our - session/transaction management idiom is reduced to this: + auto-flush, auto-close and auto-connection-release enabled (regardless of the above property + settings). Our session/transaction management idiom is reduced to this: - There is one caveat to the use of auto_close_session. Due to a limitation - of the JTA spec, it is not possible for Hibernate to automatically clean up any unclosed - ScrollableResults or Iterator instances returned by - scroll() or iterate(). You must - release the underlying database cursor by calling ScrollableResults.close() - or Hibernate.close(Iterator) explicity from a finally + There is one caveat to the use of after_statement connection release + mode. Due to a silly limitation of the JTA spec, it is not possible for Hibernate to + automatically clean up any unclosed ScrollableResults or + Iterator instances returned by scroll() or + iterate(). You must release the underlying database + cursor by calling ScrollableResults.close() or + Hibernate.close(Iterator) explicity from a finally block. (Of course, most applications can easily avoid using scroll() or iterate() at all from the CMT code.) @@ -694,12 +696,17 @@ session.disconnect(); // Return JDBC connection ]]> The foo object still knows which Session it was loaded in. Session.reconnect() obtains a new connection (or you - may supply one) and resumes the session. The method Session.disconnect() will disconnect the session from - the JDBC connection and return the connection to the pool (unless you provided the - connection). After reconnection, to force a version check on data you aren't updating, you - may call Session.lock() with LockMode.READ on any - objects that might have been updated by another transaction. You don't need to lock any - data that you are updating. + may supply one) and resumes the session. The method Session.disconnect() + will disconnect the session from the JDBC connection and return the connection to the pool + (unless you provided the connection). After reconnection, to force a version check on data + you aren't updating, you may call Session.lock() with + LockMode.READ on any objects that might have been updated by another + transaction. You don't need to lock any data that you are updating. + + + + If the explicit calls to disconnect() and reconnect() + are too onerous, you may instead use hibernate.connection.release_mode.