Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor 

git-svn-id: https://svn.jboss.org/repos/hibernate/trunk/Hibernate3/doc@6474 1b8cb986-b30d-0410-93ca-fae66ebed9b2
This commit is contained in:
Christian Bauer 2005-04-20 15:00:47 +00:00
parent 23824bbc8d
commit 57d60d0e76
2 changed files with 32 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
reference/en/modules/configuration.xml
View File

@ -1577,10 +1577,11 @@ hibernate.dialect = org.hibernate.dialect.PostgreSQLDialect]]></programlisting>
<literal>getCurrentSession()</literal> method on the <literal>SessionFactory</literal>
to obtain a Hibernate <literal>Session</literal>. If there is no Hibernate
<literal>Session</literal> in current JTA transaction, one will be started and
assigned. If you have set both the <literal>hibernate.transaction.flush_before_completion</literal>
and <literal>hibernate.transaction.auto_close_session</literal> configuration options,
the <literal>Session</literal> will also be flushed and closed automatically
when the container ends the JTA transactions.
assigned. Both the <literal>hibernate.transaction.flush_before_completion</literal>
and <literal>hibernate.transaction.auto_close_session</literal> configuration option,
will be set automatically for every <literal>Session</literal> you retrieve with
<literal>getCurrentSession()</literal>, so they will also be flushed and closed
automatically when the container ends the JTA transactions.
</para>
<para>

47
reference/en/modules/transactions.xml
View File

@ -436,12 +436,14 @@ finally {
<para>
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.
</para>
<para>
If you use bean-managed transactions (BMT) Hibernate will tell the application server to start
and end a BMT transaction if you use the <literal>Transaction</literal> API. So, the
transaction management code is identical to the non-managed environment.
</para>
<programlisting><![CDATA[// BMT idiom
@ -464,24 +466,29 @@ finally {
}]]></programlisting>
<para>
Note that you should choose <literal>org.hibernate.transaction.JTATransactionFactory</literal>
in a BMT session bean, and <literal>org.hibernate.transaction.CMTTransactionFactory</literal>
in a CMT session bean. Remember to also set
<literal>org.hibernate.transaction.manager_lookup_class</literal>.
</para>
<para>
If you set the properties <literal>hibernate.transaction.flush_before_completion</literal>
and <literal>hibernate.transaction.auto_close_session</literal> to <literal>true</literal>,
Hibernate will automatically flush and close the <literal>Session</literal> 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 <literal>RuntimeException</literal>
thrown by a session bean method tells the container to set the global transaction to
rollback. <emphasis>This means you do not need to use the Hibernate
With CMT, transaction demarcation is done in session bean deployment descriptors, not programatically.
You still have to flush and close the <literal>Session</literal> yourself, unless you set the properties
<literal>hibernate.transaction.flush_before_completion</literal> and
<literal>hibernate.transaction.auto_close_session</literal> to <literal>true</literal>. Hibernate will
then automatically flush and close the <literal>Session</literal> 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 <literal>RuntimeException</literal> thrown by a session bean method tells the container
to set the global transaction to rollback. <emphasis>This means you do not need to use the Hibernate
<literal>Transaction</literal> API at all in CMT.</emphasis>
</para>
<para>
Note that you should choose <literal>org.hibernate.transaction.JTATransactionFactory</literal>
in a BMT session bean, and <literal>org.hibernate.transaction.CMTTransactionFactory</literal>
in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set
<literal>org.hibernate.transaction.manager_lookup_class</literal>.
</para>
<para>
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 <literal>ThreadLocal</literal> 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 <literal>Session</literal> instance around, the
<literal>SessionFactory</literal> provides the <literal>getCurrentSession()</literal>
method, which returns a session that is bound to the JTA transaction context. This is the