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