On 8 June 2010 18:11, Jim Fulton <jim@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 <jim@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