Connection Pooling Comparison

There are lot of database connection pool options available like commons dbcp,c3p0,proxool,tomcat dbcp.But the most common in use are commons-dbcp and c3p0.DBCP is recommended for a comparatively low load applications and is comparatively faster compared to c3p0 which is quite recommended for the heavy traffic and high load apps.Below is a comparative study and the references.

DBCP (apache commons dbcp)

Pros: 1.
DBCP is quite fast in performance in both (single and multi threaded environments) compared to c3p0 and proxool. 2. Work with high performance with comparatively low traffic and low load applications. 3. Version 2 is on progress and it has a background which makes it reliable since Many Production problems have been tackled. 4. Switching to Tomcat jdbc pool ( high performance JDBC pool ) is seamless. 5. If Tomcat is used as the app container then the use of DBCP or the new version Tocat JDBC pool is recommended.

Cons:
1. commons-dbcp is single threaded, in order to be thread safe commons-dbcp locks the entire pool, even during query validation. 2. commons-dbcp is slow - as the number of logical CPUs grow, the performance suffers, the above point shows that there is not support for high concurrency Even with the enormous optimizations of the synchronized statement in Java 6, commons-dbcp still suffers in speed and concurrency. 3. commons-dbcp is complex, over 60 classes. tomcat-jdbc-pool, core is 8 classes, hence modifications for future requirement will require much less changes. This is all you need to run the connection pool itself, the rest is gravy. 4. commons-dbcp uses static interfaces. This means you can't compile it with JDK 1.6, or if you run on JDK 1.6/1.7 you will get NoSuchMethodException for all the methods not implemented, even if the driver supports it. 5. The commons-dbcp has become fairly stagnant. Sparse updates, releases, and new feature support. 6. It's not worth rewriting over 60 classes, when something as a connection pool can be accomplished with as a much simpler implementation. 7. Tomcat jdbc pool implements a fairness option not available in commons-dbcp and still performs faster than commons-dbcp 8. Tomcat jdbc pool implements the ability retrieve a connection asynchronously, without adding additional threads to the library itself 9. Tomcat jdbc pool is a Tomcat module, it depends on Tomcat JULI, a simplified logging framework used in Tomcat. 10. Retrieve the underlying connection using the javax.sql.PooledConnection interface. 11. Starvation proof. If a pool is empty, and threads are waiting for a connection, when a connection is returned, the pool will awake the correct thread waiting. Most pools will simply starve.

C3P0
Pros:
1. 2. 3. 4. C3P0 also robustly handled DB disconnects and transparent reconnects on resume. C3P0 was more than capable of handling without any exceptions.(compared to the DBCP) Comes in package with hibernate. Works well in a heavy concurrent environment.

Cons:
1.

C3P0 needs a lot more connections to get the same job done and is, in general, a bit slower than DBCP.

Single-threaded Benchmark 50,000 calls to getConnection() Trial MaxPoolS Connections s ize Used DBC 50,00 50 P 0 C3P 50,00 50 0 0 C3P 50,00 50 0 0 C3P 50,00 50 0 0 C3P 50,00 50 0 0 1 50 39 27 30 Secon Settings ds 5.18 6.72 6.6 6.45 6.63 *numHelperThread s=3 numHelperThreads =4 numHelperThreads =5 numHelperThreads =6

Tomcat jdbc pool

This comes in packaged with Tomcat-7 with enhanced features as shown below. The JDBC Connection Pool org.apache.tomcat.jdbc.pool is a replacement or an alternative to the commons-dbcp connection pool.

Pros:
1. 2. Performance tests run by tomcat jdbc pool show it has better performance than cp30. Support for highly concurrent environments and multi core/cpu systems.

3. 4. 5. 6.

7. 8.

9. 10. 11. 12. 13. 14.

15. 16.

Dynamic implementation of interface, will support java.sql and javax.sql interfaces for your runtime environment (as long as your JDBC driver does the same), even when compiled with a lower version of the JDK. Validation intervals - we don't have to validate every single time we use the connection, we can do this when we borrow or return the connection, just not more frequent than an interval we can configure. Run-Once query, a configurable query that will be run only once, when the connection to the database is established. Very useful to setup session settings, that you want to exist during the entire time the connection is established. Ability to configure custom interceptors. This allows you to write custom interceptors to enhance the functionality. You can use interceptors to gather query stats, cache session states, reconnect the connection upon failures, retry queries, cache query results, and so on. Your options are endless and the interceptors are dynamic, not tied to a JDK version of a java.sql/javax.sql interface. High performance - we will show some differences in performance later on Extremely simple, due to the very simplified implementation, the line count and source file count are very low, compare with c3p0 that has over 200 source files(last time we checked), Tomcat jdbc has a core of 8 files, the connection pool itself is about half that. As bugs may occur, they will be faster to track down, and easier to fix. Complexity reduction has been a focus from inception. Asynchronous connection retrieval - you can queue your request for a connection and receive a Future<Connection> back. Better idle connection handling. Instead of closing connections directly, it can still pool connections and sizes the idle pool with a smarter algorithm. You can decide at what moment connections are considered abandoned, is it when the pool is full, or directly at a timeout by specifying a pool usage threshold. The abandon connection timer will reset upon a statement/query activity. Allowing a connections that is in use for a long time to not timeout. This is achieved using the ResetAbandonedTimer Close connections after they have been connected for a certain time. Age based close upon return to the pool. Get JMX notifications and log entries when connections are suspected for being abandoned. This is similar to the removeAbandonedTimeout but it doesn't take any action, only reports the information. This is achieved using the suspectTimeout attribute. Connections can be retrieved from a java.sql.Driver, javax.sql.DataSource or javax.sql.XADataSource This is achieved using the dataSource and dataSourceJNDI attributes. XA connection support

BoneCP
An interesting comparison of different connection pooling options have been given here in bonecp site http://jolbox.com/ Go to the Benchmarks link to view the comparison.

References
1.

http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html

Below are some interesting discussions in different forums and blogs

2. 3. 4. 5. 6.

http://www.informit.com/articles/article.aspx?p=353736&seqNum=4 http://javatech.org/2007/11/c3p0-vs-dbcp-the-straight-dope/ http://forum.springsource.org/showthread.php?45575-c3p0-vs.-dbcp http://www.reverttoconsole.com/blog/performance/dbcp-vs-c3p0/ http://stackoverflow.com/questions/520585/connection-pooling-options-with-jdbc-dbcp-vs-c3p0