Hi, This is not high prio, but it is something I've come across several time now. Both the preload and the state transfer code, in order to add a batch of entries into the cache use the following pattern: for (InternalCacheEntry e : state) { cache.getAdvancedCache() .withFlags(CACHE_MODE_LOCAL, SKIP_OWNERSHIP_CHECK, SKIP_CACHE_STORE,SKIP_REMOTE_LOOKUP, SKIP_INDEXING) .put(...); } This has some flaws: - it is not the fastest way of inserting stuff into the cache. E.g. in the case of preload it would be much simpler to simply drain the data straight into the container. Similar for a cache store. - it pollutes the rest of the code unnecessarily. E.g. at the moment when we preload data, the topology information might not be available simply because the cache has not started yet. So all the interceptors that handle the put during preload need to somehow guard against using the topology information: e.g. StateTransferInterceptor, EntryWrappingInterceptor, LockingInterceptor etc. Now this approach is in use mainly because, during state insertion, we need to (re)use some logic which is present in the interceptors. An different approach to handling state integration would be to move that reusable logic (where's needed) into corresponding managers and invoke methods on the manager directly instead of passing everything through the interceptor stack (users interested in these insertion can register listeners). I'm not sure that this would work with the extending modules? Wdyt? Cheers, Mircea