Connection Pooling with Connector/J
Connection pooling is a technique of creating and managing a pool of connections that are ready
for use by any thread that needs them. Connection pooling can greatly increase the performance
of your Java application, while reducing overall resource usage.
How Connection Pooling Works
Most applications only need a thread to have access to a JDBC connection when they are
actively processing a transaction, which often takes only milliseconds to complete. When not
processing a transaction, the connection sits idle. Connection pooling enables the idle
connection to be used by some other thread to do useful work.
In practice, when a thread needs to do work against a MySQL or other database with JDBC, it
requests a connection from the pool. When the thread is finished using the connection, it returns
it to the pool, so that it can be used by any other threads.
When the connection is loaned out from the pool, it is used exclusively by the thread that
requested it. From a programming point of view, it is the same as if your thread
called DriverManager.getConnection() every time it needed a JDBC connection. With
connection pooling, your thread may end up using either a new connection or an already-existing
connection.
Benefits of Connection Pooling
The main benefits to connection pooling are:
Reduced connection creation time.
Although this is not usually an issue with the quick connection setup that MySQL offers
compared to other databases, creating new JDBC connections still incurs networking and
JDBC driver overhead that will be avoided if connections are recycled.
Simplified programming model.
When using connection pooling, each individual thread can act as though it has created its
own JDBC connection, allowing you to use straightforward JDBC programming techniques.
Controlled resource usage.
If you create a new connection every time a thread needs one rather than using connection
pooling, your application's resource usage can be wasteful, and it could lead to
unpredictable behaviors for your application when it is under a heavy load.
Using Connection Pooling with Connector/J
The concept of connection pooling in JDBC has been standardized through the JDBC 2.0
Optional interfaces, and all major application servers have implementations of these APIs that
work with MySQL Connector/J.
Generally, you configure a connection pool in your application server configuration files, and
access it through the Java Naming and Directory Interface (JNDI). The following code shows
how you might use a connection pool from an application deployed in a J2EE application server:
Example 8.1 Connector/J: Using a connection pool with a J2EE application server
import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import javax.naming.InitialContext;
import javax.sql.DataSource;
public class MyServletJspOrEjb {
public void doSomething() throws Exception {
/*
* Create a JNDI Initial context to be able to
* lookup the DataSource
*
* In production-level code, this should be cached as
* an instance or static variable, as it can
* be quite expensive to create a JNDI context.
*
* Note: This code only works when you are using servlets
* or EJBs in a J2EE application server. If you are
* using connection pooling in standalone Java code, you
* will have to create/configure datasources using whatever
* mechanisms your particular connection pooling library
* provides.
*/
InitialContext ctx = new InitialContext();
/*
* Lookup the DataSource, which will be backed by a pool
* that the application server provides. DataSource instances
* are also a good candidate for caching as an instance
* variable, as JNDI lookups can be expensive as well.
*/
DataSource ds =
(DataSource)ctx.lookup("java:comp/env/jdbc/MySQLDB");
/*
* The following code is what would actually be in your
* Servlet, JSP or EJB 'service' method...where you need
* to work with a JDBC connection.
*/
Connection conn = null;
Statement stmt = null;
try {
conn = ds.getConnection();
/*
* Now, use normal JDBC programming to work with
* MySQL, making sure to close each resource when you're
* finished with it, which permits the connection pool
* resources to be recovered as quickly as possible
*/
stmt = conn.createStatement();
stmt.execute("SOME SQL QUERY");
stmt.close();
stmt = null;
conn.close();
conn = null;
} finally {
/*
* close any jdbc instances here that weren't
* explicitly closed during normal code path, so
* that we don't 'leak' resources...
*/
if (stmt != null) {
try {
stmt.close();
} catch (sqlexception sqlex) {
// ignore, as we can't do anything about it here
}
stmt = null;
}
