Update of /cvsroot/hibernate/Hibernate2/doc/reference/html_single
In directory sc8-pr-cvs1:/tmp/cvs-serv9746/reference/html_single
Modified Files:
index.html
Log Message:
documented latest QL changes
Index: index.html
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/html_single/index.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** index.html 2 Mar 2003 13:59:01 -0000 1.5
--- index.html 3 Mar 2003 01:07:03 -0000 1.6
***************
*** 63,74 ****
<tt class="literal">foo==bar</tt>
</p></dd></dl></div><p>
! Then for objects returned by a <span class="emphasis"><em>particular</em></span> <tt class="literal">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 class="literal">Session</tt>) or object identity (within a session the
[...3099 lines suppressed...]
! particular transaction.
</p></dd><dt><span class="term">In a three tiered architecture, consider using <tt class="literal">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 class="literal">Session.update()</tt> or <tt class="literal">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>
***************
*** 3461,3465 ****
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 class="literal">Transaction</tt> and close the <tt class="literal">Session</tt>. If you don't, Hibernate
can't guarantee that in-memory state accurately represents persistent state
--- 3457,3461 ----
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 class="literal">Transaction</tt> and close the <tt class="literal">Session</tt>. If you don't, Hibernate
can't guarantee that in-memory state accurately represents persistent state
|
