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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev