Forget it, I was thinking in locking the map's entry in cache cluster
wide when accessing its collections, but that would also mean locks
for put/remove of data in map, so it would be even worse...
-- Eduardo
..............................................
Not sure I understand. What would you lock? :-) And doesn't
that still cause contention?
On 6 Jan 2011, at 13:25, Eduardo Martins wrote:
> Just a wild guess, do we have cluster wide locks? Since the usage of
> its collections (keyset(), etc) is rare we could opt to lock the entry
> cluster wide and merge all entries from each different hashing cluster
> part...
>
> -- Eduardo
> ..............................................
>
http://emmartins.blogspot.com
>
http://redhat.com/solutions/telco
>
> On Thu, Jan 6, 2011 at 12:33 PM, Manik Surtani <manik(a)jboss.org> wrote:
>>
>> On 6 Jan 2011, at 12:28, Eduardo Martins wrote:
>>
>>>
>>> Right now, considering the types available, the AtomicMap is the best
>>> option, yet ideally that structure containing the child fqns should be
>>> a Map, without entry put/remove locks (using flags or not), with delta
>>> replication, and without colocation :)
>>
>> Well, any such map would colocate its elements by nature. Consider:
>>
>> cache.put(key, map).
>>
>> Anything in that map is stored under a single entry in the cache. Hence
colocation.
>>
>>> I really don't know much about Infinispan internals besides the Tree
>>> API and its impl so let me ask you, is that possible to achieve?
>>
>> If you break up that map and store its constituent entries as separate cache
entries, then sure. But then the trouble begins when you try and look up all of these
entries again, to create a coherent and complete view. :-)
>>
>> --
>> Manik Surtani
>> manik(a)jboss.org
>>
twitter.com/maniksurtani
>>
>> Lead, Infinispan
>>
http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)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
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev