[Hibernate-commits] Hibernate2/doc/reference/src manipulating_data.xml,1.6,1.7 session_configuration.xml,1.9,1.10

[<one...@us...>]

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

Modified Files:
	manipulating_data.xml session_configuration.xml 
Log Message:
documented some newer features

Index: manipulating_data.xml
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/src/manipulating_data.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** manipulating_data.xml	12 Apr 2003 03:14:11 -0000	1.6
--- manipulating_data.xml	22 Apr 2003 11:11:35 -0000	1.7
***************
*** 649,656 ****
  
          <para>
!             From time to time the <literal>Session</literal> will execute the
!             SQL statements needed to synchronize the JDBC connection's state with the state
!             of held in memory. This process, <emphasis>flush</emphasis>, occurs at the
!             following points:
          </para>
  
--- 649,656 ----
  
          <para>
!             From time to time the <literal>Session</literal> will execute the SQL statements 
!             needed to synchronize the JDBC connection's state with the state of objects held in 
!             memory. This process, <emphasis>flush</emphasis>, occurs by default at the following 
!             points
          </para>
  
***************
*** 726,738 ****
  
          <para>
!             If you happen to know that a particular <literal>find()</literal>
!             or <literal>iterate()</literal> query does <emphasis>not</emphasis> require that 
!             the <literal>Session</literal> be flushed beforehand, it is possible to override 
!             the default behavior using <literal>Session.suspendFlushes()</literal> and
!             <literal>Session.resumeFlushes()</literal>. Judicious usage might improve 
!             performance of some transactions. However, the session is now very clever about 
!             when it flushes before queries.
          </para>
!         
      </sect1>
  
--- 726,745 ----
  
          <para>
!             It is possible to change the default behavior so that flush occurs less frequently.
!             The <literal>FlushMode</literal> class defines three different modes. This is most
!             useful in the case of "readonly" transactions, where it might be used to achieve a
!             (very) slight performance increase.
          </para>
! 
!         <programlisting><![CDATA[sess = sf.openSession();
! Transaction tx = sess.beginTransaction();
! sess.setFlushMode(FlushMode.COMMIT); //allow queries to return stale state
! Cat izi = (Cat) sess.load(Cat.class, id);
! izi.setName(iznizi);
! // execute some queries....
! sess.find("from Cat as cat left outer join cat.kittens kitten"); //change to izi is not flushed!!
! ....
! tx.commit(); //flush occurs]]></programlisting>
! 
      </sect1>
  
***************
*** 908,915 ****
--- 915,951 ----
  
          </sect2>
+         
      
      </sect1>
  
      <sect1 id="manipulating-data-s14">
+         <title>Managing the Session Cache</title>
+         <para>
+             Whenever you pass an object to <literal>save()</literal>, <literal>update()</literal>
+             or <literal>saveOrUpdate()</literal> and whenever you retrieve an object using 
+             <literal>load()</literal>, <literal>find()</literal>, <literal>iterate()</literal>,
+             or <literal>filter()</literal>, that object is added to the internal cache of the
+             <literal>Session</literal>. When <literal>flush()</literal> is subsequently called,
+             the state of that object will be synchronized with the database. If you do not want
+             this synchronization to occur or if you are processing a huge number of objects and
+             need to manage memory efficiently, the <literal>evict()</literal> method may be
+             used to remove the object and its collections from the cache.
+         </para>
+         
+         <programlisting><![CDATA[Iterator cats = sess.iterate("from eg.Cat as cat"); //a huge result set
+ while ( cats.hasNext() ) {
+     Cat cat = (Cat) iter.next();
+     doSomethingWithACat(cat);
+     sess.evict(cat);
+ }]]></programlisting>
+         
+         <para>
+             The <literal>Session</literal> also provides a <literal>contains()</literal> method
+             to determine if an instance belongs to the session cache.
+         </para>
+         
+     </sect1>
+     
+     <sect1 id="manipulating-data-s15">
          <title>Interceptors</title>
          <para>

Index: session_configuration.xml
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/src/session_configuration.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** session_configuration.xml	12 Apr 2003 03:14:11 -0000	1.9
--- session_configuration.xml	22 Apr 2003 11:11:36 -0000	1.10
***************
*** 416,419 ****
--- 416,433 ----
                      <row>
                          <entry>
+                             <literal>hibernate.cglib.use_reflection_optimizer</literal>
+                         </entry>
+                         <entry>
+                             Enables use of CGLIB instead of runtime reflection (default
+                             is to use CGLIB where possible). Reflection can sometimes
+                             be useful when troubleshooting.
+                             <para>
+                                 <emphasis role="strong">Value:</emphasis> 
+                                 <literal>true</literal> | <literal>false</literal>
+                             </para>
+                         </entry>
+                     </row>
+                     <row>
+                         <entry>
                              <literal>hibernate.connection.provider_class</literal>
                          </entry>