Comment 9 for bug 1328983

So based on Steve's work, it appears our best guess at the problem is this:

* SQLAlchemy marks a transaction as COMMITTED at some point _before_ it completes processing of the commit().
* If an exception (in this case GreenletExit) is raised during the commit(), SQLAlchemy attempts to rollback the transaction.
* If the exception occurs after the transaction state has changed to COMMITTED, the rollback() fails with this error.

So this is a somewhat artificial problem, in that it's triggered by the timing of Tempest sending multiple delete calls to a stack that contains no resources. The proposed solution is equally artificial and just adds a delay to prevent that case.

This is probably the right way to go *assuming* that we are not missing out on any important operations by cancelling the commit() operation (albeit after the state has reached COMMITTED) without attempting a rollback. This is a question we need to take up with the SQLAlchemy folks.