Almost all relational databases today, and some nonrelational databases, support transactions. Most of them follow the style that was introduced in 1975 by IBM System R, the…
- 09.01What Exactly Is a Transaction?Almost all relational databases today, and some nonrelational databases, support transactions. Most of them follow the style that was introduced in 1975 by IBM System R, the…
- 09.02The Meaning of ACIDThe safety guarantees provided by transactions are often described by the well-known acronym ACID, which stands for atomicity, consistency, isolation, and durability. The term…
- 09.03Single-Object and Multi-Object OperationsTo recap, in ACID, atomicity and isolation describe what the database should do if a client makes several writes within the same transaction:
- 09.04Weak Isolation LevelsIf two transactions don’t access the same data, or if both are read-only, they can safely be run in parallel, because neither depends on the other. Concurrency issues (race…
- 09.05Read CommittedThe most basic level of transaction isolation is read committed, and it makes two guarantees:
- 09.06Snapshot Isolation and Repeatable ReadIf you look superficially at read-committed isolation, you could be forgiven for thinking that it does everything that a transaction needs to do: it allows aborts (required for…
- 09.07Preventing Lost UpdatesOur discussion of the read-committed and snapshot isolation levels has primarily focused on guarantees about what a read-only transaction can see in the presence of concurrent…
- 09.08Write Skew and PhantomsIn the previous sections we looked at dirty writes and lost updates, two kinds of race conditions that can occur when different transactions concurrently try to write to the…
- 09.09SerializabilityIn this topic we have seen several examples of transactions that are prone to race conditions. Some race conditions are prevented by the read-committed and snapshot isolation…
- 09.10Actual Serial ExecutionThe simplest way of avoiding concurrency problems is to remove the concurrency entirely: execute only one transaction at a time, in serial order, on a single thread. By doing…
- 09.11Two-Phase LockingFor around 30 years, only one algorithm was widely used for serializability in databases: two-phase locking (2PL), sometimes called strong strict two-phase locking (SS2PL) to…
- 09.12Serializable Snapshot IsolationThis topic has painted a bleak picture of concurrency control in databases. On the one hand, we have implementations of serializability that don’t perform well (2PL) or don’t…
- 09.13Distributed TransactionsIn a single-node transaction, you have a single machine that is in charge of executing the transaction logic, such as the concurrency control algorithms for transaction…
- 09.14Two-Phase CommitTwo-phase commit is an algorithm for achieving atomic transaction commit across multiple nodes. It is a classic algorithm in distributed databases. 2PC is used internally in…
- 09.15Distributed Transactions Across Different SystemsDistributed transactions and 2PC have a mixed reputation. On the one hand, they are seen as providing an important safety guarantee that would be hard to achieve otherwise; on…
- 09.16Database-Internal Distributed TransactionsAs explained previously, there is a big difference between distributed transactions that span multiple heterogeneous storage technologies and those that are internal to a…
- 09.17Exactly-Once Message Processing RevisitedWe saw in “Exactly-once message processing” that an important use case for distributed transactions is to ensure that an operation takes effect exactly once, even if a crash…
- 09.18Recap: TransactionsTransactions are an abstraction layer that allows an application to pretend that certain concurrency problems and certain kinds of hardware and software faults don’t exist. A…