Open Stack

> I'd have to look at the Neutron code, but I suspect that a simple
> strategy of issuing the UPDATE SQL statement with a WHERE condition that

I¹m assuming the locking is for serializing code, whereas for what you
describe above, is there some reason we wouldn¹t just use a transaction?

Thanks,
doug



On 7/30/14, 9:41 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:

>There's also no need to use locks at all for this (distributed or
>otherwise).
>
>You can use a compare and update strategy with an exponential backoff
>similar to the approach taken here:
>
>https://review.openstack.org/#/c/109837/
>
>I'd have to look at the Neutron code, but I suspect that a simple
>strategy of issuing the UPDATE SQL statement with a WHERE condition that
>is constructed to take into account the expected current record state
>would do the trick...
>
>Best,
>-jay
>
>On 07/30/2014 09:33 AM, Clint Byrum wrote:
>> Please do not re-invent locking.. the way we reinvented locking in Heat.
>> ;)
>>
>> There are well known distributed coordination services such as Zookeeper
>> and etcd, and there is an abstraction for them already called tooz:
>>
>> https://git.openstack.org/cgit/stackforge/tooz/
>>
>> Excerpts from Elena Ezhova's message of 2014-07-30 09:09:27 -0700:
>>> Hello everyone!
>>>
>>> Some recent change requests ([1], [2]) show that there is a number of
>>> issues with locking db resources in Neutron.
>>>
>>> One of them is initialization of drivers which can be performed
>>> simultaneously by several neutron servers. In this case locking is
>>> essential for avoiding conflicts which is now mostly done via using
>>> SQLAlchemy's
>>> with_lockmode() method, which emits SELECT..FOR UPDATE resulting in
>>>rows
>>> being locked within a transaction. As it has been already stated by
>>>Mike
>>> Bayer [3], this statement is not supported by Galera and, what¹s more,
>>>by
>>> Postgresql for which a lock doesn¹t work in case when a table is empty.
>>>
>>> That is why there is a need for an easy solution that would allow
>>> cross-server locking and would work for every backend. First thing that
>>> comes into mind is to create a table which would contain all locks
>>>acquired
>>> by various pieces of code. Each time a code, that wishes to access a
>>>table
>>> that needs locking, would have to perform the following steps:
>>>
>>> 1. Check whether a lock is already acquired by using SELECT lock_name
>>>FROM
>>> cross_server_locks table.
>>>
>>> 2. If SELECT returned None, acquire a lock by inserting it into the
>>> cross_server_locks table.
>>>
>>>     In other case wait and then try again until a timeout is reached.
>>>
>>> 3. After a code has executed it should release the lock by deleting the
>>> corresponding entry from the cross_server_locks table.
>>>
>>> The locking process can be implemented by decorating a function that
>>> performs a transaction by a special function, or as a context manager.
>>>
>>> Thus, I wanted to ask the community whether this approach deserves
>>> consideration and, if yes, it would be necessary to decide on the
>>>format of
>>> an entry in cross_server_locks table: how a lock_name should be formed,
>>> whether to support different locking modes, etc.
>>>
>>>
>>> [1] https://review.openstack.org/#/c/101982/
>>>
>>> [2] https://review.openstack.org/#/c/107350/
>>>
>>> [3]
>>> 
>>>https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#Pessimistic_Loc
>>>king_-_SELECT_FOR_UPDATE
>>
>> _______________________________________________
>> 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