[openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues
kevin at benton.pub
Fri May 13 09:04:40 UTC 2016
>While opt.2 only prevents the conflicting changes, but does not guarantee
that the object does not change while within the context,
I'm not sure what you mean here. In a multi-writer galera cluster both
SELECT FOR UPDATE and CAS won't fail until commit time if someone writes to
So the DB lock only provides the conflicting change guarantee in a
single-writer mysql setup.
On Thu, May 12, 2016 at 11:26 AM, Ilya Chukhnakov <ichukhnakov at mirantis.com>
> Hi everyone.
> I’ve recently found that straightforward use of NeutronDbObject is prone to
> concurrency-related problems.
> I’ve submitted a patch set  with some tests to show that without special
> treatment using NeutronDbObject could lead to unexpected results.
> Further patch sets will provide acquire_object/acquire_objects
> methods to the NeutronDbObject class. These methods are to be used in
> place of
> get_object/get_objects whenever the user intends to make changes to the
> These methods would start an autonested_transaction.
> There are (at least) two potential options for the implementation:
> 1. Based on the DB locks (e.g. SELECT FOR UPDATE/SqlAlchemy
> - the object is guaranteed to not be changed while within the context
> - prone to deadlocks ( and potentially when locking multiple
> 2. Lock-free CAS based on object version counter. Can use SqlAlchemy
> counter  or add our own. If conflicting changes are detected upon
> the context (i.e. version counter held differs from the one in the DB),
> raise OSLO RetryRequest exception.
> - does not require locking
> - require an additional field in the models
> While opt.2 only prevents the conflicting changes, but does not guarantee
> the object does not change while within the context, opt.1 may seem
> preferential. But even with opt.1 the user should not expect that the
> made to the object while within the context will get to the database as the
> autonested_transaction could fail on flush/commit.
> So I’d like to hear others’ opinion on the problem and which of the two
> implementation options would be preferred? Or maybe someone has a better
>  http://docs.sqlalchemy.org/en/rel_0_9/orm/versioning.html
>  https://review.openstack.org/#/c/315705/
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev