Hi guys,<br><br>I've took a look at the implementation of JDBCCacheLoader and here are some thoughts on it. <br><br>There is an alternative way of persisting trees into the database. It has certain advantages compared to the straight forward solution of each node keeping a reference to its parent (
a.k.a. Adjacency List Model). The basic idea is to traverse the tree in preorder and add some indexing info to each node - you can find a nice and simple description of the model here: <a href="http://www.sitepoint.com/print/hierarchical-data-database" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.sitepoint.com/print/hierarchical-data-database</a>. This indexing info will be further used for optimizing fetching and removing operations.<br><br>The big advantage is that all the recursive calls for the loadSubtree and removeSubtree operations are nicely avoided. Drawback - insertions is slightly more time consuming.
<br><br>I've made a comparison between this approach and the existing implementation and here are some figures. Methods that are affected are: remove(Fqn), loadState(Fqn subtree, ..) and put(Fqn, value)<br><br>1) remove(Fqn). Current recursive implementation performs about pow(m,n) database calls. M = the average # of children, n the depth of the subtree. The new approach would reduce it to a fix value(3 calls - retrieve the node, delete it together with all its children, update indexes)
<br>2) loadState(Fqn subtree, ..) - similar to remove; pow(m,n) database calls, 2 queries for loading it.<br>3) put(Fqn, value) - here is the drawback. Normally a new update should be performed in order to shift the indexes. An optimization can be performed though. By indexing with a step of lets say 10, we'll be assured that the next 9 insertion will not conflict, so the drawback would be an update for each 9 insertions - not a big deal I would say.
<br><br>If you guys find it usefully, really glad to go ahead with an implementation and compare the performance figures...<br><br>Cheers,<br>Mircea<br><br> <br><br><br><br><br><br><br><br>