Re: [infinispan-dev] Concurrent hashmaps parameters
On Sep 16, 2009, at 10:22 AM, Jason T. Greene wrote:
Bela Ban wrote:
>
> David M. Lloyd wrote:
>> NonBlockingHashMap is great *except* that it relies on
>> sun.misc.Unsafe,
>> which makes portability a bit iffy. I *think* that it could be
>> ported to
>> use Atomic* instead, but it looked like quite a bit of work to do
>> so (not
>> to mention testing).
>>
>> The problem with CHM is that they are *big*, so you don't want to
>> have a
>> lot of them - *especially* if you're using a high concurrency level,
>> because they get even bigger in that case.
>
> Understood that CHMs are big, but back to my question: how doesn
> Infinispan intend to address hashmaps with 1000 different keys ? Or
> are
> you guys already parameterizing creation of CHMs ?
>
There is a concurrency level setting that the user can set based off
of
expected size (it also affects striping).
I think this only has to do with the lock
striping, and is rather
related to the number of concurrent users expected to access the
cache, not with the size of the data.
AFAIK, there's no correlation between the number of cache entries, and
the way the CHMs are being instantiated. Manik can put some more light
on this on his return, but I do see a lot of sense for this correlation.
--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev