On Oct 6, 2014, at 12:44, Tristan Tarrant <ttarr...@redhat.com> wrote:
> 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). for keySet and values, Will's distributed iteration is a way nicer way of doing it, as it only fetches the data iteratively. Better to throw an exception and point user to the distributed iterator. > > Tristan > > On 06/10/14 12:57, Sanne Grinovero wrote: >> On 3 October 2014 18:38, Dennis Reed <der...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev