[AARGH- I hate top-posting!] oops..when I wrote "pessimistic locking", I meant "optimistic locking"..sorry.
Mike, I'm curious about this "full attribute optimistic locking" you mention. I know only JPA/hibernate's version that you don't seem so keen on. In that case, just a "version" field is remembered for each object, and an update does (roughly): update foo set x=1, y=1, version=35 where somekey=someval and version=34 This means that an update fails if the record has been updated by someone else since it was read (because version is no longer 34). The failure to update then causes an exception to be thrown. Is it possible to describe "full attribute optimistic locking" in a couple of sentences, or should I look at the cayenne docs? (A quick google didn't show anything obviously related..) NB: the original question had (I think) two parts: (1) how to avoid "last editor overwrites first editor" and (2) how to tell a user that the records are "reserved for edit" by someone else, rather than letting the second person edit them then failing on save. Optimistic locking solves the first, but not the second. Simon -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? ---- Mike Kienenberger <[EMAIL PROTECTED]> schrieb: > Well, if your ORM supports optimistic locking, then it's far simpler. > I think Hibernate supports a one-attribute versioning > optimistic locking, although not full attribute optimistic locking, > which is what I prefer. > On 10/30/07, Simon Kitching <[EMAIL PROTECTED]> wrote: > > The Java Persistence API (Hibernate, Toplink etc) provides "pessimistic > > locking", where a version column exists on each table.
