JSP 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 JSP Servlet applications run in a load-balanced web 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 cache like JvCache for persistence your JSP Servlet Session. JvCache provides intelligent replication of JSP Servlet Session and linear scalability at the same time.
If your JSP application is running in a load balanced web farm then you need a scalable and reliable JSP Servlet Session persistence. And, JvCache is an ideal JSP Servlet Session persistence option and you should use it for these reasons:
The best thing about using JvCache for JSP 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 JSP 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 JSP Servlet Session Persistence Filter through your application’s configuration file, you gain an enterprise level in-memory distributed cache for your JSP application. Here are some features JvCache provides for JSP Servlet Session persistence:
WAN Replication of JSP Servlet Session: JvCache provides a Bridge Topology to allow you to replicate your JSP 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 JSP 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 JSP 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 JSP Servlet Session: If you don’t want to replicate JSP Servlet Session across the WAN because of bandwidth consumption cost, you can choose to use this Multi-site JSP Servlet Session feature of JvCache. In this, the JSP Servlet Session is not replicated across sites and instead is kept at the location of its creation. But, then it is accessible to your JSP 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.
JSP Servlet Session Locking: JvCache implements session locking to allow you to handle concurrent JSP Servlet Session access. This may happen if you’re using AJAX or scripts/robots to talk to your JSP application.
Faster Dynamic Compact Serialization:Faster Dynamic Compact Serialization: When you put your Java objects in JSP Servlet Session and store it out-of-process the entire JSP 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 JSP 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.