On 8 June 2010 14:38, Jim Fulton <jim@zope.com> wrote:
This is intended as a broad response to the thread, rather than a response to any specific post. :)
I've been thinking of expanding the data manager API to add an optional tpc_rollback method. If tpc_finish returns a value and a data manager provided tpc_rollback and some other data manager fails in tpc_finish, then tpc_rollback would be used to *try* to recover from the other data managers failure. Note that even if tpc_rollback is implemented, it might fail if the transaction can't be rolled back (due, typically, to subsequent conflicting transactions).
While I can imagine a ZODB implementation of tpc_rollback that could work in some circumstances for some storages, even then it seems it would be quite complex and perhaps unlikely to succeed - as soon as another connection read anything from the database you would be unable to tpc_rollback, unless you deferred truly committing the transaction to a tpc_truly_finished which would just bring you back where you started. For other systems I can't think how it might be implemented - you can't unsend a mail or uncommit a committed transaction in a relational database. Laurence