Connection pools
Database connections:
- sometimes take a relatively long time to create.
- are always limited in number (most medium- and low-end servers have a maximum
of ~100 connections).
- are resources which must be systematically released when no longer in
use.
The last point is critical: connections must always be properly released when no
longer needed. Failure to do so will eventually cause the application to "hang", and fail to respond
to user actions. All code in your application regarding connections should be treated with
special care.
To ensure that database connections are used as efficiently as possible,
many applications make use of a connection pool, which can sometimes
improve performance in a distributed application. An application will use
a connection pool as follows:
-
upon startup, the application creates a pool of database connections (or,
the application's environment may already include a connection pool).
-
during normal operation, the application simply fetches a connection from
the pool every time a database operation is performed. This is often
done in a "just-in-time" manner. That is, the application does not keep
a long-lived reference to its connection objects, but will rather fetch,
use, and then close each connection in a single method.
-
when the calling code is finished with the connection, it calls a
close
method, but the underlying connection is not actually closed - rather,
it's simply returned to the connection pool.
-
when the application shuts down, the connection pool it created upon startup
(if any) is shut down as well.
A database driver may contain a connection pool as part of its services,
through its implementation of the
javax.sql.DataSource
interface. DataSource
objects are used with JNDI.
The popular Tomcat tool
implements JNDI, and connection pooling is described in its documentation.
It's not difficult to use.
See Also :