I don't really know, and don't have the time right now to figure this out properly. Jim Fulton will be a better person to answer this. Also, you could look through the ZODB UML Model:
http://www.zope.org/Documentation/Developer/Models/ZODB
- Why can't the session object rely on the ZODB memory cache. They are (for the most) fast deployed objects. Maybe even use _v_ objects (which would be automatically destroyed).
There is at the moment no API for using the ZODB memory cache outside the ZODB code itself, afaik.
- How does transactions slow down the process, and how are transactions connected to storage (in this situation)? Not so much slow down as cause undesirable side effects, like storing a complete change history of the changed object. See the ZODB UML for more information.
Aha, I see! Great point there.
There are plans to allow use of multiple Storage types within one Zope object hierarchy. Also, there are Storage available now, that do not support Undo (discard old versions). When multiple storages are supported, you could use a in-memory storage without undo for session data.
And the in-memory storage would have it's own ZEO-server for distributing and load-balancing session data, I suppose. That explains the need for the in-memory storage option. (Is this what DC have in mind, DC folks?) It would be great to have a session API pretty soon, that could be used to create session aware prototypes that could migrate to ZEO and Multiple Storage/In-Memory Session solutions in the future. The session implementation could be something less complicated for a prototype. Or is that to much work and to much unknown facts about future implementations? //johan