[replying to myself]

Martijn Faassen wrote:
Laurence Rowe wrote:
I'm not sure connection pooling is really useful in a threaded environment with recycled sessions. You want n threads = n connections. If we started creating new sessions each request then things would be different.

Mike Bayer says the following:

 > you should reuse a single engine.  It contains a pool of connections,
 > so recreating engines means new connections are constantly rebuilt and
 > it defeats the purpose of the pool.  Other than that the creation of
 > an engine is not very expensive but even a small expense is needless
 > here.

I explained to him we'd only end up creating a single engine per thread (and app), and we'll see what he has to say about that.

Mike responded like this:

> yeah that also kind of defeats the connection pool's purpose as it's
> intended to handle all connections for a particular database across
> threads.  Having a single point of pooling for a certain database has
> the advantage that you can tune the total number of connections at a
> single configuration point, and also that a database restart can be
> detected just once, resulting in a bounce of the entire pool (this is
> a distinct advantage of using a pool over a non-pooled approach).

So, it looks like we need to make sure we maintain a single engine per database.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to