Hey, [replying to myself] Martijn Faassen wrote:
Laurence Rowe wrote: [snip]
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. Regards, Martijn