On 21 Sep 2009, at 14:06, Krzysztof Sobolewski wrote:
Dnia piątek 18 wrzesień 2009 o 18:00:03
infinispan-dev-request(a)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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org