CODEWITHSUNDEEP
mvcc
Jack Peng
Jack Peng

Reputation: 632

serializable snapshot isolation outdated premise detection

I'm reading "designing data intensive applications" page 263. It breaks down the outdated scenario into 2 cases, 1. uncommitted write before read 2. uncommitted write after read

The solution to 1 is to track this write and check before commit. The solution to 2 is to track all reads by index range and when a transaction writes, it notifies the other transactions so it knows that the premise may have been changed.

So both solutions do a check at commit time. So why not always use solution 2? Seems that solution 2 also works for the before case. What's the advantage of keeping track of reads ignored by MVCC rules? Seems simpler and less error prone to just have 1 method that covers both cases since you need to cover case 2 anyway.

Upvotes: 0

Views: 43

Answers (1)

Jack Peng
Jack Peng

Reputation: 632

Never mind. I mis-read the last paragraph for case 2 on page 265. The notifications happen at uncommitted write time, not commit time. So if the write is early (case 1), the read hasn't happened and there's nothing to notify! So the ignored mvcc writes need to be handled separately.

I was assuming that solution 2 waits till commit time to notify. That would have solved both cases. To me this was more natural at first sight but compared to the solution in the book, it's delaying notification, which would result in more race conditions. So I think the book solution is good.

Upvotes: 0

Related Questions