[jbosscache-dev] Some new Cache usage questions

Manik Surtani manik at jboss.org
Tue Sep 5 14:13:04 EDT 2006 

At the moment, yes, not much efficiency will be gained since we ae  
still making callbacks to the underlying TreeCache.  Once this  
changes though, and once we have a better structure of being able to  
work on nodes directly even internally (means having to pass method  
invocations on Node up the Interceptor stack as well) we will be more  
efficient (less tree-walking to find the node you need).  But then  
this 2nd level of efficiency isn't scheduled till 2.1.  2.0 is just  
the new interfaces.
--
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 18:58, Brian Stansberry wrote:

> Somewhat off-topic..
>
> If at webapp startup I do:
>
> Node webappRoot =
> cache.get(Fqn.fromString("/JSESSIONID/localhost/webapp1");
>
> .. and then cache webappRoot
>
> And then for various requests
>
> Node session = webappRoot.getChild(sessionId);
> return session.get(VERSION_ID);
>
> Is that going to have any significant efficiency over simply doing  
> this
> for each request:
>
> return cache.get("/JSESSIONID/localhost/webapp1/" + sessionId ,
> VERSION_ID);
>
>
> Let's disregard efficiencies related to constructing Fqn objects;  
> assume
> in real code that's highly optimized and not a big deal.
>
> If the Node is just a wrapper around the cache that calls back into
> TreeCache, that would imply that the former case will internally just
> boil down to the latter case.  So, the call will still walk the tree
> from the root; it won't gain any efficiency because it can start at
> "/JSESSIONID/localhost/webapp1".  I'd think it would have to start at
> the root, otherwise it can't acquire the necessary read locks.
>
> Manik Surtani wrote:
>> 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.
>>
>>> 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
>
>
>
> 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