[Hibernate-commits] Hibernate2/doc/reference/html_single index.html,1.2,1.3

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

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

Modified Files:
	index.html 
Log Message:
fixed dialect class names

Index: index.html
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/html_single/index.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** index.html	28 Jan 2003 13:25:10 -0000	1.2
--- index.html	2 Feb 2003 07:02:31 -0000	1.3
***************
*** 75,86 ****
                      <tt>foo==bar</tt>
                  </td></tr></table><p>
!             Then for objects returned by a <span class="emphasis"><i>particular</i></span> <tt>Session</tt>, 
!             the two notions are equivalent. However, while the application might concurrently access 
              the "same" (persistent identity) business object in two different sessions, the two
              instances will actually be "different" (JVM identity).
          </p><p>
!             This approach leaves Hibernate and the database to worry about concurrency (the 
              application never needs to synchronize on any business object, as long as it sticks to a
!             single thread per <tt>Session</tt>) or object identity (within a session the 
[...2864 lines suppressed...]
!                     particular transaction.
                  </p></dd><dt><span class="term">In a three tiered architecture, consider using <tt>saveOrUpdate()</tt>.</span></dt><dd><p>
                      When using a servlet / session bean architecture, you could pass persistent objects loaded in
!                     the session bean to and from the servlet / JSP layer. Use a new session to service each request.
!                     Use <tt>Session.update()</tt> or <tt>Session.saveOrUpdate()</tt> to update the
                      persistent state of an object.
                  </p></dd><dt><span class="term">In a two tiered architecture, consider using session disconnection.</span></dt><dd><p>
***************
*** 3312,3316 ****
                      remember to disconnect the session before returning control to the client.
                  </p></dd><dt><span class="term">Don't treat exceptions as recoverable.</span></dt><dd><p>
!                     This is more of a necessary paractice than a "best" practice. When an exception occurs, roll back 
                      the <tt>Transaction</tt> and close the <tt>Session</tt>. If you don't, Hibernate
                      can't guarantee that in-memory state accurately represents persistent state
--- 3312,3316 ----
                      remember to disconnect the session before returning control to the client.
                  </p></dd><dt><span class="term">Don't treat exceptions as recoverable.</span></dt><dd><p>
!                     This is more of a necessary paractice than a "best" practice. When an exception occurs, roll back
                      the <tt>Transaction</tt> and close the <tt>Session</tt>. If you don't, Hibernate
                      can't guarantee that in-memory state accurately represents persistent state