BEA WebLogic Server Tuning Guide

5
//
// Once the DataSource is registered in the JNDI namespace an
// application can lookup the Datasource and use it
//
try
{
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup(“jdbc/warehouseDS”);
Connection dbconn = ds.getConnection(username, password);
// Execute db statements using the connection
dbconn.close();
}
catch (Exception e)
{
//handle exceptions
}
In the preceding code fragments, the Connection object represents a physical connection to the database. There is a
one-to-one mapping between the client connection and the physical connection to the database.
2.2 The Need for Connection Pooling
When many application processes operate in parallel, the one-to-one association between logical and physical
connections can be very expensive due to the significant overhead in establishing each connection.
In a J2EE application server environment, for example, applications share resources so they can be equitably
distributed and efficiently used. The common model in J2EE environments is for application components to own a
resource only for the duration of the work performed by the resource. Applications are expected to follow an
“acquire – use- release” sequence when using resources.
If J2EE components such as EJBs and servlets were to follow the one-to-one connection handling model in the
preceding code example, each request would incur a significant overhead – primarily to create the connection and
initialize the session with the database server. Moreover, in a J2EE environment, as in any application framework,
the application server needs to manage connections to make sure resources are efficiently used by all deployed
applications. Use of a one-to-one connection model would restrict that ability.
A more efficient alternative is to share a connection across many processes. To support this, the standard extension
specification for the JDBC 2.0 specification introduced a mechanism called “connection pooling.” A JDBC
connection pool represents a pool of connections to the respective database and is configured with minimum and
maximum capacities. Once a database connection is opened, the connection pooling mechanism lets these
database connections be shared by all applications that need database access. The overhead associated with
establishing a connection is incurred only once for each connection in the pool, instead of once per client request.
The J2EE application server monitors the pool of database connections, refreshing them as needed and ensuring
reliable database services for applications.
2.3 Connection Pooling as Described in the JDBC Specification
In the JDBC Connection pooling model, the database driver provides a ConnectionPoolDataSource implementation
and the application server provides the connection pooling infrastructure using the facilities provided by the JDBC
driver.
The sequence of events shown below describes the steps that occur in preparation for JDBC connection pooling for
a DataSource.