[infinispan-dev] About size()

[Tristan Tarrant]

I think we should provide correct implementations of size() (and others) 
and provide shortcut implementations using our usual Flag API (e.g. 
SKIP_REMOTE_LOOKUP).

Tristan

On 06/10/14 12:57, Sanne Grinovero wrote:
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>