Databases Reference
In-Depth Information
necessary decreases the number of connections available to other users and
can increase the demand for resources. Don't forget to close them when the
database work is complete so that the connection can return to the pool for
reuse.
When Not to Use Connection Pooling
Some applications are not good candidates for using connection pooling. If your
applications have any of the following characteristics, you probably don't want to
use connection pooling. In fact, for these types of applications, connection pool-
ing may degrade performance.
•
Applications that restart numerous times daily
—This typically applies
only to architectures that are not using an application server
.
Depending on
the configuration of the connection pool, it may be populated with connec-
tions each time the application is started, which causes a performance
penalty up front.
•
Single-user applications, such as report writers
—If your application only
needs to establish a connection for a single user who runs reports two to
three times daily, the memory usage on the database server associated with a
connection pool degrades performance more than establishing the connec-
tion two or three times daily.
•
Applications that run single-user batch jobs, such as end-of-
day/week/month reporting
—
Connection pooling provides no advantage
for batch jobs that access only one database server, which typically equates to
only one connection. Furthermore, batch jobs are usually run during off
hours when performance is not as much of a concern.
Performance Tip
When your application does not use connection pooling, avoid connect-
ing and disconnecting multiple times throughout your application to exe-
cute SQL statements, because each connection might use five to ten
times as many network requests as the SQL statement.
