Open Stack

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