Open Stack

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