Multi-site Java Session Support

NCache provides multi-site session persistence to manage servlet Java sessions across gegraphically distant web .This helps to save the bandwidth consumption in replicating sessions across WAN. To understand this, consider Java servlet applications running in load-balanced web server farms spanning multiple regions. A Load Balancer can redirect clients to different regions depending on user traffic. To cache Java sessions, a clustered cache is required so that sessions replicate across regions. However, this approach may not be suitable due to the high bandwidth consumption and performance issues caused by session replication across the WAN, especially since the caching nodes are geographically separated.

NCache Multi-site Java Sessions

To solve these problems, NCache presents the concept of multi-site sessions. Caching the sessions in a geographically separated web farm applications 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 servlets) as a web farm, with each client configuring 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 is loaded when the NCache session provider filter is initialized, allowing each client to recognize caches in different regions. The session id generated by the NCache session provider includes a prefix that corresponds to the primary cache of each region, making it easy to identify the session associated with that specific region. These clients will add, update, and get sessions mostly from their own clustered cache, i.e., the primary cache. However, there are times when a client request may be routed to a web farm in a different geographical location for load balancing. In such cases, NCache can identify the request using its primary cache prefix, enabling users to access the same session from the previous cache.

To understand this, consider a request routed 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 have a set of all other region caches as secondary caches, NCache will fetch this session from the CR-1 cache. It then updates the session id by appending its current primary cache prefix, i.e., CR-2, and saves this updated session in the CR-2 cache for future requests. Let's suppose a client makes a request that goes through the Load Balancer. It is then directed to Web Server1 in a web farm based on system load. When the request arrives, a session is created with the Web Server1 prefix added to its session id, and saved in the primary cache for the web farm, which in this case is Replicated Cache1.

When the Load Balancer directs the same client to Web Farm2, NCache analyzes the session prefix and retrieves the session from Replicated Cache1, even though it belongs to Web Farm1. This setup allows for multiple active data centers, managing most traffic locally while occasionally redirecting to others when needed. Additionally, if one data center goes down, user sessions remain accessible from other data centers, ensuring uninterrupted service. If necessary, session data can also be transferred to the cache in another region to prevent data loss.

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

  • Tomcat
  • JBoss/WildFly
  • Web Logic
  • WebSphere

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

See Also

Conceptual Overview
Configuring Applications to Use Java Session Module
Error Logging