We currently share a cache for http session repl and clustered sso repl. This is problematic if buddy replication is used, as buddy replication isn't really appropriate for the sso use case.
With clustered sso, the user might be pinned to different servers for the different webapps being accessed. In this case, as the user moves from app to app, the sso will be gravitated from one server to another.
This may not be a huge problem, as in most cases a user will work for a while with one app then go to another; i.e. bouncing around isn't common.
Also, if the "emptySessionPath" attribute on the Tomcat Connector is set to true, the session cookie will be scoped to the host. If the suite of applications share the same virtual host name, the load balancer will should send the user to the same server for all apps. So, buddy replication would be fine.
In the 5.0 series, there is another cache available for use by SSO -- the cache used for HA-JNDI/DRM/DistributedState. So, if users didn't want BR for SSO they can configure it to use the non-BR cache.
This is not an alternative in the 4.0.x series; if users wanted BR for http sessions but not for SSO they would have to configure and deploy their own cache.
I'll create a wiki page (probably mostly stating the above) once I've thought a bit more about what to do in 4.0.x.
