Re: [infinispan-dev] ClusteredGet and direct operations on a cacheloader

Manik Surtani wrote: cache loaders are read only and stores use bucket locking, it's a different locking level though... At the same time, unique calls for different keys would increase the memory footprint... though I agree with your point of view overall: after all remote cache can be considered just another cache user. yes, +1 I see, it gets a bit complicated now... TBH, I think the 'problem' is in the fact that our interceptors are a bit too 'fat' - with this interceptor approach we "spread" the ClusterGet logic in too many places: - in the ClusterGet command, that does the call - in the DistributionInterceptor, where you have to add the additional if, to check that the call is local - (other interceptors will have to do that as well). Having thinner interceptors would move the logic in one place only (e.g. LockingInterceptor is thin, as all locking logic is in LockManager, and all the calls are delegated to it, no 'fat' logic in interceptor itself) would make the code easier to follow and change (and solve the above issue, with not having access to InternalCacheEntry). So, the code in ClusterGetCommand might look something like this: perform() { lockManager.lock(key); if (dataContainer.get(key) != null) return...; if (loaderManager != null) return loaderManager.get(key); lockManager.release(key); } I think the code is much slef-explanatory than a plain cache.get(), that does lots of things not imediately visible. Also if he wants to add another lookup from somewhere else, it's easier. There is no code duplication as well, as all the work is delegated to the managers.