On 24/11/2020 16:26, Phil Steitz wrote: > > > On 11/24/20 8:52 AM, Rob Sargent wrote: >> Perhaps I read too much into the description of "The tomcat JDBC >> Connection Pool" page? >> >> TheJDBC Connection Pool|org.apache.tomcat.jdbc.pool|is a replacement >> or an alternative to theApache Commons DBCP >> <https://commons.apache.org/dbcp/>connection pool. >> >> I reacted to the "replacement" bit. Are both equally sound, supported, >> surviving? > > Yes. I can't speak for jdbc-pool, but it looks like it is being > actively maintained. I can confirm that Commons DBCP is being > maintained. A repackaged, slightly stripped down version of DBCP is the > default pool that ships with tomcat. I am not sure if the > PerUserPoolDataSource is included in the tomcat distro, but you can just > use DBCP directly to get this if you want to use it. > > Others who know dbcp-pool better can chime in, but I think the > difference between the two is that DBCP has more features (including, > for example the DS above), but those features come at the expense of a > larger code base, dependency on Commons Pool (another widely used, > pretty well-maintained library) and slightly worse performance. When > jdbc-pool was first introduced, the performance gap, and some nasty bugs > in DBCP 1.x made the former a better choice for high-concurrency > applications. With DBCP 2, the gap has narrowed to the point where it > is not practically significant. The tomcat website text has never been > updated to reflect this.
There is some useful (although not necessarily from a neutral viewpoint) history in this thread: https://markmail.org/message/nhayhdcstkj2lssf One point that thread doesn't address is that jdbc-pool has better JMX monitoring than DBCP which is a large part of why it is still around. Mark > > Phil >> I try to use what I think is the safest longer term bet (my retirement >> is nigh, it shouldn't take the code with it :) ) >> >> >> On 11/24/20 8:28 AM, Phil Steitz wrote: >>> >>> On 11/24/20 8:14 AM, Rob Sargent wrote: >>>> 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? >>> >>> Per response elsethread, see PerUserPoolDataSource [1] provided by >>> Commons DBCP. It does that. >>> >>> Phil >>> >>> [1] https://s.apache.org/dlghr <https://s.apache.org/dlghr> >>> >>>> >>>> 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 >>>>> >>>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
