Hello, all. This a question to advanced ZGurus. ;-) When I have close a DB connection (exactly ZOracleConnection) and even deleted from ZODB, there is still a Oracle session. This is very bad, because count of sessions grows very fast. :( In Zope 2.5.0 session between Database and Server timeout is approx. 7-12 min, but in Zope 2.6.0 is probably forewer. :( Is there some cache of something? If yes, where it can be reduced to minimum? Does anybody know how to enforce to KILL em immediately and release a session between servers? Otherwise Zope goes to be unusable tool for "per-user" connections. :( -- Regards, Bogdan Of course I use Microsoft. Setting up a stable unix network is no challenge ;p
On Thursday 19 December 2002 05:13 am, Bo M. Maryniuck wrote:
Hello, all.
This a question to advanced ZGurus. ;-)
When I have close a DB connection (exactly ZOracleConnection) and even deleted from ZODB, there is still a Oracle session. This is very bad, because count of sessions grows very fast. :( In Zope 2.5.0 session between Database and Server timeout is approx. 7-12 min, but in Zope 2.6.0 is probably forewer. :( Is there some cache of something? If yes, where it can be reduced to minimum?
i'm wondering if this is a feature not a bug (sorry, i've always wanted to say that ;-)... relating to the new zodb cache impl toby did thats in 2.6. what exactly are you doing and how are you doing it? are you holding on to connections for more than the length of one request, how are you creating them, etc.
Does anybody know how to enforce to KILL em immediately and release a session between servers? Otherwise Zope goes to be unusable tool for "per-user" connections. :(
if your using the ttw zmi tools yes, but you can do things like this in unrestricted python you should be paying any more penalty than you would given the design costs of opening up a db connection per user, which is horribly inefficient anyways. -k
On Thursday 19 December 2002 06:34, kapil thangavelu wrote:
design costs of opening up a db connection per user, which is horribly inefficient anyways.
Hmm. But Oracle J2EE can do that via Web. -- Regards, Bogdan I'm a shareware signature! Send $2 if you use me, $10 for a manual.
On Thursday 19 December 2002 09:38 am, Bo M. Maryniuck wrote:
On Thursday 19 December 2002 06:34, kapil thangavelu wrote:
design costs of opening up a db connection per user, which is horribly inefficient anyways.
Hmm. But Oracle J2EE can do that via Web.
unless there is some mechanism of switching a user after a connection is made your basically talking about starting up an oracle process for every new user/connection. of course, oracle might have some special internal hooks... ah the joy of closed source dbs. ;-) regardless of the design choices, if you want some help with your problem, it would help to have some answers to the forensic questions i asked. -k
Bo M. Maryniuck writes:
On Thursday 19 December 2002 06:34, kapil thangavelu wrote:
design costs of opening up a db connection per user, which is horribly inefficient anyways.
Hmm. But Oracle J2EE can do that via Web. Oracle can reassign a new user for an existing connection. No need to open a new one...
Dieter
On Friday 20 December 2002 21:08, Dieter Maurer wrote:
Oracle can reassign a new user for an existing connection. No need to open a new one... Not exactly. AFAIK, this "reassign" means shutdown old user via a dozen of a triggers, drop old Oracle session, authorize new user, create him new Oracle session, pick out new permissions and register new user in the $_blah... tables for SQL caching, monitoring etc. and much-much more...
-- Regards, Bogdan 31337 is a prime number, go figure...
On Thursday 19 December 2002 06:34, kapil thangavelu wrote:
say that ;-)... relating to the new zodb cache impl toby did thats in 2.6. what exactly are you doing and how are you doing it? are you holding on to connections for more than the length of one request, how are you creating them, etc.
I create a connection with unique ID for each logged in user. Therefore user should run only one thread of its unique connect (at least I guess Zope will not clone it somehow). The only think I found is to _delete_ a self._v_database_connection on manage_close_connection() in ../Shared/DC/..../Connection.py and it even works as I expect. But I'm not sure it is right way. -- Regards, Bogdan One picture is worth 128K words.
participants (3)
-
Bo M. Maryniuck -
Dieter Maurer -
kapil thangavelu