Open Stack

>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
another server.
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>
wrote:

> Hi everyone.
>
> I’ve recently found that straightforward use of NeutronDbObject is prone to
> concurrency-related problems.
>
> I’ve submitted a patch set [3] 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
> contextmanager
> 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
> object.
> 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
> with_for_update).
>
>    pros:
>      - the object is guaranteed to not be changed while within the context
>
>    cons:
>      - prone to deadlocks ([1] and potentially when locking multiple
> objects)
>
> 2. Lock-free CAS based on object version counter. Can use SqlAlchemy
> version
>    counter [2] or add our own. If conflicting changes are detected upon
> exiting
>    the context (i.e. version counter held differs from the one in the DB),
> will
>    raise OSLO RetryRequest exception.
>
>    pros:
>      - does not require locking
>
>    cons:
>      - require an additional field in the models
>
> While opt.2 only prevents the conflicting changes, but does not guarantee
> that
> 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
> changes
> 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
> idea.
>
> [1]
> https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#MySQLdb_.2B_eventlet_.3D_sad
> [2] http://docs.sqlalchemy.org/en/rel_0_9/orm/versioning.html
>
> [3] https://review.openstack.org/#/c/315705/
>
> --
> Thanks,
> Ilya
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160513/517cba51/attachment.html>