Hi! I'd like to open and store a database connection per session to enable things like transactions over multiple http accesses, use of (existing) python code, user authorization via database server etc. Unfortunately the session manager tries to pickle the connection object, which of course doesn't work here. Is it possible to avoid this? Anyway, as session data should be stored in RAM, I don't see the point of pickling... If it's possible to do what I want, is it also possible/necessary to avoid multiple concurrent accesses from the same user/session? Regards, Dietmar
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"
In <URL:news:local.ZOPE> on Fri 26 Apr, Chris McDonough wrote:
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.
I'm using a more or less standard installation. The session manager is configured to use /temp_folder/session_data as Transient object container. The help text for the Temporary Folder tells me: Temporary Folders are Folders which store their contents "in-memory", in much the same way as a RAM disk. The contents of a Temporary Folder are lost upon shutdown. [snip] Since Temporary Folders use RAM to store data, it is advised to add items to a Temporary Folder sparingly. The capacity of a Temporary Folder is limited by available RAM. So I really got the impression that my sessions would be stored in RAM...
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?
Yes, but would that help me if I want transactions over multiple page fetches? Don't think so. I'm not sure whether I'll really need this. The first applications will be quite simple and read-only (I still will use the Python database connection for user authentication, but for this purpose the connection may be closed after the login). Most write accesses will be from Python apps outside Zope. Regards, Dietmar
So I really got the impression that my sessions would be stored in RAM...
They are stored in RAM, but in a RAM-backed ZODB database.
Yes, but would that help me if I want transactions over multiple page fetches? Don't think so.
Not out of the box, no, you're right. Zope makes the assumption that request start/end are natural transaction boundaries. Hope it helped, - C
Dietmar Schwertberger writes:
I'd like to open and store a database connection per session to enable things like transactions over multiple http accesses, use of (existing) python code, user authorization via database server etc. Unfortunately the session manager tries to pickle the connection object, which of course doesn't work here. Is it possible to avoid this? I fear not. At least it will not be easy. Anyway, as session data should be stored in RAM, I don't see the point of pickling... You must be very careful!
As I found out (the hard way), it is very dangerous to store persistent objects in RAM: A persistent object has a reference to the ZODB connection. This reference is only valid in the current request. A new request may get a different ZODB connection, making the one in the persistent object invalid. Non-deterministic failures of the form: "Unable to load ..." "XXX does not have attribute YYY" may result. Acquisition wrappers which are themselvse not persistent contain references to persistent objects. Therefore, they, too, are dangerous to store in RAM.
If it's possible to do what I want, is it also possible/necessary to avoid multiple concurrent accesses from the same user/session? That depends on what you are doing and the multi-thread safety of your data structure.
You may look at "SharedResource" to find out how to synchronize when necessary. See <http://www.dieter.handshake.de/pyprojects/zope> Dieter
participants (3)
-
Chris McDonough -
Dieter Maurer -
Dietmar Schwertberger