Using CMAN's Session Multiplexing Feature

Session multiplexing, the feature older material calls connection concentration, is fully supported in Oracle AI Database 26ai. Putting it to use takes two separate pieces of configuration: enabling multiplexing on the database side, and routing the clients you want concentrated through CMAN instead of straight to the database.

A common deployment pattern runs CMAN on the same computer as an application web server, letting that web server route its client sessions through CMAN to the database. This is particularly useful for web applications, where session availability and response time matter and a large number of clients may each have only light or intermittent database usage; one CMAN instance with multiple gateway processes can let thousands of concurrent users share a database connection pool that would otherwise require thousands of individual connections.

Why Use Session Multiplexing

Session multiplexing is recommended for networks where continuous connectivity is required, and it carries a specific, documented set of advantages: it limits the network resources each process consumes, supports large client populations, maximizes the number of client and server sessions that fit over a limited number of process connections, optimizes resource utilization generally, lets you identify and monitor real users rather than shared connections, enables mid tier applications to support additional services, and needs only a single transport for clients running multiple applications or a single network connection for database links between dispatchers. It has one real tradeoff, stated just as plainly in Oracle's own documentation: clients have to connect to Oracle Connection Manager to get any of this, which is exactly the configuration this lesson walks through.

Step 1: Enable Session Multiplexing on the Database

Session multiplexing is a shared server feature, so the destination database must already be configured for shared server, with multiplexing turned on at the dispatcher. This is set with the MULTIPLEX attribute of the DISPATCHERS parameter in the database's initialization parameter file:

DISPATCHERS="(PROTOCOL=tcp)(MULTIPLEX=on)"

MULTIPLEX accepts more than a plain on or off: 1, on, yes, true, or both enables multiplexing for both incoming and outgoing sessions, in enables it only for incoming client sessions, out enables it only for outgoing sessions such as database link connections between dispatchers, and 0, off, no, or false disables it entirely.

Older course material described this step using MTS_DISPATCHERS and a MULTIPLEXING=ON attribute. Both names are retired: Oracle renamed the Multi-Threaded Server (MTS) to shared server back in Oracle 9i, and the parameter has been DISPATCHERS with a MULTIPLEX attribute since the same renaming.

One more modernization worth a note: the initialization parameter file referred to here can mean either a PFILE, the traditional init.ora text file, or an SPFILE, the server side binary parameter file Oracle has recommended by default for years. PFILE is still fully supported and not deprecated, it is simply less convenient for ongoing administration, since an SPFILE lets you issue ALTER SYSTEM commands that persist across restarts without manually editing a text file. Either one accepts the DISPATCHERS parameter shown above.

Step 2: Configure the Database Server for Oracle Connection Manager

With multiplexing enabled at the dispatcher, the database still needs to register itself with CMAN. This means the database's tnsnames.ora file needs the relevant service name entry, and its initialization parameter file needs a descriptor pointing at CMAN's listening address, so the database knows to register there. If you have not settled on a consistent approach to naming and distributing tnsnames.ora across your environment, our guide to creating and maintaining the tnsnames.ora file covers that, including testing entries with TNSPING before relying on them.
If the database you want to register is on a different node than CMAN, this registration needs one more piece: the cman.ora parameter VALID_NODE_CHECKING_REGISTRATION, covered in the third lesson of this module, needs to allow the remote node, either by adding it to REGISTRATION_INVITED_NODES or by setting VALID_NODE_CHECKING_REGISTRATION appropriately. Without this, CMAN's default behavior only accepts registration from local databases.

This registration is the same mechanism covered in the second lesson of this module: once the database registers its service with CMAN, that information flows into the registration chain where a gateway process registers with CMADMIN and CMADMIN registers with the listener, so the listener always knows which gateway to hand an incoming connection to. A database that has not registered with CMAN simply will not be reachable through it, no matter how correctly the client side is configured.

Step 3: Route Client Connections Through CMAN

The last piece is pointing clients at CMAN instead of at the database directly. A client's connect descriptor needs CMAN's address rather than the database's:

sales=
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=cman-pc)(PORT=1521))
    (CONNECT_DATA=(SERVICE_NAME=example.com)))

The modern way to build this is through Oracle Net Manager's Net Service Name wizard rather than hand editing the file: start Oracle Net Manager, select Service Naming, click the plus sign or choose Create from the Edit menu to open the Net Service Name wizard, enter a name and click Next, select TCP/IP as the protocol on the Protocol page, specify CMAN's host and port on the Protocol Settings page, default port 1521, and enter the service name on the Service page. Do not click Test at this point, since a connection cannot be verified until the rest of the setup is in place; click Finish to save the new net service name.
Older course material described this as a Net8 Assistant step under Profile and the General tab. Net8 Assistant was renamed Oracle Net Manager in the same 9i renaming that retired MTS and replaced the older Net8 connectivity model generally; for a fuller look at how Oracle connectivity has evolved since then, see our guide to modern Oracle connection methods. Routing through CMAN today is configured on the Service Naming page of Oracle Net Manager, not a general profile setting.

A Caveat: Oracle Notification Service

One practical caveat worth knowing before deploying this in production: Oracle Notification Service (ONS) auto-configuration does not work for connections made through CMAN. If your client stack relies on ONS, for Fast Application Notification with a Universal Connection Pool client, for example, it needs to be configured manually, with connectivity confirmed from the client to the ONS server on its port, 6200 by default. Consult the relevant client developer's guide, Oracle Universal Connection Pool for JDBC clients, Oracle Call Interface for OCI clients, or Oracle Data Provider for .NET for ODP.NET clients, for the manual configuration steps.
Once all three steps are in place, verify the setup with a real client connection rather than relying on the Net Service Name wizard's Test button, which deliberately is not available until after the service name is created, since CMAN registration needs to complete first. A successful connection through CMAN, together with CMAN's own logs showing the session being accepted and handed to a gateway process, confirms the three pieces are working together correctly.

It is easy to confuse CMAN's session multiplexing with Database Resident Connection Pooling (DRCP), since both are commonly described as connection pooling, but they are separate features. DRCP pools database server processes directly, with no CMAN involvement required: a client requests a pooled connection by appending :POOLED to an Easy Connect string, for example oraclehost.company.com:1521/books.company.com:POOLED, or by setting (SERVER=POOLED) in a connect descriptor's CONNECT_DATA, and the database's own connection broker hands out a pooled server process. CMAN's session multiplexing, by contrast, works at the network layer, funneling many client sessions through fewer physical connections to the dispatcher. The two can be used together, but configuring one does not configure the other.

Putting the Three Steps Together

Seen end to end, enabling session multiplexing touches three different configuration surfaces rather than one. On the database side, the initialization parameter file gets the multiplexing enabled dispatcher entry from Step 1. Still on the database side, but now talking to CMAN rather than to clients, tnsnames.ora and the service registration descriptor from Step 2 tell the database where CMAN is and let it register there, subject to CMAN's own node checking rules. On the client side, the connect descriptor or net service name from Step 3 points at CMAN's address instead of the database's, so ordinary client connection requests flow through CMAN rather than around it. Each piece is simple on its own; the feature only works when all three are in place together, which is why a session multiplexing deployment that is not working as expected is usually missing one of these three pieces rather than misconfigured in a complicated way.