Storage for Session State Data (Sun Java System Application Server 9.1 High Availability Administration Guide)

Sun Java System Application Server 9.1 High Availability Administration Guide

Storage for Session State Data

Storing session state data enables the session state to be recovered after the failover of a server instance in a cluster. Recovering the session state enables the session to continue without loss of information. Application Server provides the following types of high availability storage for HTTP session and stateful session bean data:

In-memory replication on other servers in the cluster
High availability database

In-Memory Replication on Other Servers in the Cluster

In-memory replication on other servers provides lightweight storage of session state data without the need to obtain a separate database, such as HADB. This type of replication uses memory on other servers for high availability storage of HTTP session and stateful session bean data. Clustered server instances replicate session state in a ring topology. Each backup instance stores the replicated data in memory. Replication of session state data in memory on other servers enables sessions to be distributed.

The use of in-memory replication requires the Group Management Service (GMS) to be enabled. For more information about GMS, see Group Management Service.

If server instances in a cluster are located on different machines, ensure that the following prerequisites are met:

To ensure that GMS and in-memory replication function correctly, the machines must be on the same subnet.
To ensure that in-memory replication functions correctly, the system clocks on all machines in the cluster must be synchronized as closely as possible.

Considerations for using in-memory replication:

Very simple to set up and use. There are little or no administration costs.
More Java Virtual Machine (JVM) heap space is used. JVM will need tuning for any production system.
Does NOT provide 99.999% availability. Therefore, in-memory replication is unsuitable for any customer that requires this level of availability.
Typically incurs less overhead than HADB does.
Cannot be used to create a highly available Message Queue cluster. This is only possible by using a highly available database.

Although an Application Server does cluster its Message Queue instances, this provides only a conventional Message Queue cluster and not a highly available Message Queue cluster.

For information on Message Queue requirements, see Sun Java System Message Queue 4.1 Administration Guide.

High Availability Database

Note –

The HADB software is supplied with the Application Server standalone distribution of Sun Java System Application Server. For information about available distributions of Sun Java System Application Server, see Distribution Types and Their Components in Sun Java System Application Server 9.1 Installation Guide. HADB features are available only in the enterprise profile. For information about profiles, see Usage Profiles in Sun Java System Application Server 9.1 Administration Guide.

Application Server provides the High Availability Database (HADB) for high availability storage of HTTP session and stateful session bean data. HADB is designed to support up to 99.999% service and data availability with load balancing, failover, and state recovery. Generally, you must configure and manage HADB independently of Application Server.

Keeping state management responsibilities separated from Application Server has significant benefits. Application Server instances spend their cycles performing as a scalable and high performance application containers delegating state replication to an external high availability state service. Due to this loosely coupled architecture, Application Server instances can be very easily added to or deleted from a cluster. The HADB state replication service can be independently scaled for optimum availability and performance. When an Application Server instance also performs replication, the performance of Java EE applications can suffer and can be subject to longer garbage collection pauses.

Considerations for using High Availability Database:

Provides 99.999% availability if guidelines are followed (redundant power supplies, network infrastructure, and so on).
Needs additional hardware resources and careful sizing to perform efficiently.

However, the HADB nodes could be on separate lower-cost dedicated machines rather than on large machines (which also helps with redundancy). HADB processes are fairly single-threaded, and do not make the best use of our multi-threaded processors. This means that more HADB nodes would need required to make best use of the resources, thus complicating the achievement of 99.999% availability.
HADB is complex and tricky to administer
Machines need to be on the same subnet. HADB nodes use UDP multicasting for heartbeats and cluster event notification.

For information on planning and setting up your application server installation for high availability with HADB, including determining hardware configuration, sizing, and topology, see Planning for Availability in Sun Java System Application Server 9.1 Deployment Planning Guide and Chapter 3, Selecting a Topology, in Sun Java System Application Server 9.1 Deployment Planning Guide.