Menu
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).
912
You reuse a prior database connection, in a new context to avoid the cost of setting up a new database connection for each request. The primary reason to avoid using database connections is that you're application's approach to solving problems isn't structured to accommodate a database connection pool.
Using connection pools helps to both alleviate connection management overhead and decrease development tasks for data access. Each time an application attempts to access a backend store (such as a database), it requires resources to create, maintain, and release a connection to that datastore.
The DBCP Component Opening a connection per user can be unfeasible in a publicly-hosted Internet application where the number of simultaneous users can be very large. Accordingly, developers often wish to share a "pool" of open connections between all of the application's current users.
There are multiple JDBC frameworks for connection pooling the most popular choices being Tomcat JDBC and HikariCP. Whatever framework you choose it's important to configure the properties correctly, (a big plus of HikariCP is that it offers good defaults for optional configs).
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.
139
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
