Quartz 4

write-skew

2 min read

Write Skew

Summary: A subtle race condition where two transactions update different objects based on a shared premise, leading to an inconsistent state.

Sources: chapter7

Last updated: 2026-04-17

Write skew is neither a dirty write nor a lost update, because the two transactions are updating two different objects. However, it is a race condition: if the two transactions had run one after another, the second one would have seen a different state and might have made a different decision (source: chapter7).

The On-Call Example

Imagine a hospital where at least one doctor must be on call. Two doctors, Alice and Bob, are both on call and both feel unwell. They both check if there are at least two doctors on call (the shared premise). Both see that there are two, so they both update their status to “off call.” Now no doctors are on call, violating the constraint (source: chapter7).

Phantoms and Write Skew

Write skew often follows a pattern:

  1. A SELECT query checks if some requirement is satisfied.
  2. Based on the result, the application code decides how to continue.
  3. The application makes a write (INSERT, UPDATE, or DELETE) that changes the precondition of the decision in step 2.

This effect, where a write in one transaction changes the result of a search query in another transaction, is called a phantom (source: chapter7).

Solutions

  • Serializable isolation: The most effective solution.
  • Explicit locking: Using SELECT ... FOR UPDATE to lock the rows the transaction depends on.
  • Materializing conflicts: Artificially introducing lock objects into the database.

Graph View

Backlinks