[infinispan-dev] Evaluating Infinispan

[Manik Surtani]

Hi Krzysztof, good to see that you're looking at Infinispan as well,  
now!  :-)

On 17 Sep 2009, at 10:16, Krzysztof Sobolewski wrote:

> I'm currently evaluating Infinispan for our internal project  
> (porting from
> JBoss Cache) and I have some comments/issues - and probably more to  
> come. I
> figure I should post them before Infinispan leaves beta stage :) If  
> they're
> JIRA-worthy, I can also repost them there.

Great - feedback is always appreciated.

> First, something small: TreeCache.getCache() (I obviously first try  
> to use the
> tree compatibility layer) returns Cache<K,V>, which is obviously  
> wrong, as the
> TreeCacheImpl returns Cache (raw type) which is in fact
> AtomicMapCache<NodeKey,Object> (and really, really in fact it's
> AtomicMapCache<NodeKey,AtomicMap<?,?>).

Interestingly, this is the first bit of feedback I've got on the  
TreeCache compat layer.  Most folks I know are using the Map API  
directly.

Yes, agreed.  It should really return Cache<?, ?>, or rather whatever  
was passed in to the TreeCacheImpl constructor.

I've logged this as https://jira.jboss.org/jira/browse/ISPN-195

> As a side note, I don't really like how the getAtomicMap() overrides  
> the V
> type parameter of Cache. The cache is supposed to store and return  
> V's, but
> this methods forcibly puts AtomicHashMap as values. I say this will  
> lead to
> problems. Maybe it's better to make AtomicMapCache<K> (one type  
> parameter)
> extend Cache<K,AtomicMap<?,?>> (maybe even with optional type  
> parameters for
> AtomicMap).

Yes, we did consider this, but that would mean that this is all you  
use the cache for.  E.g., if someone comes up with a more generic  
Cache<String, Object>, he will be restricted from using AtomicMaps  
with this cache.  Perhaps this is a valid restriction, the jury is  
out.  What do folks think?

> As another side note, I can see that you're not big fans of  
> generics :)

I actually hate them.  :-)  I think they are completely broken in the  
way the JDK implements them, and this is why for internal classes and  
APIs, I choose to leave them out completely (InternalCacheEntry, for  
example).  I do see their value in public API though.

> Second issue I wanted to mention, which also exists in JBoss Cache  
> but I never
> got around to reporting a bug, is that the JDBC cache stores use lock
> striping. I've run into *lots* of trouble with lock striping (here  
> and in MVCC
> lock manager) so I always turn it off (or reimplement, if there's no  
> option for
> that). Increasing the concurrency level is not an option because  
> whatever it
> is, it's still not correct (as in: non-zero probability of  
> collision), at
> least for my use cases.
>
> So... Can I ask for an option to not do lock striping... anywhere? :)

You have an option to disable lock striping.  See  
Configuration.setUseLockStriping(), or, using XML, see all.xml [1],  
look at the 'lockPerEntry' named cache.

[1] http://bit.ly/4xoHqA

Cheers
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org