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

correct spell 

git-svn-id: https://svn.jboss.org/repos/hibernate/core/trunk@18801 1b8cb986-b30d-0410-93ca-fae66ebed9b2
This commit is contained in:
Strong Liu 2010-02-15 13:02:33 +00:00
parent 3fda092751
commit 494caf6dbd
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
entitymanager/src/main/docbook/en/modules/transactions.xml
View File

@ -110,7 +110,7 @@
injected (or looked up) entity managers share the same persistence injected (or looked up) entity managers share the same persistence
context for a particular JTA transaction. The beauty of EJB3 is that you context for a particular JTA transaction. The beauty of EJB3 is that you
don't have to care about that anymore and just see data access through don't have to care about that anymore and just see data access through
entity manager and demaraction of transaction scope on session beans as entity manager and demarcation of transaction scope on session beans as
completely orthogonal.</para> completely orthogonal.</para>
<para>The challenge is the implementation of this (and other) behavior <para>The challenge is the implementation of this (and other) behavior
@ -371,7 +371,7 @@
<sect1 id="transactions-demarcation"> <sect1 id="transactions-demarcation">
<title>Database transaction demarcation</title> <title>Database transaction demarcation</title>
<para>Datatabase (or system) transaction boundaries are always necessary. <para>Database (or system) transaction boundaries are always necessary.
No communication with the database can occur outside of a database No communication with the database can occur outside of a database
transaction (this seems to confuse many developers who are used to the transaction (this seems to confuse many developers who are used to the
auto-commit mode). Always use clear transaction boundaries, even for auto-commit mode). Always use clear transaction boundaries, even for
@ -581,7 +581,7 @@ finally {
<literal>iterate()</literal>. You <emphasis>must</emphasis> release the <literal>iterate()</literal>. You <emphasis>must</emphasis> release the
underlying database cursor by calling underlying database cursor by calling
<literal>ScrollableResults.close()</literal> or <literal>ScrollableResults.close()</literal> or
<literal>Hibernate.close(Iterator)</literal> explicity from a <literal>Hibernate.close(Iterator)</literal> explicitly from a
<literal>finally</literal> block. (Of course, most applications can <literal>finally</literal> block. (Of course, most applications can
easily avoid using <literal>scroll()</literal> or easily avoid using <literal>scroll()</literal> or
<literal>iterate()</literal> at all from the CMT code.)</para> <literal>iterate()</literal> at all from the CMT code.)</para>
@ -638,8 +638,8 @@ finally {
<para>Hibernate wraps <literal>SQLException</literal>s thrown while <para>Hibernate wraps <literal>SQLException</literal>s thrown while
interacting with the database in a <literal>JDBCException</literal>. In interacting with the database in a <literal>JDBCException</literal>. In
fact, Hibernate will attempt to convert the eexception into a more fact, Hibernate will attempt to convert the exception into a more
meningful subclass of <literal>JDBCException</literal>. The underlying meaningful subclass of <literal>JDBCException</literal>. The underlying
<literal>SQLException</literal> is always available via <literal>SQLException</literal> is always available via
<literal>JDBCException.getCause()</literal>. Hibernate converts the <literal>JDBCException.getCause()</literal>. Hibernate converts the
<literal>SQLException</literal> into an appropriate <literal>SQLException</literal> into an appropriate
@ -724,9 +724,9 @@ finally {
intermediate conversation work will be processed in methods not intermediate conversation work will be processed in methods not
involving transaction. The end of the conversation will be processed involving transaction. The end of the conversation will be processed
inside a <literal>JTA</literal> transaction. Hence all queued operations inside a <literal>JTA</literal> transaction. Hence all queued operations
will be executed to the database and commited. If you are interested in will be executed to the database and committed. If you are interested in
the notion of conversation inside your application, have a look at JBoss the notion of conversation inside your application, have a look at JBoss
Seam. Jboss Seam emphasizes the concept of conversation and entity Seam. JBoss Seam emphasizes the concept of conversation and entity
manager lifecycle and bind EJB3 and JSF together.</para> manager lifecycle and bind EJB3 and JSF together.</para>
</sect2> </sect2>
@ -811,7 +811,7 @@ em.close();</programlisting>
<para>Clearly, manual version checking is only feasible in very trivial <para>Clearly, manual version checking is only feasible in very trivial
circumstances and not practical for most applications. Often not only circumstances and not practical for most applications. Often not only
single instances, but complete graphs of modified ojects have to be single instances, but complete graphs of modified objects have to be
checked. Hibernate offers automatic version checking with either checked. Hibernate offers automatic version checking with either
detached instances or an extended entity manager and persistence context detached instances or an extended entity manager and persistence context
as the design paradigm.</para> as the design paradigm.</para>