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