i.e. 'optimistic locking' as opposed to the 'pessimistic locking' referenced in the 3rd link of the email starting the thread. On Wed, Jul 30, 2014 at 9:55 AM, Jay Pipes <jaypipes at gmail.com> wrote: > 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 > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/d73c4205/attachment.html>