<div dir="ltr">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?<div><br></div><div>Take the following example where two workers want to update a record:<br><div><br></div><div>Worker1: "UPDATE items set value=newvalue1 where value=oldvalue"</div><div>Worker2: "UPDATE items set value=newvalue2 where value=oldvalue"</div></div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 4:01 PM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jun 16, 2015 at 2:18 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
> But zzzeek (Mike Bayer) is coming to our help; as a part of his DBFacade<br>
> work, we should be able to treat active/active cluster as active/passive for<br>
> writes, and active/active for reads. This means that the write set<br>
> certification issue just won't show up, and the benefits of active/active<br>
> clusters will still be attained for most operations (I don't think there's<br>
> any doubt that SELECT operations represent the majority of all DB<br>
> statements).<br>
<br>
</span>Okay, so we stop worrying about the write certification failures?<br>
Lock for update would work as expected?  That would certainly simplify<br>
the Galera concern.  Maybe everyone already knew this and I have just<br>
been behind on the latest news again.<br>
<span class=""><br>
> DBDeadlocks without multiple workers also suggest we should look closely at<br>
> what eventlet is doing before placing the blame on pymysql. I don't think<br>
> that the switch to pymysql is changing the behaviour of the database<br>
> interface; I think it's changing the way in which neutron interacts to the<br>
> database thus unveiling concurrency issues that we did not spot before as we<br>
> were relying on a sort of implicit locking triggered by the fact that some<br>
> parts of Mysql-Python were implemented in C.<br>
<br>
</span>++<br>
<div class="HOEnZb"><div class="h5"><br>
Carl<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>