Announcing vFabric GemFire HTTP session management module for Tomcat/TCServer

Clustering of HTTP Sessions has been around for a while. I suspect many of you are already wondering how is this better or unique compared to the built-in clustering mechanisms in application servers or third party solutions like EHCache, Oracle Coherence, etc. Several of our customers already manage sessions in GemFire explicitly using our API. The need to effectively manage large quantities of session state is too great not to use a distributed data grid solution such as GemFire, which can partition session state in memory across the cluster for scale and maintain synchronous copies of session state in memory on multiple nodes to provide high availability (HA).

So, what is new? This announcement brings clean, pluggable integration of GemFire within Tomcat and SpringSource tc Server environments. HTTP session management is enabled through very simple configuration steps. Unlike other competitive products, there is no vendor-specificonfiguration of  "cache" XML in most cases. If you understand your application volume and scale requirements then it might just be a matter of configuring one of the pre-packaged templates when you start up tc Server instances.

You can read about the features, download and give it a try from our community site.

But, there are several interesting patterns that go beyond this basic value proposition and I will attempt to cover these below ...

Support for multi site clustering: Today, HA for sessions implies copies maintained on 2 or more servers that are part of the same cluster. If the entire cluster were to fail or becomes unreachable (say a network split occurs) your applications is likely going to fail over to some DR cluster but without access to the sessions. Wouldn't it be nice if your session state survives such failure conditions?  With Gemfire, you can configure the session state to be replicated over what we call "WAN gateways"(See section "multi site setup") to your DR cluster. The replication is asynchronous with support for batching and conflation.

Sessions are getting increasingly obese and may never die: Session state often reference personalization information - things like preferences, past transactions and even things like past chat sessions with customer support. Traditionally, all this data was only managed in the RDB and fetched every single time the user logs in - one of the main causes of database overload. Increasingly, I see sessions that range in size from a few KB to several MB each. These are represented by convoluted object graphs and when changes occur, they represent only a minuscule fraction of the entire session state. Managing complex, constantly changing and ever growing session state requires special consideration:

1. when sessions change the session replication layer needs to be smart about only replicating the changes and not the entire session every single time. 
2. User Sessions may come and go but the associated state may last forever. This implies you cannot maintain everything in memory. You need to offload to disk as well as a super efficient mechanism to persist the state to disk across the cluster. This persistence mechanism cannot be expensive and shouldn't require administration overhead like with common RDBs.

With GemFire, when sessions are updated only updated attributes are sent over the wire - to servers and replicas. Session state can overflow to disks across the cluster and can even be made persistent. The state will recover in parallel even if the entire cluster were to be restarted.

Burst into the cloud: There is increasing interest in the ability to go beyond what the cluster can handle when the load threshold is too great. Ideally, applications can burst into the "cloud" – most likely a private cloud that supports on-demand provisioning of resources using virtualization. Bursting, basically, means new Tomcat instances would get sparked on demand in some remote data center. This may also mean migrating users to the new cluster. Now, wouldn't it be nice if the session state were to magically appear or be accessible from the primary cluster?
Alright! in reality, magic is just an illusion. Nothing happens magically in GemFire. Let me spare you a long narration. With GemFire, one can achieve this by configuring WAN gateways to potential remote clusters. If and when a remote "cloud" cluster were to be launched, the sessions will automatically land up getting replicated.

Sessions span heterogeneous apps: Session state published by one clustered application may need to be accessible by other distributed applications. These applications won't necessarily be deployed as part of the same application server cluster. You need session state that can outlast your application or your cluster, with a storage format such that it is accessible from other languages. Though we don't support pluggable session management for other languages like .NET(yet), the application developer can still use GemFire native serialization and access the session state from other environments like C# and C++. We intend to support seamless session access across many environments in the future.

So, again, You can read about the features, download and give it a try from our community site.