DataGravitation of entire subtrees
brian.stansberry May 26, 2006 1:45 AMHaving some trouble integrating BR into HttpSession repl due to some quirks in data gravitation.
For ATTRIBUTE granularity, a session is stored in 2 nodes -- parent node "metadata", whose name is the session id, and which stores session metadata, and child named ATTRIBUTE, which stores the attributes in its data map.
2 server cluster, servers A and B; session owned by A.
Upon failover, get() is called against the Fqn of "metadata". This causes "metadata" to be gravitated. What happens next depends on how I configure "dataGravitationRemoveOnFind".
If true, a remove call is sent around the cluster. A receives it and removes the metadata node as well as the ATTRIBUTE node. When B then wants to access the ATTRIBUTE node, it needs to gravitate it, but can't because it's been removed!
If false, an evict call is sent around the cluster. A evicts the metadata node's data, but leaves the node, because it still has child ATTRIBUTE. B then tries to access ATTRIBUTE, can't find it, and the data gravitates from A. Another evict is sent over the cluster; this time A removes the ATTRIBUTE node, as it has no children.
Problem here is the empty metadata node is left on A. This screws things up if that Fqn is ever accessed again on A. The presence of the empty node breaks data gravitation!
I was able to hack around this for ATTRIBUTE granularity, but in a way I'm really not happy about. Also I fear that this will be a big problem with FIELD granularity, where the node structure is much deeper. That I still have to test.
In general, leaving empty nodes littered around is not good. For BR to work properly, it's critical that nodes in the main tree only exist in the cache that owns them.
One concept I thought of is adding a switch whereby entire subtrees could be gravitated in one go. Perhaps returned as an array of NodeData objects, similar to state transfer. If that could be done, then having "dataGravitationRemoveOnFind" set to true would work fine -- the remove call would be no problem as the child nodes would all be moved.
With such a switch though, an Option to disable DataGravitation for individual calls would certainly be needed so the application can safely do things like put("/JSESSION/localhost/webapp1") to create the root node for an app's sessions without worrying about the whole tree gravitating. But, I think that Option is needed anyway.