...
3. At the end of step 1, the Hibernate Session is stored in the user's HttpSession. The Hibernate Session remains active for the entire "conversation" - this technique is described as "session-per-conversation". Step 2 would retrieve the Hibernate Session from the user's HttpSession and all domain objects associated with the Hibernate Session in step 1 would be available to step 2. In this approach, it would be essential for the end of step 1 to disconnect the JDBC connection; and for the beginning of step 2 to establish a new JDBC connection.
Chosen Solution
For Education Systems web apps we have decided to use detection option 1 - passing the version number to the JSP in the GET request, and moving the version number into the retrieved Hibernate entity during the POST request. Hibernate itself will then take care of checking version number on update. If a concurrency problem is encountered, Spring should throw a org.springframework.orm.hibernate3.HibernateOptimisticLockingFailureException. This exception should be intercepted by the web app and an appropriate UI action should take place (for example, forwarding to an error page, or displaying a message on the current page).
There is a simple web app demonstrating this scheme. It uses an in-memory H2 database so should be self-contained :
svn+ssh://svn.mit.edu/csf-playground/web-concurrency
| Wiki Markup |
|---|
Also there is a non-web project that uses a unit test \[TestConcurrency.testConcurrentUpdate()\] to illustrate the concurrent update situation: |
svn+ssh://svn.mit.edu/csf-playground/hibernate-concurrency
Further Reading
Some useful information is available here:
...