Mysql transaction and transaction isolation

1. Transaction features

Example: Checking Sheet and Savings Sheet

start transaction;

Select balance from checking where customer_id=12345;

Update checking set balance=balance-100 where customer_id=12345;

Update savings set balance=balance+100 where customer_id=12345;

Commit;

 

1.1 Atomicity

A transaction must be regarded as an indivisible minimum unit of work. All operations in the entire transaction are either completely committed successfully or all failed and rolled back. For a transaction, it is impossible to perform only a part of the operations, which is the transaction atomicity.

 

1.2 Consistency

The database always transitions from one consistent state to another consistent state. In the above example, consistency ensures that even if the system crashes between the execution of the third and fourth statements, there is no loss of $100 in the checking account, because the transaction is not committed in the end, so the changes made in the transaction are also will not be saved to the database.

 

1.3 isolation (isolation)

In general, changes made by one transaction are not visible to other transactions until they are finally committed. In the above example, when the third statement is executed and the fourth statement has not yet started, another account summary program starts to run, and the balance of the checking account it sees is not subtracted by 100 yuan. money.

Ps: The usual explanation, read uncommitted level

 

1.4 Durability

Once a transaction commits, its modifications are permanently saved to the database. Sincerely, even if the system crashes, the modified data will not be lost. Persistence is a somewhat vague concept because there are actually many different levels of persistence. Some persistence strategies provide very strong security guarantees, while others do not. And it's impossible to have a strategy that can achieve 100% durability guarantees (if the database itself can achieve true durability, how can backups increase durability?).

 

2. Transaction isolation level

Set transaction isolation level command:

set Session | GLOBAL TRANSACTION ISOLATION LEVEL read uncommitted | read committed | repeatable read | serializable;

View the current transaction isolation level:

select @@tx_isolation;

 

2.1read uncommitted (read uncommitted)

At the read unCommitted level, modifications within a transaction, even if not committed, are visible to other transactions. Transactions can read uncommitted data, also known as dirty reads. This level can cause a lot of problems. In terms of performance, Read unCommitted is not much better than other levels, but it lacks many of the benefits of other levels. Unless there are really necessary reasons, it is generally rarely used in practical applications. .

 

2.2read committed

The default isolation level of most database systems is Read Committed (Mysql default is Repeatable Read).

Read Committed satisfies the simple definition of isolation mentioned earlier: at the beginning of a transaction, only the changes made by the committed transaction are "see". In other words, any modifications made by a transaction from the start until it is committed are invisible to other transactions. This level is sometimes called nonrepeatable, because executing the same query twice may yield different results.

 

2.3 repeatable read (repeatable read)

Mysql's default transaction isolation level

Repeatable Read solves the problem of dirty reads. At this level, the results of multiple reads of the same record in the same transaction are guaranteed to be consistent. However, in theory, the repeatable read isolation level still cannot solve the problem of another phantom read (Phantom Read). The so-called phantom read means that when a transaction reads records in a certain range, another transaction inserts new records in the range. When the previous transaction reads the records in the range again, it will Generates a Phantom Row. InnoDB and XtraDB storage engines solve the problem of phantom reads through Multiversion Concurrency Control (MVCC, Multiversion Concurrency Controller).

PS: InnoDB uses MVCC to support high concurrency, the default level is Repeatable Read, and the next-key locking strategy is used to prevent phantom reads. Gap locks allow InnoDB not only to lock the rows involved in the query, but also to lock the gaps in the index to prevent the appearance of phantom rows.

 

2.4serializable (serializable)

Serializable is the highest isolation level. It avoids the aforementioned phantom read problem by forcing transactions to be executed serially. Simply put, Serializable locks each row of data read, so it can cause a lot of timeouts and lock contention problems. This transaction isolation level is rarely used in practical applications. It is only considered when it is very necessary to ensure data consistency and no concurrency is acceptable.

Table 2-1: ANSI SQL transaction isolation levels

Isolation Level Dirty Read Possibility Unrepeatable Read Possibility Phantom Read Possibility Locked Read

read uncommittedYesYesYesNo

read committedNoYesYesNo

repeatable readNoNoYesNo

serializableNoNoNoYes

 

3. The effect of isolation level on locking

3.1 Read Uncommitted

Set the mysql global isolation level to read uncommitted:

set GLOBAL TRANSACTION ISOLATION LEVEL read uncommitted;

T1 event sequence T2

start transaction;

 

update account

set balance=balance-100

where userID=12345;

 

select balance 

from account

where userID=12345;

 

rollback; T1 and T2 begin.

T2 queries the balance in a user account, equal to 500

T1 subtracts 100 yuan from the balance of an account, and the query account balance is 400

T2 queries the user account balance again to be 400

T1 rolls back, making the second query result of T2 invalid start transaction;

 

select balance 

from account

where userID=12345;

 

waiting 00:00:30

 

select balance 

from account

where userID=12345;

 

commit;

 

When the transaction isolation level is read uncommitted,

1. Allow other tasks to read rows and tables that hold exclusive locks, that is, read uncommitted data changes.

2. Do not apply shared locks for the rows and tables being searched.

3. Any transaction modification performed by T2 acquires row, table exclusive locks, and blocks on table locks to be changed by the modification operation.

 

3.2 Read Committed

Set the mysql global isolation level to read committed:

set GLOBAL TRANSACTION ISOLATION LEVEL read committed;

 

 

4. Spring transaction propagation features

Propagation: The key property determines which method the proxy should add transactional behavior to. The most important part of such a property is the propagation behavior. The following options are available:

4.1PROPAGATION_REQUIRED

——Support the current transaction, if there is no current transaction, create a new transaction. This is the most common choice.

For example, the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, then since ServiceA.methodA has already started a transaction when ServiceA.methodA is executed, ServiceB.methodB is called at this time, and ServiceB.methodB sees that it is already running in ServiceA.methodA Inside the transaction, no new transaction is started. And if ServiceA.methodA runs and finds that he is not in a transaction, he will assign himself a transaction. This way, if an exception occurs in ServiceA.methodA or anywhere within ServiceB.methodB, the transaction will be rolled back. Even if the transaction of ServiceB.methodB has been committed, but ServiceA.methodA will be rolled back in the next fail, ServiceB.methodB will also be rolled back.

 

4.2PROPAGATION_SUPPORTS

Support the current transaction, if there is no current transaction, it will be executed in a non-transactional mode.

 

4.3PROPAGATION_MANDATORY

- Supports the current transaction, throws an exception if there is no current transaction.

That is, it must be run in a transaction, otherwise, he will throw an exception.

 

4.4PROPAGATION_REQUIRES_NEW

- Create a new transaction, if there is a current transaction, suspend the current transaction.

This is rather convoluted. For example, we design the transaction level of ServiceA.methodA to be PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB to be PROPAGATION_REQUIRES_NEW, then when ServiceB.methodB is executed, the transaction where ServiceA.methodA is located will hang, and ServiceB.methodB will start a new one Transaction, waits for ServiceB.methodB's transaction to complete before he continues to execute. The difference between him and the PROPAGATION_REQUIRED transaction is the degree of rollback of the transaction. Because ServiceB.methodB is a new transaction, then there are two different transactions. If ServiceB.methodB has been submitted, then ServiceA.methodA fails and rolls back, but ServiceB.methodB will not roll back. If ServiceB.methodB fails and rolls back, if the exception he throws is caught by ServiceA.methodA, the ServiceA.methodA transaction may still commit.

 

4.5PROPAGATION_NOT_SUPPORTED

- Execute the operation in a non-transactional manner, and suspend the current transaction if there is a current transaction.

For example, the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NOT_SUPPORTED, then when ServiceB.methodB is executed, the transaction of ServiceA.methodA is suspended, and he finishes running in a non-transactional state, and then continues ServiceA .methodA's transaction.

 

4.6PROPAGATION_NEVER

- Execute in a non-transactional manner, throwing an exception if there is currently a transaction.

Cannot run in a transaction. Assuming that the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NEVER, then ServiceB.methodB will throw an exception.

 

4.7PROPAGATION_NESTED

The key to understanding Nested is the savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW starts another transaction, which will be independent of his parent transaction, while Nested's transaction is dependent on his parent transaction, and his submission is to be submitted together with his parent transaction. . That is, if the parent transaction rolls back last, he will also roll back. And the nice thing about Nested affairs is that he has a savepoint.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326119853&siteId=291194637