Clustered SSO and Buddy Replication

Beginning with release 4.0.5, JBoss offers Buddy Replication as a configuration option for the JBoss Cache used for HttpSession replication. (By default in 4.0.5 buddy replication is disabled.)  This new feature has implications for Clustered SSO, as we currently share a cache for HTTP session replication and Clustered SSO replication. This shared use is problematic if buddy replication is used, as buddy replication is inappropriate for the SSO use case.

Buddy replication is meant for use cases where all requests that will access a certain piece of cached data are meant to come from the same server.  As long as that server is running, it is the only one that really deals with the cached data. The cached data is replicated to one or more buddies purely to ensure a backup copy exists.  This paradigm is perfect for cached HTTP sessions, as the use of session affinity or "sticky sessions" means the load balancer will always send all requests for a session to the same server.  "Sticky sessions" should always be used with distributed web applications.

However, with Clustered SSO, the load balancer might pin the user to different servers for the different webapps being accessed.[1] As a result, multiple servers in the cluster need to monitor the cached data. For example, if the user logs out of the SSO on one server, all servers in the cluster need to know the SSO is now invalid; it is insufficient to only inform the node(s) that is the buddy of the one where the logout occurred.

If users wanted to enable buddy replication for HTTP sessions, they would have to configure and deploy their own cache for use by the Clustered SSO valve.  How to do this is explained on the main Clustered SSO page.

[1] There is a use case for Clustered SSO where it is used with only a single webapp. See JBAS-1900 and related discussion on the main Clustered SSO page for background. In this case, since sticky session should always be used with a clustered webapp, there should only be one server handling all requests related to the SSO. In this case, using buddy replication for the SSO cache is valid.