On Mon, Apr 13, 2009 at 5:43 PM, Richard Broersma
<richard.broersma@gmail.com> 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
