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

[Eduardo Martins]

On Thu, Jan 6, 2011 at 12:04 PM, Manik Surtani <manik at jboss.org> wrote:
>
> 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.
>

I believe all entries related to a specific node should be colocated,
so I guess it's fine as it is now.

>>
>>> 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).
>

Right now, considering the types available, the AtomicMap is the best
option, yet ideally that structure containing the child fqns should be
a Map, without entry put/remove locks (using flags or not), with delta
replication, and without colocation :)

I really don't know much about Infinispan internals besides the Tree
API and its impl so let me ask you, is that possible to achieve?

-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco