As there is growing need for supporting cross-cluster availability with zero downtime deployment of our application, the need to implement a session caching mechanism which helps us achieve this and other requirements (viz. support clustering without depending on weblogic session replication, better visibility into cache contents for better application performance and management) became evident. With these requirement to cache the HTTP session for our application we started looking around cache stores to implement the same.
With many stores like Hazelcast, Memcached and Redis, we found Redis suits best to our needs. (Will keep discussion about all these three and their working compared to each other for another day!)

From the Redis website “Redis is an open source, BSD licensed, advanced key-value cache and store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperlog logs.” [ ] So Redis is much more than a cache store and there are quite a few potential use cases for us in our current application. And hosting for this being AWS Elasticache it comes with whole set of AWS hosting benefits for our application.

There are various clients available for Redis (in various languages). Our application being built using Spring and other open source frameworks, We chose Jedis and Spring Data. Not only they get along very well but they are easy to include in a spring project and start off our engineering efforts!

In the same lines of JDBCTemplate, Spring Data provides RedisTemplate as interface for all the Redis operations while the Jedis provides a pooled connections to Redis server. With a custom web filter which intercepts all the HTTP requests we were able store away all the contents of the sessions into Redis. The hash operations and bulk get and set APIs provided by Redis come handy in our use case. Through the availability of hash store it is quite convenient to group all the attributes belonging to a session.

Several other features which are part of the implementation are,
a. deferred-write mode (updating the contents of session on Redis at the end of each request-response cycle instead of reading/writing for every attributes. This reduces a lot of traffic between the application server and the Redis server)
b. fail-safe mechanism when Redis server becomes unavailable (e.g. during a failover scenario when it takes a minute or two to promote a new redis primary)
c. capture tracing information in order monitor and analyse the session usage

To ease the development efforts Redis comes with quite a few handy tools for monitoring, memory usage etc.

Update: Spring has released their Spring Session API which looks promising. However how it will fare when it comes to functionalities like deferred writes, fail over scenarios when used with Redis or similar caching mechanism will be something interesting to look into.