Re: [infinispan-dev] Feedback from Mobicents Cluster Framework on top of Infinispan 5.0 Alpha1

On 5 Jan 2011, at 21:20, Eduardo Martins wrote: >> >> 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, > > I just said both are colocated because both maps are stored in > Infinispan using an entry key object that defers hashCode() to fqn's > hashCode() only, it does not uses the NodeKey type also. I had the > idea that would result in colocation, is that incorrect? Ah ok, I didn't realise that.  We can experiment with using different hash codes so the 2 AtomicMaps are distributed independently, but then this still doesn't really solve your problem of all structural information being stored together.

> >> 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, >> /a/b/c <-- could be on N1 >> /a/b/c/d <-- could be on N2 >> 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. > > That's what I mean in 3. using Cache.get(...) would not need parent. > > I think you misunderstood the real issue, the fact that the node > structure is a map where all entries are colocated, as I said this > means that for populars parent nodes which have lots of childs, there > will be a lot of traffic to add/remove childs, this would not happen > if the parent's structure entry related with the child was colocated > with the child entries itself. Right.  Well, if you have a better proposal to store such structural information, I'd be happy to hear it.  :-)  It would mean that you cannot use AtomicMaps for this purpose though, since anything stored in an AtomicMap will always be colocated (by design).