In terms of limitations, there are no known memory or size limitations within JBoss Cache, as long as your JVM has adequate heap size.
In terms of performance, tree breadth is represented as Maps containing child nodes for each parent node. If each parent node has a large number of children, the Map implementation may become a bottleneck. As of the current stable release (2.0.0.GA) we use java.util.concurrent.ConcurrentHashMaps here. I would say it is worthwhile profiling to see if this does become a bottleneck for you.
In terms of depth, while 20 - 30 levels deep is probably close to the upper level of what I have seen in production use as most folk tend to prefer broader trees to deeper ones. THe limiting factor here is the cost of retrieving a node from the tree (since it walks the tree structure). Deeper trees means more walking. In 2.1.0 we will be optimising this by significantly reducing tree walking (JBCACHE-811). Again though, something I'd recommend profiling first to see how much of an impact it causes with your access patterns.
Finally, regarding your issue of verifying existence, do you have any eviction configured? It could be that an eviction thread is removing nodes from the tree.
Thanks for the reply Manik,
we are very much new to JBOSS cache, and trying to perform some feasibility study to know whether this solution will fit to our requirements, during the implementation of the above scenario i didnt configure any eviction, which eviction policy should i have to configure?
Please read through the eviction section of the user guide. This will explain how each eviction policy works, and you can decide which is most appropriate for you.