Thanks. I get it. But...
- seems this solution raises the footprint of the pooler, with
number-of-users * minimum-connection-count etc
- would it be beyond the pale for the pooler to maintain
username-connectionList maps?
Thankfully, I'll be wildly successful if I have two concurrent users (a
user may have hundreds of clients needing db connection)
(rant. The RDBMSs really should have a more lightweight way of changing
current user. (e.g. postgres set role doesn't cut it, doesn't even
invoke the users default search path))
Thanks again, I appreciate the feedback and knowledge sharing
On 11/24/20 6:28 AM, Christopher Schultz wrote:
Rob,
On 11/19/20 12:38, Rob Sargent wrote:
Since the connection URL names a specific postgres database is it
standard practice to have a pool per target database? (Switching
databases in postgres amounts to closing/opening a connection.)
I generally consider a database connection pool to be a connection to
a certain database/tablespace/schema, not a connection to an IP
address. That's the only thing that would make sense in terms of an
application, which would expect a connection to a specific data store,
right?
If you are closing connections (and reopening them), the pool isn't
dong its job.
I would recommend a separate pool per database/tablespace/schema.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
