Databases Reference
In-Depth Information
Multi-Threaded Server/shared server
Oracle7 introduced the Multi-Threaded Server (MTS, renamed the shared server in
Oracle9
i
) (described in
Chapter 2
) to allow Oracle to support larger user populations.
While shared server / MTS reduced the number of server processes, each client still used
its own physical network connection. The resources for network connections aren't
unlimited, so Oracle8 introduced two solutions for increasing the capabilities of the
actual network socket layer at the operating system level:
Oracle Net connection pooling
Allows the client population to share a pool of shared physical network connections.
Idle clients transparently “time out,” and their network connections are returned
to the pool to be used by active clients. Each idle client maintains a virtual connec‐
tion with Oracle and will get another physical connection when activity resumes.
With the Oracle security model, authentication is separate from a specific connec‐
tion, so a single pooled connection can represent different users at different times.
Connection pooling is suitable for applications with clients that connect but aren't
highly active all the time.
Oracle Net Connection Manager
Reduces the number of network connections used on the database server. Clients
connect to a middle-tier machine running the Oracle Net Connection Manager
(CMAN). The Connection Manager multiplexes the traffic for multiple clients into
one network connection per Oracle Net dispatcher on the database server. Unlike
connection pooling, there is no notion of “timeout” for a client's virtual network
connection. The Oracle network topology can include multiple machines running
the Connection Manager to provide additional scalability and fault tolerance.
In terms of scalability, you can think of connection pooling as the middleweight solution
and multiplexing via Connection Manager as the heavyweight solution.
Figure 9-5
illustrates these two network scaling technologies.
Connection Manager became more flexible in Oracle Database 10
g
, with the added
ability to dynamically alter configuration parameters without shutting down Connec‐
tion Manager and improved access rules to filter CMAN traffic.
Oracle Database 11
g
added Database Resident Connection Pooling, which can be even
more efficient for high-volume, middle-tier connections to the database. Database Res‐
ident Connection Pooling eliminates the need to store session information by pooling
sessions as well as servers, and this feature also eliminates the need to use a dispatcher
in communications between the middle tier and the database.
