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