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
Overview of 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
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
This section explains how to configure and enable the high availability session persistence service.
To Enable Availability for a Cluster, Standalone Instance or Container
Configuring Replication and Multi-Threaded Concurrent Access to HttpSessions
This procedure explains how to enable high availability for a cluster as a whole, or for Web, EJB, or JMS containers that run in a cluster, or for a standalone server instance that is not part of a cluster.
For more information, see To Create a Cluster.
For instructions, see Setting Up HTTP Load Balancing.
These steps are also necessary when enabling availability for a Web, EJB, or JMS container running in a cluster. The cluster and all instances in the cluster for which you want to enable availability must be running.
asadmin> list-clusters
A list of clusters and their status (running, not running) is displayed. If the cluster for which you want to enable availability is not running, you can start it with the following command:
asadmin> start-cluster cluster-name
asadmin> list-instances
A list of instances and their status is displayed. If the instances for which you want to enable availability are not running, you can start them by using the following command for each instance:
asadmin> start-instance instance-name
asadmin> set cluster-name-config.availability-service.availability-enabled=true
For example, for a cluster named c1:
asadmin> set c1-config.availability-service.availability-enabled=true
asadmin> set cluster-name-config.availability-service \ .web-container-availability.availability-enabled=true
asadmin> set cluster-name-config.availability-service \ .ejb-container-availability.availability-enabled=true
asadmin> set cluster-name-config.availability-service \ .jms-availability.availability-enabled=true
asadmin> set instance-name-config.availability-service.availability-enabled=true
If the instance is currently serving requests, quiesce the instance before restarting it so that the instance gets enough time to serve the requests it is handling. For more information, see Disabling (Quiescing) a Server Instance or Cluster.
Select methods for which checkpointing the session state is necessary. For more information, see Configuring Availability for an Individual Bean.
For more information, see Web Module Deployment Guidelines in Oracle GlassFish Server 3.1 Application Deployment Guide.
See the links below for instructions.
See Also
To enable and configure availability for an individual web application, edit the application deployment descriptor file, glassfish-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 replicated to enable high availability session persistence.
<glassfish-web-app> ... <session-config> <session-manager persistence-type="replicated"> <manager-properties> <property name="persistenceFrequency" value="web-method" /> </manager-properties> <store-properties> <property name="persistenceScope" value="session" /> </store-properties> </session-manager> ... </session-config> ...
If you are using Memory Replication and your web application involves multiple client threads concurrently accessing the same session ID, then you may experience session loss even without any instance failure. The problem is that the GlassFish Server 3.1 memory replication framework makes use of session versioning. This feature was designed with the more traditional HTTP request/response communication model in mind.
However, for some types of applications, the traditional request/response model does not work. Examples include many Ajax-related frameworks and the use of Frames. Another example is when a page includes many static resources, such as JPG files. In these situations, most browsers will optimize the loading of these resources by using multiple parallel connections, each of which is handled by a separate request processing thread. If the application has already established a session, then this will also involve more than one thread at a time accessing a single HttpSession.
The solution in such cases is to use the relaxVersionSemantics property in the glassfish-web.xml deployment descriptor file for the application. This enables the web container to return for each requesting thread whatever version of the session that is in the active cache regardless of the version number. This is critical when multiple threads are interacting in an essentially non-deterministic fashion with the container.
The following is an example snippet from a glassfish-web.xml file that illustrates where to add the relaxVersionSemantics property.
<glassfish-web-app> <session-config> <session-manager persistence-type="replicated"> <manager-properties> <property name="relaxCacheVersionSemantics" value="true"/> </manager-properties> </session-manager> </session-config> ..... </glassfish-web-app>
In a single application server instance, once a user is authenticated by an application, the user is not required to re-authenticate individually to other applications running on the same instance. This is called single sign-on.
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 using in-memory replication. 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 by using 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:
asadmin> set config1.availability-service.web-container-availability. \ sso-failover-enabled="true"
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.
Built on top of Oracle Coherence, Coherence*Web is an HTTP session management module dedicated to managing session state in clustered environments. Starting with Coherence 3.7 and GlassFish Server 3.1, there is a new feature of Coherence*Web called ActiveCache for GlassFish. ActiveCache for GlassFish provides Coherence*Web functionality in web applications deployed on GlassFish Servers. Within GlassFish Server, Coherence*Web functions as an additional web container persistence type, named coherence-web.
For information about how to configure and deploy Coherence*Web on GlassFish Server, see Using Coherence*Web with GlassFish Server.