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 >