Session persistence considerations

 

If the application maintains state between HTTP requests and we are using vertical or horizontal scaling, then we must consider using an appropriate strategy for session management.

Each appserver runs in its own JVM process. To allow a failover from one application server to another without logging out users, we need to share the session data between multiple processes. There are two different ways of doing this in IBM WAS Network Deployment V5.1:

  1. Memory-to-memory session replication

    Provides replication of session data between the process memory of different appserver JVMs. A JMS based publish/subscribe mechanism, called Data Replication Service (DRS), is used to provide assured session replication between the JVM processes. DRS is included with IBM WAS Network Deployment V5.1 and is automatically started when the JVM of a clustered (and properly configured) application server starts. Please note that DRS is not based on JMS, so you do not need to install the WebSphere JMS Provider.

  2. Database persistence

    Session data is stored in a database shared by all appservers.

Memory-to-memory replication has the following advantages and disadvantages compared to database persistence:

See HTTP sessions and the session management facility for additional information about the performance of database persistence versus memory-to-memory replication.

Refer to Chapter 14, "Configuring session management", especially Section 14.9, "Persistent session management", of the redbook IBM WebSphere Version 5.0 System Management and Configuration, SG24-6195 for detailed information.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.