CORBA 2.6.1 Programmer's Guide for C++

In the POA in the CORBA server application, ensure that the proprietary state policy has a value of STATELESS. You can do this either
by setting the lifespan policy to PERSISTENT or by directly setting the state policy to STATELESS.
Note:
The use of server pools provides a number of other advantages, including availability, automatic load balancing,
and process management (allowing the operator to configure, monitor, start, and stop processes). For further
information, refer to the NonStop TS/MP System Management Manual.
Stateful and Stateless Objects
In NonStop CORBA, objects can be either stateful or stateless. The use of stateful and stateless objects is closely related to the use of server
pools.
If an object is stateful, all operations directed to that object must be handled by the same servant (instance of the object). Operations directed
to other objects in the class can be handled by different servants in other processes. A stateful object can maintain state information (data
associated with a particular object instance) in memory between operations, because all requests for that reference go to the same instance.
With stateful objects, a client's object must always reference the specific instance of that object. By default, a CORBA object whose lifespan
policy is set to TRANSIENT is stateful.
If an object is stateless, operations directed to that object can result in requests to different servants, and these servants can reside in
different processes in a server pool. A stateless object cannot maintain state information in memory between operations, because the state
information would be available to only one process. A client reference can address any of a set of instances. Stateless objects are accessible
only when hosted in a server pool. By default, a CORBA object whose lifespan policy is set to PERSISTENT is stateless.
The same server pool can host both stateful and stateless objects. The distinction between stateful and stateless objects is made regardless of
whether the object is in a server pool or in a dedicated single server.
Server pools are managed by TS/MP, which provides scalability and load balancing by allowing multiple processes to work in parallel to perform
the same task. TS/MP also provides for availability: its monitor process, called PATHMON, automatically restarts a process that fails.
Note:
If your application requires network clients to access stateless objects, you must configure NonStop CORBA to use
Comm Server processes, as described in the NonStop CORBA 2.6.1 Administration Guide.
With respect to ORB routing of operation requests, stateless operations are more scalable than stateful operations, because they allow TS/MP
to distribute each incoming request to the next available process. This situation is analogous to using many bank tellers rather than one bank
teller. This factor makes it attractive to design classes to be stateless to maximize capacity.
However, in some cases, making an object stateless is inconvenient or costly. For example, if an object returns the results of a large SQL query
to a client using a cursor, the client must then perform multiple operations on the server to retrieve the data. If the object is stateless,
subsequent requests could reach different server processes, each of which would have to repeat the original query.
State Policy
By default, the value of the lifespan POA policy (PortableServer::LifeSpan) determines whether an object is stateful or stateless. A CORBA
object whose lifespan policy is PERSISTENT is stateless by default. A CORBA object whose lifespan policy is TRANSIENT is stateful by default.
The state policy (PortableServer::StatePolicy) is a NonStop CORBA proprietary policy you can apply to allow persistent stateful objects in a
server-pool process to be accessed by the GIOP over TS/MP transport protocol. (By default, an object with a lifespan policy of PERSISTENT is
assumed to be stateless.) The state policy has two values: STATEFUL and STATELESS.
Using Stateless Factory Objects to Create Stateful Servants
The use of stateless factory objects in combination with server pools provides a pattern for scalable stateful servants: you create a factory POA
with a state policy of STATELESS (if the lifespan policy is PERSISTENT, then STATELESS is set by default) and then create a separate POA
for the created servant (worker) objects with the state policy explicitly set to STATEFUL.
Figure 6–1 shows the operation of the factory and
worker objects with these POA settings.
Figure 6.1. Stateless Factory Object and Stateless Servant