<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 4 Jan 2011, at 16:12, Eduardo Martins wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">4) AtomicMap doubt<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I read in the Infinispan blog that AtomicMap provides colocation of<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">all entries, is that idea outdated? If not we may need a way to turn<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">that off :) For instance would not that mean the Tree API does not<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">works well with distribution mode? I apologize in advance if I'm<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">missing something, but if AtomicMap defines colocation, AtomicMap is<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">good for the node's data map, but not for the node's childs fqns.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Shouldn't each child fqn be freely distributed, being colocated<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">instead with the related node cache entry and data (atomic)map? Our<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">impl is kind of an "hybrid" of the Tree API, allows cache entries<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">references (similar to childs) but no data map, and the storage of<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">references through AtomicMap in same way as Tree API worries me.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Please clarify.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Each FQN has underneath an AtomicMap, so each you won't find yourself finding k,v pairs belonging to a particular Fqn in different nodes.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">We make no guarantees wrt child fqn nodes. So, just cos FQN B is child of FQN A, it does not mean that the atomic map of B will be in same node as atomic map of B.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Before I proceed with my reasoning, please clarify, the colocation<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">within AtomicMap is real? If I store data there, all data will be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">colocated?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yup, all *data* stored in the AtomicMap will be located in the same node. It's treated as a single entity.<br></blockquote><blockquote type="cite"><br></blockquote><br>Ok, then lets think on the Tree API, typically/optimally you add, get<br>and remove a specific node in same cluster node/zone, iterating<br>through a node's childs is rare and usually without much perf<br>constraints. With current impl the node's child map entries are<br>colocated, since each node does that through an AtomicMap with child's<br>last FQN element, IMHO this is not great for performance:<br><br>1. Consider parent node P in node N1<br>2. In node N2, add a P child, this goes to N1. Adding P Child also<br>creates the child cache entries, all 3 seem to be colocated through<br>hashCode(), correct me if I'm wrong. Lets assume all hash ideally to<br>local node N2.</span></blockquote><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">3. In node N2, get P child, this may go to N1 if we use P, skips it if<br>use Cache.get(...)<br>4. In node N2, remove P child, this needs to go to N1<br><br>Are you following the issue, if P is a popular parent node (which<br>happens a lot to root childs), N1 will be hammered by other nodes!<font class="Apple-style-span" color="#006312"><font class="Apple-style-span" color="#144FAE"><br></font></font></span></blockquote></div><div><br></div>What you said above is not exactly true. A TreeNode contains 2 AtomicMaps - one for data and one for structure. The DataMap contains the K/V attribute pairs on the node. The StructureMap contains information about children. Firstly, these 2 AtomicMaps aren't necessarily colocated. This is OK, since you rarely update structure (adding/removing children) and data (attributes on a node) in the same transaction. Secondly, there is nothing that says parents and children are colocated since they use different keys. So,<div><br></div><div>/a/b/c <-- could be on N1</div><div>/a/b/c/d <-- could be on N2</div><div><br></div><div>so transactions doing stuff on /a/b/c and /a/b/c/d won't be affecting the same node - unless it is structure that is changing. So as per your example above, in step 2, all 3 don't necessarily go to the same node. Also if you do something like TreeCache.getNode() with an FQN, you don't walk through parents.</div><div><br></div><div><a href="https://github.com/infinispan/infinispan/blob/master/tree/src/main/java/org/infinispan/tree/TreeCache.java#L181">https://github.com/infinispan/infinispan/blob/master/tree/src/main/java/org/infinispan/tree/TreeCache.java#L181</a></div><div><br></div><div>HTH</div><div>Manik<br><div>
<div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org">http://www.infinispan.org</a></div><div><br></div></div><br class="Apple-interchange-newline">
</div>
<br></div></body></html>