Paul Everitt wrote I wonder why you think the ZODB isn't the place to do this? If it is because of the versioning issue:
It is indeed because of the versioning issue.
1) You can create a special datastructure that doesn't version on every commit, but instead perhaps every minute. Think of it as halfway between volatile and persistent.
That's still going to be an awfully large number of objects in the DB. And it'll blow the undo log to hell...
2) One of these days we'll come out with a non-versioning Storage class, plus allow people to mix Storages in the same process.
At that point, I think it would be useful to reconsider storing things like webcounters and sessions in the ZODB.
3) Then again, perhaps people could live with the 20 byte or so growth on each Session commit.
not really. If you look at a different way - committing once a minute means that it's one commit per minute, per current user of the web site. More importantly, if you do have to bounce Zope for some reason, then all active users will suddenly find their web sessions rewinding backwards by up to a minute. One of the main things I'm using this for is for multi-page forms - having the session suddenly rewind would be very confusing for a user...