Thanks James and Marcus for your suggestions. I tried using detached objects and got the exception I was looking for. The problem is 1. we use the Hibernate session for object identity rather than defining equals() and hashCode() on all persisted objects, which is not conducive to using detached objects and 2. with the size and complexity of some of our objects, we try to avoid storing them into the web session.
I've got a hybrid solution working now where the property persistence strategy uses a datasqueezer to store just the object class, id, and now version into the web session between requests. Then on unsqueeze it compares the version on the squeezed string to the version of the object loaded from the database and records an error if there is a version conflict. Not the most efficient route but no worse than what we had. Session-per-conversation is probably the best long-term route but such a drastic change would have to wait until at least our next release cycle. Ben -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 10:54 PM To: 'Tapestry users' Subject: RE: [OT] Tapernate and Optimistic Locking Tapernate allows you to use detached objects and still enforce optimistic locking. You have to use @Persist("reattach-merge") so that Tapernate will try to merge() your object. If the object stored in the session has the old version number, you'll get the exception. -----Original Message----- From: Ben Dotte [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 6:24 PM To: Tapestry users Subject: [OT] Tapernate and Optimistic Locking Our Tapestry application is using Tapernate-like behavior to load persisted objects in automatically at the beginning of each request and now I've been asked to look into changing our database locking strategy from pessimistic to optimistic. I've tried versioning the objects as is suggested for Hibernate but the problem is I have no basis for comparison between versions since each object gets reloaded at the beginning of each request, and the StaleObjectStateException I am expecting never gets thrown. I can't figure out how optimistic locking would ever work unless you are using detached objects. Has anyone come across a good solution to this problem without resorting to detached objects? Thanks, Ben --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
