This blog post is about applications that, by design, maintain and keep some level of session data associated with their users. The reality of session data is that one has to plan on session data failover. If the application process is taken down for maintenance or due to some other runtime issue like running out of memory or crashing then the user's session data needs to be able to be reinstantiated in another application instance. The mechanism for accomplishing this is known as session persistence. The session data is persisted in some cache accessible to all the application instances and updated as changes are made to the user's session. This post addresses the different available mechanisms for traditional WebSphere Application Server Network Deployment environments.
In memory session persistence
Without using a database there are a couple of strategies one can use with strictly in memory session persistence.
Memory to memory Peer to Peer
In its simplest form all the JVMs in a cluster can share session data with each other. Suitable for small scale, development application functional testing of session failover. It is not suitable for any other environment as the size of the cluster grows and the number of user sessions increase the overhead of maintaining session state starts to monopolize the CPU across all nodes and cluster members.
Memory to memory client / server
A slightly more sophisticated technique is treating the application JVMs as clients to a cluster of JVMs dedicated to session persistence or Replication Domain. This alleviates the persistence from the application cluster and moves that workload to JVMs whose job is to do nothing more than persist session data. However, there will be practical limits. If the user base continues to grow then eventually more capacity is needed for both CPU and memory. Leading to problems when resources are exhausted.
Database Persistence
By far the most robust persistence mechanism is the database. After all, a database is meant to hold and retrieve data fast and efficiently. Though mechanisms like configuring multi-row persistence individual attributes of the session object can be persisted individually without the rest of the unchanged attributes. The database has scalability capabilities that are much easier to implement and its own troubleshooting mechanisms. Configurations of the JDBC connection pool can be optimized for performance.
eXtreme Scale
Another robust method is using the eXtreme Scale external cache. Not as widely used as database persistence (everyone usually has a database already available) it is an option that is available and proven to be reliable and scaleable. Running eXtreme scale does require setting up its dedicated runtime environment, clusters and configurations.
Conclusion
Session persistence, as with most technologies, has many ways it can be implemented. However, employing the database to provide session persistence has been the mainstay for most enterprise customers as it provides the best performance for the least amount of system administration, is comparatively easy to troubleshoot and most people already have a database available.
#automation-portfolio-specialists-app-platform #WebSphereApplicationServer