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
