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:

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]
> [2]
> [3]

OpenStack-dev mailing list

Reply via email to