Database Reference
In-Depth Information
Database Resident Connection Pooling (DRCP)
Database Resident Connection Pooling (DRCP) is an optional method of connecting to the database and establishing
a session. It is designed as a more efficient method of connection pooling for application interfaces that do not
support efficient connection pooling natively—such as PHP, a general purpose web scripting language. DRCP is a
mixture of dedicated server and shared server concepts. It inherits from a shared server the concept of server process
pooling, only the processes being pooled will be dedicated servers, not shared servers; it inherits from the dedicated
server the concept of—well—being dedicated.
In a shared server connection, the shared server process is shared among many sessions and a single session
will tend to use many shared servers. With DRCP, this is not true; the dedicated server process that is selected from
the pool will become dedicated to the client process for the life of its session. In a shared server, if I execute three
statements against the database in my session, there is a good chance that the three statements will be executed by
three different shared server processes. Using DRCP, those same three statements would be executed by the dedicated
server assigned to me from the pool—that dedicated server would be mine until my session releases it back to the
pool. So DRCP has the pooling capabilities of a shared server and the performance characteristics of a dedicated
server. We'll explore performance of a dedicated versus a shared server more later in this chapter.
Connections vs. Sessions
It surprises many people to discover that a connection is not synonymous with a session. In most people's eyes they
are the same, but the reality is they do not have to be. A connection may have zero, one, or more sessions established
on it. Each session is separate and independent, even though they all share the same physical connection to the
database. A commit in one session does not affect any other session on that connection. In fact, each session using
that connection could use different user identities!
In Oracle, a connection is simply a physical circuit between your client process and the database instance—a
network connection, most commonly. The connection may be to a dedicated server process or to a dispatcher.
As previously stated, a connection may have zero or more sessions, meaning that a connection may exist with no
corresponding sessions. Additionally, a session
may or may not
have a connection. Using advanced Oracle Net features
such as connection pooling, a physical connection may be dropped by a client, leaving the session intact (but idle).
When the client wants to perform some operation in that
session
, it would reestablish the physical
connection
. Let's
define these terms in more detail:
•
Connection
: A connection is a physical path from a client to an Oracle instance. A connection
is established either over a network or over an IPC mechanism. A connection is typically
between a client process and either a dedicated server or a dispatcher. However, using Oracle's
Connection Manager (CMAN), a connection may be between a client and CMAN, and CMAN
and the database. Coverage of CMAN is beyond the scope of this topic, but
Oracle Database
some detail.
•
Session
: A session is a logical entity that exists in the instance. It is your
session state
, or a
collection of data structures in memory that represents your unique session. It is what would
come first to most people's minds when thinking of a database connection. It is your session
on the server, where you execute SQL, commit transactions, and run stored procedures.
