Chapter 2 offline concurrency and lock mechanism

Chapter 2 offline concurrency and lock mechanism

 

Source of offline concurrency

In web projects, offline concurrency is particularly serious. For example, if user a and user B Modify the r row of a table in the database at the same time and add the r row, there are two fields C1 and C2 respectively.

Modify the parameters as follows:

1 user a reads data R (C1, C2) to a's browser.

2. User B reads data R (C1, C2) to B's browser.

3. User A changes data to R (C1 ', C2) in the browser and updates the data to the database.

4. User B changes data to R (C1, c2') in the browser and updates the data to the database.

There are two problems in the above process. First, when step B modifies the data, the data in the database is inconsistent with that in B's browser. Second, if the program processes the changes in the fields updated in the database, the content of the r row in the database is (C1 ', C2') after the four steps above '), this is different from the idea of A or B (A thinks it is (C1 ', C2), B thinks it is (C1, C2 ')).

 

In the above process, A's modification to the database or B's modification to the database cannot be modified according to the latest database content, so it becomes offline. When both A and B perform the record R, it should be called offline.

 

The preceding environment is called offline concurrency.

 

So how can we solve the problems encountered in the offline concurrency process? We introduce the lock mechanism.

Lock Mechanism

The lock mechanism is to add a mutex lock to the data to be modified, and prevent data from being modified at the same time through the mutex lock. The locking mechanism is further divided into application environments.Optimistic lockAndPessimistic lock

 

Optimistic lock

Optimistic lock means that conflicts rarely occur. Therefore, when data is modified, the modified basic data is compared with the data in the database. If the data is the same, the modified data is changed, otherwise, you are prompted to reload the changed data in the database.

Implementation Method 1: Use the where condition during update to compare all the data obtained from the previous query in the where tag. If the data in the database does not change, update can be updated to the content. Otherwise, the update statement cannot be updated to the content. You can determine whether the update is successful Based on the update return value.

Implementation Method 2: append a special field in each table, whose type is timestamp. During each update, compare whether the values of this field are consistent. If they are consistent, update the field, at the same time, this field is updated to the current time. Otherwise, the data has changed. This can also be implemented using update and where.

 

Pessimistic lock

The pessimistic lock refers to the data to be modified. The data is locked when it is read. Other users determine whether the data is locked when preparing to modify and reading the data, to determine whether to perform the read operation before the modification.

Implementation Method:

A lock table is usually created in a database. The fields in the table include, indicating, unique index, time, and user information.

When you prepare to modify the read data, you must first determine whether the lock table contains the data you want to read.

If it does not exist, add a record to the lock table to record the row of data in the table to be modified. If it exists, determine whether the time field times out.

If timeout occurs, update the time field of this record in the lock table.(Necessary measures to prevent deadlocks)

If the record exists and does not time out, it indicates that the record is being modified by another user, and the concurrent message is returned.