When concurrent puts are performed to a tree cache under a fixed parent the cache can get into an inconsistent state.
Given an existing parent node with fqn /parent if two threads attempt to add data to two new children /parent/child_0 and /parent/child_1 say:
Thread 0:
treeCache.put("/parent/child_0", "someKey", "value_0");
Thread 1:
treeCache.put("/parent/child_1", "someKey", "value_1");
Then when a subsequent get(...) on these fqns/keys gives "value_0" (or "value_1") correctly, the node API for the parent node sometimes does not include the child nodes for both of the children. (Even though the data is there! Strange.)
We are using a transactional cache with optimistic locking.
I have a unit test for this (attached). Should I raise a bug?
As background info: We have a use case where we use the tree cache to hold data relating to nodes in our own corresponding hierarchical structure. We populate the cache (based on relatively slow database queries) following a cache miss (and use the PUT_FOR_EXTERNAL_READ flag). Problems started to occur when we deleted nodes from our hierarchy, and automatically removed the corresponding nodes from the cache. We noticed that if we recreated the same hierarchical structure just deleted (as can happen in our application), cache lookups were returning the old values. Some debugging showed that the reason for this was that the tree cache remove calls were failing (returning false - as if the items were not present) even though the old values still remained.
