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