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

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