Oracle 5.0 Reference Manual page 2118

}
}
}
As shown in the example above, after obtaining the JNDI InitialContext, and looking up the
DataSource, the rest of the code follows familiar JDBC conventions.
When using connection pooling, always make sure that connections, and anything created by them
(such as statements or result sets) are closed. This rule applies no matter what happens in your
code (exceptions, flow-of-control, and so forth). When these objects are closed, they can be re-used;
otherwise, they will be stranded, which means that the MySQL server resources they represent (such
as buffers, locks, or sockets) are tied up for some time, or in the worst case can be tied up forever.
Sizing the Connection Pool
Each connection to MySQL has overhead (memory, CPU, context switches, and so forth) on both
the client and server side. Every connection limits how many resources there are available to your
application as well as the MySQL server. Many of these resources will be used whether or not the
connection is actually doing any useful work! Connection pools can be tuned to maximize performance,
while keeping resource utilization below the point where your application will start to fail rather than just
run slower.
The optimal size for the connection pool depends on anticipated load and average database
transaction time. In practice, the optimal connection pool size can be smaller than you might expect. If
you take Sun's Java Petstore blueprint application for example, a connection pool of 15-20 connections
can serve a relatively moderate load (600 concurrent users) using MySQL and Tomcat with acceptable
response times.
To correctly size a connection pool for your application, create load test scripts with tools such as
Apache JMeter or The Grinder, and load test your application.
An easy way to determine a starting point is to configure your connection pool's maximum number
of connections to be unbounded, run a load test, and measure the largest amount of concurrently
used connections. You can then work backward from there to determine what values of minimum and
maximum pooled connections give the best performance for your particular application.
Validating Connections
MySQL Connector/J can validate the connection by executing a lightweight ping against a server. In
the case of load-balanced connections, this is performed against all active pooled internal connections
that are retained. This is beneficial to Java applications using connection pools, as the pool can
Connection Pooling with Connector/J
* 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;
}
if (conn != null) {
try {
conn.close();
} catch (sqlexception sqlex) {
// ignore, as we can't do anything about it here
}
conn = null;
}
2098