On Mon, Apr 13, 2009 at 5:43 PM, Richard Broersma <richard.broer...@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 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
