Hi Ryan,

The way I've done this in the past is to have a custom SessionDAO that
communicates with a backing data store that allows query/lookup by
either the session ID or user ID.  When a user authenticates during
their session, I save the user ID as a session property (not
necessarily an 'attribute' in the attribute map).  I hesitate to call
this a user id 'column' though since this technique works just as well
in NoSQL data stores as it does in RDBMSs.  Also, many enterprise
caches allow this type of query capability such that you can still use
only the EnterpriseCachingSessionDAO directly.

Anyway, with this in place, I can query the session data store based
on user id for my needs, while Shiro can (via the SessionDAO) lookup
the session by session id for its needs.

Another approach is to have 2 caches to satisfy needs:

1.  The normal cache of session ID to Session that the Shiro
CachingSessionDAO uses.
2.  A second cache of user id to session id mappings.  Based on the
user id, you can lookup the session ID and then get the session from
the first cache.

This technique would require a persistent cache that can overflow to
disk so you don't randomly lose entries due to LRU algorithms.  You'd
also need to ensure that both caches are cleaned up if you delete
either a user or session.

My preference is to go with a custom SessionDAO with a backing data
store that allows me to query against either the session id or user id
'columns' in the data store, but the dual cache mechanism would work
fine too (as long as it will never evict data).

Also note that with either approach, native session 'cleanup' (to
prevent filling up memory/disk) is handled by the
SessionValidationScheduler (a property of
AbstractValidatingSessionManager instances, like the
DefaultSessionManager and DefaultWebSessionManager).  The scheduler
ensures that cleanup runs periodically to prevent orphans.  You can
use the default or implement your own for custom cleanup strategies.
The default ExecutorServiceSessionValidationScheduler implementation
uses a regular/periodic validation period while the
QuartzSessionValidationScheduler can allow for more control via cron
expressions and the like.

Does that help?

Cheers,

-- 
Les Hazlewood
CTO, Katasoft | http://www.katasoft.com | 888.391.5282
twitter: http://twitter.com/lhazlewood
katasoft blog: http://www.katasoft.com/blogs/lhazlewood
personal blog: http://leshazlewood.com

Reply via email to