Serializability

Introduction

In the previous lessons we have seen how incorrect results from concurrent transactions can be prevented using read committed or snapshot isolation. However, race conditions can still occur due to write skew and phantoms. In general reasoning about isolation levels for correctness is harder in complex applications with several moving parts and because of non-uniform implementation of isolation levels across different database vendors. Also, apart from static analysis tools, there is a dearth of technology and tooling to detect and test for concurrency issues, which are usually nondeterministic and manifest depending on the execution sequence of transactions. To avoid the issues that come with using weaker forms of isolation, one can use serializable isolation — the strongest form of isolation. Serializable isolation guarantees that multiple transactions when executed will produce an end result as if the transactions ran serially, even if the database runs them in parallel. Serializable isolation is generally implemented using one of the following techniques in the context of single node databases that we’ll discuss next:

1. Actual Serial Execution

2. Two Phase Locking

3. Serializable Isolation Snapshot

Actual Serial Execution