[ZODB-Dev] Re: Connection pool makes no sense

[David Rushby]

I don't mean to intrude in this discussion, but I've communicated with
the original poster privately.

--- Dieter Maurer <dieter at handshake.de> 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. 
http://brand.yahoo.com/cybergivingweek2005/