[infinispan-dev] Evaluating Infinispan

Mon Sep 28 03:39:28 EDT 2009

On Sep 25, 2009, at 4:18 PM, Manik Surtani wrote:

>
> 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.  :-)
Current JDBC impl doesn't use database transactions indeed. This means  
that during commit. This should change, though: https://jira.jboss.org/jira/browse/ISPN-201

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