Well, if your ORM supports optimistic locking, then it's far simpler. You don't have to worry about session timeouts or deadlocks since there's no "lock" to clean up. The commit sql fails if someone else changes it first, and you can also write a recovery procedure if you want to try to handle the error transparently.
I am not 100% sure, but I think optimistic locking is supported as an optional add-on for JPA. I know it's supported in Cayenne classic (non-JPA). I think Hibernate supports a one-attribute versioning optimistic locking, although not full attribute optimistic locking, which is what I prefer. The downside of optimistic locking is that your ORM layer needs to keep a snapshot of the previous attribute values, which is harder to do if you're working with POJO entities (unless you go with the one-attribute versioning, but then you've added database overhead). On 10/30/07, Simon Kitching <[EMAIL PROTECTED]> wrote: > ---- ULA UVULA <[EMAIL PROTECTED]> schrieb: > > I have written a jsf application which is maintaining a java data structure > > (bean). (BTW: I never have written any jsp pages, I direct > > starting with jsf). > > > > Is there any way to inform the users that another user is already > > manipulating this structure? > > > > Workflow: > > a user can add/delete/edit/copy items into the data structure. After the > > work is finished, the user can > > "activate/save" his settings. During this time span, I want to lock the > > page for other users or at least I want to > > inform the second user, that another user is already active. > > The goal is to have consistency and not "last write wins". > > > > Can you also consider: what happens, if the first user is closing the > > web-browser without doing a "logoff" on the page? > > It's not an easy problem to solve AFAIK. > > The Java Persistence API (Hibernate, Toplink etc) provides "pessimistic > locking", where a version column exists on each table. When data is read, > this version# is also read. When data is written, if the version# has changed > then the write fails. This provides "first write wins" type functionality > rather than "last write wins". However it's still probably not what you want. > > I don't know of any other standard mechanism for doing what you want. You're > talking about "logically locking" an object over a number of requests (a > conversation). > > I would think the best thing to do is to have a separate "lock table", > containing columns > object-name > object-key > lock-expiry-time > owner > and inserting a row whenever someone starts editing a specific object. On > write, remove the row. Forbid starting an edit if there already exists a lock > entry with lock-expiry-time > now. > > Sounds fairly complicated though. It would indeed be nice if there was some > standard solution to this. Maybe such a thing would belong in Myfaces > Orchestra, as it really is conversation-related, but there is no such feature > yet. > > Regards, > > Simon >
