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 <[email protected]> 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
