[infinispan-dev] About size()

Mircea Markus mmarkus at redhat.com
Wed Oct 8 10:09:26 EDT 2014


On Oct 3, 2014, at 18:38, Dennis Reed <dereed at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list