Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/a6ceded2/attachment.html>