Let's consider a scenario of a write skew below.
In an MVCC protocol for snapshot isolation, let's assume the initial state is this:
| Item | Version | Value |
|---|---|---|
| on_call | 3 | [Alice, Bob] |
Then transition TA started and given a unique timestamp of 5 and after some time transition TB will start with a timestamp of 7. Both read on_call and return the value [Alice, Bob] as version 3 is less than both timestamps 5 and 7.
Representing the above statement in a table:
| TA(5) | TB(7) |
|---|---|
| R(on_call) = [Alice, Bob] | |
| R(on_call) = [Alice, Bob] |
After this TA starts a write and the current version(3) is lower than the transaction's timestamp(5), It's able to add it to the DB. making the state as
| Item | Version | Value |
|---|---|---|
| on_call | 3 | [Alice, Bob] |
| on_call | 5 | [Bob] |
| TA(5) | TB(7) |
|---|---|
| R(on_call) = [Alice, Bob] | |
| R(on_call) = [Alice, Bob] | |
| W(on_call, Alice, false) |
After that TB starts a write call and finds out the current version is 5 and TB's timestamp is 7. And as all transactions running MVCC will record all active transactions in the beginning. It figured that the current on_call version 5 was made by an active transaction and TB will restart with a new timestamp. Which is a valid case here.
I have read that snapshot isolation doesn't support write skew but in the above case, I don't see a problem.
Can someone please tell me if there is an issue with the above use case? And redirect me to some docs, that can prove write skew happens in a snapshot isolation.
