Java Reference
In-Depth Information
er that is doing the statement pooling and want to provide a simpler driver. Some application
servers do not provide and manage a pool; they expect the JDBC driver to handle that task
and don't want to complicate their code. Both arguments have merit (though a JDBC driver
that does not provide a statement pool puts a burden on you if you are the developer of a
standalone application). In the end, you'll have to sift through this landscape and make sure
that the statement pool is created somewhere.
Since there are no standards, you may encounter a situation where both the JDBC driver and
the application server are capable of managing the prepared statement pool. In that case, it is
important that only one of them be configured to do so. From a performance perspective, the
better choice will again depend on the exact combination of driver and server. As a general
rule, you can expect the JDBC driver to perform better statement pooling. Since the driver is
(usually) specific to a particular database, it can be expected to make better optimizations for
that database than the more generic application server code.
To enable statement pooling (or caching) for a particular JDBC driver, consult that driver's
documentation. In many cases, you need only set up the driver so that the maxStatements
property is set to the desired value (i.e., the size of the statement pool). Other drivers may re-
quire additional settings (e.g., the Oracle JDBC drivers require that specific properties be set
to tell it whether to use implicit or explicit statement caching).
QUICK SUMMARY
1. Java applications will typically execute the same SQL statement repeatedly. In
those cases, reusing prepared statements will offer a significant performance
boost.
2. Prepared statements must be pooled on a per-connection basis. Most JDBC
drivers and Java EE frameworks can do this automatically.
3. Prepared statements can consume a significant amount of heap. The size of the
statement pool must be carefully tuned to prevent GC issues from pooling too
many very large objects.
JDBC Connection Pools
Connections to a database are time-consuming to create, so JDBC connections are another
prototypical object that you should reuse in Java.
Search WWH ::




Custom Search