Redis is indeed a good choice for this too. But like Hazelcast, you'll want to ensure it dumps data to disk (how often is dependent upon your needs) so if your Redis cluster runs out of memory you don't lose sessions.
On Thu, Jan 24, 2013 at 7:47 AM, John Moore <[email protected]> wrote: > We're using Redis as a backing store for sessions, because it's blindingly > fast and completely straightforward to deploy (on Debian/Ubuntu, 'sudo > apt-get install redis-server' is pretty well all you need to do). I did a > Redis implementation of the Cache and CacheManager classes, in > Grails/Groovy > (but they should be easily translatable to straight Java). > > In a short time, Redis will, I believe, have the feature you require, using > its publish/subscribe mechanism, so your application could subscribe to the > event which occurs when that session key expires. In the meantime, though, > you could easily do some kind of workaround using polling (which, given the > relatively small likely number of concurrent sessions and the sheer speed > of > Redis, would be unlikely to have much overhead), whereby you maintain an > in-memory list of session keys and every 10 seconds, say, you loop through > this checking whether each one is still alive in Redis. If not, you can do > any clean-up you require and remove it from the list. > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/EnterpriseCacheSessionDAO-Session-Expiry-and-Reporting-Session-State-tp7578194p7578203.html > Sent from the Shiro User mailing list archive at Nabble.com. >
