Re: deciding whether to do work in tpc_vote or tpc_finish

On Tue, Jun 8, 2010 at 1:44 PM, Laurence Rowe <[email protected]> wrote:
> On 8 June 2010 18:11, Jim Fulton <[email protected]> wrote:
>> On Tue, Jun 8, 2010 at 1:00 PM, Laurence Rowe <[email protected]> wrote:
>>> 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.
>>
>> 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.

Sure.  Although, stale pages pretty much define caches. <.5 wink>

> This may well be preferable to the
> inconstancies following from a failure in tpc_finish though.

Yup.

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

This all depends on how the 1-phase commit data managers work.

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

No.  This would be equivalent to the original tpc_finish failure.

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

I don't think it really increases complexity all that much.  I agree
the potential benefit is pretty limited.

Jim

-- 
Jim Fulton
_______________________________________________
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 )