On 10/31/07, Simon Kitching <[EMAIL PROTECTED]> wrote: > [AARGH- I hate top-posting!]
I know you hate top-posting, but I like it :-) > 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..) Sure. Instead of creating and locking on a special version field, lock on all fields (or all that are important). Assuming table foo[w,x,y,z], use "update foo set x=1, y=1 where w=old_w, x=old_x, y=old_y, z=old_z" > 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. You could be right about two issues. I may not have read it closely enough. If so, addressing the second forces pessimistic locking, and requires cleanup of locks. The pitfalls are many and numerous, and I'm sure there are better descriptions of how to solve it than can be communicated on the MyFaces mailing list, since there's nothing JSF-specific about it.
