With 1.4.0, we've improved marshalling of objects and RPC [Remote Procedure Calls] on the wire. This improves replication throughput by about 30% (see JBoss Cache on Steriods) and this makes things a lot more efficient when replicating state across a cluster.

But the big new feature when it comes to scalability is Buddy Replication. You now no longer need to replicate state to every node in the cluster. Instead, each node selects one or more "buddies" to replicate state to as a backup, which means that adding more nodes in a cluster does not cost in terms of network overhead (more nodes to replicate to) or memory (each node needs to maintain more state in memory).

Prior to Buddy Replication, each node had to maintain nX bytes in memory, where n is the number of nodes in a cluster and X is the average size of state per node. Now with Buddy Replication, each node maintains (b+1)X, where b is the number of buddies per node. As you can see, this now has no dependency on n, the number of nodes in a cluster. Which means adding more nodes to the cluster will not incur a memory penalty.

One of the pre-requisites of Buddy Replication, though, is that some form of session affinity is in place—such as HTTP sticky sessions. This will prevent unnecessary (and expensive) moving around of state from one node to another, if the state is only accessed on one node.

See Buddy Replication for JBoss Cache 1.4.0 for more details on Buddy Replication.