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.
Any doc explaining how FGAM is broken in transactions for curiosity. 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