Shared Server -- Part II

So, to continue with our shared server series, let's begin with how a user connects through a shared server connection:
When a dedicated server is used, the listener spawns a dedicated server process for each separate client connection. The listener then gets out of the way and the client is connected to the server process dedicated to it. In a shared server environment, however, the listener does not spawn a separate process for each connecting user. Instead, the listener connects the user to a process known as dispatcher, which assumes the task of communicating with the clients. The listener, instead of handing off the connection to a dedicated server process, does so to the most lightly loaded dispatcher, which in turn handles all communication with the client for the duration of the session.

At least one dispatcher process is already there when a client initiates a connection request. To the question of how many dispatchers need to be configured, my opinion is that you need one for each protocol you support, while in practice you may need more than that, because of your operating system's limitations regarding the number of connections it will support, as well as the issue of performance. There may be a serious performance degradation if your clients are busy and you have fewer number of dispatchers configured, although as I will show later, changing the number of dispatchers is pretty simple. A good starting point will be to base the number of dispatchers on the number of connections to be made. Later on, you can make adjustments by monitoring how busy your dispatchers remain.
Dispatchers is the key initialization parameter that need to be set in order to implement shared server. Let me show it on the server of Creative Infotech, my employer.

system@ORCL-SQL>>sho parameter disp

NAME_COL_PLUS_SHOW_PARAM TYPE
-------------------------------------------------------------------------------- -----------
VALUE_COL_PLUS_SHOW_PARAM
----------------------------------------------------------------------------------------------------
dispatchers string
(PROTOCOL=TCP) (SERVICE=orclXDB)
max_dispatchers integer

I have not configured shared server on my system and as such no values have been set either for the dispatchers or max_dispatchers initialization parameters. Now, let's configure a few dispatchers:

system@ORCL-SQL>>alter system set dispatchers="(protocol=TCP)(dispatchers=3)(connections=100)"

System altered.
system@ORCL-SQL>>alter system set dispatchers="(protocol=NMP)(dispatchers=2)(connections=100)";


System altered.
system@ORCL-SQL>>alter system set max_dispatchers=10;

System altered.

system@ORCL-SQL>>column NAME_COL_PLUS_SHOW_PARAM format a40
system@ORCL-SQL>>column VALUE_COL_PLUS_SHOW_PARAM format a40
system@ORCL-SQL>>sho parameter disp

NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM
---------------------------------------- ----------- ----------------------------------------
dispatchers string (protocol=TCP)(dispatchers=3)(connection
s=100), (protocol=NMP)(dispatchers=2)(co
nnections=100)
max_dispatchers integer 10
system@ORCL-SQL>>

That's it. Pretty straightforward and simple. However things can become complicated when you force an address with the dispatcher. You may want to do so , for example, to get around firewall issues or specify a particular port.The Listener attribute of the Dispatcher parameter allows you to specify which listener you want your dispatcher to register with. By default dispatchers register on the listener monitoring port 1521 on the local machine, but if your listener is running on a different machine or you to regiter with a non default listerner you need to use the Listener attribute to specify that.

Ok, now let's get back to what the dispatcher actually do. For a start, the dispatcher takes the requests of the clients and place it on a request queue.

The request queue is an area of memory in the System Global Area(SGA). The shared server process monitors the request queue. When a request is put on the queue, an available sever process picks it out of the queue and services it. Requests are handled in first in-first out basis(FIFO) as shared servers become available.

After a request has been serviced it is placed in a response queue. The response queue is an area of memory within the SGA and it is dispatcher specific. That means that while all the requests are placed in a single queue, each dispatcher will have it's own response queue. When a dispatcher finds a response in it's response queue, it sends that response back to the client that initiated the request.
In my next post, I will take up the issues of which data dictionary views contain what information vis-a vis shared servers etc., large pool configuration and other sundry items.