Manual

Syntax:
-DSessionBasedLoadBalancing=[ true | false ]
NOTE: The default value of -DSessionBasedLoadBalancing is set to true.
For example, if you want to enable the SessionBasedLoadBalancing feature for your
MyFaces application and save the application sessions in a persistent store, set the Arglist
as:
Server $server_objectcode {
…
…
…
…
Arglist -DSessionBasedLoadBalancing=true \
-DSaveSessionOnCreation=true \
…
…
…
…
}
where,
server_objectcode is mapped to the servlet.ssc object in the <iTP WebServer
deployment directory>/bin directory on OSS.
While setting arguments, consider the following:
1. If both the SaveSessionOnCreation and SessionBasedLoadBalancing options
are set to false, and if a Persistent Manager is configured with a persistent store, all
sessions are written to the store at the end of each request processing cycle. As a result,
all changes made to the session by the user application are persisted to the store.
2. When SessionBasedLoadBalancing is set to false and a Persistent Manager is
configured with a persistent store, sessions are written to the store at the end of each
request processing cycle. As a result, all changes made to a session by the client
application are persisted to the store.
NOTE: When the SessionBasedLoadBalancing feature is turned ON, messages
are delivered to NSJSP not only through TS/MP but also through file system calls. Hence,
there could be a situation that all messages delivered to a particular dynamic process
are through file system calls and none through TS/MP. Therefore, TS/MP may assume
that a particular dynamic process is not required any more and will shut down the
process. However, that dynamic process can have valid session objects in memory,
which will be lost if the process is shutdown. With the SessionBasedLoadBalancing
feature turned ON, it is important not to configure the dynamic processes.
Enabling or disabling the SessionBasedLoadBalancing feature depends on the
application requirement. Your MyFaces application might encounter any of the following
scenarios:
— The application depends heavily on the state stored in session objects. Therefore,
session objects cannot be lost and the application cannot recover from loss of state.
— Application response is of prime importance and the application can recover from
a loss of state.
— The application is expected to handle largely varying loads and having a large
number of static NSJSP instances is not an option.
— The session objects must be valid for large durations (such as an entire day).
— The session objects must be available whenever the application restarts.
NonStop Platform Configurations 245