Five types of concurrency problems
Lost Updates (Type 1 Lost Updates)
When revoking a transaction, overwrite the updated data submitted by other transactions (transactions A and B are executed concurrently, and transaction A is updated after the update is performed; transaction B also updates the data of the row after transaction A is updated and before the end of transaction B. update operation, then rollback, both update operations are lost). This concurrency problem is caused by the complete lack of isolated transactions. As long as the isolation level is set, the database can guarantee that such problems do not occur.
The customer loses 100 yuan.
dirty read
A transaction reads the uncommitted update data of another transaction (transactions A and B are executed concurrently, after transaction B executes the update, transaction A queries the uncommitted data of transaction B, and transaction B rolls back, the data obtained by transaction A is not in the database. real data. That is, dirty data, that is, data that is inconsistent with the database).
The customer loses 100 yuan.
non-repeatable read
A transaction reads the updated data submitted by another transaction (transactions A and B are executed concurrently, transaction A queries the data, then transaction B updates the data, and when A queries the data again, it is found that the data has changed).
Override updates (the second category of lost updates)
This is a special case of non-repeatable read, where one transaction overwrites the updated data that has been committed by another transaction (that is, transaction A updates the data, then transaction B updates the data, and the transaction A query finds that the updated data has changed).
The bank loses 100 yuan.
Virtual reading (phantom reading)
A transaction reads the newly inserted data that has been committed by another transaction (A and B transactions are executed concurrently, A transaction queries data, B transaction inserts or deletes data, A transaction queries again and finds that there is no data in the result set or data that was previously in the result set. data disappeared).
Shared locks and exclusive locks
In order to solve the concurrency problem, the database system introduces a locking mechanism.
There are two basic types of locks: exclusive locks (Exclusive locks abbreviated as X locks) and shared locks (Share locks abbreviated as S locks).
- Exclusive locks are also known as write locks. If transaction T adds X lock to data object A, only T is allowed to read and modify A, and no other transaction can add any type of lock to A until T releases the lock on A. This ensures that other transactions can no longer read and modify A until T releases the lock on A.
- Shared locks are also known as read locks. If transaction T adds S lock to data object A, transaction T can read A but cannot modify A. Other transactions can only add S lock to A, but not X lock until T releases the S lock on A. This ensures that other transactions can read A, but cannot make any changes to A until T releases the S lock on A.
block granularity
Blocking technology is used in the database to achieve concurrency control.
The size of the block object is called block granularity (Granularity).
The blocked object can be a logical unit or a physical unit. Taking a relational database as an example, the blocking object can be such logical units: attribute values, sets of attribute values, tuples, relations, index items, the entire index item, and even the entire database; it can also be such physical units: pages (data page or index page), physical records, etc.
Blocking Protocols and Isolation Levels
When using exclusive locks and shared locks to lock data objects, it is also necessary to agree on some rules, such as when to apply for an exclusive lock or a shared lock, lock holding time, and when to release it. Call these rules the Locking Protocol. Different rules are stipulated for the blocking method, and various blocking agreements are formed. Different blocking protocols correspond to different isolation levels.
Level 1 blocking protocol (corresponding to read uncommited)
The first-level blocking protocol is: transaction T must add X lock to data R before modifying it, and it will not be released until the end of the transaction. Transaction ends include normal end (COMMIT) and abnormal end (ROLLBACK).
A first-level blocking protocol prevents lost updates and guarantees that transaction T is recoverable.
In the first-level blocking protocol, if you just read the data without modifying it, there is no need to lock it, so it cannot guarantee repeatable reading and no reading of "dirty" data.
Level 2 blocking protocol (corresponding to read committed)
The second-level blocking protocol is: the first-level blocking protocol plus transaction T must add an S lock to the data R before reading it, and the S lock (instantaneous S lock) can be released after reading.
In addition to preventing lost updates, the secondary blocking protocol further prevents reading "dirty" data.
Level 3 blocking protocol (corresponding to reapetable read)
The third-level blocking protocol is: the first-level blocking protocol plus transaction T must add S lock to the data R before reading it, and it will not be released until the end of the transaction.
In addition to preventing lost updates and unread 'dirty' data, the three-level blocking protocol further prevents non-repeatable reads and overwrite updates.
Level 4 blocking protocol (corresponding to serialization)
The fourth-level blocking protocol is an enhancement to the third-level blocking protocol, and its implementation mechanism is the simplest. It directly adds a table lock to the table where the data read or changed in the transaction is located, that is, other transactions cannot read or write the table. any data. In this way, all five types of concurrency problems can be avoided!
Note: Blocking protocols and isolation levels do not strictly correspond.
Concurrency problems that can be avoided by various isolation levels
The higher the isolation level, the better the data integrity and consistency can be guaranteed, but the greater the impact on concurrent performance. For most applications, it is preferable to set the isolation level of the database system to Read Committed. It avoids dirty reads and has good concurrency performance. Although it can lead to concurrency problems such as non-repeatable reads, phantom reads, and second-class lost updates, in individual cases where such problems may occur, it can be controlled by the application using pessimistic locking or optimistic locking.