Parallel transactions refer to running multiple transactions at the same time , each transaction is executed independently and will not affect each other. In a database management system, when multiple users read or write the same data set at the same time, using parallel transactions can improve the throughput and response time of the system . At the same time, since parallel transactions can perform multiple operations at the same time, it can greatly improve the performance and efficiency of the database system. However, concurrency control needs to be considered when using parallel transactions to avoid issues such as data inconsistency and deadlocks.
When processing multiple transactions at the same time, problems such as dirty reads, non-repeatable reads, and phantom reads may occur .
1. Dirty read
Dirty read means that a transaction reads the data of another uncommitted transaction, that is, reads uncommitted data . If the transaction is subsequently rolled back, the data read is invalid. Dirty reads are a relatively common problem in database concurrency control.
Dirty reads are mainly caused by multiple transactions accessing data in the database at the same time. In a concurrent environment, in order to ensure data consistency, the database system will isolate and lock transactions. However, if a transaction reads uncommitted data of another transaction, it may lead to data inconsistency, that is, the generation of dirty reads.
For example, suppose there are two transactions T1 and T2. During execution, T1 reads the data that T2 is modifying. If T2 performs a rollback operation at this time, the data read by T1 is invalid.
Dirty reads will not only lead to data inconsistency, but also increase data access conflicts . Therefore, the isolation level of the database can control whether the transaction can read uncommitted data, and whether it needs to lock the data, etc., to avoid the occurrence of dirty reads. At the same time, when developing database applications, you can also control the access behavior of transactions through codes to avoid dirty reads.
2. Non-repeatable read
Non-repeatable read means that in a concurrent scenario, a user reads the same row of data multiple times in the same transaction, but gets different results in these reads.
In layman's terms, assuming that user A reads a certain data multiple times in transaction T1, and another user B completes a modification during the interval between these several reads, then user A reads the same row again at this time data, different results may be obtained. This is called non-repeatable read.
Non-repeatable read is a concurrency problem in the database that usually occurs under the read uncommitted transaction isolation level . At this isolation level, uncommitted data is visible, and concurrent modifications may result in data inconsistencies.
To avoid problems with non-repeatable reads, higher transaction isolation levels such as read committed, repeatable read, and serialization can be used. Under the committed read isolation level, there will be no non-repeatable read problem; under the repeatable read and serialization isolation level, the read data will be locked to avoid the interference of concurrent operations.
3. Phantom reading
If the "number of records" that meets the query conditions is queried multiple times in a transaction, if the number of records queried two times before and after is different, it means that a "phantom read" phenomenon has occurred.
Usually, phantom reads and non-repeatable reads are caused by concurrent transactions, but the main differences between the two are:
1. Non-repeatable reads are for modification operations, while phantom reads are for insertion and deletion operations.
2. Non-repeatable reads can be solved by row-level locks or snapshot reads, while phantom reads can only be avoided by locking more rows.Phantom reading is due to changes in the range of data read by a transaction, which may be new records or deleted records. These changes cannot be perceived within the same transaction . Therefore, in order to avoid phantom reading, more rows need to be locked in the transaction to make the range of data read more accurate.
The phantom reading problem mainly occurs under the Serializable (serialization) isolation level, and other isolation levels can also occur, but the probability is low. There are generally two ways to solve phantom reads. One is to use data concurrency control technologies such as row-level locks, and the other is to adjust the transaction isolation level to Repeatable Read or Serializable. Choose the appropriate method based on specific scenarios and needs.
The order of severity of the above three phenomena is as follows:
