diff --git a/reference/en/modules/configuration.xml b/reference/en/modules/configuration.xml index 902ed42e34..56b368b0df 100644 --- a/reference/en/modules/configuration.xml +++ b/reference/en/modules/configuration.xml @@ -1577,10 +1577,11 @@ hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect]]> getCurrentSession() method on the SessionFactory to obtain a Hibernate Session. If there is no Hibernate Session in current JTA transaction, one will be started and - assigned. If you have set both the hibernate.transaction.flush_before_completion - and hibernate.transaction.auto_close_session configuration options, - the Session will also be flushed and closed automatically - when the container ends the JTA transactions. + assigned. Both the hibernate.transaction.flush_before_completion + and hibernate.transaction.auto_close_session configuration option, + will be set automatically for every Session you retrieve with + getCurrentSession(), so they will also be flushed and closed + automatically when the container ends the JTA transactions. diff --git a/reference/en/modules/transactions.xml b/reference/en/modules/transactions.xml index c25bd6a7de..801a506782 100644 --- a/reference/en/modules/transactions.xml +++ b/reference/en/modules/transactions.xml @@ -436,15 +436,17 @@ finally { If your persistence layer runs in an application server (e.g. behind EJB session beans), - transaction boundaries are defined in deployment descriptors. Every datasource connection - obtained by Hibernate will automatically be part of the global JTA transaction. Hibernate - simply joins this transaction, or if a particular session bean method has no mandatory - transaction, Hibernate will tell the application server to start and end a BMT transaction - directly. So, for BMT, the session handling idiom is identical to case of a non-managed - environment: + every datasource connection obtained by Hibernate will automatically be part of the global + JTA transaction. Hibernate offers two strategies for this integration. + + + + If you use bean-managed transactions (BMT) Hibernate will tell the application server to start + and end a BMT transaction if you use the Transaction API. So, the + transaction management code is identical to the non-managed environment. - + + 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. + + Note that you should choose org.hibernate.transaction.JTATransactionFactory in a BMT session bean, and org.hibernate.transaction.CMTTransactionFactory - in a CMT session bean. Remember to also set + in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set org.hibernate.transaction.manager_lookup_class. - If you set the properties hibernate.transaction.flush_before_completion - and hibernate.transaction.auto_close_session to true, - Hibernate will 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 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). 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 @@ -490,7 +497,7 @@ finally { session/transaction management idiom is reduced to this: -