Unification Algorithm の解説

この場合の Unification Algorithm を解説する。

graph_unify_loop_0 (1,2,3,graph も同様)

Fig. 48 graph_unify_loop_0

実は、今回は初期の graph が最終状態となっている。なぜなら、従来の Algorithm では “leader_id: 2” が “leader_id: 1” に置き換わってしまう (マージされてしまう) はずだが、do_not_merge_key: で設定されている member_id ではマージされないようになっているので、これ以上変化が起きないのである。

canonical_id について

canonical_id の生成と割り当て

今回のケースでは、4種類の canonical_id が生成されることになる。

Fig. 49 canonical_id の生成と割り当て

従来と異なるのは、収束状態に関わらず、”follower: a@ex.com” が、2つの leader である “member_id: 1” と “member_id: 2” を指している状態であることである。

実際、lookup テーブルにおいても a@ex.com におけるレコードが2行あることになる。

id	canonical_id
1	4ydklKlyPnfa
2	XNKI3XAY1Hja
3	xqaWYjT4GR3a
a@ex.com	4ydklKlyPnfa
a@ex.com	XNKI3XAY1Hja
b@ex.com	xqaWYjT4GR3a
c@ex.com	NEKDReELMAxH

これは、アルゴリズムの収束判定方法の1つである、「全ての follower がただ1つの leader だけを指している」状態にならずに収束していることを意味する。ただ、もう1つの方法である「WF Logs の +report_diff タスクの出力を確認する」方法は有効である。