Questions? Feedback? powered by Olark live chat software

Generic Web Session Replication

Web Session Replication is replicating web session to other members of the cluster each time there is a change in the session data. With session replication, session-failover is automatic. If an application server goes offline, the load balancer simply sends incoming requests to another server. The user can be sent to any server, since all servers have a copy of the user’s session.

Hazelcast Open Source Generic Session Replication

With Hazelcast Open Source Generic Session Replication, you can easily store your user sessions in Hazelcast. Let’s say you have more than one web server (A,B,C) with a load balancer. And when a server goes down, you don’t lose user sessions. Users will be routed to other servers (B or C) but they will continue their transactions: users don’t notice whether A is up or down. You can also scale your web servers. You can add new servers to your cluster or shut down servers from cluster. You will not lose any sessions.

Hazelcast Generic Web Session Replication Architecture

Hazelcast Generic Web Session Replication Architecture Diagram

If you are running on Tomcat or Jetty, consider using Hazelcast IMDG Native Session Replications over the Open Source Session Replication Module. Native Modules are more development operations friendly and better integrated into Tomcat and Jetty for better performance.

Requirements

The following are required for enabling Hazelcast Session Clustering.

  • The target application or web server should support Java 1.5+
  • The target application or web server should support Servlet 2.4+ spec
  • The session objects that need to be clustered have to be serializable

Easy to Set Up

You don’t change anything in your application. You only need to perform some configuration to easily attach Hazelcast Session Replication to your web applications.

Put the hazelcast and hazelcast-wm jars in your WEB-INF/lib directory. Optionally, if you wish to connect to a cluster as a client, add hazelcast-client as well.

Put the following XML into the web.xml file. Make sure Hazelcast filter is placed before all the other filters, if there are any: for example, you can put it at the top.

<filter>
   <filter-name>hazelcast-filter</filter-name>
   <filter-class>com.hazelcast.web.WebFilter</filter-class>
   <!–
       Name of the distributed map storing
       your web session objects
   –>
   <init-param>
       <param-name>map-name</param-name>
       <param-value>my-sessions</param-value>
   </init-param>
   <!– How is your load-balancer configured? stick-session
means all requests of a session is routed to the node where the session is
first created. This is excellent for performance. If sticky-session is set to
false, when a session is updated on a node, entry for this session on all other
nodes is invalidated. You have to know how your load-balancer is configured
before setting this parameter. Default is true. –>
   <init-param>
       <param-name>sticky-session</param-name>
       <param-value>true</param-value>
   </init-param>
   <!–
       Are you debugging? Default is false.
   –>
   <init-param>
       <param-name>debug</param-name>
       <param-value>true</param-value>
   </init-param>
</filter>
<filter-mapping>
   <filter-name>hazelcast-filter</filter-name>
   <url-pattern>/*</url-pattern>
   <dispatcher>FORWARD</dispatcher>
   <dispatcher>INCLUDE</dispatcher>
   <dispatcher>REQUEST</dispatcher>
</filter-mapping>
<listener>
   <listener-class>com.hazelcast.web.SessionListener</listener-class>
</listener>

Hazelcast.com

Menu