On 01/27/2014 01:38 PM, Dan Berindei wrote:
On Mon, Jan 27, 2014 at 2:43 PM, Pedro Ruivo <pedro(a)infinispan.org
<mailto: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 :)
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(a)infinispan.org
<mailto:pedro@infinispan.org>> wrote:
>>>>
>>>>
>>>> On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
>>>>> On 23 January 2014 18:03, Dan Berindei
<dan.berindei(a)gmail.com <mailto:dan.berindei@gmail.com>> wrote:
>>>>>>
>>>>>> On 22 Jan 2014 16:10, "Pedro Ruivo"
<pedro(a)infinispan.org
<mailto: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(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev