Re: [infinispan-dev] Evaluating Infinispan

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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev