For the impatient: it’s a small jar that lets you compile/run/deploy java instantly, like php. I’ts the real HOT DEPLOY that jvm lacks out of the box.

No more restarting the server, ever again, even after reconfiguring Spring beans.

I used this for a month, and convinced my manager to buy licenses for all. It’s that good.

The commons-dbcp package relies on code in the commons-pool package to provide the underlying object pool mechanisms that it utilizes.

Applications can use the commons-dbcp component directly or through the existing interface of their container / supporting framework.

C3P0, on the other hand,

c3p0 is an easy-to-use library for augmenting traditional (DriverManager-based) JDBC drivers with JNDI-bindable DataSources, including DataSources that implement Connection and Statement Pooling, as described by the jdbc3 spec and jdbc2 std extension.

I found an interesting article comparing DBCP and C3PO, but it was only available via google’s cache. So I’m copying it here after the jump…

C3P0 vs DBCP – The Straight Dope

Posted in November 12th, 2007

by Darren Hicks in Open Source, Benchmarks

I’ve found it very difficult to find any accurate comparisons of C3P0 and DBCP. Why should I choose C3P0 over DBCP? When might DBCP be better?

Well, here’s a fairly in-depth overview of both with pros and cons and similarities and differences included.

The first thing to note is that if you’re not in a multi-threaded environment, then DBCP is going to be faster than C3P0 and will also use significantly fewer connections than C3P0. For example, using the default settings for each and sizing the pool to contain 50 connections at most, will yield results like the following single-threaded test.

Single-threaded Benchmark – 50,000 calls to getConnection()

Suffice it to say that DBCP is obviously better suited to Single-threaded applications with high load. Needing 50 connections in the pool to do the work where only 1 is needed is certainly not desired. This is the case with C3P0’s default setting of “numHelperThreads=3?. Regardless of the environment you have ( single-threaded, multi-threaded ) I would always change this setting if you forsee high load on the program. I would always use at least “numHelperThreads=5?. As a bit of background/explanation, C3P0 doesn’t actually make a connection available in the pool when it is checked-in. Instead the HelperThreads will detect these and do the work to get them back in the pool. This is great in high-load, multi-threaded environments as it avoids blocking issues. But it inherently requires a much larger number of connections to provide the same functionality ( especially if you keep “numHelperThreads=3? ). Also, notice that DBCP is 20% faster regardless of how we tweak numHelperThreads.

Score 2 points for DBCP. 2-0.

Next what if we run the same test with a smaller connection pool size – say of only 5 connections, and numHelperThreads=3 for C3P0?

The results are a bit counterintuitive ( to me at least ). DBCP does at least manage to stay the same – very fast and reasonable ( needing just 1 connection in its pool ). But C3P0, which I expected to take longer because it previously needed all 50 connections, but actually runs faster with a smaller pool : 6.25 seconds down from 6.7 seconds. The lesson here is that C3P0 is slowing itself down with the HelperThreads having to manage all the extra connections to get them back in the pool.

Score 1 point each. DBCP for making sense and C3P0 for speeding up.

3-1, DBCP in the lead.

Now for the good stuff – the multi-threaded tests. I’ll be varying the number of Threads which will be running.
Multi-threaded tests

Score yet another to DBCP. Faster across the board on all accounts. So, what is it about C3P0 that has everybody ( myself included ) using it and singing its praises? Multiple threads yield multiple points again for DBCP – 2 points awarded.

5-1, C3P0 will need a miracle comeback at this point.

I know, usually Connections aren’t just checked out and run with a small SQL statement and immediately returned like the Benchmarks I’ve been running. Maybe I need to put some delay in there to more closely mimic real world performance. I’m going to throw a new setting in here which is a delay in milliseconds that each call to getConnection() will endure before finishing with the connection. I’ll give it a shot with an extra 100ms of sleep time after each SQL statement is run.

Multi-threaded – 100ms of sleep time added

4 users commented in ” C3P0 vs DBCP – The Straight Dope “

Follow-up comment rss or Leave a Trackback

rpt said,

in November 23rd, 2007 at 1:14 pm

So, what is it about C3P0 that has everybody (yourself included) using it and singing its praises?

Darren Hicks said,

in November 23rd, 2007 at 7:59 pm

The biggest thing is the lack of blocking in multithreaded environments. With DBCP, even the act of returning a connection to the pool is a blocking operation. In production environments where there are other resources being worked with ( possibly also synchronously ), there then arises the likelihood of slowdowns and the potential for deadlocks. It only takes a few of these occurences to see the value C3P0 adds. Additionally, C3P0 ships with JMX management and can be fine tuned to a greater extent than DBCP.

I’ve got to finish the article and come up with the test cases demonstrating the DBCP slowdowns and deadlocks when using other synchronous resources

andy said,

in November 25th, 2007 at 2:15 am

how about adding Proxool to the comparison ?

mike said,

in April 9th, 2008 at 4:21 pm

Thanks for taking the time to benchmark and share with everyone…

I haven’t used Proxool at all but was recently using DBCP on a busy tomcat site (15M hits/day) and was running into a wall of contention that turned out to be DBCP… Switched to C3P0 and this issue was immediately resolved and actually looked like it was doing so with less connections and faster response times.

However, this is still limited in that it only returns the total size of the Object, not the details about the Object size in regard to its composition.

Enter monq.jar from
Whatizit.

There’s a Sizeof class in monq.jar with a static sizeof method that walks through an Object instance at runtime and counts up the bytes in use for all its elements and then returns a HashTable. The results seem to be consistent with what I’ve seen by using the java.lang.Runtime class to estimate heap size. The Sizeof class also provides a convenient printTypes method which can be used to dump the HashTable data to an OutputStream (such as System.out). This allows you to easily see which nodes of a given Object tree might be prone to causing trouble. Though it cannot be 100% accurate, it’s probably very close.

Here’s a simple usage example:

public void printObjectSizeTable(Object object) {
   Sizeof.printTypes(System.out, Sizeof.sizeof(object));
}

The above will print out a table consisting of four columns, which are:

• Count of the particular type
• Total byte size of the type
• Containing type class name
• Type class name

Example output using a populated ArrayList as the parameter to the method above:

26 1516 java.lang.Object; java.util.ArrayList
25 500 java.util.ArrayList java.util.ArrayList
1 20 java.util.ArrayList monq.stuff.Sizeof$Root
52 2036 TOTAL

I might just start integrating this into some junit tests. I certainly believe that it will be very useful in determining the cause of performance problems.

-”That’s all for now folks”