Laurence Rowe wrote:
On 8 June 2010 12:59, Chris Withers <chris@simplistix.co.uk> wrote:
Laurence Rowe wrote:
it fails you will end up in an inconsistent state whatever. It's just that with the maildir implementation, it pretty much can't fail as it is only a rename and that should always succeed. Really, it should register as an after commit hook instead. How do I do that?
transaction.get().addAfterCommitHook(callable, args, kwargs)
Hmm, I realised from looking at the code this morning that this won't. The reason being that there's no equivalent AfterAbortHook where I can abort the messaging transaction in the event of transaction-package transaction abort. I see these things called "synchronizers", though... what are they and what is their intended purpose? Where are they documented?
My other thought was to have it commit the message send in tpc_vote, and make sure it sorts before zope.sqlalchemy. That way, if the message send fails, the "transaction" will be aborted, and that will include rolling back the zope.sqlalchemy session rather than committing it.
In that case if the sqlalchemy commit fails, you still sent the message.
Yeah, I guess given that, of the possible failure modes, I'd prefer the message not to be sent in the event of sqlalchemy commit failure, I should have it sort after sqlalchemy... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk