MySQL transaction isolation level and spring Transaction transaction propagation

What is the ACID principle of transactions?

1. Atomicity: The smallest and indivisible. Either all execute or none.
2. Consistency (consistency): the execution of the transaction makes the database from one correct state to another correct state
3. Isolation (isolation): When each transaction is executed synchronously, the data obtained is not affected by other transactions.
4. Durability: After the transaction is committed, the result is always stored in the database.

What are the problems with concurrent transactions?

1. Dirty read: Transaction A reads uncommitted data of transaction B.
2. Non-repeatable read: A certain data has been read twice in the same transaction, but the data read is inconsistent.
3. Phantom read: A certain data is read twice in the same transaction, and the record that was not found in the previous query (specifically refers to the newly inserted row) is queried in the latter.
4. Update loss: Divided into a type of update loss and a second type of update loss. One category: Rollback is lost. The second category: Loss of coverage update. That is, the record modified later will overwrite the record modified before. (Add exclusive lock to solve)

What are the isolation levels of mysql transactions?

1. DEFAULT: The default isolation level (REPEATABLE-READ)
2. READ_UNCOMMITTED: Read has not been submitted. Able to read uncommitted data of other transactions (there will be concurrency issues)
3. READ_COMMITTED: Read has been submitted. Able to read data submitted by other transactions. (RC for short. Dirty reading can be solved, but there will be non-repeatable reading and phantom reading problems)
4. REPEATABLE_READ: Repeat reading. (Referred to as RR. It can solve dirty reads and non-repeatable reads, but there will be phantom reading problems)
5. SERLALIZABLE: serialization. No matter how many transactions are executed one by one. (Can solve all problems, but there will be performance problems, equivalent to single-threaded)

 

How to solve the problem of missing updates:

  Use row lock (Record Lock): lock the index record, the key is locked

(1) Pessimistic lock (assuming that there is a high probability of update loss, lock it at the beginning, but pay attention to the deadlock problem )

     1. Add a shared lock: select …… lock in share model;

     Shared locks are also called read locks (S locks). Indicates that this transaction is readable and writable, but other transactions are readable and not writable.

     2. Add exclusive lock: select …… for update;

    Exclusive lock is also called write lock (X lock). Indicates that this transaction is readable and writable, but other transactions are not readable or writable.

(2) Optimistic locking (assuming that there is a small probability of update loss, and lock again before the last step of the update)

   Implementation method: Add a column of timestamp type fields to the table, and record the latest time for each update or insert.

When the data is modified, the query condition is accompanied by a timestamp type field. For example: where id=1 and lastUpdateTime='2020-10-12 11:15:03'. When the number of affected rows returned is 0, it means that this modification has failed, prompting the user that the operation has expired.

 

How to solve the phantom reading problem:

  Exclusive lock

 

mysql query isolation level:

1. View the current session isolation level

select @@tx_isolation; (Before mysql version 8.0)

select @@transaction_isolation (mysql version 8.0 or later)

2. View the current isolation level of the system

select @@global.tx_isolation;

3. Set the current session isolation level

set session transaction isolatin level repeatable read;（参数可以为：Read uncommitted|Read committed|Repeatable read|Serializable））

Only valid for the current session

4. Set the current isolation level of the system

set global transaction isolation level repeatable read;

All subsequent sessions are valid, and the existing sessions will not be affected

 

What are the types of spring Transaction transaction propagation behaviors?

1. PROPAGATION_REQUITRED: If there is no current transaction, create a new transaction. Join if there is a transaction currently (independent of the parent transaction, if the parent transaction rolls back does not affect the child transaction) . (Commonly used)
2. PROPAGATION_NESTED: If there is no current transaction, create a new transaction. If there is a transaction currently, it is executed within a nested transaction (depends on the parent transaction, if the parent transaction rolls back, the child transaction is also rolled back) . The key is savepoint
3. PROPAGATION_SUPPORTS: If there is no transaction currently, it is already running non-transactional. Join if there is currently a transaction. (If there is a parent transaction, the transaction will run, and if there is no transaction, it will run)
4. PROPAGATION_MANDATORY: throw an exception if there is no transaction currently. Join if there is currently a transaction. (He can only be called by the parent transaction. Otherwise, he will throw an exception)
5. PROPAGATION_REQUITRED_NEW: Create a new transaction regardless of whether there is a transaction currently. ( The difference between the transaction and PROPAGATION_REQUIRED is the degree of rollback of the transaction. If the child transaction is abnormal, the parent transaction will still be committed after being captured )
6. PROPAGATION_NOT_SUPPORTED: Run as a non-transactional. If there is a transaction currently, the current transaction is suspended. (Suspend the parent transaction, and then execute the parent transaction after the child transaction is executed as a non-transaction)
7. PROPAGATION_NEVER: Run as a non-transactional. If there is currently a transaction, an exception is thrown. ( He cannot be called by the parent transaction. Otherwise, he will throw an exception )