Unfortunately the session manager tries to pickle the connection object, which of course doesn't work here. Is it possible to avoid this?
It'll probably be a requirement in this case to either: - create a "transient object container" that doesn't use the ZODB (which is ultimately doing the pickling that is causing you problems) to store data. .. or .. - to "hack around" the problem by registering a connection with a global connection registry for each session and storing a (string) reference to it in the session (instead of storing the connection object itself).
Anyway, as session data should be stored in RAM, I don't see the point of pickling...
That would make life simple, but it's not always true. People want persistent sessions as well as the ability to share session data across ZEO clients, and the current transient data container implementation lets that happen by using the ZODB to store session data. The fact that the OOTB sessioning implementation in Zope uses ZODB to store session data is what is causing you problems here.
If it's possible to do what I want, is it also possible/necessary to avoid multiple concurrent accesses from the same user/session?
Not really. Frames are a problem. Spidering tools or benchmarking tools like "ab" might cause simultaneous writes to the same session. Even clicking really really fast might cause simultaneous writes to the same session object. I'd give it a roll, though. I think that the worst that can happen to you is that you open and close your database connections more often than you'd really like to. BTW, are you aware that the relational database support in Zope does its own "connection pooling" and that schemes like this that are commonly used in Java for this kind of thing aren't really necessary? - C -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"