[infinispan-dev] Integration between HotRod and OGM

[Dan Berindei]

On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo <pedro at 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 <pedro at infinispan.org> wrote:
> >>>>
> >>>>
> >>>> On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
> >>>>> On 23 January 2014 18:03, Dan Berindei <dan.berindei at gmail.com>
> wrote:
> >>>>>>
> >>>>>> On 22 Jan 2014 16:10, "Pedro Ruivo" <pedro at 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140127/5dc09e8a/attachment.html