[ZODB-Dev] undo (and storage interface) brokenness
jim at zope.com
Wed Dec 23 15:26:13 EST 2009
I'm looking at undo today because it is complicating ZEO transaction management.
Undo is broken in a number of ways. Does anyone care? Does anyone use undo?
Undo is broken in the following ways:
- The TransactionalUndo resource manager invalidates objects too early.
- If undo is mixed with stores, store invalidations may not be handled properly.
This is because, with undo, the two-phase commit calls are made on a storage
multiple times. This was OK a long long time ago, but not since
returning important information.
Of course, mixing undo and stores is problematic in a number of
ways, but there's
nothing to prevent it now.
- Because undo returns affected oids immediately, it's impossible to
delay getting the
storage lock until tpc_vote is called. This is a performance issue
and is less serious
than the problems mentioned above.
Undo can be fixed, but not in a way that preserves the existing API.
I'm tempted to remove undo support, at least from ZEO.
So, I repeat: is anyone actually using undo these days?
BTW, this analysis reveals a flaw in the storage APIs that I'd like to
fix. You're allowed
to call tpc_begin multiple times with the same transaction. Extra
calls are ignored.
Also, calling tpc_finish with a wrong transaction (a transaction other
than the one
the storage is dealing with or when a storage isn't committing) is
ignored. This feels
like a bug magnet to me, but it's there, afaict, to support the current broken
undo implementation. Changing existing standard storages to be more
restrictive (and fixing tests that specifically tested the permissive
behavior) doesn't break anything but
the current undo implementation.
More information about the ZODB-Dev