Session persistence considerations

Unless you have only a single application server or your application is completely stateless, maintaining state between HTTP client requests is also a factor in determining your topology. Use of session information, however, presents a fine line between convenience for the developer and performance and scalability of the system. It is impractical to eliminate session data altogether, but try to minimize the amount of session data passed. Persistence mechanisms decrease the capacity of the overall system, or incur additional costs to increase the capacity or even the number of servers. Therefore, when designing your WebSphere environment, take session needs into account as early as possible.

If the application maintains state between HTTP requests and you use vertical or horizontal scaling, then consider using an appropriate strategy for session management. Each application server runs in its own JVM process.

To allow a failover from one application server to another without losing state, share the session data between multiple processes.

There are two methods of achieving this in WAS Network Deployment:

• Memory-to-memory session replication

  This method employs Data Replication Service (DRS) to provide replication of session data between the process memory of different application server JVMs. DRS is included with WAS and is automatically started when the JVM of a clustered member starts.

  It also does not require a separate database to store the persistent states, and eliminates a single point of failure found in the session database if the database itself has not been made highly available using clustering software.

• Database persistence

  With this method, session data is stored in a database shared by all application servers. It requires external clustering software to make it highly available.

  The default maximum pool size of 10 is a useful starting point when you size the connection pool for database persistence. You may want to increase it if wer session object is quite large, or your site handles thousands of concurrent users.

  Regarding large session objects: You can achieve faster performance by increasing page size, which will allow session object to fit into a single database page. In IBM DB2®, for example, page size can be adjusted from the default of 4 KB to 8 KB, 16 KB, and 32 KB. Using the multi-row schema option can also improve performance.

  For larger session sizes, the overhead of session replication increases. Database replication has a lower overall throughput than memory-to-memory due to database I/O limitations (the database becomes a bottleneck). However, although like database replication with large sessions performs slower, less CPU power is used than with memory-to-memory replication, and the unused processor power can be used by other tasks on the system.

  Also, storing session states in a persistent database or using memory-to-memory replication provides a degree of fault tolerance to the system. If an application server crashes or stops, any session state that it may have been working on would normally still be available either in the back-end database or in the running application server's memory, so that other application servers can take over and continue processing subsequent client requests associated with that session.

  Neither mechanism provides a 100% guarantee that a session state will be preserved in case of a server crash. However, such a situation represents only a very small window of vulnerability, and a very small percentage of all occurrences that typically happen throughout the life of a system in production.

  The overhead of replicating session information might be significant, depending on the number of application servers in your cluster and the size of the sessions. In these situations, database persistence might be the better choice in a memory-constrained environment.

  The question becomes, how to choose one option over the other. For configurations where cross-cell session failover is a requirement, then database persistence might be the better choice. In a cascading failure, the database may survive, although memory-to-memory replicators may not. Similarly, with memory-to-memory, there can only be a single replicator common to the cells, which leads to a single point of failure (SPOF).

  Keep in mind that most of the cost of replication is incurred in the serialization and deserialization of the session object, and this applies to both cases. Also in both cases, as a session object's size increases, performance decreases.

  Ultimately, your decision will depend upon your application availability requirements, the quality of service needed for your applications, and your comfort zone for the technology, whether database or memory-to-memory.

  ---