|
I think your assumption is valid.
A couple of fairly irrelevant impacts
...
* Unless
your caching implementation does replication, there is negligible
impact on X509 and dao provider (the only two know usages of caching I know of).
* If you decide to invalidate all the "remember
me"s by changing the key, you'll have to remember to change the config in each
instance.
Its seems cluster friendly.
----- Original Message -----
Sent: Wednesday, June 08, 2005 12:53
PM
Subject: [Acegisecurity-developer] IP
Stickyness and Acegi Security
I'm working on a
project and we are looking to use Acegi Security. Our J2EE
container will be a WebLogic (WLS) clustered architecture. >From my
research thus far, it looks like I will not have to worry about hitting the
same WLS instance where a user authenticated (IP Stickyness). This
is my understanding because of how Acegi Security stores the ContextHolder,
SecurityContext, and subsequent Authentication object in the
HTTPSession. Since WLS will replicate the HTTPSession in the cluster, I
should be able to access the Authentication object in a different WLS instance
than the one where the user was originally authenticated, knowing that the
HttpSessionContextIntegrationFilter will pick it up in the filter chain. Each WLS
cluster will have the Acegi Security data stored in
cache.
Will someone
please verify my assumption?
Thanks,
John
| 