On Oct 3, 2014, at 18:38, Dennis Reed <dereed(a)redhat.com> wrote:
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.
+1
-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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)