views:

3171

answers:

4

The JDBC 3.0 spec talks about Connection (and Prepared Statement) pooling.

We have several standalone Java programs (i.e. we are not using an application server) that have been using DBCP to provide connection pooling. Should we continue to use DBCP, or can we take advantage of the JDBC-provided pooling and get rid of DBCP?

We are using MySQL (Connector/J) and will eventually be adding SQL Server support (jTDS); it's unlikely that we'll support any other databases.

EDIT: See comment below about my attempt to eliminate the connection pooling library. It appears that DBCP is still relevant (note that some commenters recommended C3P0 over DBCP).

A: 

People still use DBCP, I think it even comes as a default with Hibernate.

Is DBCP not meeting your current needs?

I'm not a big believer in replacing infrastructure unless there's already a performance or functionality gap that it can't fill, even if there are newer or fancier alternatives around.

Uri
DBCP works, but if I can get the same features from the JDBC driver, I'd just as soon simplify things. I also wouldn't mind removing some of the code we've added to "fix" DBCP exception handling.
jdigital
c3p0 comes with Hibernate.
Adeel Ansari
+1  A: 

I prefer using dbcp or c3p0 because they are vendor neutral. I found out, at least with mysql or oracle, that whenever I try to do something with the jdbc client that is not standard sql I have to introduce compile-time dependency on the vendor's classes. See, for example, a very annoying example here.

I am not sure about mysql, but oracle uses their specific, non-standard classes for connection pooling.

Yoni
The thread - you provided - is not relevant, I am afraid.
Adeel Ansari
I know. I referred to it to illustrate what I meant regarding compile dependencies.
Yoni
+3  A: 
erickson
How big an effort is it to switch from DBCP to JDBC pooling?
jdigital
It depends on the driver. With Oracle and PostgresQL, it was a simple configuration change--the code was already working with a (DBCP) DataSource. I don't have experience with MySQL drivers.
erickson
I would agree that DBCP is broken. We switched to C3PO and it worked like a dream
j pimmel
Same question would apply to C3PO - is it still relevant?
jdigital
We've been using DBCP together with Spring for about 4 years with no issues - maybe we've been lucky!
Fortyrunner
+6  A: 

Based on the encouragement of other posters, I attempted to eliminate DBCP and use the MySQL JDBC driver directly (Connector/J 5.0.4). I was unable to do so.

It appears that while the driver does provide a foundation for pooling, it does not provide the most important thing: an actual pool (the source code came in handy for this). It is left up to the application server to provide this part.

I took another look at the JDBC 3.0 documentation (I have a printed copy of something labeled "Chapter 11 Connection Pooling", not sure exactly where it came from) and I can see that the MySQL driver is following the JDBC doc.

When I look at DBCP, this decision starts to make sense. Good pool management provides many options. For example, when do you purge unused connection? which connections do you purge? is there a hard or soft limit on the max number of connections in the pool? should you test a connection for "liveness" before giving it to a caller? etc.

Summary: if you're doing a standalone Java application, you need to use a connection pooling library. Connection pooling libraries are still relevant.

jdigital