Concurrency consistency issues

Concurrency consistency issues

Common concurrency concurrency Consistency issues include: missing changes, non-repeatable reads, read dirty data, Phantom reads (Phantom reads are often associated with non-repeatable reads in some materials).

Missing modifications

Let's take a look at an example that shows inconsistencies in the data caused by concurrent operations.

Consider an activity sequence in the aircraft booking system:

1. A ticketing point (a) read out the balance of a flight ticket a, set a=16.
2. b Ticketing Point (b business) read out the same flight ticket balance a, also 16.
3. Sell a ticket at a ticket office, modify the balance a←a-1. So a is 15, write a back to the database.
4. B Ticket sales also sell a ticket, modify the balance a←a-1. So a is 15, write a back to the database.

As a result, two tickets were sold, and the balance in the database was reduced by only 1.

Summed up is: Two transactions T1 and T2 read into the same data and modify, T2 submitted results destroy the results of the T1 submitted, resulting in T1 modification is lost. The problems and workarounds mentioned in the previous article (2.1.4 Data deletion and update) are often addressed to such concurrency problems. But there are still several types of problems that cannot be solved by the above method:

Non-REPEATABLE READ

Non-repeatable read refers to the transaction T1 after the data is read, T2 performs the update operation, so that T1 cannot reproduce the previous read result. Specifically, non-repeatable reading consists of three cases:

• After the transaction T1 reads a data, the transaction T2 modifies it, and when transaction 1 reads the data again, it gets a different value than the previous one. For example, T1 reads b=100 to perform operations, T2 reads the same data B, modifies it, and then writes b=200 back to the database. T1 in order to proofread the read value b,b has been 200, inconsistent with the first read value.
• Transaction T1 After some data records have been read from the database by a certain condition, the transaction T2 deleted some of the records, and when T1 again reads the data in the same condition, some records are found to have disappeared.
• Transaction T1 After some data records are read from the database by certain criteria, the transaction T2 inserts some records, and when T1 again reads the data in the same condition, it finds some more records. (This is also called Phantom Reading)

Read "Dirty" data

Read "Dirty" data refers to the transaction T1 modify a certain data, and write it back to disk, transaction T2 read the same data, T1 for some reason was revoked, at this time T1 modified data Recovery original value, T2 read the data is inconsistent with the data in the database, then T2 read the data is "dirty" data, that is, incorrect data.

The main reason for the above three types of data inconsistency is that concurrent operations undermine the isolation of transactions. Concurrency control is the correct way to dispatch concurrent operations, so that the execution of a user's transaction is not affected by other transactions, so as to avoid the inconsistency of data.

Workarounds for concurrency consistency issues blocking (Locking)

Blocking is a very important technique for implementing concurrency control. The so-called blockade is a transaction t before a data object such as tables, records, and so on, before the system to make a request to lock it. After locking, the transaction T has some control over the data object, and other transactions cannot update the data object until the transaction T releases its lock.

There are two basic types of blocking: exclusive locks (Exclusive locks précis-writers for x locks) and shared locks (Share locks précis-writers for s locks).

Exclusive lock is also called write lock. If the transaction t adds an X lock to the data object A, only T reads and modifies a, and no other transaction can add any type of lock to a, until T releases the lock on A. This guarantees that the other transaction can no longer read and modify a when T releases the lock on A.

Shared locks are also known as read locks. If the transaction t adds the S lock to the data object A, the other transaction can only be locked to a plus s, not the x lock, until T releases the S lock on a. This guarantees that the other transaction can read a, but cannot make any modifications to a when T releases the S lock on a.

Concurrency consistency issues