There seems to be confusion on what causes deadlocks. Can one of you explain to me how an optimistic locking strategy (a.k.a. compare-and-swap) results in deadlocks?
Take the following example where two workers want to update a record: Worker1: "UPDATE items set value=newvalue1 where value=oldvalue" Worker2: "UPDATE items set value=newvalue2 where value=oldvalue" Then each worker checks the count of rows affected by the query. The one that modified 1 gets to proceed, the one that modified 0 must retry. Do those statements also risk throwing deadlock exceptions? If so, why? I haven't seen a clear article explaining deadlock conditions not related to "FOR UPDATE". On Tue, Jun 16, 2015 at 4:01 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > On Tue, Jun 16, 2015 at 2:18 PM, Salvatore Orlando <sorla...@nicira.com> > wrote: > > But zzzeek (Mike Bayer) is coming to our help; as a part of his DBFacade > > work, we should be able to treat active/active cluster as active/passive > for > > writes, and active/active for reads. This means that the write set > > certification issue just won't show up, and the benefits of active/active > > clusters will still be attained for most operations (I don't think > there's > > any doubt that SELECT operations represent the majority of all DB > > statements). > > Okay, so we stop worrying about the write certification failures? > Lock for update would work as expected? That would certainly simplify > the Galera concern. Maybe everyone already knew this and I have just > been behind on the latest news again. > > > DBDeadlocks without multiple workers also suggest we should look closely > at > > what eventlet is doing before placing the blame on pymysql. I don't think > > that the switch to pymysql is changing the behaviour of the database > > interface; I think it's changing the way in which neutron interacts to > the > > database thus unveiling concurrency issues that we did not spot before > as we > > were relying on a sort of implicit locking triggered by the fact that > some > > parts of Mysql-Python were implemented in C. > > ++ > > Carl > > __________________________________________________________________________ > 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 > -- Kevin Benton
__________________________________________________________________________ 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
