Sun logo      Previous      Contents      Next     

Sun Java System Application Server Enterprise Edition 8.1 Administration Guide 2005Q1

Chapter 7
Configuring Availability and Session Persistence

This chapter describes how to configure session persistence and availability in the Sun Java™ System Application Server Enterprise Edition environment. It contains the following sections:

About Availability and Session Persistence

Why Session Persistence Is Needed

As an application session proceeds, there is often data that is part of a session that is not stored in a traditional database. An example of such data is the content of a shopping cart. Sun Java System Application Server provides the capability to save, or persist, this session data in a repository so that if an application server instance experiences a failure, the session state can be recovered and the session can continue without information loss.

In J2EE applications, session data is typically stored in HTTP sessions or stateful session bean (SFSB) sessions. Sun Java System Application Server supports persistence of the state of both HTTP sessions and SFSB sessions. Failover of certain J2EE object references that are stored in both HTTP sessions and SFSB sessions is also supported; see the Developer’s Guide.

The high-availability database (HADB) bundled with the Sun Java System Application Server works as the persistence store to provide high availability for session data.

Overview of Session Persistence Configuration

For successful session persistence configuration, ensure that these steps are followed in the order in which they are presented, because some later steps have one or more previous steps as prerequisites.

  1. Create an HADB database for the cluster. See the description of the configure-ha-cluster command in the Reference Manual.
  2. Set up HTTP load balancing for the cluster. See Chapter 3, "Configuring Load Balancing and Failover."
  3. Enable availability for the application server instances and web or EJB containers that should support session persistence, and configure the session persistence settings. Choose one of these approaches:
  4. If you are not enabling availability, you can change the file system session store for SFSBs if desired. See "Configuring the SFSB Session Store When Availability Is Disabled".
  5. Restart each server instance in the cluster.
  6. Enable availability for any specific SFSB that requires it, and select methods for which checkpointing the session state is necessary. See the Developer’s Guide.
  7. Make distributable each web module that should be highly available. See the Developer’s Guide.
  8. Enable availability for a J2EE application, web module, or EJB module during deployment. In the Administration Console, check the Availability Enabled box, or use the deploy command with the --availabilityenabled option set to true.

    9. Note

    Session persistence is incompatible with dynamic deployment, dynamic reloading, and auto deployment. These deployment features are intended for development environments, not production environments. For information about how to disable these features, see Chapter 5, "Deploying Applications."

    Note

    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.

Levels of Availability

Availability can be enabled at five different levels:

  1. The server instance, enabled by default
  2. The web or EJB container, enabled by default
  3. The application, disabled by default
  4. The stand-alone web or EJB module, disabled by default
  5. The SFSB, disabled by default

For availability to be enabled at a given level, it must be enabled at all higher levels as well. For example, to enable availability at the application level, you must also enable it at the server instance and container levels.

The default for a given level is the setting at the next level up. For example, if availability is enabled at the container level, it is enabled by default at the application level.

When availability is disabled at the server instance level, enabling it at any other level has no effect. When availability is enabled at the server instance level, it is enabled at all levels unless explicitly disabled.

Availability of Single Sign-on in the HTTP Session State

In a single application server instance, once a user is authenticated by an application, the user is not required to reauthenticate individually to other applications running on the same instance. This is called single sign-on. For more information on single sign-on, see "Verifying 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 to the HADB. First enable availability for the server instance and the web container, then enable single-sign-on state persistence. See "Configuring Availability at the Server Instance Level".

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.

Sample Applications

The following directories contain sample applications that demonstrate HTTP and SFSB session persistence:

install_dir/samples/ee-samples/highavailability
install_dir/samples/ee-samples/failover

Admin Console Tasks for Configuring Availability

Configuring the SFSB Session Store When Availability Is Disabled

If availability is disabled, the local file system is used for SFSB state passivation, but not persistence. To change where the SFSB state is stored, change the Session Store Location setting in the EJB container. See "Configuring the General EJB Settings".

Configuring Availability at the Server Instance Level

To enable or disable availability at the server instance level using the Administration Console:

  1. In the tree component, expand the Configurations node.
  2. Expand the node for the configuration you want to edit.
  3. Select the Availability Service node.
  4. Go to the Availability Service page.
  5. Enable instance level availability by checking the Availability Service box. To disable it, uncheck the box.

    6. You can change the Store Pool Name if you changed the JDBC resource used for connections to the HADB for session persistence. For details, see the description of the configure-ha-cluster command in the Reference Manual.

  6. Click on the Save button.
  7. Expand the Instances node.
  8. Select the server instance.
  9. Go to the server instance page.
  10. Restart the server.

Configuring Availability at the Web Container Level

To enable availability or override availability settings for an individual web application, use settings in the sun-web.xml file. For details, see the Developer’s Guide.

To enable or disable web container availability using the Administration Console:

  1. Select the Web Container Availability tab, then check the Availability Service box. To disable it, uncheck the box. You can also change these optional 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 ha (the HADB). If availability is enabled, the default is ha. If availability is disabled, the default is memory. For production environments that require session persistence, use ha.

      If the Persistence Type is set to memory, you can use the sessionFilename property to specify a file system location where the HTTP session state is stored if the server instance is gracefully shut down. This is useful for internal testing but is not supported for production environments.

      If the Persistence Type is set to file, you can use the directory property to specify the file system location where the HTTP session state is stored. Persisting to the file system is useful for internal testing but is not supported for production environments.

    • Persistence Frequency: Specifies how often the session state is stored. Applicable only if the Persistence Type is ha. Allowed values are as follows:
      • 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 less of a guarantee that the session state is fully updated. However, it can provide a significant performance improvement because the state is not stored after each request. To set this property, see "Configuring the Store Properties".
    • Persistence Scope: Specifies how much of the session state is stored. Applicable only if the Persistence Type is ha. 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 J2EE 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.
    • HTTP Session Store: You can change the HTTP Session Store if you changed the JDBC resource used for connections to the HADB for session persistence. For details, see the description of the configure-ha-cluster command in the Reference Manual.
  2. Click on the Save button.
  3. To change additional optional settings that affect session persistence, see "Configuring Web Container Sessions".
  4. Expand the Instances node.
  5. Select the server instance.
  6. Go to the server instance page.
  7. Restart the server.

Configuring Availability at the EJB Container Level

To enable availability and select methods to be checkpointed for an individual stateful session bean (SFSB), use settings in the sun-ejb-jar.xml file. For details, see the Developer’s Guide.

To enable or disable EJB container availability using the Administration Console:

  1. Select the EJB Container Availability tab, then check the Availability Service box. To disable it, uncheck the box. You can also change these optional settings:
    • HA Persistence Type: Specifies the session persistence and passivation mechanism for SFSBs that have availability enabled. Allowed values are file (the file system) and ha (the HADB). For production environments that require session persistence, use ha, the default.
    • SFSB Persistence Type: Specifies the passivation mechanism for SFSBs that do not have availability enabled. Allowed values are file (the default) and ha.

      If either Persistence Type is set to file, the EJB container specifies the file system location where the passivated session bean state is stored. See "Configuring the General EJB Settings". Checkpointing to the file system is useful for internal testing but is not supported for production environments.

    • SFSB Store Pool Name: You can change the SFSB Store Pool Name if you changed the JDBC resource used for connections to the HADB for session persistence. For details, see the description of the configure-ha-cluster command in the Reference Manual.
  2. Click on the Save button.
  3. Expand the Instances node.
  4. Select the server instance.
  5. Go to the server instance page.
  6. Restart the server.


Previous      Contents      Next     

Copyright 2004 - 2005 Sun Microsystems, Inc. All rights reserved.