Re: [SQLObject] collision detection strategy

[Ian B. <ia...@co...>]

On Tue, 2003-05-20 at 19:20, Matt Goodall wrote:
> > For instance, with the timestamp, what is the object's starting point? 
> > Let's say you do:
> > 
> > obj = Something(someID) # op A
> > x = obj.a               # op B
> > y = obj.a               # op C
> > obj.a = x + 10          # op D
> > 
> > What is the concurrency expectation?  I.e., when is does optimistic
> > locking fail?  All of A, B, and C are potential times when the timestamp
> > could be fetched from the database.
> 
> I may be missing something obvious but why would reading the timestamp
> ever make an opt lock fail? The only time it matters is when the
> database is updated isn't it?

It's a question of: supposing someone changes the row between A and D,
should it fail?  B and D?  C and D?  It could be implemented any of
those ways (well, between B and D would require more code than I show
there), or in an entirely different way.  Using optimistic locking, it
kind of boils down to when the timestamp was last retrieved from the
database.

As for what you want, any of those options is a valid programming
decision.  Maybe obj.a is dependent on other attributes, or other
objects entirely, so A and D is right.  Maybe you just want to make sure
you've incremented it by 10, so B and D is right.  Maybe you do your own
consistency checking of x and y, so C to D is all that's necessary. 
Some sort of annotation is necessary.

> > So if we have to be explicit about locking, how do we express that?  How
> > do you say what you are locking?  Columns, rows, tables?  All are valid
> > options, and none particularly more difficult than the others.
> 
> Agh! Not table locking, please! The MySQL manual is the only place that
> sort of talk is acceptable ;-).
> 
> I would imagine optimistic locking would take place at the object level
> which generally means row level in the database.

Given a locking interface, it shouldn't be hard to implement other
locking (no one will force you to use it :).  Locking on timestamps or
other IDs is the most difficult, so if we do that there's no reason we
can't do the other locking too.

  Ian