On 25 Sep 2009, at 12:11, Krzysztof Sobolewski wrote: > Dnia czwartek 24 wrzesień 2009 o 16:41:25 infinispan-dev- > request(a)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(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Dnia piątek 25 wrzesień 2009 o 15:18:45 Manik Surtani napisał(a): >> 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. It's more of a chore than inflexibility, because the types must match anyway, generics or not. But the declarations spread like a wildfire. Give me [more] type inference and type aliases and I'm almost happy :)

Or maybe it's better to switch to Scala.

>> 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. :) I can see you changed some things already (and the TreeCache.getCache () thing). Unfortunately currently I have some other things to do than porting to Infinispan, but I'll get back to it some day :)