[jboss-user] [JBoss Cache] New message: "Re: How to evict a node when all its children have been evicted?"
Nikolazy Zamosenchuk
do-not-reply at jboss.com
Sat Jan 30 11:20:27 EST 2010
User development,
A new message was posted in the thread "How to evict a node when all its children have been evicted?":
http://community.jboss.org/message/523139#523139
Author : Nikolazy Zamosenchuk
Profile : http://community.jboss.org/people/nzamosenchuk
Message:
--------------------------------------------------------------
Have some assumption, that proposed ActionPolicy may cause some problems, but not sure.
There is a piece of code in method evict()
// The expected data structure is of type $CHILD_NODES/${node-id}/${sub-node-name} or
// $CHILD_PROPS/${node-id}/${sub-property-name}
>>> Set<Object> names = cache.getChildrenNames(parentFqn); <<<
if (names.isEmpty() || (names.size() == 1 &&
names.contains(fqn.get(2))))
This code will be invoked if node, that is going to be evicted is from CHILD_NODES or CHILD_PROPS and it's fqn size is 3. (i.e.
$CHILD_PROPS/parentUUID1/childName1). In this case such code will be invoked:
cache.getChildrenNames(parentFqn); (*)
Investigating forums and cache source code, I've found that this will trigger a VISIT event on JBC nodes, so all the nodes will be
refreshed, so they will be moved to the end of eviction queue.
Let's imagine situation, when we have lots of nodes in $CHILD_PROPS sub tree. We are not using them for a long time and some node like
$CHILD_PROPS/parentUUID15/childName100 is now going to be evicted. ParentNodeEvictionActionPolicy.evict() will invoke this code (*), so all nodes in $CHILD_PROPS/parentUUID1/* will be "visited", so they will not be evict. Aren't them? So there is a situation when lots of
really unused JBC nodes will always be visited (refreshed) and so will remain in cache.
Its just an idea and may be I'm mistaken.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/523139#523139
More information about the jboss-user
mailing list