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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -