[infinispan-dev] Evaluating Infinispan

[Krzysztof Sobolewski]

Dnia czwartek 24 wrzesień 2009 o 16:41:25 infinispan-dev-
request at lists.jboss.org napisał(a):

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

That's interesting. I would expect that it would be more popular... But maybe 
people that would be porting their code from JBoss Cache are more conservative 
about "beta-quality" software :) Or are just happy with what they have now 
(for example our JBCache-based module finally works as expected and we're too 
afraid to touch it now).

> > 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?

I don't mind that that much... But if I create an AtomicMap for a key and then 
forget that it's "special" and try to get a regular V from that key, I will 
get a ClassCastException and that's not very good. It's all or nothing or 
tricky ;)

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

Yeah, it's a kind of love-hate relationship. I personally prefer to have them 
everywhere (and sometimes come up with really bizarre contraptions). At least 
one prominent book writer thought once I was an expert on the topic ;)

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

AFAIK this only turns off lock striping in the cache itself, not in the cache 
loader. But as I later found out, it's not really relevant because there is no 
tree in Infinispan. In JBCache I could run into problems because the cache 
loader would try to acquire locks for parent nodes and deadlock with 
completely unrelated cache operation whose Fqn's accidentally mapped to the 
same locks.
In Infinispan the JDBC cache loader also doesn't use database transactions - 
should I be worried about this? :)

>> Well, my biggest gripe with the tree cache layer is that it doesn't
>> like when
>> the node does not exist (for example doing a Cache.put(Fqn, key,
>> value) would
>> create the node in JBCache, but in Infinispan it just throws NPE).
>> That forces
>> me to get/create the node first, and then perform the operation. It
>> doesn't
>> look very atomic. Would batches help here?
>
>This is a bug.  TreeCache.put(Fqn, k, v) should behave the same as
>with JBC.  Care to file this in JIRA?

Sure...
https://jira.jboss.org/jira/browse/ISPN-199
It turns out that this only affects TreeCache.put(Fqn, Map).

I wonder how much compatible this compatibility layer can/should be. I 
don't think a complete, like "bug-for-bug", compatibility is possible and some 
of that might be relevant for our internal component. At least until we decide 
to port to plain Infinispan, but that will be a completely different, well, 
problem.

>> BTW: How do I actually get a reference to AtomicMapCache? I haven't
>> seen any
>> API except for casting...
>
>This AtomicMaps are not meant for public consumption (yet).  They are
>internal APIs, although at some point we may want to make them - along
>with DeltaAware and Delta - public.  In which case they would need to
>be properly genericized.
>
>Is there any specific reason you need direct access to AtomicMapCaches?

I actually read about it on your blog and assumed that it's a public API :) I 
thought I could use it to solve some problems relating to lack of tree 
structure (or, more specifically, lack of getChildrenNames()).
-KS