Sorry, I didn't quite understand your use case in the beginning. If you are adding data to .5 while at the same time reading the same data from the other nodes (causing data gravitation), this will naturally cause some timeouts since there is contention on a buddy backup subtree. In general though, we very strongly recommend that you have session affinity if you are using buddy replication. I.e., only perform reads and writes on ONE INSTANCE in the cluster for each key. Data gravitation should really only be used as a form of recovery if a node dies and your reads and writes are now redirected to a standby instance. See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheBuddyReplicationDesign. I guess judging by your access patterns, you need something like Partitioning, which won't be available for at least another 6 months or so - unless you're willing to help out! ;-) Without better knowledge of your application, I can't really recommend an alternative strategy - do you use a load balancer to distribute requests between caches? Do you use some form of session id per request and is data shared between "sessions"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117056#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...