Optimization

you may notice that there would be many possible retrying thread concurrently running for updating same snapshotEdge.

For example, assume there is 3 request that need to be applied on same snapshotEdge. only one thread can mutate snapshotEdge so while one thread success, the other 2 would be failed and retry.

so number of retrying thread increase when there are many contentions.

we resolve this problem by squashing requests on same snapshotEdge and mutate as batch.

This is possible since following is same.

assume there are multiple requests arrived on different server and contention occur.

server 1 requests

t0, insert, {p0: true, p1: 0, p2: 0}
t1, update, {p1: -1}
t4, update, {p2: 100}

server 2 requests

t2, delete
t3, insert, {p1: -1, p2: 20}
t5, delete

The final expected state would be no edge remain.

each server is smart to squash multiple requests on same snapshotEdge and batched them.

instead of run above logic 3 times on server1 and 3 times on server2, each server squash them into following.

t4, update, {p0: (true, t0), p1: (-1, t1), p2: (100, t4)}

t5, delete

Then S2Graph run retry logic on these squashed two requests, not orignal 6 requests.