[Zope-dev] deciding whether to do work in tpc_vote or tpc_finish

[Laurence Rowe]

On 8 June 2010 18:11, Jim Fulton <jim at zope.com> wrote:
> On Tue, Jun 8, 2010 at 1:00 PM, Laurence Rowe <l at lrowe.co.uk> wrote:
>> On 8 June 2010 14:38, Jim Fulton <jim at 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 web applications, one consequence of this is that you could end up
with stale pages cached in a proxy. This may well be preferable to the
inconstancies following from a failure in tpc_finish though.

If it were implemented, I guess it would be desirable for data
managers implementing tpc_recover to be called before those
implementing only tpc_vote/tpc_finish, which in turn should be sorted
before those implementing only 1-phase-commit.

If multiple data managers implemented tpc_recover, would a failure of
one data manager's tpc_recover prevent other data manager's
tpc_recover being run at all? I guess you want to end up in the 'least
inconsistent' state, but it's difficult to know whether this would be
achieved by attempting to tpc_recover on the other data managers or
not.

I guess my concern is that the benefits from implementing this should
outweigh the cost in higher complexity.

Laurence