[infinispan-dev] Integration between HotRod and OGM

[Pedro Ruivo]

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

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

It also does not work when you enable write skew check with optimistic 
transactions (we have a JIRA somewhere)

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