> I'd have to look at the Neutron code, but I suspect that a simple > strategy of issuing the UPDATE SQL statement with a WHERE condition that
I¹m assuming the locking is for serializing code, whereas for what you describe above, is there some reason we wouldn¹t just use a transaction? Thanks, doug On 7/30/14, 9:41 AM, "Jay Pipes" <jaypi...@gmail.com> wrote: >There's also no need to use locks at all for this (distributed or >otherwise). > >You can use a compare and update strategy with an exponential backoff >similar to the approach taken here: > >https://review.openstack.org/#/c/109837/ > >I'd have to look at the Neutron code, but I suspect that a simple >strategy of issuing the UPDATE SQL statement with a WHERE condition that >is constructed to take into account the expected current record state >would do the trick... > >Best, >-jay > >On 07/30/2014 09:33 AM, Clint Byrum wrote: >> 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_Loc >>>king_-_SELECT_FOR_UPDATE >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
