On Tue, Jun 8, 2010 at 1:00 PM, Laurence Rowe <l...@lrowe.co.uk> wrote:
> On 8 June 2010 14:38, Jim Fulton <j...@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.

No. It would behave exactly like (probably built on) undo, which
generates suitable invalidations.

(Of course, undo itself weakens consistency to some degree.)

> 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.

Of course not. Those wouldn't implement this method.   But it
would provide a saner way to deal with *some* failures in 2pc.
For example, if you had a ZODB database and a relational db and
the rdb raised an error in tpc_finish, you could perhaps roll back
the zodb transaction.


Jim Fulton
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to