Multi-site Java Session Support

NCache provides multi-site session persistence that can be used to manage Java servlet sessions across multiple web farms (that are geographically separated), if you do not want to replicate sessions across WAN because of the bandwidth consumption costs.

To understand multi-site session persistence, consider Java servlet applications that run in load-balanced web server farms that span multiple regions. A Load Balancer can redirect clients to different regions depending on user traffic. To cache sessions, a clustered cache is required so that sessions replicate across regions. This approach may not be suitable due to session replication across the WAN. Also, it may raise performance issues because the caching nodes are geographically separated.

To solve these problems, NCache presents the concept of multi-site sessions. Caching the sessions in a geographically separated web farms application requires configuring separate caches in each region. Let's suppose you have four regions, each configured with separate caches as CR-1, CR-2, CR-3, and CR-4. Each clustered cache has its own set of clients (Java servlet) as a web farm. Each client will configure the NCache session servlet filter. You need to specify the primary cache (current region cache) and a set of secondary caches (list of other region caches) along with the user-defined prefixes against each cache name.

This configuration loads upon initialization of the NCache session provider filter. In this way, each client will be aware of caches in other regions. The session ID created by the NCache session provider is as per each region's primary cache prefix, i.e., the prefix of the primary cache appends in session IDs of that region. These clients will add, update, and get sessions mostly from their own clustered cache, i.e., the primary cache. However, at times a client request might be sent to the web farm of another geographical location for load balancing. Now, NCache will identify the request from its primary cache prefix and allow the user requests to access the same session from the previous cache.

To understand this, consider a request route to a web farm of the CR-2 region cache. In this situation, NCache extracts the session ID prefix that will be CR-1 and will search its cache ID in its own secondary caches list. As all region clients will have a set of all other region caches as secondary caches, NCache will fetch this session from the CR-1 cache. NCache will update this session's ID by appending its current primary cache prefix, i.e., CR-2, and updating it in the current primary cache (CR-2) to serve future requests.

Let's suppose a client makes a request that passes through the Load Balancer. Suppose the session request passes to the Web Server1 within a web farm based on system load. Once the request arrives, a session is created with the Web Server1 prefix appended with the session ID and saved in the primary cache for this web farm, in this case, Replicated Cache1.

When the Load Balancer routes the same client to Web Farm2, NCache analyzes the session prefix. With the help of this prefix, it fetches the session from Replicated Cache1 even though it belongs to Web Farm1. This allows you to have two or more active data centers and keep most of the traffic in its own data center, but occasionally overflowing to other data centers if necessary. And you can also bring down one of the data centers without causing any interruptions for the users because their sessions will be accessible by other data centers. Or we can say that if one of the web farms goes down for any reason, other web farms will start accessing user sessions from that region cache, and eventually, the entire session data is moved to the cache in the next region to prevent losing session data.

NCache provides a no-code change option for Java-based web applications to store sessions in NCache by implementing the session module nc-sessionprovider.jar as a JSP Servlet Filter. To use the NCache Java session module, you must be running a Servlet 2.3+ compatible container (webserver). The user only needs to reference a few libraries and add a filter in the web.xml of the application so that all the requests will come to the application through NCache. The following J2EE/Jakarta platforms are supported:

Tomcat
JBoss/WildFly
Web Logic
WebSphere

To learn more about how you can configure Multi-Site Session Module, please refer to Multi-Site Session State Provider.

Multi-site Java Session Support

See Also