In my opinion it's getting increasingly obvious that the ZODB badly needs cheap, non-undoable, "transient" transactions.
Counters, sessions, often-refreshed internal state tables -- lots of applications need it, and moving this stuff outside the ZODB breaks with the object-oriented design.
How it's actually implemented is irrelevant, be it in-memory or file-based, but in its simplest form it should not be difficult to do.
Jim can better speak to this, but it's more difficult than it looks (see the UML model for more information), but has to do with supporting multiple databases in the same tree. We already have a few storage mechanisms that don't support undo or versions., it's simply the integration into the full system that is more complex. Patches, as always, are accepted. :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com