[ZODB-Dev] undo (and storage interface) brokenness

[Jim Fulton]

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

Jim

-- 
Jim Fulton