Shiro will delegate to a cache for persistence of authc, authz and
session data.  The Cache/CacheManager implementation is responsible
for evicting entries based on implementation-specific
time-to-live/time-to-idle or memory constraint settings.

If you're using native sessions and the EnterpriseCacheSessionDAO
(where it is assumed the Cache itself has the ability to overflow to
disk if all available cache memory becomes full), you will want to
ensure that the session cache region does not evict entries at all
(the assumption is that they'd be removed permanently).  When Shiro's
session validation mechanism executes, it will explicitly remove
sessions that are stale or expired.  All other cache regions (authc,
authz data) can be evicted as you see fit.

Another approach for a sessions specifically is to turn off Shiro's
session validation entirely and let the Cache implementation's TTL
setting be the session timeout.  That is, if you set the TTL to, say,
30 minutes, then the Cache eviction mechanism _is_ the session cleanup
mechanism.  This might be more efficient than running a validation job
every N minutes, especially if you have a cluster of web application
instances (i.e. does each web app instance perform validation for the
entire cluster?  do they all do it?).

The key here is that _something_ is responsible for evicting stale or
expired sessions to ensure your session data store does not fill up
unnecessarily.  If you turn off Shiro's built-in validation mechanism,
something else must be responsible for it.

HTH,

Les

On Wed, Feb 8, 2012 at 6:36 AM, John Moore <[email protected]> wrote:
> I've implemented Cache and CacheManager using Redis. Am I right in thinking
> that Shiro handles all issues to do with cache expiration and that I
> shouldn't automatically expire the cache entries in Redis myself? I deduced
> this from looking at the EHCache implementation. Please correct me if I'm
> wrong. I'll probably still expire the entries after say 24 hours, to avoid
> clogging up the db with orphaned items, unless there's a compelling reason
> not to do this.

Reply via email to