Re: [infinispan-dev] About size()

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(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev