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 _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev