Open Stack

Excerpts from Jay Pipes's message of 2014-07-30 13:53:38 -0700:
> On 07/30/2014 12:21 PM, Kevin Benton wrote:
> > Maybe I misunderstood your approach then.
> >
> > I though you were suggesting where a node performs an "UPDATE record
> > WHERE record = last_state_node_saw" query and then checks the number of
> > affected rows. That's optimistic locking by every definition I've heard
> > of it. It matches the following statement from the wiki article you
> > linked to as well:
> >
> > "The latter situation (optimistic locking) is only appropriate when
> > there is less chance of someone needing to access the record while it is
> > locked; otherwise it cannot be certain that the update will succeed
> > because the attempt to update the record will fail if another user
> > updates the record first."
> >
> > Did I misinterpret how your approach works?
> 
> The record is never "locked" in my approach, why is why I don't like to 
> think of it as optimistic locking. It's more like "optimistic read and 
> update with retry if certain conditions continue to be met..." :)
> 
> To be very precise, the record is never locked explicitly -- either 
> through the use of SELECT FOR UPDATE or some explicit file or 
> distributed lock. InnoDB won't even hold a lock on anything, as it will 
> simply add a new version to the row using its MGCC (sometimes called 
> MVCC) methods.
> 
> The technique I am showing in the patch relies on the behaviour of the 
> SQL UPDATE statement with a WHERE clause that contains certain columns 
> and values from the original view of the record. The behaviour of the 
> UPDATE statement will be a NOOP when some other thread has updated the 
> record in between the time that the first thread read the record, and 
> the time the first thread attempted to update the record. The caller of 
> UPDATE can detect this NOOP by checking the number of affected rows, and 
> retry the UPDATE if certain conditions remain kosher...
> 
> So, there's actually no locks taken in the entire process, which is why 
> I object to the term optimistic locking :) I think where the confusion 
> has been is that the initial SELECT and the following UPDATE statements 
> are *not* done in the context of a single SQL transaction...
> 

This is all true at a low level Jay. But if you're serializing something
outside the DB by using the "doing it" versus "done it" state, it still
acts like a lock.