Re: [SQLObject] collision detection strategy

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

Thanks, Luke.

and here some reactions from an equally fried bains..

On Tue, 20 May 2003 17:57:52 -0500
Luke Opperman <lu...@me...> wrote:

> Bud -
> 
> Your example appears to me to be optimistic row-level locking, straight
> forward. At first glance it seems like a reasonable implementation, although
> the big question with optimistic/detection schemes is how do you recover? I
> generally think this needs to be at the programmer's discretion, both for
> recovery method (typically overwrite or exception in my experience) and for
> scope (for X transaction, is attribute-level reasonable?)

Definitely a difficult question!  I will first opt for simple
exception...

> The other thought I'm having right now is that SQLObject seems to simplify
> some of this if you're using cached objects, because now there is only one
> possible object, so it's all on the python side to deal with locking as the
> developer sees fit. but I haven't entirely thought this through.

This is true if there is a single cache, ie. a single interpreter.
But I'll likely run in a multi-process and possibly multi-machine
environment...  Keeping a cache coherent in a distributed setting is
probably a non-trivial task..

One thing I've thought of is to funnel all write activity into a
single process...  Not sure how difficult this is..

But I think I'll keep it simple for starters..

> Also, transactions or otherwise, it would seem that with cached objects it
> would be possible to support setting and managing what level of locking is
> appropriate on a class(table) or instance(row) or attribute level basis.

I have looked at the concurrancy control doc of PostgreSQL and am
quite impressed.  If I wasn't too tired to understand, they decide on
the "separation level" per transaction (not per table or instance...).  


cheers
-b