<div dir="ltr">Hi neutron folks,<div><br></div><div>There is an ongoing effort to refactor some neutron DB logic to be compatible with galera/mysql which doesn't support locking (with_lockmode('update')).</div><div><br></div><div>Some code paths that used locking in the past were rewritten to retry the operation if they detect that an object was modified concurrently.</div><div>The problem here is that all DB operations (CRUD) are performed in the scope of some transaction that makes complex operations to be executed in atomic manner.</div><div>For mysql the default transaction isolation level is 'REPEATABLE READ' which means that once the code issue a query within a transaction, this query will return the same result while in this transaction (e.g. the snapshot is taken by the DB during the first query and then reused for the same query).</div><div>In other words, the retry logic like the following will not work:</div><div><br></div><div>def allocate_obj():</div><div>    with session.begin(subtrans=True):</div><div>         for i in xrange(n_retries):</div><div>              obj = session.query(Model).filter_by(filters)</div><div>              count = session.query(Model).filter_by(id=<a href="http://obj.id">obj.id</a>).update({'allocated': True})</div><div>              if count:</div><div>                   return obj</div><div><br></div><div>since usually methods like allocate_obj() is called from within another transaction, we can't simply put transaction under 'for' loop to fix the issue.</div><div><br></div><div>The particular issue here is <a href="https://bugs.launchpad.net/neutron/+bug/1382064">https://bugs.launchpad.net/neutron/+bug/1382064</a> with the proposed fix: </div><div><a href="https://review.openstack.org/#/c/129288">https://review.openstack.org/#/c/129288</a><br></div><div><br></div><div>So far the solution proven by tests is to change transaction isolation level for mysql to be 'READ COMMITTED'. </div><div>The patch suggests changing the level for particular transaction where issue occurs (per sqlalchemy, it will be reverted to engine default once transaction is committed)</div><div>This isolation level allows the code above to see different result in each iteration.</div><div>At the same time, any code that relies that repeated query under same transaction gives the same result may potentially break.</div><div><br></div><div>So the question is: what do you think about changing the default isolation level to READ COMMITTED for mysql project-wise?</div><div>It is already so for postgress, however we don't have much concurrent test coverage to guarantee that it's safe to move to a weaker isolation level.</div><div><br></div><div>Your feedback is appreciated.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div>