tomcat-dbcp vs commons-dbcp

Question

It seems there is a lot of confusion between these two connection pooling libraries. What I want to know is which one is better (if at all)?

Here are some points whi

Answer 1

It seems there is a lot of confusion between these two connection pooling libraries. What I want to know is which one is better (if at all)?

TL/DR: these are the same, don't use either of them.

Tomcat-dbcp is the original re-package of apache commons pool included in Tomcat distribution. To avoid class clash package was renamed to org.apache.tomcat.dbcp.dbcp.*

In Tomcat 7 (starting with 7.0.19 in July 2011) an additional connection pool was included in default Tomcat package (as part of tomcat-jdbc.jar) as alternative to stale apache commons implementation, called "The Tomcat JDBC Connection Pool":

https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

This article covers the differences between the two:

http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html

Short summary why new Tomcat pool is better:

• actively supported
• much smaller, easier to understand and maintain (if you care to look at source)
• supports all commons-dbcp features + adds super useful ones like "initSQL", "validationInterval", "jdbcInterceptors" and more

Answer 2

Here's a list of advantages of using Tomcat JDBC pool rather than commons-dbcp: http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html

Answer 3

Tomcat DBCP is just a renamed version of Apache Commons DBCP, with also a different internal package name prefix.

At build time, Tomcat fetches the Commons DBCP sources (the version depends on the Tomcat version, for instance Tomcat 7.0.27 uses Commons DBCP 1.4), and does package name replacement (org.apache.commons -> org.apache.tomcat.dbcp) and builds the result as tomcat-dbcp.jar.

This is done so that the internal Tomcat JDBC pools never conflict with possible application uses of the Commons DBCP classes. This avoids many potential classloading issues.

Edit: The "dbcp" packages are about datasource management. For the pure pool implementation, Commons DBCP depends on Commons Pool (package org.apache.commons.pool), but in Tomcat the implementation of the pool is replaced with Tomcat's own JDBC pool (package org.apache.tomcat.jdbc.pool).

Answer 4

Older versions of Apache Commons DBCP (i.e. version 1.2) had some nasty thread-safety issues under high load conditions, making it unsuitable for that kind of usage. It doesn't surprise me that the Tomcat folks re-worked it to fix these issues.

However, my understanding is that Commons DBCP 1.4 fixes these issues. I can't confirm that personally, but it may render the Tomcat version redundant.

Interestingly, SpringSource also rewrote Commons DBCP for their repackaged version of Tomcat (tc-Server), and they claim big performance benefits from it. They haven't open-sourced that, though.

Answer 5

Just to add here: I have noticed an interesting behavior, though it is expected but could not find any documentation for that:

For Tomcat you need to define Tomcat factory (org.apache.tomcat.jdbc.pool.DataSourceFactory or other Tomcat factories) otherwise it will work as Common DBCP.

There are differences in between default values of Common DBCP and Tomcat DBCP, specially testOnBorrow (true in Common DBCP but false in Tomcat DBCP).

Answer 6

Tomcat 7 continues to use DBCP. The main reason could be hidden in their Tomcat docs:

• The Apache Commons DBCP can be configured to track and recover these abandoned database connections. Not only can it recover them, but also generate a stack trace for the code which opened these resources and never closed them.

• Tomcat jdbc-pool library, maybe faster in highly concurrent scenarios but cannot close and release statements automatically (which a developer has forgotten to close) resulting in possible memory leaks in some jdbc drivers.

However one of the problems with DBCP code is the delegation model they use, currently their latest versions supports JDK1.6 and lower. To support 1.7 means changing at least a fourth of their classes, which was one of the reasons JDBC pool library came to existence.

NOTE: Upon further investigation, JDBC pool does have a way of closing opening statements when a connection is closed, using a StatementFinalizer interceptor.