Oracle7 Server Distributed Systems Volume I: Distributed Data
How SQL*Net Establishes Connections to a Multi-Threaded Server
A multi-threaded server enables many clients to connect to the same server without the need for dedicated server processes for each client. Using the Multi-Threaded Server enables you to minimize the memory and processing resources needed on the server side as the number of connections to the database increases.
The sequence of events that occurs with the Oracle7 multi-threaded server can occur in two stages:
- The listener and the multi-threaded server start up.
- Clients connect to the Oracle7 multi-threaded server.
What Happens When an MTS and Listener are Started
During initial startup of the Oracle7 multi-threaded server and the listener, the following sequence occurs:
1. The listener starts and listens for the addresses pre-configured in the LISTENER.ORA file. (The network administrator creates this file with Network Manager.)
2. The DBA starts the Oracle7 database. Dispatchers start according to the configuration parameters in the initialization parameter file. Dispatchers each use one particular protocol. There may be many, on assorted protocols. Each dispatcher performs a wildcard listen for the protocol assigned to it.
Note: A wildcard listen is where the server process listens, but informs the underlying protocol stack (or operating system in the case of the IPC Protocol Adapter) that it has no preference as to what address it listens for other than specifying the protocol on which it wishes to perform the operation. As a result, many operating systems will choose a free listening address and automatically assign this to the requesting server process.
Note: If step 2 is performed before step 1, the dispatchers will be unable to contact the listener in step 3. If this occurs, each dispatcher loops and attempts to reconnect to the listener every 60 seconds. Meanwhile, incoming connection requests will be handled through other means (prespawned dedicated or newly-spawned dedicated server processes).
The listener and the Oracle7 multi-threaded server should be ready for incoming connections, at this point. You can check which dispatchers have registered with the Listener by typing
lsnrctl services listener_name
How a Multi-Threaded Server Connection Request is Handled
The following is how a multi-threaded server connection
request is handled:
1. The client calls the preconfigured well-known address of
the listener.
2. The listener receives the connection request, performs the connection handshake and determines if the client is allowed to connect (by checking the list of SIDs it listens for), at which point it continues with step 3. If not, the listener refuses the connection and then resumes at step 6.
3. The listener issues a redirect message back to the client containing the address of the least-called dispatcher that is listening on the protocol used by the client.
4. The client closes the connection to the listener and then establishes a new connection to the dispatcher, using the address provided by the Listener in the redirect message.
5. The listener and dispatcher perform a short handshake to update each other of the presence of a new connection. This is so that the listener can load balance connections between dispatchers running on the same protocol.
6. The listener resumes listening for incoming connections.
When an Oracle7 Server has been configured as a multi-threaded server, incoming connections are always routed to the dispatcher unless the connection request specifically requests a dedicated server (by having SERVER=DEDICATED in the CONNECT_DATA portion of the connect descriptor) or no dispatchers are available.