CORBA 2.6 Programmer's Guide for C++

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
System 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