Open Stack

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...

Best,
-jay

> On Wed, Jul 30, 2014 at 11:07 AM, Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>
>     On 07/30/2014 10:53 AM, Kevin Benton wrote:
>
>         Using the UPDATE WHERE statement you described is referred to as
>         optimistic locking. [1]
>
>         https://docs.jboss.org/__jbossas/docs/Server___Configuration_Guide/4/html/__The_CMP_Engine-Optimistic___Locking.html
>         <https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/The_CMP_Engine-Optimistic_Locking.html>
>
>
>     SQL != JBoss.
>
>     It's not optimistic locking in the database world. In the database
>     world, optimistic locking is an entirely separate animal:
>
>     http://en.wikipedia.org/wiki/__Lock_(database)
>     <http://en.wikipedia.org/wiki/Lock_(database)>
>
>     And what I am describing is not optimistic lock concurrency in
>     databases.
>
>     -jay
>
>
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> --
> Kevin Benton
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>