Browse Prior Art Database

Database Connection Pool Management

IP.com Disclosure Number: IPCOM000123520D
Original Publication Date: 1998-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 3 page(s) / 177K

Publishing Venue

IBM

Related People

Hutchison, G: AUTHOR [+2]

Abstract

A running application or component server (such as an EJB server, Weblogic's Tengah, MS MTS, Sysbase's CTS or Component Broker) will pool database connections either in the monitor itself or in the equivalent of the ODBC/ JDBC subsystem. This is because opening connections to a database is a relatively slow operation. Typically connections to the same databases would be opened and closed repeately in a running server and these connections can be shared and recycled between users' transactions.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 33% of the total text.

Database Connection Pool Management

   A running application or component server (such as an EJB
server, Weblogic's Tengah, MS MTS, Sysbase's CTS or Component
Broker) will pool database connections either in the monitor itself
or in the equivalent of the ODBC/ JDBC subsystem.  This is because
opening connections to a database is a relatively slow operation.
Typically connections to the same databases would be opened and
closed repeately in a running server and these connections can be
shared and recycled between users' transactions.

   Recycling these connections via a pool between their use
by individual applications or transactions has a significant impact
on overall performance and most sophisticated servers implement a
form of connection pooling.

   When server objects request a connection the system
examines the connection pool to see if an appropriate connection can
be recycled.  Only if there is not a suitable candidate does an 'open
connection' command get flowed to the underlying database system.

   Similarly when a server object issues a 'close connection'
operation this connection is not actually closed to the underlying
database but is placed in the pool for possible recycling with little
overhead whereupon it may later be presented to a subsequent
requester as a 'new' connection.

   This system works well once the server has been running
for some time and the pool is fully populated with useful
connections.  Connections to different databases can be considered as
disjoint subsets of the pool as a connection can only ever be re-used
to the same database they were attached to initially.

   The number of connections in the pool plus the number of
connections in active use will grow initially but will stabilise
around the peak requirement for simultaneous connections to a
particular database.  Once this point is reached almost all 'open
connection' requests are likely to be satisfiable from the pool, the
server runs at optimum efficiency and this situation continues for
the remaining lifetime of the server's run.

   Until the server gets to this state unlucky user
applications will find the connection pool devoid of suitable
re-useable, pre-opened connections and will be delayed while a new
connection is opened by the system.  The applications cannot
reasonably predict when this will happen, all that will be observed
is an apparent speed up of tasks once the server has been running for
a while.  If the server is used in the same capacity between active
runs the connection pool is likely to stabilise with a very similar
profile of connections in terms of the overall number and makeup of
the particular destinations.

   While it would be impossible to produce an algorithm to
dynamically build an optimum connection pool on server start-up as it
is very difficult to predict the exact nature of future work arriving
at the server, the approach described here achieves a useful degree
of optimisation by recognising that...