Looking at your scenario I think this is expected behaviour.
cache.remove() will remove the node and all it's children. When you use a cache loader, this behaviour is passed on to the cache loader too.
So when you do cache.remove("/a") this will remove /a and all its children both in memory and in the cache loader.
So I'm not surprised that when you then to a cache.get("/a/b/c") you get null. :)
thank you for your response. This indeed makes sense, though I forgot to mention that our custom CacheLoader is one-way; it does not write any values back to the store.
Is there a way I can configure JBC so it does not try to persist the data using the CacheLoader?
Regarding locks, is there a difference between a CacheLoader's put() into the cache and an externally called put()? I could discard the CacheLoader and load and put the values outside of the cache.
Yes, you can suppress the cache loader from writing by setting ignoreModifications to true in your cache loader cfg.
And yes, in this case wasRemovedInTx() will prevent the value from being loaded from the cache loader - this is an optimisation since in MOST cache loaders this would result in a null coming back anyway, after hitting the disk. But I see what you mean in that this does impair on the *correctness* of behaviour when ignoreModifications is true. Feel free to create a JIRA for this and vote for it.
And regarding loading externally, you could use Cache.putForExternalRead() which is built for the purpose of doing a put which is a result of a read from an external data source (as opposed to a put() which is a write to the external data source as well, such as a new item in the cache and data source).