[infinispan-dev] Evaluating Infinispan

[Krzysztof Sobolewski]

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.

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<?,?>).

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).

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

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? :)
-KS