0
$\begingroup$

My understanding why distributed transaction need synchronized clock is the following

Assume NTP max drift is 250ms

true time = 100ms
node A local time = 100ms
node B local time = 0ms

the following transaction will run into conflicted sequence

transactionA arrive nodeA at (true time 100ms, A time 100ms, B time 0ms)
transactionA commit by nodeA at (true time 110ms, A time 110ms, B time 10ms)
nodeB gets transactionA replicated at (true time 111ms, A time 111ms, B time 11ms) BUT with timestamp (110ms)
transactionB arrive nodeB at (true time 120ms, A time 120ms, B time 20ms)
transactionB is commit by nodeB at (true time 130ms, A time 130ms, B time 30ms)

now there is a conflict in transaction time between transactionA and transactionB

transactionA commit time = 110ms (local of A)
transactionB commit time = 30ms (local of B)

transaction A should be processed before transaction B , but because node B lag node A by 100ms transactionB is now considered to be processed before transactionA

Spanner have atomic clock that guarantees max time drift to be 7ms, and it waits this max uncertainty time of 7ms before commit. But how does that fundamentally solve the issue?

Imagine the following example

true time = 7ms
node A local time = 7ms
node B local time = 0ms



trxA arrive nodeA at (true time 7ms, A time 7ms, B time 0ms)
trxA commit by nodeA at (true time 14ms, A time 14ms, B time 7ms)

trxB arrive nodeB at (true time 9ms, A time 9ms, B time 2ms)
trxB is commit by nodeB at (true time 16ms, A time 16ms, B time 9ms)

In this example 7ms wait doesn't solve the problem, trxB is still committed at 9ms (local nodeB time) trxA is committed at 14ms (local nodeA time)

The conflict of trxB committed before trxA still exist

What am i missing here?

$\endgroup$

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.