RE: [jbosscache-dev] Some new Cache usage questions

Basically just Hibernate - where in a given Hibernate session where data of a particular type is accessed, the node for that type can be cached and it's direct children queried without the need to find the node repeatedly. I guess it makes sense in this use case where the parent node will not (often) be removed from the tree. > TBH, this thread has lost me a bit. My expectation was for session > replication I'd as much as possible just use Cache.get(Fqn, Object) > Cache.put(Fqn, Object, Object), Cache.remove(Fqn, Object). I'm kind > of a simple-minded guy. :) > > So, I'm lost as to what the situation is where we'd be recommending > caching nodes. If it's a common situation where lot's of people will > blindly do it, that's a problem. If it's some specialized situation > where a sophisticated program can understand to use a try/catch > block, it's no big deal. > > It might be nice if the CacheException were a specialized subclass > that could be specifically caught. > > Manik Surtani wrote: >> A Node is still just a wrapper. Every time you try and do anything >> with it, calls are passed thru the interceptor stack to the >> TreeCache object. >> >> If a Node no longer exists, a CacheException will be thrown. >> >> Do we foresee this as a problem, and should we not be recommending >> caching Nodes? >> >>> Isn't caching a Node dangerous, as you have no way of knowing it >>> hasn't been removed from the tree? Unless you add a CacheListener >>> just for that. >>> >>> jbosscache-dev-bounces(a)lists.jboss.org wrote: >>>> Use Cache for cache-wide operations like getRegion(), etc. >>>> >>>> Use Node to manipulate data in the node, retrieve child nodes, >>>> etc. This way refs to Nodes - buckets of data storage - can be >>>> cached since it is these that would be most frequently used. >>>> >>>>> It does. But then, does it mean I need to keep both the reference >>>>> for Cache and "parent" Node at the same time? Although Cache is a >>>>> wrapper, it does have some additional APIs like evict and also >>>>> getRegion() that doesn't exist in Node. Or what's your >>>>> recommendation? >>>>> >>>>> Actually, currently I am keeping the CacheSPI reference (and also >>>>> possibly NodeSPI in the future when it has life of its own) >>>>> within my code. Keeping the Node reference doesn't seem to make >>>>> much sense to me, although this can be just a pattern for the >>>>> customed cache provider (e.g., PojoCache). >>>>> >>>>> -Ben >>>>> >>>>> -----Original Message----- >>>>> From: Manik Surtani [mailto:manik@jboss.org] >>>>> Sent: Tuesday, September 05, 2006 12:10 AM >>>>> To: Ben Wang >>>>> Cc: Bela Ban; jbosscache-dev(a)lists.jboss.org >>>>> Subject: Re: [jbosscache-dev] Some new Cache usage questions >>>>> >>>>> >>>>> On 4 Sep 2006, at 16:58, Ben Wang wrote: >>>>> >>>>>> 1. I suspect people using JBC for session management purpose >>>>>> won't store the Node ref but the Cache instead. Brian can say >>>>>> better but for example of the http session, unless you store the >>>>>> root Node, otherwise caching the children Node is not that >>>>>> useful. >>>>> >>>>> Node jSessionNode = Cache.getChild(Fqn.fromString("/ >>>>> JSESSIONID")); // this can be cached... Node sessionNode = >>>>> jSessionNode.getChild(Fqn.fromString (sessionId)); // this can >>>>> be retrieved every time... >>>>> >>>>> Does this help in any way? >>>>> >>>>> >>>>>> >>>>>> 2. ic. Do we have explicit contract for Cache to be "root" Node >>>>>> only? I mean, even getRoot() is just a self pointer, it still >>>>>> serves the purpose, IMO. >>>>> >>>>> From the javadocs: "The cache is essentially a wrapper around >>>>> the default root Node." >>>>> >>>>> >>>> http://labs.jboss.com/file-access/default/members/jbosscache/ >>>> freezone/ >>>>> docs/Habanero/api/org/jboss/cache/Cache.html >>>>> >>>>> >>>>>> >>>>>> -Ben >>>>>> >>>>>> -----Original Message----- >>>>>> From: Manik Surtani [mailto:manik@jboss.org] >>>>>> Sent: Monday, September 04, 2006 7:06 PM >>>>>> To: Ben Wang >>>>>> Cc: Bela Ban; jbosscache-dev(a)lists.jboss.org >>>>>> Subject: Re: [jbosscache-dev] Some new Cache usage questions >>>>>> >>>>>> Not in your case, no. But many other use cases will be able to >>>>>> cache a node and use it directly. >>>>>> >>>>>> I too would rather keep the API clean in this regard. Also, >>>>>> calling cache.getRoot() is redundant since the Cache interface >>>>>> is a wrapper around the root Node. In fact, I even think we >>>>>> should get rid of the getRoot() method. >>>>>> >>>>>> Cheers, >>>>>> -- >>>>>> Manik Surtani >>>>>> >>>>>> Lead, JBoss Cache >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> Email: manik(a)jboss.org >>>>>> Telephone: +44 7786 702 706 >>>>>> MSN: manik(a)surtani.org >>>>>> Yahoo/AIM/Skype: maniksurtani >>>>>> >>>>>> >>>>>> On 1 Sep 2006, at 15:49, Ben Wang wrote: >>>>>> >>>>>>> Thing is I only do put to specific fqn once. So caching it >>>>>>> doesn't buy you anything. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Bela Ban >>>>>>> Sent: Friday, September 01, 2006 10:22 PM >>>>>>> To: Ben Wang >>>>>>> Cc: jbosscache-dev(a)lists.jboss.org >>>>>>> Subject: Re: [jbosscache-dev] Some new Cache usage questions >>>>>>> >>>>>>> My 2 cents: I'd rather keep the API clean, at the expense of >>>>>>> folks potentially writing wrapping code (like Ben). >>>>>>> >>>>>>> Your code samples look a bit weird: >>>>>>> #1 >>>>>>> Why do you always get the child ? Can't you get the node and >>>>>>> cache it, e.g. Node n=cache.getRoot().getChild(fqn); >>>>>>> n.containsKey(PojoInstance.KEY) >>>>>>> >>>>>>> #2 >>>>>>> Same as for #1: you don't need to call cache.getRoot().getChild >>>>>>> (fqn) all the time, for example in a loop, simply cache it >>>>>>> >>>>>>> >>>>>>> Ben Wang wrote: >>>>>>>> Manik, >>>>>>>> >>>>>>>> While trying to use the new API in PojoCache, I have found >>>>>>>> that I need to: >>>>>>>> >>>>>>>> 1. To check if a attribute exist, I need to do: >>>>>>>> cache_.getRoot().getChild(fqn_).getData().values().contains >>>>>>>> (PojoInstance.KEY) >>>>>>>> >>>>>>>> 2. And then, I need to do a lot of cache_.getRoot().getChild >>>>>>>> (fqn).put(map) >>>>>>>> >>>>>>>> So looks like I need to write a wrapper layer just to provide >>>>>>>> straight api for: >>>>>>>> >>>>>>>> Cache_.exists(fqn, key) >>>>>>>> And >>>>>>>> Cache_.put(fqn, map) >>>>>>>> >>>>>>>> If this is rare case, then I will bite the bullet. But if it >>>>>>>> is a common one, then that really begs the question whether we >>>>>>>> should provide additional apis or not? >>>>>>> >>>>>>> -- >>>>>>> Bela Ban >>>>>>> Lead JGroups / Manager JBoss Clustering Group JBoss - a >>>>>>> division of Red Hat >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jbosscache-dev mailing list >>>>>>> jbosscache-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> jbosscache-dev mailing list >>>> jbosscache-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >>> >>> >>> >>> Brian Stansberry >>> Lead, AS Clustering >>> JBoss, a division of Red Hat >>> Ph: 510-396-3864 >>> skype: bstansberry > > > > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > Ph: 510-396-3864 > skype: bstansberry