(1) The problem with merging state is that it is very dependent on the application and also, in most cases, non trivial to do right. As Brian mentioned, merging web session state is simple, but what happens if an HTTP session has a Pojo as value ? Or even worse, an entity bean which has a primary key and is persistent ? Then anyone can get a ref to that bean and change it, so we cannot assume the session is the only way to access an entity bean. (2) Primary partition This is generally good, as we avoid a merging because the non-primary partition(s) discard their state and re-initialize themselves from the primary partition. However, this means that all state changes that happened in the non-primary partition is discarded ! This is probably not acceptable for most applications. (3) Primary partitions detected when they happen If we can say that (assuming we have 5 nodes in the cluster) a primary partition needs to have 3 or more nodes and - if it has less than 3 - becomes read-only, then we avoid state changes in a non-primary partition. We could define a primary partition to be the majority, requiring an odd number of nodes, or come up with a different *deterministic* scheme. Problem is: if we have {A,B,C,D,E} and then 2 partitions P1={A,B,C} and P2={D,E}, and they're all connected to a DB, then changes within P1 and replicated within P1 and persisted to the DB, but *not* replicated to P2. This means that applications connected to P2 will read stale data ! In this case, the only solution I see is to shut down P2 and redirect clients if that's possible. Shutting down could mean - Leave the cluster (P2), so D and E disconnect from the cluster - Suspend (or close) the AJP connector (if we come in via Apache mod_jk), or *somehow* let the load balancer know that it should redirect requests to P1 and not P2 anymore. This of course requires the load balancer to have visibility to P1and P2. My 2 cents View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079459#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...