4:16 a.m.
I'm currently evaluating Infinispan for our internal project (porting from
JBoss Cache) and I have some comments/issues - and probably more to come. I
figure I should post them before Infinispan leaves beta stage :) If they're
JIRA-worthy, I can also repost them there.
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<?,?>).
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).
As another side note, I can see that you're not big fans of generics :)
Second issue I wanted to mention, which also exists in JBoss Cache but I never
got around to reporting a bug, is that the JDBC cache stores use lock
striping. I've run into *lots* of trouble with lock striping (here and in MVCC
lock manager) so I always turn it off (or reimplement, if there's no option for
that). Increasing the concurrency level is not an option because whatever it
is, it's still not correct (as in: non-zero probability of collision), at
least for my use cases.
So... Can I ask for an option to not do lock striping... anywhere? :)
-KS
6:52 p.m.
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?)
On Thu, Sep 17, 2009 at 7:16 PM, Krzysztof Sobolewski
<Krzysztof.Sobolewski(a)atm.com.pl> wrote:
I'm currently evaluating Infinispan for our internal project
(porting from
JBoss Cache) and I have some comments/issues - and probably more to come. I
figure I should post them before Infinispan leaves beta stage :) If they're
JIRA-worthy, I can also repost them there.
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<?,?>).
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).
As another side note, I can see that you're not big fans of generics :)
Second issue I wanted to mention, which also exists in JBoss Cache but I never
got around to reporting a bug, is that the JDBC cache stores use lock
striping. I've run into *lots* of trouble with lock striping (here and in MVCC
lock manager) so I always turn it off (or reimplement, if there's no option for
that). Increasing the concurrency level is not an option because whatever it
is, it's still not correct (as in: non-zero probability of collision), at
least for my use cases.
So... Can I ask for an option to not do lock striping... anywhere? :)
-KS
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
9:24 a.m.
Hi Krzysztof, good to see that you're looking at Infinispan as well,
now! :-)
On 17 Sep 2009, at 10:16, Krzysztof Sobolewski wrote:
I'm currently evaluating Infinispan for our internal project
(porting from
JBoss Cache) and I have some comments/issues - and probably more to
come. I
figure I should post them before Infinispan leaves beta stage :) If
they're
JIRA-worthy, I can also repost them there.
Great - feedback is always appreciated.
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.
Yes, agreed. It should really return Cache<?, ?>, or rather whatever
was passed in to the TreeCacheImpl constructor.
I've logged this as https://jira.jboss.org/jira/browse/ISPN-195
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?
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.
Second issue I wanted to mention, which also exists in JBoss Cache
but I never
got around to reporting a bug, is that the JDBC cache stores use lock
striping. I've run into *lots* of trouble with lock striping (here
and in MVCC
lock manager) so I always turn it off (or reimplement, if there's no
option for
that). Increasing the concurrency level is not an option because
whatever it
is, it's still not correct (as in: non-zero probability of
collision), at
least for my use cases.
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.
[1] http://bit.ly/4xoHqA
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6036
days inactive
6043
days old
infinispan-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Krzysztof Sobolewski -
Manik Surtani -
Michael Neale