olafA
Joined 2 years ago
Karma
1
Submissions
4
Member since
Feb 15
Joined 2 years ago
> To be externally consistent, a transaction must see the effects of all the transactions that complete before it and none of the effects of transactions that complete after it, in the global serial order
Example when both node waited
real-world time = 7ms
node A local time = 7ms
node B local time = 0ms
trxA arrive nodeA at (real-world time 7ms, A time 7ms, B time 0ms)
wait 7ms before commit
trxA commit by nodeA at (real-world time 14ms, A time 14ms, B time 7ms)
trxB arrive nodeB at (real-world time 9ms, A time 9ms, B time 2ms)
wait 7ms before commit
trxB is commit by nodeB at (real-world time 16ms, A time 16ms, B time 9ms)
result, localtime(trxA) = 14ms , localtime(trxB) = 9msNo wait example
real-world time = 7ms
node A local time = 7ms
node B local time = 0ms
trxA arrive nodeA at (real-world time 7ms, A time 7ms, B time 0ms)
trxA take 1ms to commit
trxA commit by nodeA at (real-world time 8ms, A time 8ms, B time 1ms)
trxB arrive nodeB at (real-world time 9ms, A time 9ms, B time 2ms)
trxB take 1ms to commit
trxB is commit by nodeB at (real-world time 10ms, A time 10ms, B time 3ms)
result, localtime(trxA) = 8ms , localtime(trxB) = 3msin both cases localtime(trxA) > localtime(trxB) , external consistency is not achieved?
and in the no wait example the transactions are not concurrent, only when it waited it became concurrent?
I must be missing something here?
I am confused on why each data node have to wait 7ms to commit, isn't it easier to ask whichever client is reading to read from the maximum uncertainty timestamp?
Assume the following example
For example if client C is reading and client C lags real world time by 7ms Instead of asking each node to wait to commit timestamp, this guarantees any commit happened before read in real-world time is read, and none of the commit happend after read in real-world is read (since we are requesting read at the time read happens)