Open Stack

>In a multi-writer galera cluster both SELECT FOR UPDATE and CAS won't fail until commit time

Good point, I did not consider multi-writer. But anyway, my point was that opt.2 is no worse than opt.1.


> On 13 May 2016, at 12:04, Kevin Benton <kevin at benton.pub> wrote:
> 
> >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 <mailto: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 <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 <http://docs.sqlalchemy.org/en/rel_0_9/orm/versioning.html>
> 
> [3] https://review.openstack.org/#/c/315705/ <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __________________________________________________________________________
> 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/74342a78/attachment.html>