[openstack-dev] [neutron] Cross-server locking for neutron server

Kevin Benton blak111 at gmail.com
Wed Jul 30 19:21:59 UTC 2014


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?


On Wed, Jul 30, 2014 at 11:07 AM, Jay Pipes <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
>>
>
> 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)
>
> And what I am describing is not optimistic lock concurrency in databases.
>
> -jay
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/2c9f5e6b/attachment.html>


More information about the OpenStack-dev mailing list