[infinispan-dev] Integration between HotRod and OGM

[Pedro Ruivo]

On 01/27/2014 01:38 PM, Dan Berindei wrote:
>
>
>
> On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo <pedro at infinispan.org
> <mailto: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 :)

you don't need to change the application. we can implement the 
AtomicHashMap interface on top of grouping :D

I'm expecting a negative performance impact but not that high. Also, 
with the current implementation, FGAHM performs a copy for writing... 
anyway, we should test and see how it goes :)

>
>
>      >
>      > 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?

I haven't tested yet, but I'm assuming the worst (i.e. yes, it is 
affected). I'm trying to find a way to fix it without destroying 
anything else :(

>
>     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.

that is cross-site replication...

I mean to this: https://issues.jboss.org/browse/ISPN-2729
that is originated because we don't support version in Deltas

>
>
>
>      > 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
>     <mailto: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 <mailto:dan.berindei at gmail.com>> wrote:
>      >>>>>>
>      >>>>>> On 22 Jan 2014 16:10, "Pedro Ruivo" <pedro at infinispan.org
>     <mailto: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
>     <mailto:infinispan-dev at lists.jboss.org>
>      >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >>>
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto: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
>