educative.io

Why write skew can not happen in Repeatable reads?

Courses
,
#1

On “Prevention of Anomalies in Isolation Levels” chapter, from the diagram of “Isolation levels and prevented anomalies”, the write skew is not possible in Repeatable reads isolation level. From what I understand from the course, repeatable read only ensure the data won’t be changed in one transaction, but write skew occurs in multiple transaction.
So I’m curious about why write skew can not happen in Repeatable reads ?

Course: Distributed Systems for Practitioners - Learn Interactively
Lesson: Prevention of Anomalies in Isolation Levels

#2

Hi @tao_feng !!
The prevention of write skew in the context of isolation levels is closely related to the guarantees provided by the repeatable read isolation level. Let’s clarify the concepts of repeatable read and write skew:

  1. Repeatable Read Isolation Level:

    • In the repeatable read isolation level, a transaction ensures that once it reads a piece of data, that data remains unchanged for the duration of the transaction.
    • Any subsequent read within the same transaction will see the same snapshot of the database, regardless of changes made by other transactions.

  2. Write Skew:

    • Write skew is a phenomenon where two transactions read some common data, make decisions based on that data, and then independently update the shared data. This can lead to inconsistencies because both transactions might believe they are making decisions based on the same state, but they are not aware of each other’s updates.

Now, to address your question:

  • Write skew involves multiple transactions that are interleaved, and each transaction reads some data and makes decisions based on that data before updating it.

  • In repeatable read isolation level, once a transaction reads a piece of data, it ensures that this data remains unchanged for the duration of the transaction. Therefore, if a transaction reads data, makes decisions based on that data, and updates it later in the transaction, it won’t encounter changes made by other transactions in the meantime.

  • In other words, repeatable read prevents scenarios where another transaction updates the data that the current transaction has read and is based on, because it locks the rows or the range of data it has read until the transaction is committed or rolled back.

By preventing changes to the data that has been read within the transaction, repeatable read helps avoid write skew scenarios where multiple transactions make decisions based on the same data and independently update it, leading to inconsistent results. This is why, in the context of the prevention of anomalies in isolation levels, write skew is not possible in the repeatable read isolation level.
I hope it helps. Happy Learning :blush:

1 Like