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).
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org