Open Stack

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 <carl at ecbaldwin.net> wrote:

> On Tue, Jun 16, 2015 at 2:18 PM, Salvatore Orlando <sorlando at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/9429390a/attachment.html>