On Tue, Mar 09, 2004 at 01:14:14PM +0100, Federico Di Gregorio wrote:
> Il mar, 2004-03-09 alle 12:59, Marco Bizzarri ha scritto:
> > 1) If there were no reference to a connection after a refresh or
> > after a _v_ attribute is deleted, the gc would remove the object, and
> > then close the connection
> >
> > 2) Since the connection is not closed and is not deleted, this means
> > that there is a reference to the object (in Zope or in Psycopg), a
> > cursor, or whatever, I don't know (Federico, please help).
> >
> > I suspect this is not showing in other application server because there
> > is an explicit management of connections, and of closing them.
> >
> > We could try avoiding the use of _v_ attributes to mantain the only
> > reference to the connection (something like what the ZOracleDA is doing,
> > but simpler), in this way:
> >
> > 1) we create a dictionary indexed by thread pid;
> > 2) when a thread requests a connect, it actually gets from the pool of
> > connections (actually, it has just one connection for itself);
> > 3) if the connection is not available for the thread pid, a new one is
> > created and inserted in the dictionary.
> >
> > Do you think this could be suitable?
>
> unfortunately no. how does the thread give back the connection?
> ZOracleDA does that in the __del__ method but *we are calling close()*
> on the connection in the __del__ method and we end up with non-closed
> connections anyway. why? the solution is in the answer to this question.
That's exactly what I'm saying in the mail above. The __del__ in the
db.py is *NEVER* called, otherwise we will not have the connection
which remains open. The __del__ is called only if this is the *LAST*
reference to the connection, which is not the case. I've added a
yell in the __del__, and *SURPRISE*, when you refresh a product, the
__del__ is not called.
> I know this can sound a bit crazy, but psycopg 2 has a much simpler
> connection/cursor management and should work with 1.1 ZPsycopgDA. Can
> you please try it out on your devel box. probably it will break a lot of
> stuff but it will give us some more information during the cache-flush
> test.
I will try, as a way to have more information on the problem.
> also, can you add a yell() call to __del__ and send me a log that shows
> n+1 connections open?
I added, now I will try to add some more log...
> thank you very much,
> federico
>
> --
> Federico Di Gregorio http://people.initd.org/fog
> Debian GNU/Linux Developer
> fog-8fiUuRrzOP0dnm+yROfE0A@xxxxxxxxxxxxxxxx
> INIT.D Developer
> fog-NGVKUo/i/6DYtjvyW6yDsg@xxxxxxxxxxxxxxxx
> Viviamo in un mondo reale, Ciccio. -- Lucy
Regards
Marco
--
Marco Bizzarri - Amministratore Delegato - Icube S.r.l.
Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: m.bizzarri-QB8vYuOG93c@xxxxxxxxxxxxxxxx WWW: www.icube.it
Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588
pgpnDeluHHhTm.pgp
Description: PGP signature
_______________________________________________
Psycopg mailing list
Psycopg-IAPFreCvJWPBWskQ1e/+sw@xxxxxxxxxxxxxxxx
http://lists.initd.org/mailman/listinfo/psycopg
|
