web server - Borland Technical Publications

Sessions in secondary storage
If you set this property to a non-zero value, you can also set the integer property
ejb.sfsb.instance_max for each deployed session bean in their deployment descriptors.
This property defines the maximum number of instances of a particular stateful session
bean that are allowed to exist in the EJB container's memory at the same time. If this
number is reached and a new instance of a stateful session needs to be allocated, the
EJB container throws an exception indicating lack of resources. 0 is a special value. It
means no maximum set.
If the maximum number of stateful sessions defined by the ejb.sfsb.instance_max
property is reached, the EJB container blocks a request for an allocation of a new bean
for the time defined by the integer property ejb.sfsb.instance_max_timeout. The
container will then wait for the number to drop below this value before throwing an
exception indicating a lack of resources. This property is defined in ms (1/1000th of
second). 0 is a special value. It means not to wait and throw an exception indicating
lack of resources immediately.
Aggressive Passivation
One of the key advantages in the use of JSS is its ability to fail over. Several containers
implementing JSS can be configured to use the same persistent store, allowing them to
fail over to each other. Setting up the JSS for failover is discussed in Chapter 6, “Java
Session Service (JSS) configuration.” To facilitate taking advantage of the JSS failover
capability, Borland provides the option of using aggressive passivation.
Aggressive passivation is the storage of session state regardless of its timeout. A bean
that is set to use aggressive passivation will have its session state persisted every time
it is polled, although its instance will not be removed from memory unless it times out.
In this way, if a container instance fails in a cluster, a recently-stored version of the
bean is available to other containers using identical JSS instances communicating with
the same backend. As in simple passivation, if the bean times out, it will still be
removed from memory.
Again, aggressive passivation is set Partition-wide using the boolean property
ejb.sfsb.aggressive_passivation. Setting the property to true (the default) stores the
session's state regardless of whether it was accessed before the last passivation
attempt. Setting the property to false allows the container to use only simple
passivation. Again, this property is set in the container's properties file partition.xml
located in:
/var/domains/base/configurations/
/ mos//adm/properties
Bear in mind that although using aggressive passivation aids in failover, it also results
in a performance hit since the container accesses the database more often. If you
configure the JSS to use a non-native database (that is, you choose not to use
JDataStore), the loss of performance can be even greater. Be aware of the trade-off
between availability and performance before you elect to use aggressive passivation.
Sessions in secondary storage
Most sessions are not kept in persistent storage forever after they timeout. Borland
provides a mechanism for removing stored sessions from the database after a discrete
period of time known as the keep alive timeout. The keep alive timeout specifies the
minimum amount of time in seconds to persist a passivated session in stateful storage.
The actual amount of time it is kept in the database can vary, since it is not wise from a
performance standpoint to constantly poll the database for unused sessions. The
actual amount of time a session is persisted is at least the value of the keep alive
timeout and not more than twice the value of the keep alive timeout.
108 BES Developer’s Guide