For FIELD repl I'd basically have to start and stop a PojoCacheSession on the way in and out for each request. Certainly doable. I wonder though if the overhead of managing all this exceeds that created by just always setting the option internal before resolving the reference. (Of course don't set it if BR is disabled or autoDataGravitation=true.) Besides the work of setting the option, here's what's wasted if a call hits the DataGravitatorInterceptor for a node that doesn't need gravitation: if (isGravitationEnabled(ctx) && MethodDeclarations.isGetMethod(m.getMethodId())) | { | // test that the Fqn being requested exists locally in the cache. | Fqn fqn = extractFqn(m.getMethodId(), m.getArgs()); | if (log.isTraceEnabled()) log.trace("Checking local existence of fqn " + fqn); | if (BuddyManager.isBackupFqn(fqn)) | { | log.info("Is call for a backup Fqn, not performing any gravitation. Direct calls on internal backup nodes are *not* supported."); | } | else | { | if (cache.peek(fqn, false) == null) One thing I notice here is my statement last night about gravitation occuring on a put seems incorrect (see first if statement). I don't know if something changed, or if my year old memory of the issues I was seeing with BR when used for session repl is faulty. There were definitely problems related to greatly excessive gravitation calls that were solved by setting autoDataGravitation=false and using the option. I'll have a look at the old forum posts; IIRC Manik and I sorted it out on the forums. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056918#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...