tomcat-dbcp vs commons-dbcp

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 which I would like to put up... Could someone please verify?

1. Tomcat DBCP: uses the default tomcat-dbcp.jar which will be present in your tomcat/lib directory. You do not need commons-dbcp.jar or commons-pool.jar libraries in your web-inf/lib. The DB driver should be placed in tomcat/lib.

2. Tomcat DBCP datasource class is org.apache.tomcat.dbcp.dbcp.BasicDataSource. Commons DBCP datasource class is org.apache.commons.dbcp.BasicDataSource.

3. The only difference between these two can be found in this blog. Do not know if the information is correct or not.

4. The official Tomcat documentation mentions clearly that most classes have just been re-named and re-packaged.

So the question is: which one to use and which one is better?

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).

>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

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.

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.

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).

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