Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide |
1. High Availability in GlassFish Server
2. Setting Up SSH for Centralized Administration
3. Administering GlassFish Server Nodes
4. Administering GlassFish Server Clusters
5. Administering GlassFish Server Instances
6. Administering Named Configurations
7. Configuring Web Servers for HTTP Load Balancing
8. Configuring HTTP Load Balancing
9. Upgrading Applications Without Loss of Availability
10. Configuring High Availability Session Persistence and Failover
Enabling the High Availability Session Persistence Service
To Enable Availability for a Cluster, Standalone Instance or Container
Configuring Availability for Individual Web Applications
Configuring Replication and Multi-Threaded Concurrent Access to HttpSessions
Using Single Sign-on with Session Failover
Using Coherence*Web for HTTP Session Persistence
Stateful Session Bean Failover
Configuring Availability for the EJB Container
Configuring the SFSB Session Store When Availability Is Disabled
Configuring Availability for an Individual Application or EJB Module
Configuring Availability for an Individual Bean
Specifying Methods to Be Checkpointed
11. Configuring Java Message Service High Availability
GlassFish Server provides high availability session persistence through failover of HTTP session data and stateful session bean (SFSB) session data. Failover means that in the event of an server instance or hardware failure, another server instance in a cluster takes over a distributed session.
For example, 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.
Note - When using high availability session persistence together with a load balancer, use a load balancer that includes session-based stickiness as part of its load-balancing algorithm. Otherwise, session data can be misdirected or lost. An example of a load balancer that includes session-based stickiness is the Loadbalancer Plug-In available in Oracle GlassFish Server.
The following topics are addressed here:
A distributed session can run in multiple Oracle GlassFish Server instances, if:
Each server instance has access to the same session state data. GlassFish Server supports in-memory session replication on other servers in the cluster for maintaining HTTP session and stateful session bean data. In-memory session replication is enabled by default for GlassFish Server clustered environments if the Group Management Service is enabled.
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 hosts, ensure that the following prerequisites are met:
To ensure that GMS and in-memory replication function correctly, the hosts must be on the same subnet.
To ensure that in-memory replication functions correctly, the system clocks on all hosts in the cluster must be synchronized as closely as possible.
Note - GlassFish Server 3.1 does not support High Availability Database (HADB) configurations. Instead, use in-memory replication, as described in High Availability Session Persistence.
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 subcommand with the --availabilityenabled option set to true. For more information on these subcommands, see deploy(1) and deploydir(1).
When configuring session persistence and failover, note the following 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.
EJB Singletons are created for each server instance in a cluster, and not once per cluster.
The high availability session persistence service is not compatible with dynamic deployment, dynamic reloading, and autodeployment. These features are for development, not production environments, so you must disable them before enabling the session persistence service. For information about how to disable these features, see the Oracle GlassFish Server 3.1 Application Deployment Guide.
GlassFish Server 3.1 does not support High Availability Database (HADB) configurations. Instead, use in-memory replication, as described in High Availability Session Persistence.
You can only bind certain objects to distributed sessions that support failover. Contrary to the Servlet 2.4 specification, GlassFish Server 3.1 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:
Local home and object references for all EJB components.
Colocated stateless session, stateful session, or entity bean reference .
Distributed stateless session, stateful session, or entity bean reference.
JNDI Context for InitialContext and java:comp/env.
UserTransaction objects. However, if the instance that fails is never restarted, any prepared global transactions are lost and might not be correctly rolled back or committed.
Serializable Java types.
You cannot bind the following object types into sessions that support failover:
JDBC DataSource
Java Message Service (JMS) ConnectionFactory and Destination objects
JavaMail™ Session
Connection Factory
Administered Objects
Web service reference
In general, for these objects, failover will not work. However, failover might work in some cases, if for example the object is serializable.
The availability service can be enabled for the following scopes, ranging from highest to lowest:
Cluster
Standalone server instance (not part of a cluster)
Web, EJB, or JMS container in a cluster
Application
Standalone Web, EJB, or JMS module
Individual Stateful Session Bean (SFSB)
In general, enabling or disabling availability session persistence for a cluster or container involves setting the boolean availability-service property to true or false by means of the asadmin set subcommand. The availability service is enabled by default for GlassFish Server clusters and all Web, EJB, and JMS containers running in a cluster.
The value set for the availability-service property is inherited by all child objects running in a given cluster or container unless the value is explicitly overridden at the individual module or application level. For example, if the availability-service property is set to true for an EJB container, the availability service will be enabled by default for all EJB modules running in that container.
Conversely, 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 cluster or server instance and container levels.