On Mon, Jan 30, 2012 at 9:40 AM, John Moore <[email protected]> wrote: > Les, thanks for your very timely response. Since posting the earlier JSON > message I figured I'd just try doing straight object serialization to a > ByteArrayOutputStream and Base64 encoding the byte array, forgetting about > JSON, and I'd just got that working nicely when I read your response > (although I used standard Groovy stuff and not the Shiro utilities, which I > was unaware of). I may well go down that path as in reality I have no real > requirement for the human-readability of the stored session objects which > JSON would provide. > > You're right about Shiro hitting the session cache frequently - I traced a > request and was surprised how often the 'get' method of Cache is called. > Redis is blindingly fast but you're right, the network round trips would be > best avoided. Isn't there some staleness risk in using a local in-memory > cache, though?
There could be, depending on how long your TTL is. However, this is easily enough solved IMO using a ThreadLocal implementation that simulates a local cache: Look up the object in the ThreadLocal - if its ID matches the DAO ID argument, return it. If it doesn't match, clear out the ThreadLocal, look up the session object from the underlying store and then store it in the ThreadLocal. Also overwrite the ThreadLocal value during a write operation. This logic probably will go into Shiro's implementation for 1.3, but that kind of gives you an idea if you need this right away. (Of course if you do work on this and you are capable, any patches would be appreciated!) Cheers, Les -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
