I would prefer to have a performance hit than a map of sets (group name
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.
=> set of keys). I also think that keep this map synchronized with the
keys in data container will not be easy...
well, the map is not isolated, so you can see the updates from other
>
> Any doc explaining how FGAM is broken in transactions for curiosity.
>
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@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