My ignorance of portal internals is becoming apparent. I'd thought portlet sessions were managed as data stored inside the overall javax.servlet.http.HttpSession. So, either: 1) You guys are overriding the standard HttpSession replication config and substituting your own cache for the one defined in deploy/jboss-web-cluster.sar 2) I'm clueless and portlet sessions are using a completely different replication mechanism. I suspect #2. :-) What to do depends on which it is. If #1, the answer depends on why you replaced the standard HttpSession replication cache. If there's not a good reason, go back to using the standard cache, but enable buddy replication. If #2, you guys have developed your own independent clustering technology, and I can only make general comments: a) Generally "sessions" of whatever type should be "owned" by a particular node in the cluster. The only reason to replicate them is to provide HA in the unexpected case of failover. Generally REPL_ASYNC is used for this, as it scales much better. The downside is the potential loss of state if failover happens before the latest replication message arrives. In most cases that risk is acceptable in order to get better performance. INVALIDATION can't be used for a session cache. The only place the session exists is in the cache. If you invalidate it instead of replicating, you have no HA. Entities are shared by all nodes, and an entity cache should use SYNC communication for the reasons already discussed. Bottom line, using the same cache for both entities and sessions is not a good approach. b) Generally, turning on buddy replication for a "session" cache should only be done if the cache integration layer has been written with BR in mind. It's not a simple matter of changing a config flag and voila, it works. The standard HttpSession cache integration layer has been written with BR in mind. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168791#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...