[jbosscache-dev] Some new Cache usage questions

Manik Surtani manik at jboss.org
Tue Sep 5 11:16:47 EDT 2006 

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.
--
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 5 Sep 2006, at 15:46, Brian Stansberry wrote:

> 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

More information about the jbosscache-dev mailing list