Re: [Zope] Session and objects
well, you will not be able to directly store those connections in the session. i would store them somewhere else (a tool for it in the ZODB maybe?) and retrieve the right connection based on a simple key you store in the session. jens On Monday, Sep 30, 2002, at 07:48 US/Eastern, Bo M. Maryniuck wrote:
On Monday 30 September 2002 13:44, you wrote:
i'm not sure what you are trying to achieve here. it is always the easiest to store nothing but simple python data types (strings, sequences, dictionaries) in a session data container. a much better solution might be to store something that acts as a "key" and lets you find what you need in the real ZODB when you need it. Well, I would like to store a Oracle DA connection to the session, because I need _different_ connection at the same time for different user. The problem is to logout user, if he is just close browser (not press button "Logout" or so). Then I want somehow hook this exception. There is no way (perhaps) to do it with ZODB, so I need put this connection to the session and the connection will die as soon as user closes the browser, itn't it?
-- Regards, Bogdan
Everyone has a photographic memory. Some don't have film.
On Monday 30 September 2002 13:57, Jens Vagelpohl wrote:
i would store them somewhere else (a tool for it in the ZODB maybe?) and retrieve the right connection based on a simple key you store in the session. Actually yes, that's what I'm doing right now. New connection is stored in ZODB, opened and user enjoys his work for a while. But the problem is, when we have thousands of users and Zope need to logout or break the connection somehow when user just CLOSES browser, but not logged out via logout form, then connection is still open.
-- Regards, Bogdan 1 4m 5o 3l337! just got r00t on this <a href="127.0.0.1">k3wl site</a> j00 sux0r5!
there is no way for the application to detect that someone has closed their browser. there is methods in the sessioning machinery that allow you to do processing on session data that is about to expire. that's where you need to look. jens On Monday, Sep 30, 2002, at 07:59 US/Eastern, Bo M. Maryniuck wrote:
On Monday 30 September 2002 13:57, Jens Vagelpohl wrote:
i would store them somewhere else (a tool for it in the ZODB maybe?) and retrieve the right connection based on a simple key you store in the session. Actually yes, that's what I'm doing right now. New connection is stored in ZODB, opened and user enjoys his work for a while. But the problem is, when we have thousands of users and Zope need to logout or break the connection somehow when user just CLOSES browser, but not logged out via logout form, then connection is still open.
-- Regards, Bogdan
On Monday 30 September 2002 14:23, Jens Vagelpohl wrote:
there is no way for the application to detect that someone has closed their browser. there is methods in the sessioning machinery that allow you to do processing on session data that is about to expire. that's where you need to look.
Do You want to say, that I need look from the Zope to the user session? 8-| Well, I need turn-off the DB connection on the _Zope_ side, not on the user side. Then how to look via all the sessions that someones already expired? :-) Yes, I have a solution with remote scripting & crontab or with XCron, but maybe there is a better way? -- Regards, Bogdan WARN_(accel)("msg null; should hang here to be win compatible\n"); -- WINE source code
Bo M. Maryniuck wrote:
On Monday 30 September 2002 14:23, Jens Vagelpohl wrote:
there is no way for the application to detect that someone has closed their browser. there is methods in the sessioning machinery that allow you to do processing on session data that is about to expire. that's where you need to look.
Do You want to say, that I need look from the Zope to the user session? 8-| Well, I need turn-off the DB connection on the _Zope_ side, not on the user side. Then how to look via all the sessions that someones already expired? :-) Yes, I have a solution with remote scripting & crontab or with XCron, but maybe there is a better way?
Maybe you could state why you want to stop the DB connection. Normaly there's no need to do something like that. Do you want/have something like per-user persistent DB connections, maybe with individual connection string (login/password)? cheers, oliver
participants (3)
-
Bo M. Maryniuck -
Jens Vagelpohl -
Oliver Bleutgen