Java Servlet Session provides two commonly used storage options. They are InProc and Clustered. But, both of them either slow performance, low or no scalability, or lack of reliability. And, these problems become more severe when your Java Servlet applications run in a load-balanced web server farm.
InProc option does not replicate JSP Servlet Session and therefore causes session data loss in case a web server goes down. Session clustering replicates the Session but is slow. And, both options have serious scalability issues.
A much better option is to use an in-memory distributed data grid like JvCache for persistence your Java Servlet Session. JvCache provides intelligent replication of Java Servlet Session and linear scalability at the same time.
JvCache is an extremely fast and scalable in-memory distributed data grid for Java applications. It lets you cache application data, reduce those expensive database trips, and improve your application performance and scalability.
If your Java application is running in a load balanced web server farm then you need a scalable and reliable Java Servlet Session persistence. And, JvCache is an ideal Java Servlet Session persistence option and you should use it for these reasons:
The best thing about using JvCache for Java Servlet Session persistence is that there is no programming required on your part. You simply modify your application configuration file and add JvCache as a Filter to your Java Servlet application. Here is an example of configuration changes:
< session-config> <session-timeout>30</session-timeout> </session-config> <filter> <filter-name>JvCacheSessionProvider</filter-name> <filter-class>com.alachisoft.jvcache.web.session.JvCacheSessionProvider </filter-class> <init-param> <description>Name of running cache that will be used to persist sessions. </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>%InstallDir%/config</param-value> </init-param> <!-- <init-param> <param-name>log.props</param-name> <param-value>log4j.properties</param-value> </init-param> --> <init-param> <description>Lock timeout in milliseconds to be used by JvCache locking API. API.</description> <param-name>lockTimeout</param-name> <param-value>1</param-value> </init-param> <init-param> <description>Enables JvCache JavaSession Provider to use session locking. </description> <param-name>enableSessionLocking</param-name> <param-value>true</param-value> </init-param> <init-param> <description>Number of retries in case the session is locked. </description> <param-name>numberOfRetries</param-name> <param-value>5</param-value> </init-param> <init-param> <description>Number of milliseconds delay to retry a locked session. </description> <param-name>retryInterval</param-name> <param-value>500</param-value> </init-param> </filter> <filter-mapping> <filter-name>JvCacheSessionProvider</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app>
By plugging in JvCache Java Servlet Session Persistence Filter through your application’s configuration file, you gain an enterprise level in-memory distributed data grid for your Java application. Here are some features JvCache provides for Java Servlet Session persistence:
WAN Replication of Java Servlet Session: JvCache provides a Bridge Topology to allow you to replicate your Java Servlet Session persistence store (the cache) to other datacenters across the WAN. JvCache supports active-passive, active-active, one active and multiple passive, and 3 or more active datacenter scenarios.
In case of active-active scenarios if the same Java Servlet Session gets updated in multiple datacenters and causes a conflict, JvCache does conflict resolution on “last update wins” rule. But, you can provide your own conflict resolution handler.
With JvCache Bridge Topology, you can ensure that your Java Servlet Session is replicated to multiple datacenters and there is no loss of data in case any datacenter goes down. Read more about Bridge Topology.
Multi-site Java Servlet Session: If you don’t want to replicate Java Servlet Session across the WAN because of bandwidth consumption cost, you can choose to use this Multi-site Java Servlet Session feature of JvCache. In this, the Java Servlet Session is not replicated across sites and instead is kept at the location of its creation. But, then it is accessible to your Java application that is running in other datacenters.
This allows you to have two or more active data centers, keep most of the traffic to its own datacenter but occasionally overflow to the other datacenter if you want. And, you can also bring down one datacenter without causing any interruptions for the users because their sessions will be accessible by other datacenters.
Java Servlet Session Locking: JvCache implements session locking to allow you to handle concurrent Java Servlet Session access. This may happen if you’re using AJAX or scripts/robots to talk to your Java application.
Faster Dynamic Compact Serialization: When you put your Java objects in Java Servlet Session and store it out-of-process the entire Java Servlet Session must be serialized along with your Java objects with regular Java serialization. And, this regular Java serialization uses Reflection at runtime and is therefore quite slow. JvCache provides almost 10 times faster serialization called Dynamic Compact Serialization. With this, your Java application speed increases noticeably. And, the best thing is that you don’t have to write any code for it.
With Dynamic Compact Serialization, JvCache provides a way for you to register your Java classes with JvCache and JvCache generates serialization source code at runtime when your application connects to the cache. JvCache then compiles this source code in memory and uses it for serialization. That is why this is so much faster than regular Java serialization.