[infinispan-dev] Evaluating Infinispan

[Manik Surtani]

On 21 Sep 2009, at 14:06, Krzysztof Sobolewski wrote:

> Dnia piątek 18 wrzesień 2009 o 18:00:03 infinispan-dev-request at lists.jboss.org
> napisał(a):
>> Maybe it is the tree cache compatability layer, but the infinispan
>> Cache "new" class seems quite nice, generics wise.
>> Perhaps you have identified some JIRA worthy issues specific to the
>> tree cache layer? (as it probably doesn't get as much attention at  
>> the
>> moment?)
>
> 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?

> Regarding generics, there are more types that could be parameterized  
> (e.g. it
> is possible to make the coupling between DeltaAware and its Delta
> implementation more type-safe). The implementation classes of generic
> interfaces usually use raw types. And this TreeCache.getCache()  
> thing :) I'm
> not a big fan of AtomicMapCache.getAtomicMap() either...
>
> 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?

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