Connection Pooling

From Apache OpenOffice Wiki
Jump to: navigation, search

In a basic implementation, there is a 1:1 relationship between the object used by the client and physical database connection. When the Connection object is closed, the physical connection is dropped, thus the overhead of opening, initializing, and closing the physical connection is incurred for each client session. A connection pool solves this problem by maintaining a cache of physical database connections that can be reused across client sessions. Connection pooling improves performance and scalability, particularly in a three-tier environment where multiple clients can share a smaller number of physical database connections. In API, the connection pooling is part of a special service called the ConnectionPool. This service manages newly created connections and reuses old ones when they are currently unused.

The algorithm used to manage the connection pool is implementation-specific and varies between application servers. The application server provides its clients with an implementation of the interface that makes connection pooling transparent to the client. As a result, the client gets better performance and scalability. When an application is finished using a connection, it closes the logical connection using close() at the connection interface This closes the logical connection, but not the physical connection. Instead, the physical connection is returned to the pool so that it can be reused. Connection pooling is completely transparent to the client: A client obtains a pooled connection from the service calling getConnectionWithInfo() at its interface and uses it just the same way it obtains and uses a non-pooled connection.

The following sequence of steps outlines what happens when an SDBC client requests a connection from a ConnectionPool object:

  1. The client obtains an instance of the from the global service manager and calls the same methods on the ConnectionPool object as on the DriverManager.
  2. The application server providing the ConnectionPool implementation checks its connection pool for a suitable PooledConnection object, a physical database connection, that is available. Determining the suitability of a given PooledConnection object includes matching the client's user authentication information or application type, as well as using other implementation-specific criteria. The lookup method and other methods associated with managing the connection pool are specific to the application server.
  3. If there are no suitable PooledConnection objects available, the application server creates a new physical connection and returns the PooledConnection. The ConnectionPool is not driver specific. It is implemented in a service called
  4. Regardless if the PooledConnection has been retrieved from the pool or created, the application server does internal recording to indicate that the physical connection is now in use.
  5. The application server calls the method PooledConnection.getConnection() to get a logical Connection object. This logical Connection object is a handle to a physical PooledConnection object. This handle is returned by the XDriverManager method getConnectionWithInfo() when connection pooling is in effect.
  6. The logical Connection object is returned to the SDBC client that uses the same Connection API as in the standard situation without a ConnectionPool. Note that the underlying physical connection cannot be reused until the client calls the XConnection method close().

In API, connection pooling is enabled by default and can be controlled through Tools - Options - Database . If a connection from a data source defined in API is returned, this setting applies to your connection, as well. To take advantage of the pool independently of API data sources, use the instead of the DriverManager.

Content on this page is licensed under the Public Documentation License (PDL).
Personal tools
In other languages