On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo <pe...@infinispan.org> wrote:
> > > 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... > Sure, I would prefer the simpler implementation as well. But if changing an application to use groups instead of atomic maps will change the processing time of a request from 1ms to 1s, I'm pretty sure users will prefer to keep use the atomic maps :) > > > > 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) > > Do you know if AtomicMap is affected, too? > It also does not work when you enable write skew check with optimistic > transactions (we have a JIRA somewhere) > I assume you mean https://issues.jboss.org/browse/ISPN-3939 ? This looks like it also affects AtomicMap, so the only workaround is to use pessimistic locking. > > > 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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
