Comment 5 for bug 1040694

I think part of the topic here is that there are two ways I've proposed of retrying transactions. The simple, easy and boring one we have is the wrap_db_retry() decorator. The other one is an exotic event-based approach I did for a client, which I feel is pretty experimental which is over at https://bitbucket.org/zzzeek/sqlalchemy/issue/3104/transaction-replay-extension , the attached patch is already in production elsewhere. The experimental design actually records all the SQL as the transaction proceeds, intercepts a selected set of exceptions as "good for retry" and then replays a subset of that SQL back, namely the DML. This is a very exotic way to go as it makes a lot of assumptions that those same INSERT/UPDATE/DELETE statements are still valid, even though we're in a new transaction.

I have a notion that we should ultimately have all methods that start using a database transaction wrapped in a decorator that establishes this context. The retry of the whole method should probably be rolled into that decorator.