As you know, Java web applications have the concept of a Session object that allows them to handle multiple user session. This is because HTTP protocol is stateless and Session is used in maintaining user’s state across multiple HTTP requests.
In a single web server configuration, there is no issue persisting Web Sessions but as soon as you have a multi-server load balanced web farm running your Java web application, you immediately run into the issue of where to persist the Web Session. This is because a load balancer ideally likes to route each HTTP request to any web server that is most appropriate at that time based on the load on all web servers. But, if the Session for this user is kept on a specific web server, then you’re forced to use the sticky session feature of the load balancer so it sends the HTTP requests always to that specific web server where the given Web Session was originally created.
Sticky Sessions are Bad
This sticky session behavior means one web server might get overwhelmed with too many HTTP requests because the Web Session for that user resides on that web server even though you have other web servers sitting idle or with much less load. This of course limits scalability because you cannot solve this issue just by adding more web servers. Additionally, keeping the Web Session object only on one web server also means loss of Session data if that web server goes down for any reason. And, losing Web Session means your users are kicked out of your application and have to log in again.
Regular Session Replication is Slow
To avoid this data loss problem, you must have a mechanism where Web Session is replicated to more than one web server. Here, the leading Servlet Engines (Tomcat, WebLogic, WebSphere, and JBoss) all provide some form of Web Session persistence. They even include some form of Web Session replication but all of them have issues. For example, file based and JDBC persistence is very slow and cause performance and scalability issues. Web Session replication is also very weak because it replicates all Web Sessions to all web servers thereby creating unnecessary copies of the Web Session when you have more than two web servers even though fault tolerance can be achieved with only two copies.
Solution: In-Memory Data Grid
In such situations, a Java in-memory data grid like JvCache is your best bet because it resolves these issues seamlessly without any code changes. JvCache ensures that the Web Session persistence across multiple servers in web cluster is done very intelligently and without hampering your scalability. JvCache has a caching topology called “Partition-Replica” that not only provides you high availability and failover through replication but also provides you large in-memory session storage through data partitioning. Data partitioning enables you to store large amounts of data by breaking up the data grid into partitions and storing each partition on different server in the data grid.
JvCache Partition-Replica topology replicates the session data of each node to only one other node in data grid. This approach eradicates the performance implications of replicating session data on all servers without compromising the reliability.
In addition, session persistence provided by the web servers (Apache, Tomcat, Weblogic and WebSphere) uses the resource and memory of web cluster. This approach hinders your application performance because the web cluster nodes which are responsible to process the client request are also handling the extra work of session replication and its in-memory storage. Whereas, you can use JvCache to formulate a data grid on separate boxes other than the ones part of your web cluster. This way you can free the web cluster resources and web cluster can use those resources to handle more and more client requests.
JvCache Web Session Persistence Plug-In
For Web Session persistence, JvCache has implemented session module jvc-sessionprovider.jar as Java filter. JvCache Web Session Filter dynamically intercepts requests and responses and handles session persistence behind the scenes. And, you don’t have to change any of your application code.
Following is example of how the deployment descriptor should look like after defining the
JvCache session filter for your web application.
<session-config> <session-timeout>30</session-timeout> </session-config> <filter> <filter-name>jvc-sessionprovider</filter-name> <filter-class> com.alachisoft.jvcache.web.sessionstate.JvCacheStoreProvider</filter-class> <init-param> <description>Name of running cache that will be used to persist sessionstate.</description> <param-name>cacheName</param-name> <param-value>mycache</param-value> </init-param> <init-param> <description>configPath is used to load the jvc-client.conf </description> <param-name>configPath</param-name> <param-value>%JVC_HOME%/config/</param-value> </init-param> </filter> <filter-mapping> <filter-name>jvc-sessionprovider</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list>
Hence, JvCache provides you a much better mechanism to achieve session persistence and replication in web cluster along with performance boost and scalability.
You can use JvCache and try it yourself to see how easily JvCache solves your Web Session persistence and replication issues.