Comment 9 for bug 504291

afterCall() only gets called when things are succeeding. If an exception is raised, we go to handleException which is much more complex and relies on a fair bit of code not raising exceptions before the transaction.abort() is finally called.

I think the best way to proceed is add cope *at the start* of endRequest in canonical.launchpad.webapp.publication to detect stores in a disconnected state and call rollback() on them, raising an exception or logging a soft oops. This should let us track down the code path that leaves our stores in a disconnected state.