Re: deciding whether to do work in tpc_vote or tpc_finish

On 8 June 2010 14:38, Jim Fulton <[email protected]> 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
_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )