Re: [SQLObject] collision detection strategy

[Bud P. B. <bu...@si...>]

On 21 May 2003 01:20:02 +0100
Matt Goodall <ma...@po...> wrote:

> Unless the check is done during the update then there is no way to
> guarantee that the optimistic lock is honoured. Unless, that is, the
> object's row is locked using "select ... for update" (or something
> similar) just before the update.

It seems that in the case of a single process application (possibly
multi-threaded), the locking could move from the dbms to the
middle-layer.  But this is not valid for all cases and to me it seems
that (optimistic) locking in the dbms is easier and more general...

At least in web apps, select .. for update seems to be problematic
since a client may die away after locking without ever committing a
change....  So there must be timeouts, administration, etc.  Ugh...

Also, if one would select for update just before committing a change,
the client app could still die in the meantime (even if it's shorter)
and at that point one basically has nothing more than optimistic
locking...

So it seems (as you have said for web apps) that optimistic locking is
the only way..

--b