HTTP/SIP Session Failover

Java EE and SIP 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.

Configuring Availability for the Web Container

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.

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

asadmin set 
config1.availability-service.web-container-availability.availability-enabled="true"

asadmin set 
config1.availability-service.web-container-availability.persistence-frequency="time-based"

To Enable Availability for the Web Container with Admin Console

1. In the tree component, select the desired configuration.

2. Click on Availability Service.

3. Select the Web Container Availability tab.

   Check the Availability Service box to enable availability. To disable it, uncheck the box.

4. Change other settings, as described in the following section, Web Container Availability Settings

5. Restart the server instance.

Web Container Availability Settings

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

Persistence Type: Specifies the session persistence mechanism for web applications that have availability enabled. Allowed values are memory (no persistence) file (the file system), and replicated (memory on other servers).

If web container availability is enabled, the default persistence type depends on the profile, as shown in the following table.

For production environments that require session persistence, use replicated. The memory persistence type and the file persistence type do not provide high availability session persistence.

If web container availability is disabled, the default persistence type memory.

Persistence Frequency: Specifies how often the session state is stored. Applicable only if the Persistence Type is 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 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.

Single Sign-On State: Check this box to enable persistence of the single sign-on state. To disable it, uncheck the box. For more information, see Using Single Sign-on with Session Failover

Configuring Availability for Individual Web Applications

To enable and configure availability for an individual web or converged web or SIP 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 replicated to enable high availability session persistence.

For more information about the sun-web.xml file, see The sun-web.xml File in Sun GlassFish Communications Server 2.0 Application Deployment Guide.

Example

<sun-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> ...

Configuring Availability for the SIP Container

Use the asadmin set command to enable web container availability and to change availability settings. For example, use the set command as follows, where config1 is the configuration name:

asadmin set 
config1.availability-service.sip-container-availability.availability-enabled="true"

asadmin set 
config1.availability-service.sip-container-availability.persistence-frequency="time-based"

To Enable Availability for the SIP Container with Admin Console

1. In the tree component, select the desired configuration.

2. Click on Availability Service.

3. Select the SIP Container Availability tab.

   Check the Availability Service box to enable availability. To disable it, uncheck the box.

4. Change other settings, as described in the following section, SIP Container Availability Settings.

5. Restart the server instance.

SIP Container Availability Settings

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

Persistence Type: Specifies the session persistence mechanism for web applications that have availability enabled. Allowed values are memory (no persistence) and replicated (memory on other servers). If SIP container availability is disabled, the default persistence type memory. If SIP container availability is enabled, the default persistence type is replicated. For production environments that require session persistence, use replicated. The memory persistence type does not provide high availability session persistence.

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

• sip-transaction - The session state is stored at the end of each 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 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 SipApplicationSession.setAttribute() or SipApplicationSession.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.

Single Sign-On State: Check this box to enable persistence of the single sign-on state. To disable it, uncheck the box. For more information, see Using Single Sign-on with Session Failover.

Configuring Availability for Individual SIP Applications

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

For a converged web/SIP application, edit sun-web.xml to configure the web container and sun-sip.xml to configure the SIP container.

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.

For more information about the sun-sip.xml file, see The sun-sip.xml File in Sun GlassFish Communications Server 2.0 Application Deployment Guide.

Example

<sun-web-app> ... 
  <session-config> 
    <session-manager persistence-type="replicated"> 
      <manager-properties> 
        <property name="persistenceFrequency" value="sip-transaction" /> 
      </manager-properties> 
      <store-properties> 
        <property name="persistenceScope" value="session" /> 
      </store-properties> 
    </session-manager> ... 
</session-config> ...

Using Single Sign-on with Session Failover

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 more information, see User Authentication for Single Sign-on in Sun GlassFish Communications Server 2.0 Developer’s Guide.

For this feature to continue to work even when an HTTP/SIP 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 with the Admin Console in the Web Container Availability or SIP 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:

asadmin set --user admin --passwordfile password.txt 
--host localhost --port 4849 
config1.availability-service.web-container-availability.
sso-failover-enabled="true"

Single Sign-On Groups

Applications that can be accessed through a single name and password combination constitute a single sign-on group. For HTTP/SIP 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.

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() or SipApplicationSession.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.