BEA WebLogic Server Tuning Guide

2.5 JDBC Statement Pooling

JDBC 3.0 introduced the concept of statement pooling, where a JDBC Statement object is tightly coupled with the

underlying physical DB Connection. A statement prepared for one connection cannot be used with another

connection. Note that statement pooling applies only to PreparedStatement objects. It is recommended that all

applications use PreparedStatements to prepare and execute SQL statements.

JDBC drivers implement statement pooling as follows:

1. The driver intercepts the close method call on the PreparedStatement object.

2. Instead of performing a physical close, the driver moves the object to a cache (after performing any necessary

cleanup on the PreparedStatement object so that it can be reused). The PreparedStatement object is typically

identified in the cache by the SQL statement, isolation level of the transaction, and other relevant information.

3. When a request to prepare the same SQL statement (with the same execution settings) is made, the JDBC driver

uses the cached object instead of going through the process of requesting the Database server to prepare the

statement again.

This provides an opportunity for the JDBC driver to pool PreparedStatement objects such that a given SQL statement

is prepared only once for a DB connection regardless of the number of logical Connections created off of it.

Statement pooling makes sense only with connection pooling, where logical Connection objects are closed but the

physical DB connection is long-lived.

Even though Statement pooling is formally introduced only in the JDBC 3.0 specification, many JDBC vendors have

implemented statement pooling functionality in their existing JDBC 2.x compliant drivers (which is the specification

mandated by J2EE 1.3).

The WebLogic Server implements statement pooling differently. Its implementation is independent of JDBC driver

pooling functionality. Statement pooling is referred to as “Statement Caching” in WebLogic Server.

As with Connection pooling, WebLogic Server creates a wrapper for all JDBC objects. When WebLogic Server

Statement caching is enabled, these wrapper objects intercept the close request and do the necessary work to clean

up the PreparedStatement object. Instead of delegating the close request to the underlying JDBC object, the

wrappers clean up the Statement object (using JDBC APIs) and move the statement to a free pool maintained by

WebLogic Server for later reuse.

2.6 WebLogic Server Execute Queues

In WebLogic Server, one of the critical resources configured for each managed server instance is the execute

queue. An execute queue represents the configuration of a “work” item queue, an associated pool of threads

servicing the queue and the thread priorities.

The actual usage of a thread pool is dependent on its execute queue. There are many predefined WebLogic Server

system execute queues, and there can also be application defined execute queues. Execute Queues form the basis

for the staged processing architecture of WebLogic Server.

One of the main execute queues in WebLogic Server is named the kernel queue (or the default queue). This

execute queue specifies the thread pool for the execution of WebLogic Server internal requests, application

requests, and handling sockets, among other things. An application can optionally define its own execute queue for

handling the application requests. If such a queue is not defined for an application, requests for that application

component are handled using the default execute queue.