Appendix B Failover Scenarios (Enterprise Edition)

The scenarios in this appendix illustrate how session persistence settings for application server instances and web applications affect the failover of session state and stateful session bean (SFSB) state in Sun Java System Application Server, Enterprise Edition. It also includes a discussion and sample failover scenario for Java Remote Method Invocation (RMI) and Internet Inter-Orb Protocol (IIOP) requests.

HTTP Session Failover

Assumptions and Requirements

Persistence Type Set to memory for Application Server Instances in Cluster

Persistence Type Set to memory for an Application Server Instance

Persistence Type Set to file for an Application Server Instance

Persistence Type Set to ha for Application Server Instances in a Cluster

Persistence Type Set to memory for a Web Application

Persistence Type Set to file for a Web Application

Persistence Type Set to ha for a Web Application

Assumptions and Requirements

The following information about HTTP session persistence is relevant to the scenarios described in this appendix:

For production environments that require HTTP session persistence, the only persistence type supported is ha.

To support session persistence for HTTP sessions you must enable high availably. For more information about enabling high-availability, see Enabling and Disabling Availability. In order for availability to work at the application level, it must have been enabled for the application and at all levels above the application. In the scenarios described here, it is assumed that availability has been enabled for the application server instances, the web containers, and the applications.

For a web application to take part in session persistence, it should be distributable. For more information about distributable web applications, see Making a Web Application Distributable. In the scenarios described in this appendix, it is assumed that the web applications are distributable.

Session persistence configuration for a web application takes precedence over the session persistence configuration for the application server instances on which the web application is deployed.

Persistence Type Set to memory for Application Server Instances in Cluster

Summary

The persistence type for the application server instances in a cluster is set to memory and there are no persistence type settings defined for the web applications deployed in the cluster. If an application server instance on which HTTP sessions have been created becomes unavailable, the HTTP sessions created on it are not failed over to other application server instances.

Example

You have set persistence type to memory for all application server instances in the cluster.

You have deployed a web application with no persistence type settings.

This web application has serviced requests and sessions for these requests have been created on one or more application server instances.

An application server instance on which one or more of these sessions were created becomes unavailable.

Result Description

These sessions will not be failed over to other application server instances in the cluster. If requests corresponding to these sessions come in, these requests will be routed to other (available) application server instances in the cluster as per the load balancing algorithm of the load balancer.

Persistence Type Set to memory for an Application Server Instance

Summary

In a development environment, the persistence type for an application server instance is set to memory and there are no persistence type settings defined for the web applications deployed on the instance.

The instance is gracefully shut down. When the instance restarts, it can recover HTTP session state from a file.

This mode is useful when you are using only one application server instance and there is no load balancer. However, in a clustered environment with a load balancer, by the time you have shut down the instance completely and then restarted it, the load balancer may have failed over the session state to other instances in the cluster and the instance may not be able to recover session state when it restarts.

Example

In a development environment, you have set persistence type to memory for an application server instance.

You have deployed a web application on the application server instance with no session persistence settings.

This web application has serviced requests and sessions for these requests have been created on the instance.

The instance is gracefully shutdown.

Result Description

Before the graceful shutdown, the instance stores the session state in a file in a directory. The path of the directory is the value of the sessionFilename property of session-manager in the server.xml file.

When you restart the instance, it will be able to get the session state from the file.

Persistence Type Set to file for an Application Server Instance

Summary

In a development environment, the persistence type for an application server instance is set to file and there are no persistence type settings defined for the web applications deployed on the instance.

The instance is gracefully shutdown or becomes unavailable. When the instance restarts, it can recover HTTP session state from a file.

This mode is useful when you are using only one application server instance and there is no load balancer. However, in a clustered environment with a load balancer, the session state cannot be recovered by any other instance in the cluster. Additionally, while the instance is unavailable, the load balancer may attempt to fail sessions over to other instances, and once the instance restarts, those sessions will have to be re-established (usually requiring the web client to reauthenticate).

Example

In a development environment, you have set persistence type to file for an application server instance.

You have deployed a web application on the application server instance with no session persistence settings.

This web application has serviced requests and sessions for these requests have been created on the instance.

The instance is gracefully shutdown or becomes unavailable.

Result Description

While the application server instance is available, it stores the information for each session in a corresponding file. The session is stored at intervals specified by the reapIntervalSeconds property of the session manager element in the server.xml file.

If the instance restarts, it will be able to get the information for the sessions from the corresponding files. Because the session state is stored periodically (and not, for example, after every web method), there is a risk of some loss of session data, depending on when the session was last stored.

Persistence Type Set to ha for Application Server Instances in a Cluster

Summary

The persistence type for the application server instances in a cluster is set to ha and there are no persistence type settings defined for the web applications deployed in the cluster. If an application server instance on which sessions have been created becomes unavailable, the sessions created on it are failed over to other (available) application server instances in the cluster.

Example

You have set persistence type to ha for all application server instances in the cluster.

You have deployed a web application on the cluster with no session persistence settings.

This web application has serviced requests and sessions for these requests have been created on one or more application server instances.

An application server instance on which one or more of these sessions were created becomes unavailable.

Result Description

The load balancer keeps monitoring all application server instances to check if they are available. When the instance becomes unavailable, the load balancer marks the instance as unavailable.

The load balancer stops sending any unassigned requests to the instance.

Requests that were sent to the application server instance but that were not serviced are lost and an error is sent to the client.

All subsequent requests for sessions assigned to the application server instance are failed over to other instances in the cluster.

The instance that was originally serving the requests would have written the HTTP session state to the high-availability database (HADB).

The persistence frequency setting has a bearing on how up-to-date the HTTP session state information in the HADB is.

If the persistence frequency for this application server instance is set to time-based, the HTTP session state is stored periodically at the time interval specified in the reapIntervalSeconds property of the manager-properties element in the server.xml file (for instance-level configuration) or in the sun-web.xml file (for application-level configuration). For more information, see Configuring Other HTTP Session Persistence Properties.

If the persistence frequency for the application server instance is set to web-method, the session state is stored after every web request.

Persistence Type Set to memory for a Web Application

Summary

The persistence type for a web application deployed on a cluster is set to memory. If an application server instance on which sessions for this web application have been created becomes unavailable, the sessions created on it are not failed over to other application server instances in the cluster. This will happen regardless of the persistence type setting for the application server instances in the cluster.

Example

You have deployed a web application with session persistence set to memory.

This web application has serviced requests and sessions for these requests have been created on one or more application server instances.

An application server instance on which one or more of these sessions were created becomes unavailable.

Result Description

Persistence Type Set to file for a Web Application

Summary

The persistence type for a web application deployed on a cluster is set to file. If an application server instance on which sessions for this web application have been created becomes unavailable, the sessions created on it are not failed over to other application server instances in the cluster. This will happen regardless of the persistence type setting for the application server instances in the cluster.

Example

You have deployed a web application with session persistence set to file.

This web application has serviced requests and sessions for these requests have been created on one or more application server instances.

An application server instance on which one or more of these sessions were created becomes unavailable.

Result Description

Persistence Type Set to ha for a Web Application

Summary

The persistence type for a web application deployed on a cluster is set to ha. If an application server instance on which sessions for this web application have been created becomes unavailable, the sessions created on it are failed over to other application server instances in the cluster. This will happen regardless of the persistence type setting for the application server instances in the cluster.

Example

You have deployed a web application with session persistence set to ha.

This web application has serviced requests and sessions for these requests have been created on one or more application server instances.

An application server instance on which one or more of these sessions were created becomes unavailable.

Result Description

Stateful Session Bean Failover

The state of Stateful Session Beans (SFSBs) also fails over between server instances in a cluster. If the request for an SFSB comes in over the HTTP path, the stateful session bean state fails over between server instances in the HTTP cluster. If the request for an SFSB comes in over the RMI/IIOP path, the SFSB state fails over between the instances in an IIOP cluster.

Assumptions and Requirements

SFSB State Stored in the File System

SFSB State Stored in the HADB

Assumptions and Requirements

The following information about SFSB failover is relevant to the scenarios described in this appendix:

To support failover of the SFSB state, you must enable high availability. High availability must be enabled for the server instance, EJB container, module, and for any SFSB for which the state fails over. For more information on enabling availability for the instance, container, and module levels, see Chapter 20, "Configuring Session Persistence (Enterprise Edition)." For information on enabling availability and state checkpointing for SFSBs, see the Sun Java System Application Server Developer's Guide to Enterprise JavaBeans Technology.

If you’ve specified a JNDI name of the JDBC resource for the HADB, the SFSB persistent store is assumed to be the HADB. You specify the JNDI name in the store-pool-jndi-name property in the availability-service element of the server.xml file. If you have not specified a JNDI name of the JDBC resource for the HADB, the persistent store defaults to the file system.

The same persistence store (HADB or file) should be used for both the web container and the EJB container. In production environments that require failover of SFSB state, the persistence store must be the HADB and the persistence type for the server instance must be set to ha.

Transparent failover of in-flight requests is not supported. If a server instance to which a client request is sent crashes during the request processing (before the response could be prepared and sent back to the client) an exception or error is sent to the client. The client must retry the request explicitly. When the client retries the request, the request is sent to another server instance in the cluster, which receives session state information for this client.

SFSB State Stored in the File System

Summary

In a development environment, the persistence type for an application server instance is set to file or memory and the HADB is not configured.

The instance is gracefully shutdown or becomes unavailable. When the instance restarts, it can recover SFSB state from the file system.

This mode is useful when you are using only one application server instance and there is no load balancer. However, in a clustered environment with a load balancer, the SFSB state cannot be recovered by any other instance in the cluster.

Example

In a development environment, you have set persistence type to file or memory for an application server instance.

The store-pool-jndi-name property in the availability-service element of the server.xml file is not present or its value is an empty string. This configuration sets the EJB container’s persistence store to the file system.

You have enabled availability for the server instance, EJB container, module, and SFSBs for which you want the SFSB state saved.

A client has requested a SFSB and received a response.

An application server instance on which one or more of these requests for SFSBs were served becomes unavailable.

Result Description

While the application server instance is available, it stores information on SFSB state in the file system, at the location specified in the session-store attribute in the server.xml file. The SFSB state is stored at checkpoints, either at the end of a transaction in which the SFSB participates, or at the end of a business method invoked on the SFSB.

If the instance restarts, it will be able to get the information for the SFSB states from the file system.

SFSB State Stored in the HADB

Summary

The persistence type for the application server instances in a cluster is set to ha and the HADB is configured. Availability is enabled. If an application server instance on which sessions have been created becomes unavailable, the SFSB states on it are failed over to other (available) application server instances in the cluster.

Example

You have set persistence type to ha for all application server instances in the cluster.

The store-pool-jndi-name property in the availability-service element of the server.xml file has been configured with the JNDI name of the JDBC resource for the HADB. This configuration sets the persistent store for SFSBs to the HADB.

You have enabled availability for the server instances, EJB containers, modules, and SFSBs for which you want the SFSB state to fail over.

A client has requested a SFSB and received a response.

An application server instance on which one or more of these requests for SFSBs were served becomes unavailable.

Result Description

The load balancer keeps monitoring all application server instances in the cluster to check if they are available. When the instance becomes unavailable, the load balancer marks the instance as unavailable.

The load balancer stops sending any unassigned requests to the instance.

Requests are serviced for the amount of time specified in disable-timeout-in-minutes in the loadbalancer.xml file.

Requests that were sent to the application server instance but that were not serviced are lost and an error is sent to the client.

All subsequent requests for sessions assigned to the application server instance are failed over to other instances in the cluster.

The instance that was originally serving the requests would have written the SFSB state to the high-availability database (HADB). The SFSB state is stored at checkpoints, either at the end of a transaction in which the SFSB participates, or at the end of a business method invoked on the SFSB.

The application server instances to which the sessions are failed over access the SFSB state from the HADB.

Failover on RMI/IIOP Path

RMI/IIOP request failover provides high availability of RMI/IIOP references. These references can be either EJBs or NameService references. If the server instance that published an RMI/IIOP remote reference becomes unavailable, additional requests for the reference are failed over to an accessible instance in the cluster. In order for RMI/IIOP requests to fail over to another server instance, RMI/IIOP endpoints must be configured for the other server instances in the cluster. For more information on clusters, see Chapter 19, "Managing Clusters (Enterprise Edition)."

Once an IIOP request for an object is failed over to new server instance, all the subsequent requests to that IIOP object will continue to go to the same server instance even if the original server instance is back to life. Thus, the stickiness of objects to server instances is maintained even after failover.

Assumptions and Requirements

RMI/IIOP Failover Scenario

Assumptions and Requirements

The following information about RMI/IIOP failover is relevant to the scenario described in this appendix:

To support RMI/IIOP failover, you must enable high availability for the server instance.

You must have defined a cluster and configured the IIOP endpoints for the server instances in that cluster. These configuration settings are stored in the server.xml file. For more information, see Configuring HTTP Load Balancing and Failover.

You must have configured the RMI/IIOP client. The configuration required for the client varies depending upon the type of the client.For information on configuring clients, see the Sun Java System Application Server Developer’s Guide to Clients.

The following types of clients are supported for RMI/IIOP failover:

Java applications executing in the ACC and accessing EJBs deployed on an instance

Standalone clients

For failover of SFSB state to work over IIOP, the configuration must meet the requirements outlined in Stateful Session Bean Failover.

If the server instance that published a remote reference becomes inaccessible before an RMI/IIOP request is dispatched to it, the request is failed over to another server instance. If a server instance becomes unavailable while processing an RMI/IIOP request, that request will not be retried or failed over to another Application Server instance.

RMI/IIOP Failover Scenario

Summary

A client requests a remote reference from the server instance in a cluster which has IIOP endpoints configured. The load balancer sends the request to a particular server instance. The instance is gracefully shut down or becomes unavailable.

Example

A client application requests a remote EJB with IIOP.

An application server instance in a cluster services the request.

The application server instance which serviced the request becomes unavailable.

The client makes another request for the remote reference to the unavailable server instance.

Result Description

The request for the remote EJB is failed over to another server instance in the IIOP cluster.

Previous Contents Index Next
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Update 3 Administration Guide