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
