Connection pooling shares connections across different user requests to maintain performance and reduce the number of new connections that must be created. Compare the following transaction sequences to picture the efficiency offered by pooling connections.

Example A: Without connection pooling

  1. The application creates a connection.
  2. The application sends a query to the Hybrid Data Pipeline connectivity service.
  3. The application obtains query results.
  4. The application displays the result to the end user.
  5. The application ends the connection.

Example B: With connection pooling

  1. The application requests a connection from the connection pool.
  2. If an unused connection exists, it is returned by the pool; otherwise, the pool creates a new connection.
  3. The application sends a query to the Hybrid Data Pipeline connectivity service.
  4. The application obtains query results.
  5. The application displays the result to the end user.
  6. The application closes the connection, which returns the connection to the pool.
    Note: The application calls the close() method, which allows the connection to remain open. The pool receives notification of the close request.

Connection pooling is performed in the background and does not affect how an application is coded. To use connection pooling, an application must use a DataSource object (an object implementing the DataSource interface) to obtain a connection instead of using the DriverManager class. A DataSource object registers with a JNDI naming service. Once a DataSource object is registered, the application retrieves it from the JNDI naming service in the standard way.

Note: A class implementing the DataSource interface may or may not provide connection pooling.

There is a one-to-one relationship between a JDBC connection pool and a Hybrid Data Pipeline Driver for JDBC data source, so the number of connection pools used by an application depends on the number of data sources configured to use connection pooling. If multiple applications are configured to use the same data source, those applications share the same connection pool as shown in the following figure.



An application may use only one data source, but allow multiple users, each with their own set of login credentials. The connection pool contains connections for all unique users using the same data source as shown in the following figure.



A connection pool contains two types of connections:

  • Active connection is a connection that is in use by the application.
  • Idle connection is a connection in the connection pool that is available for use.

Connection pool implementations, such as the DataDirect Connection Pool Manager, use objects that implement the javax.sql.ConnectionPoolDataSource interface to create the connections managed in the pool. All Progress DataDirect DataSource objects implement the ConnectionPoolDataSource interface.

You can create your own connection pool implementation using the DataDirect Connection Pool Manager as described in Using a DataDirect connection pool. A connection pool implementation creates PooledConnections, using the getPooledConnection() method of the ConnectionPoolDataSource interface. Then, the Pool Manager registers itself as a listener to the PooledConnection. When an application requests a connection, the Pool Manager assigns an available connection. If a connection is unavailable, the Pool Manager establishes a new connection and assigns it to that application.

When the application closes the connection, the Pool Manager is notified by the driver by the ConnectionEventListener interface that the connection is free and available for reuse. The Pool Manager is also notified by the ConnectionEventListener interface if the connection is corrupted so that the Pool Manager can remove that connection from the pool.