Open Stack

In fact there are more applications for distributed locking than just
accessing data in database.
One of such use cases is serializing access to devices.
This is what is not yet hardly needed, but will be as we get more service
drivers working with appliances.

It would be great if some existing library could be adopted for it.

Thanks,
Eugene.


On Thu, Jul 31, 2014 at 12:53 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/af7110da/attachment.html>