Introduction to Two-Phase Locking (2PL)

Concurrency is everywhere in reading and writing to a data store. It poses challenges to prove that certain concurrent code is safe to execute in parallel with others, potentially interleaving arbitrarily. The problem of concurrent data access was thoroughly studied in the context of databases and transactions in 1974. The transaction is an abstraction to safely deal with concurrency (and many other data issues). We will discuss concurrency control in the context of transactions, though the concepts are more widely applicable.

This chapter will elaborate on potential problems of data transactions, and a specific strategy databases employ to prevent them, i.e., Two-Phase Locking (2PL). We will focus mainly on:

• Concurrency management
• Addressing numerous race conditions due to concurrency insurance
• Implementations of databases’ isolation levels like serializability using 2PL

Race conditions

Multiple clients typically access databases at once. That is not a problem if they read and write to different database entries. We might still encounter concurrency issues if they access the exact database records. These are called race conditions.

Example

Imagine that two clients are incrementing a database-stored counter at the same time. Each client must read the current value, add 1, and then write back the new value, assuming the database doesn’t have a built-in increment operation. Due to the race condition, the counter only gets to 13 when it should have gone from 12 to 14 due to two increments.

Concurrency problems

The harsh reality of data systems presents several potential concurrency problems:

• Multiple clients may simultaneously write to the database, overwriting one another’s modifications.
• Data that has only been partially updated may be seen by a client and can be confusing.
• Race conditions among clients can result in unexpected bugs.

A system must handle these errors and make sure they don’t result in the catastrophic breakdown of the entire system to be dependable. However, it takes a lot of labor to implement fault-tolerant methods. To make sure the solution truly works, it takes a lot of meticulous consideration of all the potential problems.

Before understanding the 2PL mechanism, let’s first understand what transactions are and why they’re so integral in solving concurrency issues.

Transactions

Transactions have been the preferred method for resolving these problems for many years. A transaction is a means for an application to logically unite multiple reads and writes. In theory, a transaction’s reads and writes are combined into one operation, either succeeding (commits) or failing (abort, rollback). The transaction is safe to retry if it fails. An application can handle errors considerably more quickly with transactions since partial failure—when some operations succeed, and others fail—is not a concern.

Note: The application can overlook potential error scenarios and concurrency problems by utilizing transactions because the database handles them instead. We call these safety guarantees.

Given the case of race conditions and concurrency issues in transactions, the practical approach ...