[infinispan-dev] About size()

[Sanne Grinovero]

On 3 October 2014 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.

+1

> 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

And not just size() but many others from ConcurrentMap.
The question is if we should drop the interface and all the methods
which aren't efficiently implementable, or fix all those methods.

In the past I loved that I could inject "Infinispan superpowers" into
an application making extensive use of Map and ConcurrentMap without
changes, but that has been deceiving and required great care such as
verifying that these features would not be used anywhere in the code.
I ended up wrapping the Cache implementation in a custom adapter which
would also implement ConcurrentMap but would throw a RuntimeException
if any of the "unallowed" methods was called, at least I would detect
violations safely.

I still think that for the time being - until a better solution is
planned - we should throw exceptions.. alas that's an old conversation
and it was never done.

Sanne


>
> -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