concurrent update on same edge break states.

[SteamShon]

with current implementation, concurrent update on same edge, which has same (source, label, dir, target), lead to broken states in snapshot edge.

for example, if following request comes in one request, then result is not deterministic.

1434380239199   delete  e   16  1016    s2graph_label_test
1434380239200   update  e   16  1016    s2graph_label_test  {"time": 10, "weight": 20}
1434380239198   update  e   16  1016    s2graph_label_test  {"time": 10}

this is because Edge update snapshot edge without getting lock when they build update based on what they read.

for example, there was no edge between 16 and 1016 then following happens concurrently.

1. first operation read snapshot edge, and snapshot edge is none, it build it`s own update and mutate them without any checking.
2. second operation also read snapshot edge, and snapshot edge could be none or first operation can be applied. it is not deterministic. for contention, assume its fetched snapshot edge is none. then build its own update and mutate.
3. third operation also read snapshot edge, and it was none.

all of above operations build wrong update since what they read is not valid state when they build update and mutate.

to resolve wrong states in snapshot edge, we first need to validate if each edge`s update is still valid after they read using checkAndSet operation in HBase.

since we already read snapshot edge, instead of fire put, use checkAndSet and check return value. if return false, then other already update on same edge and contention occur so re-read is required. otherwise no contention so we are good to mutate indexedEdge also.

[SteamShon]

resolved in a0bf0e7