Using connection pools helps to both alleviate connection management overhead and decrease development tasks for data access.
Note: This version of WebSphere Application Server does not support JDBC 3.0.
Benefits of connection pooling
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 data source. Because users connect and disconnect frequently with applications on the Internet, the application requests for data access can surge to considerable volume. Consequently, the total datastore overhead quickly becomes high for Web-based applications, and performance deteriorates. When connection pooling capabilities are used, however, Web applications can realize performance improvements of up to 20 times the normal results.With connection pooling, most user requests do not incur the overhead of creating a new connection because the data source can 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. The overhead of a disconnection is avoided. Each user request incurs a fraction of the cost for connecting 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.
When to use connection pooling
Use WebSphere connection pooling in an application that meets any of the following criteria:How connections are pooled together
When you configure a unique data source or connection factory, you must give it a unique Java Naming and Directory Interface (JNDI) name. This JNDI name, along with its configuration information, is used to create the connection pool. A separate connection pool exists for each configured data source or connection factory.
Furthermore, Application Server creates a separate instance of the connection pool in each application server that uses the data source or connection factory. For example, if you run a three server cluster in which all of the servers use myDataSource, and myDataSource has a Maximum Connections setting of 10, then you can generate up to 30 connections (three servers times 10 connections). Consider how this behavior potentially impacts the number of connections that your backend resource can support. See Connection pool settings for more information.
Other considerations for determining the Maximum Connections setting:
It is also important to note that when using connection sharing, it is only possible to share connections obtained from the same connection pool.
Avoiding a deadlock
Deadlock can occur if the application requires more than one concurrent connection per thread, and the database connection pool is not large enough for the number of threads. Suppose each of the application threads requires two concurrent database connections and the number of threads is equal to the maximum connection pool size. Deadlock can occur when both of the following are true:
To avoid deadlock, code the application to use, at most, one connection per thread. If the application is coded to require C concurrent database connections per thread, the connection pool must support at least the following number of connections, where T is the maximum number of threads.
T * (C - 1) + 1The connection pool settings are directly related to the number of connections that the database server is configured to support. If the maximum number of connections in the pool is raised, and the corresponding settings in the database are not raised, the application fails and SQL exception errors are displayed in the stderr.log file.