Re: changing multiple pk's in one update

On Mon, Apr 13, 2009 at 5:43 PM, Richard Broersma
 wrote:
> From what I've seen, this problem can affect both surrogate and
> natural key designs.  In both cases, care must be taken to ensure that
> an underling tuple hasn't been changed by any other clients before it
> attempts to commit its changed.   Probably the most common solution is
> to use optimistic locking, another solution that I know of is to use
> serialized transaction isolation.

Right, but if you have a delayed UI, you probably don't want to hold a
lock open--if the user is viewing "/100/3" and clicks "delete", you
need to make sure that the one you delete is the same /100/3 that the
user was viewing at the time.  That's harder to do...

-- 
Glenn Maynard