Connection pooling

Using connection pools helps to both alleviate connection management overhead and decrease development tasks for data access.

Each time an application attempts to access a backend store (such as a database), it requires resources to create, maintain, and release a connection to that datastore. To mitigate the strain this process can place on overall application resources, the Application Server enables administrators to establish a pool of backend connections that applications can share on an application server. Connection pooling spreads the connection overhead across several user requests, thereby conserving application resources for future requests.

The Application Server supports JDBC 3.0 APIs for connection pooling and connection reuse. The connection pool is used to direct JDBC calls within the application, as well as for enterprise beans using the database.
Avoid trouble: Connection pooling is not supported in an application client. The application client calls the database directly and does not go through a data source. If you want to use the getConnection() request from the application client, configure the JDBC provider in the application client deployment descriptors, using Rational® Application Developer (RAD) or an assembly tool. The connection is established between application client and the database. Application clients do not have a connection pool, but you can configure JDBC provider settings in the client deployment descriptors.gotcha

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, the Application Server creates a separate instance of the connection pool in each application server that uses the data source or connection factory. For example:
  • [AIX HP-UX Linux Solaris Windows] 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).
  • [z/OS] Within a cluster, three z/OS® controllers each contain three servants that use myDataSource, and for the connection pool that the Application Server creates for every instance of myDataSource, you can set a Maximum Connections value of 10. Therefore, you can generate up to 90 connections (9 servants 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.

[AIX HP-UX Linux Solaris Windows] Other considerations for determining the maximum connections setting:
  • Each entity bean transaction requires an additional database connection, dedicated to handling the transaction.
  • If clones are used, one data pool exists for each clone.
  • [AIX] [HP-UX] [Solaris] On supported UNIX® systems, a separate DB2® process is created for each connection; these processes quickly affect performance on systems with low memory and cause errors.

It is also important to note that when using connection sharing, it is only possible to share connections obtained from the same connection pool.




Subtopics
Connection and connection pool statistics
Related concepts
Data sources
Unshareable and shareable connections
Transaction type and connection behavior
Related tasks
Tuning connection pools
Configuring connection factories for resource adapters within applications
Configuring J2EE Connector connection factories in the administrative console
Changing connection pool settings with the wsadmin tool
Related reference
Tuning the application serving environment
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 10:43:27 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v602web&product=was-nd-mp&topic=conpool
File name: cdat_conpool.html