RE: [jbosscache-dev] Some new Cache usage questions
by Brian Stansberry
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(a)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@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
>>
>>
>>
>> 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
18 years, 5 months
RE: [jbosscache-dev] Some new Cache usage questions
by Brian Stansberry
Brian Stansberry wrote:
> 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.
Sorry, meant to say "... a sophisticated *programmer* can understand
..."
18 years, 5 months
RE: [jbosscache-dev] Some new Cache usage questions
by Brian Stansberry
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(a)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@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
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years, 5 months
RE: [jbosscache-dev] Some new Cache usage questions
by Ben Wang
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
>
18 years, 5 months
RE: [jbosscache-dev] Node.getChildren()
by Ben Wang
For CachedMaplImpl, I have been relying on keySet() and entrySet() from the returned Map to get Fqn, Node Collection. Yes, I can create it myself from the returned Collection by looping. But it will do the extra work from your fresh Collection instance, will it not?
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Tuesday, September 05, 2006 12:06 AM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Node.getChildren()
So if you don't know the Fqn in advance, how does having a Map<Fqn,
Node> help over having a Collection<Node>? The only benefit I can
see here is doing Map<Fqn, Node>.containsKey()... all else should be just as easy/efficient with Collection<Node>, IMO. Am I missing something?
--
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 4 Sep 2006, at 17:01, Ben Wang wrote:
> In my case, I am querying for all children Node and find out their
> respective (fqn, Node). Problem is that I don't know the fqn in
> advance. I am using this currently for Collection implementation for
> keySet and entrySet, for example.
>
> Cheers,
>
> -Ben
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Monday, September 04, 2006 7:14 PM
> To: Ben Wang
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Node.getChildren()
>
> Hi Ben.
>
> Again, this (rather poor) implementation was just to get the API
> contracts in place. It does need refactoring in the way it is
> implemented, but I see what you mean about getChildren() returning a
> Map<Fqn, Node> being more useful than returning a Collection<Node>.
> The latter (and current impl) is cleaner from an OO perspective, but
> if the former is more practical then so be it.
>
> Just so I understand the use case better, why do you need a Map<Fqn,
> Node>? If you are looking for a specific child, wouldn't getChild
> (Fqn) suffice?
>
> 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 4 Sep 2006, at 04:32, Ben Wang wrote:
>
>> Manik,
>>
>> I have noticed that this is the current implementation for
>> Node.getChildren():
>>
>>
>> public Collection<Node> getChildren()
>> {
>> Map m = currentNode.getChildren();
>> Set<Node> children = new HashSet<Node>(m.size());
>> Iterator i = m.values().iterator();
>> while (i.hasNext())
>> {
>> children.add(new TreeCacheProxyImpl(treeCache, (NodeImpl)
>> i.next()));
>> }
>>
>> return children;
>> }
>>
>>
>> Actually, what I need now is a map of (keyFqn, node), i.e., return m.
>> But even if we stick to this api, creating children will be quite
>> expensive won't it be if getChildren is called many times (happens
>> for my case dealing with Collection classes).
>>
>> Thanks,
>>
>> -Ben
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
18 years, 5 months
RE: [jbosscache-dev] Some new Cache usage questions
by Ben Wang
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.
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.
-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
18 years, 5 months
RE: [jbosscache-dev] Node.getChildren()
by Ben Wang
In my case, I am querying for all children Node and find out their respective (fqn, Node). Problem is that I don't know the fqn in advance. I am using this currently for Collection implementation for keySet and entrySet, for example.
Cheers,
-Ben
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Monday, September 04, 2006 7:14 PM
To: Ben Wang
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Node.getChildren()
Hi Ben.
Again, this (rather poor) implementation was just to get the API contracts in place. It does need refactoring in the way it is implemented, but I see what you mean about getChildren() returning a
Map<Fqn, Node> being more useful than returning a Collection<Node>.
The latter (and current impl) is cleaner from an OO perspective, but if the former is more practical then so be it.
Just so I understand the use case better, why do you need a Map<Fqn,
Node>? If you are looking for a specific child, wouldn't getChild
(Fqn) suffice?
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 4 Sep 2006, at 04:32, Ben Wang wrote:
> Manik,
>
> I have noticed that this is the current implementation for
> Node.getChildren():
>
>
> public Collection<Node> getChildren()
> {
> Map m = currentNode.getChildren();
> Set<Node> children = new HashSet<Node>(m.size());
> Iterator i = m.values().iterator();
> while (i.hasNext())
> {
> children.add(new TreeCacheProxyImpl(treeCache, (NodeImpl)
> i.next()));
> }
>
> return children;
> }
>
>
> Actually, what I need now is a map of (keyFqn, node), i.e., return
> m. But even if we stick to this api, creating children will be
> quite expensive won't it be if getChildren is called many times
> (happens for my case dealing with Collection classes).
>
> Thanks,
>
> -Ben
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 5 months
RE: [jbosscache-dev] Some new Cache usage questions
by Ben Wang
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
18 years, 5 months
Node.getChildren()
by Ben Wang
Manik,
I have noticed that this is the current implementation for Node.getChildren():
public Collection<Node> getChildren()
{
Map m = currentNode.getChildren();
Set<Node> children = new HashSet<Node>(m.size());
Iterator i = m.values().iterator();
while (i.hasNext())
{
children.add(new TreeCacheProxyImpl(treeCache, (NodeImpl) i.next()));
}
return children;
}
Actually, what I need now is a map of (keyFqn, node), i.e., return m. But even if we stick to this api, creating children will be quite expensive won't it be if getChildren is called many times (happens for my case dealing with Collection classes).
Thanks,
-Ben
18 years, 5 months
RE: [jbosscache-dev] Need for CacheLoader.storeState?
by Vladimir Blagojevic
Yeah. Either that or expose method with boolean in CacheLoader interface
and implement method without boolean at AbstractCacheLoader with default
(true|false) parameter as a convenience.
But I am not sure how to implement method with boolean for
BdjeCacheLoader and JdbmCacheLoader. It is not straightforward. We need
to contact ppl that implemented BdjeCacheLoader and JdbmCacheLoader
since we have to conform to NodeData streaming standard anyway. Maybe
they can do it at the same time. Hopefully soon since we need to have
streaming standard for 2.0.
> And then change the cache loaders we wrote to implement the
> method with the boolean?
18 years, 5 months
