Since size() is defined by the ConcurrentMap interface, it already has a precisely defined meaning. The only "correct" implementation is E.
The current non-correct implementation was just because it's expensive to calculate correctly. I'm not sure the current impl is really that useful for anything. -Dennis On 10/03/2014 03:30 AM, Radim Vansa wrote: > Hi, > > recently we had a discussion about what size() returns, but I've > realized there are more things that users would like to know. My > question is whether you think that they would really appreciate it, or > whether it's just my QA point of view where I sometimes compute the > 'checksums' of cache to see if I didn't lost anything. > > There are those sizes: > A) number of owned entries > B) number of entries stored locally in memory > C) number of entries stored in each local cache store > D) number of entries stored in each shared cache store > E) total number of entries in cache > > So far, we can get > B via withFlags(SKIP_CACHE_LOAD).size() > (passivation ? B : 0) + firstNonZero(C, D) via size() > E via distributed iterators / MR > A via data container iteration + distribution manager query, but only > without cache store > C or D through > getComponentRegistry().getLocalComponent(PersistenceManager.class).getStores() > > I think that it would go along with users' expectations if size() > returned E and for the rest we should have special methods on > AdvancedCache. That would of course change the meaning of size(), but > I'd say that finally to something that has firm meaning. > > WDYT? > > Radim > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
