CORBA 2.6 Administration Guide

Stateful server pool●
Single process●
Whether a server runs as a server pool or as a single process depends on two configuration steps:
For a server to run as a server pool, you must define the server in a PATHCOM configuration file.
It is in that file that you specify the number of servers in the server pool and several other
characteristics important for process management.
You should use scripts to configure and run your application servers. These scripts are similar to
the scripts that you use to start and run the NonStop CORBA system. In the scripts, you configure
your servers in the same way the NonStop CORBA system processes are configured.
●
For all types of servers, you indicate which protocols the server will support in the server's
configuration profile. You define the protocols in the configuration database by using the
configuration tool. For example, a server that is specified as using the TS/MP protocol runs as a
server pool.
●
Whether a server pool accepts stateless or stateful requests depends on whether its object classes require
stateless or stateful processing.
In NonStop CORBA, objects can be either stateful or stateless. If an object is stateless, each method
invocation for the object can be handled by a different server process in the pool. A stateless object
cannot maintain state information in memory between calls, because the state information would be
available to only one process. Note that stateless objects typically make sense only when hosted in a
server pool.
If an object is stateful, the first method invocation for the object goes to any free server process in the
pool, and any subsequent requests go to that same process. A stateful object can maintain state
information in memory between method invocations, because only one process needs access to the
information.
The same server pool can host both stateless and stateful objects. The distinction between stateless and
stateful is made regardless of whether the object is in a server pool or in a dedicated single server.
Note: For the purpose of this discussion, a server pool is stateless if it hosts only objects that
require stateless processing; it is stateful if it hosts one or more objects that require stateful
processing.
From an ORB method-routing viewpoint, stateless requests are much more efficient than stateful requests
because of the queuing efficiency that TS/MP can provide (analogous to a single line for all bank tellers
rather than one line per bank teller). This factor makes it attractive to design classes to be stateless to
maximize throughput.
However, in some cases, it would be inconvenient or costly for an object to be stateless. For example, if
an object returns the results of a large SQL query to a client using a cursor, the client must make multiple
method invocations on the server. If the object is stateless, subsequent method invocations could reach
different server processes, each of which would have to repeat the original query.
Stateless and stateful server pools are managed by TS/MP, which provides for scalability and load