Originally, JDBC 1.0 defined the Java APIs for access to relational databases.
With the introduction of JDBC 2.0, the APIs were split into two parts:
Connection pooling is the maintenance of a group of database connections for reuse by applications on an application server. It is part of the JDBC 2.0 Optional Package API. Another part of the Optional Package API provides for the use of the Java Naming and Directory Interface (JNDI) and DataSource objects instead of JDBC 1.0 DriverManager objects to access relational data.
Each time a resource attempts to access a database, it must connect to that database. A database connection incurs overhead -- it requires resources to create the connection, maintain it, and then release it when it is no longer required. The overhead is particularly high for Web-based applications, because Web users connect and disconnect more frequently. In addition, user interactions are typically shorter because of the surfing nature of Internet users. Often, more effort is spent connecting and disconnecting than is spent during the interactions themselves. Further, because Internet requests can arrive from virtually anywhere, usage volumes can be large and difficult to predict.
To address the problem, WebSphere Application Server enables administrators to establish a pool of database connections that can be shared by applications on an application server. Connection pooling spreads the connection overhead across several user requests, thereby conserving resources for future requests.
Connection pooling can improve the response time of any application that requires connections, especially Web-based applications. When a user makes a request over the Web to a resource, the resource accesses a datasource. Most user requests do not incur the overhead of creating a new connection because the datasource may locate and use an existing connection from the pool of connections. When the request is satisfied and the response is returned to the user, the resource returns the connection to the connection pool for reuse. Again, the overhead of a disconnect is avoided. Each user request incurs a fraction of the cost of connection or disconnecting. After the initial resources are used to produce the connections in the pool, additional overhead is insignificant because the existing connections are reused.
Caching of prepared statements is another mechanism by which WebSphere connection pooling improves Web-based application response times. A cache of previously prepared statements is available on a connection. When a new prepared statement is requested on a connection, the cached prepared statement is returned, if available. This caching reduces the number of costly prepared statements created, which improves response times. The cache is useful for applications that tend to prepare the same statement time and again.
In addition to improved response times, WebSphere connection pooling provides a layer of abstraction from the database that can buffer the client application and make different databases appear to work in the same way relative to an application. This buffering makes it easier to switch application databases because the application code does not have to deal with vendor-specific SQL exceptions but, rather, with a WebSphere connection pooling exception.
For a comprehensive treatment of WebSphere connection pooling and data access, be sure to read the IBM whitepaper to be published on the Web during the summer of 2001.