I don't mean to intrude in this discussion, but I've communicated with
the original poster privately.
--- Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Tim Peters wrote at 2005-12-29 12:59 -0500:
> > ...
> >[Tim Peters]
> >>> It means that _ConnectionPool no longer has a reason to remember
> >>> anything about that Connection. Application code can continue
> >>> keeping it alive forever, though.
> >[Denis Markov]
> >> But what about RDB-Connection what stay in cache forever?
> >Sorry, I don't know anything about how your app uses RDB
> connections. ZODB
> >isn't creating them on its own ;-)
> They did not tell us about their application. But, Zope's database
> adapters work like this. They use the ZODB cache (and its pool)
> as an RDB connection pool. Thus, if the ZODB caches are not released,
> the RDB connections won't.
That is exactly the problem. The ZODB client application in this case
is Zope (2.8.5), and relational database connections are not being
garbage collected in a timely manner because of the cycle. If there's
an intense burst of activity followed by a lull during which no clients
are hitting Zope, numerous relational database connections are
sometimes left open because the garbage collector hasn't collected
their parent objects yet.
In this situation, adding a 'c._resetCache()' call to the end of the
while loop in _ConnectionPool._reduce_size (line 122 of
lib/python/ZODB/DB.py in the Zope 2.8.5 source code) fixes the problem.
Since ZODB doesn't know whether the connection it's releasing from the
pool is still in use, I don't know whether resetting the connection's
cache is appropriate as a general solution. But it fixes a definite
problem with Zope's behavior as a ZODB client application.
Yahoo! for Good - Make a difference this year.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org