On 01/27/2014 12:26 PM, Emmanuel Bernard wrote: > I'd be curious to see performance tests on Pedro's approach (ie walk > through the entire data key set to find the matching elements of a given > group). That might be fast enough but that looks quite scary compared to > a single lookup.
I would prefer to have a performance hit than a map of sets (group name => set of keys). I also think that keep this map synchronized with the keys in data container will not be easy... > > Any doc explaining how FGAM is broken in transactions for curiosity. > well, the map is not isolated, so you can see the updates from other transactions immediately (https://issues.jboss.org/browse/ISPN-3932) It also does not work when you enable write skew check with optimistic transactions (we have a JIRA somewhere) > On Mon 2014-01-27 11:54, Pedro Ruivo wrote: >> >> >> On 01/27/2014 09:52 AM, Sanne Grinovero wrote: >>> On 27 January 2014 09:38, Pedro Ruivo <pe...@infinispan.org> wrote: >>>> >>>> >>>> On 01/27/2014 09:20 AM, Sanne Grinovero wrote: >>>>> On 23 January 2014 18:03, Dan Berindei <dan.berin...@gmail.com> wrote: >>>>>> >>>>>> On 22 Jan 2014 16:10, "Pedro Ruivo" <pe...@infinispan.org> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/22/2014 01:58 PM, Dan Berindei wrote: >>>>>>>> >>>>>>>> >>>>>>>> It would also require us to keep a Set<K> for each group, with the keys >>>>>>>> associated with that group. As such, I'm not sure it would be a lot >>>>>>>> easier to implement (correctly) than FineGrainedAtomicMap. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Dan, I didn't understand why do we need to keep a Set<K>. Can you >>>>>>> elaborate? >>>>>> >>>>>> >>>>>> We'd need some way to keep track of the keys that are part of the group, >>>>>> iterating over the entire cache for every getGroup() call would be way >>>>>> too >>>>>> slow. >>>>> >>>>> Right, and load all entries from any CacheStore too :-/ >>>> >>>> IMO, I prefer to iterate over the data container and cache loader when >>>> it is needed than keep the Set<K> for each group. I think the memory >>>> will thank you >>> >>> Of course. I'm just highlighting how importand Dan's comment is, >>> because we obviously don' t want to load everything from CacheStore. >>> So, tracking which entries are part of the group is essential: >>> failing this, I'm still skeptical about why the Grouping API is a >>> better replacement than FGAM. >> >> I have one reason: FGAM does not work inside transactions... >> >>> >>> Sanne >>> _______________________________________________ >>> 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 > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev