[Hibernate-commits] Hibernate/doc/reference/src manipulating_data.xml,1.26,1.27

[<tu...@us...>]

Update of /cvsroot/hibernate/Hibernate/doc/reference/src
In directory sc8-pr-cvs1:/tmp/cvs-serv5812/doc/reference/src

Modified Files:
	manipulating_data.xml 
Log Message:
Fix in section IDs

Index: manipulating_data.xml
===================================================================
RCS file: /cvsroot/hibernate/Hibernate/doc/reference/src/manipulating_data.xml,v
retrieving revision 1.26
retrieving revision 1.27
diff -C2 -d -r1.26 -r1.27
*** manipulating_data.xml	28 Oct 2002 15:41:55 -0000	1.26
--- manipulating_data.xml	20 Nov 2002 10:27:48 -0000	1.27
***************
*** 760,850 ****
          </itemizedlist>
          
!     <sect2 id="manipulating-data-s13b">
!     
!         <title>Flushing the session</title>
!         <para>
!             If you happen to be using the <literal>Transaction</literal> API, you don't
!             need to worry about this step. It will be performed implicitly when the 
!             transaction is committed. Otherwise you should call 
!             <literal>Session.flush()</literal> to ensure that all changes are synchronized
!             with the database.
!         </para>
!         
!     </sect2>
      
!     <sect2 id="manipulating-data-s13b">
!         <title>Committing the transaction</title>
  
!         <para>
!             If you are using the Hibernate <literal>Transaction</literal> API, this looks like:
!         </para>
  
!         <programlisting><![CDATA[tx.commit(); // flush the Session and commit the transaction]]></programlisting>
  
!         <para>
!             If you are managing JDBC transactions yourself you should manually
!             <literal>commit()</literal> the JDBC connection.
!         </para>
  
!         <programlisting><![CDATA[sess.flush();
  sess.connection().commit();  //not necessary for JTA datasource]]></programlisting>
  
!         <para>
!             If you decide <emphasis>not</emphasis> to commit your changes:
!         </para>
  
!         <programlisting><![CDATA[tx.rollback(); // rollback the transaction]]></programlisting>
  
!         <para>
!             or:
!         </para>
  
!         <programlisting><![CDATA[//not necessary for JTA datasource, important otherwise
  sess.connection().rollback();]]></programlisting>
  
!     </sect2>
      
!     <sect2 id="manipulating-data-s13c">
!          <title>Closing the session</title>
!          
!          <para>
!              A call to <literal>Session.close()</literal> marks the end of a session. The main implication
!              of <literal>close()</literal> is that the JDBC connection will be relinquished by the session.
!          </para>
  
!         <programlisting><![CDATA[tx.commit();
  sess.close();]]></programlisting>
  
!         <programlisting><![CDATA[sess.flush();
  sess.connection().commit();  //not necessary for JTA datasource
  sess.close();]]></programlisting>
  
  
!          <para>
!              If you provided your own connection, <literal>close()</literal> returns a reference 
!              to it, so you can manually close it or return it to the pool. Otherwise <literal>close()
!              </literal> returns it to the pool.
!          </para>
! 
!     </sect2>
  
!     <sect2 id="manipulating-data-s13d">
!         <title>Exception handling</title>
  
!         <para>
!             If the <literal>Session</literal> throws an exception (including
!             any <literal>SQLException</literal>), you should immediately
!             rollback the transaction, call <literal>Session.close()</literal>
!             and discard the <literal>Session</literal> instance. Certain
!             methods of <literal>Session</literal> will <emphasis>not</emphasis>
!             leave the session in a consistent state.
!         </para>
  
  
!         <para>
!             The following exception handling idiom is recommended:
!         </para>
  
!         <programlisting><![CDATA[Session sess = factory.openSession();
  Transaction tx = null;
  try {
--- 760,849 ----
          </itemizedlist>
          
!         <sect2 id="manipulating-data-s13-1">
! 
!             <title>Flushing the session</title>
!             <para>
!                 If you happen to be using the <literal>Transaction</literal> API, you don't
!                 need to worry about this step. It will be performed implicitly when the 
!                 transaction is committed. Otherwise you should call 
!                 <literal>Session.flush()</literal> to ensure that all changes are synchronized
!                 with the database.
!             </para>
! 
!         </sect2>
      
!         <sect2 id="manipulating-data-s13-2">
!             <title>Committing the transaction</title>
  
!             <para>
!                 If you are using the Hibernate <literal>Transaction</literal> API, this looks like:
!             </para>
  
!             <programlisting><![CDATA[tx.commit(); // flush the Session and commit the transaction]]></programlisting>
  
!             <para>
!                 If you are managing JDBC transactions yourself you should manually
!                 <literal>commit()</literal> the JDBC connection.
!             </para>
  
!             <programlisting><![CDATA[sess.flush();
  sess.connection().commit();  //not necessary for JTA datasource]]></programlisting>
  
!             <para>
!                 If you decide <emphasis>not</emphasis> to commit your changes:
!             </para>
  
!             <programlisting><![CDATA[tx.rollback(); // rollback the transaction]]></programlisting>
  
!             <para>
!                 or:
!             </para>
  
!             <programlisting><![CDATA[//not necessary for JTA datasource, important otherwise
  sess.connection().rollback();]]></programlisting>
  
!         </sect2>
      
!         <sect2 id="manipulating-data-s13-3">
!             <title>Closing the session</title>
  
!             <para>
!                 A call to <literal>Session.close()</literal> marks the end of a session. The main implication
!                 of <literal>close()</literal> is that the JDBC connection will be relinquished by the session.
!             </para>
! 
!             <programlisting><![CDATA[tx.commit();
  sess.close();]]></programlisting>
  
!             <programlisting><![CDATA[sess.flush();
  sess.connection().commit();  //not necessary for JTA datasource
  sess.close();]]></programlisting>
  
+             <para>
+                 If you provided your own connection, <literal>close()</literal> returns a reference 
+                 to it, so you can manually close it or return it to the pool. Otherwise <literal>close()
+                 </literal> returns it to the pool.
+             </para>
  
!         </sect2>
  
!         <sect2 id="manipulating-data-s13-4">
!             <title>Exception handling</title>
  
!             <para>
!                 If the <literal>Session</literal> throws an exception (including
!                 any <literal>SQLException</literal>), you should immediately
!                 rollback the transaction, call <literal>Session.close()</literal>
!                 and discard the <literal>Session</literal> instance. Certain
!                 methods of <literal>Session</literal> will <emphasis>not</emphasis>
!                 leave the session in a consistent state.
!             </para>
  
  
!             <para>
!                 The following exception handling idiom is recommended:
!             </para>
  
!             <programlisting><![CDATA[Session sess = factory.openSession();
  Transaction tx = null;
  try {
***************
*** 862,870 ****
  }]]></programlisting>
  
!         <para>
!             Or, when manually managing JDBC transactions:
!         </para>
  
!         <programlisting><![CDATA[Session sess = factory.openSession();
  try {
      //do some work
--- 861,869 ----
  }]]></programlisting>
  
!             <para>
!                 Or, when manually managing JDBC transactions:
!             </para>
  
!             <programlisting><![CDATA[Session sess = factory.openSession();
  try {
      //do some work
***************
*** 881,889 ****
  }]]></programlisting>
  
!         <para>
!             Or, when using a datasource enlisted with JTA:
!         </para>
  
!         <programlisting><![CDATA[UserTransaction ut = .... ;
  Session sess = factory.openSession();
  try {
--- 880,888 ----
  }]]></programlisting>
  
!             <para>
!                 Or, when using a datasource enlisted with JTA:
!             </para>
  
!             <programlisting><![CDATA[UserTransaction ut = .... ;
  Session sess = factory.openSession();
  try {
***************
*** 900,922 ****
  }]]></programlisting>
  
!     </sect2>
      
      </sect1>
  
!     <sect1 id="manipulating-data-s17">
!     <title>Interceptors</title>
!     <para>
!         The <literal>Interceptor</literal> interface provides callbacks from the session to the 
!         application allowing the application to inspect and / or manipulate properties of a 
!         persistent object before it is saved, updated or deleted and after it is loaded. One 
!         possible use for this is to track auditing information. For example, the following 
!         <literal>Interceptor</literal> automatically sets the  <literal>createTimestamp</literal> 
!         when an <literal>Auditable</literal> is created and updates the 
!         <literal>lastUpdateTimestamp</literal> property when an <literal>Auditable</literal> is 
!         updated.
!     </para>
!     </sect1>
  
!     <programlisting><![CDATA[package cirrus.hibernate.test;
  
  import java.io.Serializable;
--- 899,920 ----
  }]]></programlisting>
  
!         </sect2>
      
      </sect1>
  
!     <sect1 id="manipulating-data-s14">
!         <title>Interceptors</title>
!         <para>
!             The <literal>Interceptor</literal> interface provides callbacks from the session to the 
!             application allowing the application to inspect and / or manipulate properties of a 
!             persistent object before it is saved, updated or deleted and after it is loaded. One 
!             possible use for this is to track auditing information. For example, the following 
!             <literal>Interceptor</literal> automatically sets the  <literal>createTimestamp</literal> 
!             when an <literal>Auditable</literal> is created and updates the 
!             <literal>lastUpdateTimestamp</literal> property when an <literal>Auditable</literal> is 
!             updated.
!         </para>
  
!         <programlisting><![CDATA[package cirrus.hibernate.test;
  
  import java.io.Serializable;
***************
*** 977,985 ****
  }]]></programlisting>
  
!     <para>
!         The interceptor would be specified when a session is created.
!     </para>
  
!     <programlisting><![CDATA[Session session = sf.openSession( new AuditInterceptor() );]]></programlisting>
  
  </chapter>
--- 975,985 ----
  }]]></programlisting>
  
!         <para>
!             The interceptor would be specified when a session is created.
!         </para>
  
!         <programlisting><![CDATA[Session session = sf.openSession( new AuditInterceptor() );]]></programlisting>
!     
!     </sect1>
  
  </chapter>