Session Invalidation race condition with clustered sessions?

[Eric Pederson <er...@gmail.com>]

Hi all -

In the typical web app scenario using Shiro sessions, each app will have a
session invalidation thread running.   Are there any problems that I should
worry about regarding race conditions when using clustered (eg Terracotta)
sessions -- ie, multiple session invalidation threads stomping on each
other?

-- Eric

Re: Session Invalidation race condition with clustered sessions?

[Les Hazlewood <lh...@apache.org>]

You really only need one server invalidating sessions - to have each
server in the cluster do it is overkill and a waste of resources IMO.

The way I've done this in the past is to configure a
SessionValidationScheduler instance on a native SessionManager.  For
example:

sessionValidationScheduler = com.my.SessionValidationScheduler
sessionValidationScheduler = $securityManager.sessionManager
securityManager.sessionManager.sessionValidationScheduler =
$sessionValidationScheduler

I've used Quartz in the past because it supports cluster-wide locking
for Jobs if you need it, this guarantees that only one node in the
cluster will acquire the lock, validate the sessions and then release
the lock.

I can't remember if the existing QuartzValidationScheduler can be used
out of the box for clustered Jobs, but if not, this code may give you
some ideas when implementing your own:

http://svn.apache.org/repos/asf/shiro/trunk/support/quartz/src/main/java/org/apache/shiro/session/mgt/quartz/

If you'd like to contribute something back to the project that would
make this easier for you (or others) in the future, please do!

HTH,

Les

On Tue, Aug 9, 2011 at 9:58 PM, Eric Pederson <er...@gmail.com> wrote:
> Hi all -
> In the typical web app scenario using Shiro sessions, each app will have a
> session invalidation thread running.   Are there any problems that I should
> worry about regarding race conditions when using clustered (eg Terracotta)
> sessions -- ie, multiple session invalidation threads stomping on each
> other?
>
> -- Eric