[jbosscache-dev] Some new Cache usage questions

Tue Sep 5 10:46:54 EDT 2006

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 at 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 at jboss.org]
>>>> Sent: Tuesday, September 05, 2006 12:10 AM
>>>> To: Ben Wang
>>>> Cc: Bela Ban; jbosscache-dev at 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 at jboss.org]
>>>>> Sent: Monday, September 04, 2006 7:06 PM
>>>>> To: Ben Wang
>>>>> Cc: Bela Ban; jbosscache-dev at 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 at jboss.org
>>>>> Telephone: +44 7786 702 706
>>>>> MSN: manik at 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 at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at 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