Session Caching: Now Powered by Jedis!

So, recently, I changed over the backend session cache from a server-specific Java ConcurrentHashMap implementation to a Redis cache.  

Our session caching system is now powered by Jedis!

But seriously, Jedis is the Java implementation (one of several) of the access client to the Redis cache.  

The Redis cache itself is an impressively small -- only 13Mb of RAM running the server on Windows 7 -- and stores keys as hashed strings to save space for people who don't already hash their cache keys.  I am storing the sessions as JSON strings using Google's Gson to serialize and deserialize the JSON to and from my custom session objects.  The memory usage of the Redis compared to the ConcurrentHashMap that I was using are similar, but I gain the ability to access Redis from other servers in the same VPN as my other backend servers, so I can skip my clever passing of encrypted sessions via HTTP parameters.

The Jedis client itself is fairly compact and straightforward to use for the most part.  The only slightly complicated piece is the pooling, but it operates on the Apache Commons Pool 2 library, so there is copious amounts of documentation for it.

On top of this, I wrapped the Jedis in an API to mirror the ConcurrentHashMap API that my previous cache used, so it was a simple drop in solution for the implementation and only took about 1 hour of time to complete, which was incredible.  Most of my coding takes several hours to do and then hours to days to sometimes weeks of debugging.  So, to have it just work was astounding and speaks highly to the quality of the programming of the Jedis folks.

 á na márië,
gumshoe, out