This is by design - a cache should cache elements as necessary so as to not saturate the network. This is well within a cache's realm of operation and responsibility.
> If you keep session work to a minimum (only principal info), this shouldn't > really happen in reality but still the # of calls will flood any distributed > cache/storage. All distributed caches I've ever used will (or can) perform local in-memory optimizations as necessary to prevent hits to the remote nodes when possible. If for some reason your distributed cache does not do this, you can easily create a Shiro CacheManager that 'wraps' your networked Cache mechanism that uses SoftHashMaps as a local in-memory cache as an optimization. An additional reason this was by design is due to write operations - during a thread's execution, when should a Shiro write operation 'hit' the underlying data store? Typically DAOs and Cache mechanisms are very intelligent in knowing when to do this (e.g. synchronizing w/ a transaction mechanism) - far better than Shiro could without do (without adding in tremendous complexity). However, we're always open to suggestions! If you feel that additional work should be done in this area, please open a Jira issue and open a discussion on the dev list and we can take it from there. Cheers, -- 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
