JBCACHE-1153 - structural nodes

[mircea.markus]

this jira is about not considering the structural nodes for eviction. This performance optimisation makes sense considering that nothing can be evicted from those nodes as they don't have an attribute map, but the eviction events are created, processed, etc(also interceptor stack when passivation is on).
Now, considering how eviction curently works, I think things can be optimized even more: by ignoring all the nodes that have empty attribute maps from eviction (this includes the prev defined structural nodes). By ignoring them from eviction I mean not generating eviction events on access on those nodes. Even at this point, when Cache.evict(fqn) is called on such an empty node, the impl works as follows:
a) fqn is NOT eaf, then then empty the attribute map
b) node is leaf, then remove it entirelly.

In the case of a) for empty nodes nothing really happens. Though when this call is performed some eviction events got processed, which is not necessary
I think the case of b should be preserved though, as keeping empty paths is not optimal.
So the optimisation would rather be: don't consider empty, not-leafs nodes for eviction.

[manik]

Thinking a bit more about this since we spoke yesterday; I think this can become a problem since even a node with no data still has an overhead and an impact on memory. I think they should still be considered for eviction.

The whole purpose behind JBCACHE-1153 is so that certain nodes can be considered structural and not considered for eviction since they are just "path builders" rather than data buckets. Can't we just use the resident flag for this purpose instead?

See my comment on http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097183#4097183 about tombstones and invalid nodes. It shows how you could have empty nodes with no data, that *should* be considered for eviction.

[mircea.markus]

I think this can become a problem since even a node with no data still has an overhead and an impact on memory. I think they should still be considered for eviction.

at the time the
If we consider for eviction such a node, and it gets to be evicted, nothing really happens at that point, unless it is a leaf node. For all non-leafs nodes, the eviction would only empty the attribute map, which in our case is already empty (effect of eviction would be void). I also agree that those nodes are not empty and somehow makes sense counting them as nodes to be evicted, but on the other hand they reduce the benefits of it which is cleaning up memory and allow for other data to be kept there...

Can't we just use the resident flag for this purpose instead?

we can go on and implement based on this approach. The implementation is a bit trickier due to transactions:

cache.put("/a/b/c","k","v");
//at this point "/a" and "/a/b" are structural + resident
tx.start()
cache.put("/a/b","k2","v2"); //at this point "/a/b" becomes not-structural
tx.rollback();
//"/a/b" should not be structural + resident as transaction failed

See my comment on http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097183#4097183 about tombstones and invalid nodes. It shows how you could have empty nodes with no data, that *should* be considered for eviction.

I haven't totally get it (Mon morning :) ), let's have a chat

[manik]

WRT transactions, I guess what I mean is, let's not automatically try and deduce whether a node is structural. I.e., let's make developers explicitly make a node resident instead. E.g.,

cache.put("/a/b/c", "k", "v");
cache.getRoot().getChild("/a").setResident(true);
cache.getRoot().getChild("/a/b").setResident(true);

[mircea.markus]

I think this is a good approach also. After all the 'resident' flag gives te user enough flexibility.

[manik]

Shall we go with this then?

[mircea.markus]

yes, let's go with this one. I'll update the part of the manual that describes 'residency' adding this use case.