[infinispan-dev] Evaluating Infinispan

[Manik Surtani]

On 25 Sep 2009, at 12:11, Krzysztof Sobolewski wrote:

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

I would have expected it to be more popular too - oh well!  :)

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

Yeah true.  Maybe it is best to restrict the cache instance used for  
the TreeCache as one that cannot be used for other 'general' stuff as  
well.

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

I used to have them everywhere in JBC and IMO it made the internal  
code very inflexible as everything needed to be parameterized in very  
unnecessary ways.

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

I'll let Mircea comment on 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.

It won't be 100% compatible, there will be certain things that change  
(such as construction and configuration, for example).  In terms of  
API though, it would be very similar.

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

In future it is something we may make public.  But needs some more  
thought before it is made public, as you can imagine.  :)

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