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

[Manik Surtani]

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 at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org