Product overview > Cache integration overview
Listener-based session replication manager
The eXtreme Scale session replication manager that is shipped with WebSphere eXtreme Scale can work with the default session manager in the application server to replicate session data from one process to another process to support user session data high availability.
The session manager has been designed so that it can run in any Java™ Platform, Enterprise Edition v1.4 container. The session manager does not have any dependencies on WebSphere APIs, so it is capable of supporting various versions of WAS as well as vendor application server environments.
The HTTP session manager provides session replication capabilities for an associated application. The session replication manager works with web container's session manager to create HTTP sessions and manage the life cycles of HTTP sessions that are associated with the application. These life cycle management activities include: the invalidation of sessions based on a timeout or an explicit servlet or JSPs call and the invocation of session listeners that are associated with the session or the web application. The session manager persists its sessions in an ObjectGrid instance. This instance can be a local, in-memory instance or a fully replicated, clustered and partitioned instance. The use of the latter topology allows the session manager to provide HTTP session failover support when application servers are shut down or end unexpectedly. The session manager can also work in environments that do not support affinity, when affinity is not enforced by a load balancer tier that sprays requests to the application server tier.
Usage scenarios
The session manager can be used in the following scenarios:
- In environments that use application servers at different versions of WAS, such as in a classic migration scenario.
- In deployments that use application servers from different vendors. For example, an application that is being developed on open source application servers and that are hosted on WAS. Another example is an application that is being promoted from staging to production. Seamless migration of these application server versions is possible while all HTTP sessions are live and being serviced.
- In environments that require the user to persist sessions with higher quality of service (QoS) levels and better guarantees of session availability during server failover than default WAS QoS levels.
- In an environment where session affinity cannot be guaranteed, or environments in which affinity is maintained by a vendor load balancer and the affinity mechanism needs to be customized to that load balancer.
- In an environment to offload the overhead of session management and storage to an external Java™ process.
- In multiple cells to enable session failover between cells.
- In multiple data centers or multiple zones.
Session manager details
The session replication manager uses standard session listener to listen on the changes of session data, and persists the session data into an ObjectGrid instance either locally or remotely. The session data is reloaded in the request path through the standard servlet from the ObjectGrid instance either locally or remotely. You can add the session listener and servlet filter to every Web module in the application with tooling that ships with WebSphere eXtreme Scale. You can also manually add these listeners and filters to the Web deployment descriptor of the application.
The session replication manager works with each vendor's base session manager to replicate application session data. Note the following considerations.
- Choose embedded ObjectGrid containers or remote ObjectGrid containers, depending on performance requirements and the data sizes. The embedded scenario gives the easiest configuration and better performance.
- Choose the number of remote ObjectGrid containers per web container according to user data sizes.
- Choose to store the whole session data together or store each attribute separately, depending on the number and size of attributes user data and change frequencies.
- Choose the replication interval. Less aggressive replication interval gives better performance.
- Choose the session table size to balance local memory size and performance. The product offloads session user data when local session cache maximum size is reached.
- The product supports HTTP sessions within the application context, according to the Servlet specification, to avoid security and use attribute naming conflict issues. You can share sessions across application context by their singleton class.
- The session replication manager replicates session data for high availability, by listening to the session data changes and reloading the stored session data on demand. This is accomplished by reusing the web container base session manager of each vendor. The session is linked together through various native session IDs. Session data is failed over from one web container into another web container by reloading session data from ObjectGrid instance. Session ID and creation time could differ before and after failover.
Parent topic:
Cache integration overview
Related concepts