user manual

128 BES Developer’s Guide
Passivating Session Beans
its state is sent to persistent storage and the bean instance is removed from
memory.
Simple Passivation
Passivation timeouts are set at the container-level. You use the property
ejb.sfsd.passivation_timeout to configure the length of time a session bean can
go un-accessed before its state is persisted and its instance removed from
memory. This length of time is specified in seconds. The default value is five
seconds. This property can be set in the partition.xml properties file for the
Partition you are configuring. This file is located in:
<install_dir>/var/domains/base/configurations/<configuration_name>
/ mos/<partition_name>/adm/properties
Edit this file to set the ejb.sfsb.passivation_timeout property.
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.