>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 <ke...@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 <ichukhna...@mirantis.com > <mailto:ichukhna...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
