Databases Reference
In-Depth Information
Your choices for implementing connections are as follows:
•
Obtain a connection from a connection pool. Read the section, “Using
Connection Pooling,” page 12.
•
Create a new connection one at a time as needed. Read the section, “Creating
a New Connection One at a Time as Needed,” page 16.
The right choice mainly depends on the CPU and memory conditions on the
database server, as we explain throughout this section.
Facts About Connections
Before we discuss how to make this decision, here are some important facts about
connections:
•
Creating a connection is performance-expensive compared to all other tasks
a database application can perform.
•
Open connections use a substantial amount of memory on both the data-
base server and database client machines.
•
Establishing a connection takes multiple network round trips to and from
the database server.
•
Opening numerous connections can contribute to out-of-memory condi-
tions, which might cause paging of memory to disk and, thus, overall perfor-
mance degradation.
•
In today's architectures, many applications are deployed in connection
pooled environments, which are intended to improve performance.
However, many times poorly tuned connection pooling can result in perfor-
mance degradation. Connection pools can be difficult to design, tune, and
monitor.
Why Connections Are Performance-Expensive
Developers often assume that establishing a connection is a simple request that
results in the driver making a single network round trip to the database server to
initialize a user. In reality, a connection typically involves many network round
trips between the driver and the database server. For example, when a driver con-
nects to Oracle or Sybase, that connection may take anywhere from seven to ten
network round trips to perform the following actions:
•
Validate the user's credentials.
•
Negotiate code page settings between what the database driver expects and
what the database has available, if necessary.
