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

[Tim Peters]

Oops!  I sent this to zope-dev instead of zodb-dev by mistake.

[Pitcher at gw.tander.ru]
>>> Not agree. Can you answer the question? Does self.all.remove(c) mean
>>> that we WANT to destroy connection instance?

[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 ;-)

> On the next peak load we get some next ZODB-Connections with
> RDB-Connection .... After repush() old ZODB-Connections will be killed
> (if  > pool_size)

I don't like the word "killed" here, because it seems highly misleading.
ZODB doesn't destroy any Connections or any caches.  ZODB destroys all its
strong references to old Connections, and that's all.  Nothing can be done
to _force_ Connections to go away forever.  It's ZODB's job here to make
sure it isn't forcing Connections (beyond the pool_size limit) to stay
alive, and it's doing that job.  It can't "kill" Connections.

> but RDB-Connection stay in cache forever
> And so on....

There's one cache per Connection.  If and when a Connection goes away, its
cache goes away too.  So when you say something "stays in cache forever", I
don't know what you mean -- you apparently have many (hundreds? thousands?)
of Connections, in which case you also have many (hundreds or thousands) of
caches.  I don't know how an RDB-Connection gets into even one of those
caches to begin with.

> as a result we get many RDB-Connections what will never use but hang our
> RDB

At this point I have to hope that someone else here understands what you're
doing.  If not, you may have better luck on the zope-db list (which is
devoted to using other databases with Zope):

    http://mail.zope.org/mailman/listinfo/zope-db