<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo <span dir="ltr"><<a href="mailto:pedro@infinispan.org" target="_blank">pedro@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
On 01/27/2014 12:26 PM, Emmanuel Bernard wrote:<br>
> I'd be curious to see performance tests on Pedro's approach (ie walk<br>
> through the entire data key set to find the matching elements of a given<br>
> group). That might be fast enough but that looks quite scary compared to<br>
> a single lookup.<br>
<br>
</div>I would prefer to have a performance hit than a map of sets (group name<br>
=> set of keys). I also think that keep this map synchronized with the<br>
keys in data container will not be easy...<br></blockquote><div><br></div><div>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 :)<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
><br>
> Any doc explaining how FGAM is broken in transactions for curiosity.<br>
><br>
<br>
</div>well, the map is not isolated, so you can see the updates from other<br>
transactions immediately (<a href="https://issues.jboss.org/browse/ISPN-3932" target="_blank">https://issues.jboss.org/browse/ISPN-3932</a>)<br>
<br></blockquote><div><br></div><div>Do you know if AtomicMap is affected, too?<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It also does not work when you enable write skew check with optimistic<br>
transactions (we have a JIRA somewhere)<br></blockquote><div><br></div><div>I assume you mean <a href="https://issues.jboss.org/browse/ISPN-3939">https://issues.jboss.org/browse/ISPN-3939</a> ?<br></div><div>This looks like it also affects AtomicMap, so the only workaround is to use pessimistic locking.<br>
<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
> On Mon 2014-01-27 11:54, Pedro Ruivo wrote:<br>
>><br>
>><br>
>> On 01/27/2014 09:52 AM, Sanne Grinovero wrote:<br>
>>> On 27 January 2014 09:38, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> On 01/27/2014 09:20 AM, Sanne Grinovero wrote:<br>
>>>>> On 23 January 2014 18:03, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> On 22 Jan 2014 16:10, "Pedro Ruivo" <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On 01/22/2014 01:58 PM, Dan Berindei wrote:<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> It would also require us to keep a Set<K> for each group, with the keys<br>
>>>>>>>> associated with that group. As such, I'm not sure it would be a lot<br>
>>>>>>>> easier to implement (correctly) than FineGrainedAtomicMap.<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>> Dan, I didn't understand why do we need to keep a Set<K>. Can you<br>
>>>>>>> elaborate?<br>
>>>>>><br>
>>>>>><br>
>>>>>> We'd need some way to keep track of the keys that are part of the group,<br>
>>>>>> iterating over the entire cache for every getGroup() call would be way too<br>
>>>>>> slow.<br>
>>>>><br>
>>>>> Right, and load all entries from any CacheStore too :-/<br>
>>>><br>
>>>> IMO, I prefer to iterate over the data container and cache loader when<br>
>>>> it is needed than keep the Set<K> for each group. I think the memory<br>
>>>> will thank you<br>
>>><br>
>>> Of course. I'm just highlighting how importand Dan's comment is,<br>
>>> because we obviously don' t want to load everything from CacheStore.<br>
>>> So, tracking which entries are part of the group is essential:<br>
>>> failing this, I'm still skeptical about why the Grouping API is a<br>
>>> better replacement than FGAM.<br>
>><br>
>> I have one reason: FGAM does not work inside transactions...<br>
>><br>
>>><br>
>>> Sanne<br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>