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
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.
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.
hazelcast-wm jars in your
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>