On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo <pedro@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@infinispan.org> wrote:
>>>>
>>>>
>>>> On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
>>>>> On 23 January 2014 18:03, Dan Berindei <dan.berindei@gmail.com> wrote:
>>>>>>
>>>>>> On 22 Jan 2014 16:10, "Pedro Ruivo" <pedro@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