Why won`t fix JBCACHE-622?

jorgemoralespou_2 Dec 5, 2007 7:57 AM

I'm having a similar problem in my app.
I use getChildrenNames() to iterate over the tree to get my nodes, in order to print them, or do queries on them.
When I set up a ClusteredCacheLoader, every call to getChildrenNames() remove the children from the cache. I have searched Jira, and found JBCACHE-622, which is similar to my problem, CacheLoaderInterceptor.loadChildren(Fqn fqn, DataNode n) returning null, and making the cache remove the nodes. I wonder why this is marked as won`t fix?

I have seen printDetails in TreeCache, to see how you iterate over the nodes, but I see that you`re using Node, and is commented with:

Does not load any previously evicted nodes from a cache loader, so evicted nodes will not be included.

Also in the forums it states that direct access to Node`s api is not the correct way for clients, but using TreeCache`s api.
How can I solve this?

1. Re: Why won`t fix JBCACHE-622?

genman Dec 7, 2007 8:01 PM (in response to jorgemoralespou_2)

I'm guessing you have to have your application wait for cache start-up to complete before accessing the cache.
Actions
2. Re: Why won`t fix JBCACHE-622?

jorgemoralespou_2 Dec 9, 2007 7:15 AM (in response to jorgemoralespou_2)

Thanks genman, but my app and the cache are both fully started. In fact, using Node directly instead of TreeCache works. The problem this way is that interceptors dont get called, which may prevent getting evicted nodes.
what I want to know is if this jira is a bug, and why it wont be fixed, or if its a feature, which i dont get.
thanks.
Actions
3. Re: Why won`t fix JBCACHE-622?

manik Dec 19, 2007 8:35 AM (in response to jorgemoralespou_2)

Regarding direct access to nodes, this has been added in 2.x. Node is a top-level user API now and calls to Node will be passed through the interceptor chain.
Actions
4. Re: Why won`t fix JBCACHE-622?

manik Dec 19, 2007 9:39 AM (in response to jorgemoralespou_2)

Regarding JBCACHE-622, I should have been more explicit on the JIRA: the issue of preferring what is retrieved from the cache loader (a null) over what is in memory is correct behaviour since the cache loader may be shared, etc.

The real bug is probably JBCACHE-131, to persist state when doing an initial state transfer (provided your cache loader is not shared/a singleton and you are not using passivation).

Will look into potentially reviving JBCACHE-131.
Actions

Go to original post