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 <jaypi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
