-----Original Message----- From: Jay Pipes <jaypi...@gmail.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>> Date: July 30, 2014 at 09:59:15 To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron] Cross-server locking for neutron server
> On 07/30/2014 09:48 AM, Doug Wiegley wrote: > >> 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? > > Because you can't do a transaction from two different threads... > > The compare and update strategy is for avoiding the use of SELECT FOR > UPDATE. > > Best, > -jay As a quick example of the optimistic locking you describe (UPDATE with WHERE clause) you can take a look at the Keystone “consume trust” logic: https://review.openstack.org/#/c/97059/14/keystone/trust/backends/sql.py Line 93 does the initial query, an update is performed then on line 108 and 115 we do the update and check to see how many rows were affected. Feel free to hit me up if I can help in any way on this. Cheers, Morgan — Morgan Fainberg _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
