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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev