Each server instance has the same distributable web application
deployed to it. The web-app element of the web.xml deployment
descriptor file must contain the distributable element.

The web application uses high-availability session persistence.
If a non-distributable web application is configured to use high-availability
session persistence, the server writes an error to the log file.

The web application must be deployed using the deploy or
deploydir command with the --availabilityenabled option
set to true. For more information on these commands, see deploy(1) and deploydir(1).

Restrictions

When a session fails over, any references to open files or network connections
are lost. Applications must be coded with this restriction in mind.

You can only bind certain objects to distributed sessions that support
failover. Contrary to the Servlet 2.4 specification, Sun Java System Application Server does
not throw an IllegalArgumentException if an object type
not supported for failover is bound into a distributed session.

You can bind the following objects into a distributed session that supports
failover:

Setting Up High Availability Session Persistence

To Set Up High Availability Session Persistence

Before You Begin

High availability session persistence is incompatible with dynamic deployment,
dynamic reloading, and auto-deployment. These features are for development,
not production environments, so you must disable them before enabling HA session
persistence. For information about how to disable these features, see Sun Java System Application Server 9.1 Application Deployment Guide.

In the Administration Console, check the Availability
Enabled box, or use the asadmin deploy command with the --availabilityenabled option set to true.

Enabling Session Availability

You can enable session availability at five different
scopes (from highest to lowest):

Server instance, enabled by default. Enabling session availability
for the server instance means that all applications running on the server
instance can have high-availability session persistence. For instructions,
see next section, Enabling Availability for a Server Instance .

Container (web or EJB), enabled by default. For information
on enabling availability at the container level, see:

To enable availability at a given scope, you must enable it at all higher
levels as well. For example, to enable availability at the application level,
you must also enable it at the server instance and container levels.

The default for a given level is the setting at the next level up. For
example, if availability is enabled at the container level, it is enabled
by default at the application level.

When availability is disabled at the server instance level, enabling
it at any other level has no effect. When availability is enabled at the server
instance level, it is enabled at all levels unless explicitly disabled.

Enabling Availability for a Server Instance

To enable availability for a server instance, use the asadmin
set command to set the configuration’s availability-service.availability-enabled property to true.

HTTP Session Failover

Java EE applications typically have significant amounts of session state
data. A web shopping cart is the classic example of session state. Also, an
application can cache frequently-needed data in the session object. In fact,
almost all applications with significant user interactions need to maintain
session state.

If you are using HADB, enable and configure web container availability
by using the asadmin configure-ha-persistence. For more
information about this command, see configure-ha-persistence(1).

Alternatively, use the asadmin set command to set
the configuration’s availability-service.web-container-availability.availability-enabled property to true and then configure-ha-persistence to
set properties as desired.

Note –

If you are using in-memory replication to store session state
data, you must use the asadmin set command
to enable web container availability and to set properties. You can use the configure-ha-persistence command only with
HADB.

For example, use the set command as follows, where config1 is the configuration name:

Persistence Frequency: Specifies
how often the session state is stored. Applicable only if the Persistence
Type is ha or replicated. Allowed values
are:

web-method - The session state is stored
at the end of each web request prior to sending a response back to the client.
This mode provides the best guarantee that the session state is fully updated
in case of failure. This is the default.

time-based - The session state is stored
in the background at the frequency set by the reapIntervalSeconds store
property. This mode provides does not guarantee that session state is fully
updated. However, it can provide a significant performance improvement because
the state is not stored after each request.

Persistence Scope : Specifies how
much of the session object and how often session state is stored. Applicable
only if the Persistence Type is ha or replicated.
Allowed values are as follows:

session - The entire session state is stored
every time. This mode provides the best guarantee that your session data is
correctly stored for any distributable web application. This is the default.

modified-session - The entire session state
is stored if it has been modified. A session is considered to have been modified
if HttpSession.setAttribute() or HttpSession.removeAttribute() was called. You must guarantee that setAttribute() is
called every time an attribute is changed. This is not a Java EE specification
requirement, but it is required for this mode to work properly.

modified-attribute - Only modified session
attributes are stored. For this mode to work properly, you must follow a few
guidelines:

Call setAttribute() every time the session
state is modified.

Make sure there are no cross-references between attributes.
The object graph under each distinct attribute key is serialized and stored
separately. If there are any object cross references between the objects under
each separate key, they are not serialized and deserialized correctly.

Distribute the session state across multiple attributes, or
at least between a read-only attribute and a modifiable attribute.

HTTP Session Store: You can change
the HTTP Session Store if you changed the JDBC resource used for connections
to the HADB for session persistence. For details, see configure-ha-cluster(1).

Configuring Availability for Individual Web Applications

To enable and configure availability for an individual web application,
edit the application deployment descriptor file, sun-web.xml.
The settings in an application’s deployment descriptor override the
web container’s availability settings.

The session-manager element’s persistence-type attribute determines the type of session persistence an application
uses. It must be set to ha or replicated to
enable high availability session persistence.

For this feature to continue to work even when an HTTP session fails
over to another instance in a cluster, single sign-on information must be
persisted to the HADB. To persist single sign-on information, first, enable
availability for the server instance and the web container, then enable single-sign-on
state failover.

You can enable single sign-on state failover with the Admin Console
in the Web Container Availability tab of the Availability Service, as described
in Configuring Availability for the Web Container.
You can also use the asadmin set command to set the configuration’s availability-service.web-container-availability.sso-failover-enabled
property to true.

For example, use the set command as follows, where
config1 is the configuration name:

Single Sign-On Groups

Applications that can be accessed through a single name and password
combination constitute a single sign-on group. For HTTP
sessions corresponding to applications that are part of a single sign-on group,
if one of the sessions times out, other sessions are not invalidated and continue
to be available. This is because time out of one session should not affect
the availability of other sessions.

As a corollary of this behavior, if a session times out and you try
to access the corresponding application from the same browser window that
was running the session, you are not required to authenticate again. However,
a new session is created.

Take the example of a shopping cart application that is a part of a
single sign-on group with two other applications. Assume that the session
time out value for the other two applications is higher than the session time
out value for the shopping cart application. If your session for the shopping
cart application times out and you try to run the shopping cart application
from the same browser window that was running the session, you are not required
to authenticate again. However, the previous shopping cart is lost, and you
have to create a new shopping cart. The other two applications continue to
run as usual even though the session running the shopping cart application
has timed out.

Similarly, suppose a session corresponding to any of the other two applications
times out. You are not required to authenticate again while connecting to
the application from the same browser window in which you were running the
session.

Note –

This behavior applies only to cases where the session times out.
If single sign-on is enabled and you invalidate one of the sessions using HttpSession.invalidate() , the sessions for all applications belonging
to the single sign-on group are invalidated. If you try to access any application
belonging to the single sign-on group, you are required to authenticate again,
and a new session is created for the client accessing the application.

Stateful Session Bean Failover

Stateful session beans (SFSBs) contain client-specific state. There
is a one-to-one relationship between clients and the stateful session beans. At creation, the
EJB container gives each SFSB a unique session ID that binds it to a client.

An SFSB’s state can be saved in a persistent store in case a server instance fails. The state of
an SFSB is saved to the persistent store at predefined points in its life
cycle. This is called checkpointing. If enabled, checkpointing generally
occurs after the bean completes any transaction, even
if the transaction rolls back.

However, if an SFSB participates in a bean-managed transaction,
the transaction might be committed in the middle of the execution of a bean
method. Since the bean’s state might be undergoing transition as a result
of the method invocation, this is not an appropriate time to checkpoint the
bean’s state. In this case, the EJB container checkpoints the bean’s
state at the end of the corresponding method, provided the bean is not in
the scope of another transaction when that method ends. If a bean-managed
transaction spans across multiple methods, checkpointing is delayed until
there is no active transaction at the end of a subsequent method.

The state of an SFSB is not necessarily transactional and might be significantly
modified as a result of non-transactional business methods. If this is the
case for an SFSB, you can specify a list of checkpointed methods, as described
in Specifying Methods to Be Checkpointed

If a distributable web application references an SFSB, and the web application’s
session fails over, the EJB reference is also failed over.

If an SFSB that uses session persistence is undeployed while the Application Server instance
is stopped, the session data in the persistence store might not be cleared.
To prevent this, undeploy the SFSB while the Application Server instance is running.

The EJB Container Availability tab of the Availability Service enables
you to change these settings:

HA Persistence Type: Specifies the
session persistence and passivation mechanism for SFSBs
that have availability enabled. Allowed values are file (the
file system), replicated (memory on other servers), and
ha (HADB). The default value is ha.
For production environments that require session persistence, use ha or replicated.

SFSB Persistence Type: Specifies
the passivation mechanism for SFSBs that do not have
availability enabled. Allowed values are file (the default), replicated, and ha.

If either Persistence Type is set to file, the EJB
container specifies the file system location where the passivated session
bean state is stored. Checkpointing to the file system is useful for testing
but is not for production environments. For information about configuring
store properties, see the Admin Console online help.

HA persistence enables a cluster of server instances to recover the
SFSB state if any server instance fails. HADB is also used as the passivation
and activation store. Use this option in a production environment that requires
SFSB state persistence. For more information, see configure-ha-cluster(1).

SFSB Store Pool Name: You can change
the SFSB Store Pool Name if you changed the JDBC resource used for connections
to the HADB for session persistence. For details, see configure-ha-cluster(1).

Configuring the SFSB Session Store When Availability
Is Disabled

If availability is disabled, the local file system is used for SFSB state passivation,
but not persistence. To change where the SFSB state is stored, change the
Session Store Location setting in the EJB container. For information about
configuring store properties, see the Admin Console online help.

Configuring Availability for an Individual Application
or EJB Module

You can enable SFSB availability for an individual application or EJB
module during deployment:

If you are deploying with the Admin Console, check the Availability
Enabled checkbox.

If you are deploying using use the asadmin deploy or
asadmin deploydir commands, set the --availabilityenabled option to true. For more information, see deploy(1) and deploydir(1).

Configuring Availability for an Individual Bean

To enable availability and select methods to be checkpointed for an
individual SFSB, use the sun-ejb-jar.xml deployment descriptor
file. .

To enable high availability session persistence, set availability-enabled="true" in the ejb element. To control the size and
behavior of the SFSB cache, use the following elements:

max-cache-size : specifies the maximum
number of session beans that are held in cache. If the cache overflows (the
number of beans exceeds max-cache-size), the container
then passivates some beans or writes out the serialized state of the bean
into a file. The directory in which the file is created is obtained from the
EJB container using the configuration APIs.

Specifying Methods to Be Checkpointed

If enabled, checkpointing generally occurs after the
bean completes any transaction, even if the transaction
rolls back. To specify additional optional checkpointing of SFSBs at the end
of non-transactional business methods that cause important modifications to
the bean’s state, use the checkpoint-at-end-of-method
element in the ejb element of the sun-ejb-jar.xml deployment descriptor
file.

The non-transactional methods in the checkpoint-at-end-of-method element
can be:

create() methods defined in the home interface
of the SFSB, if you want to checkpoint the initial state of the SFSB immediately
after creation

For SFSBs using container managed transactions only, methods
in the remote interface of the bean marked with the transaction attribute
TX_NOT_SUPPORTED or TX_NEVER

For SFSBs using bean managed transactions only, methods in
which a bean managed transaction is neither started nor committed

Any
other methods mentioned in this list are ignored. At the end of invocation
of each of these methods, the EJB container saves the state of the SFSB to
persistent store.

Note –

If an SFSB does not participate in any transaction, and if none
of its methods are explicitly specified in the checkpoint-at-end-of-method element, the bean’s state is not checkpointed at all even
if availability-enabled="true" for this bean.

For
better performance, specify a small subset of methods.
The methods should accomplish a significant amount of work or result in important
modification to the bean’s state.