On Tue, Jun 8, 2010 at 1:44 PM, Laurence Rowe <l...@lrowe.co.uk> wrote: > On 8 June 2010 18:11, Jim Fulton <j...@zope.com> wrote: >> 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 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 - Zope-Dev@zope.org 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 )