I've looked at https://review.openstack.org/#/c/16596/, and I agree we need to do the same in Quantum. Salvatore On 3 December 2012 22:18, gong yong sheng <gongysh at linux.vnet.ibm.com> wrote: > It seems easy to fix it. > > On 12/04/2012 06:03 AM, Nachi Ueno wrote: > > Hi Quantum folks > > This bp for nova looks like solve the quantum one also. > https://blueprints.launchpad.net/nova/+spec/non-blocking-db > > > 2012/12/3 Nachi Ueno <nachi at nttmcl.com> >> >> Hi Quantum folks >> >> I faced the problem with mysql transaction and eventlet. >> >> Quantum using transaction support of sqlalchemy >> Quantum also using eventlet for RPC >> >> Let's say there are api request A and B. >> Sql request of A will lock B's sql request. >> so B's sql request will wait the A's transaction. >> >> On the other hand, we are using evenetlet. >> Since we are using mysql c client, the API request may block eventlet >> thread. >> >> so when B start wait sql lock, it blocks all eventlet thread including api >> request A until lock timeout. >> >> I asked Jay about the this problem, and he said Nova solve this problem by >> this way. >> >> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2610 >> >> The strategy is to get lock just after the transaction started using. ( >> I'm not sure we can use same strategy in the quantum. ) >> >> Anyway, It looks big change needed for me. > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >