what is transaction
A transaction is a sequence of operations to access the database. The database application system completes access to the database through transaction sets. The correct execution of transactions causes the database to transition from one state to another .
Transactions must comply with the ACID principles established by ISO/IEC. ACID is the abbreviation of atomicity, consistency, isolation, and durability. The meaning of these four states is:
1. Atomicity
That is, they are indivisible, and either all transactions are executed or none are executed. If all sub-transactions of the transaction are submitted successfully, all database operations are submitted and the database status changes; if any sub-transaction fails, the database operations of other sub-transactions are rolled back, that is, the database returns to the state before the transaction was executed. No state transition occurs
2. Consistency
The execution of a transaction converts the database from one correct state to another correct state
3. Isolation
Before the transaction is correctly committed, the transaction's changes to the data are not allowed to be provided to any other transaction, that is, before the transaction is correctly committed, its possible results should not be displayed to other transactions.
4. Durability
After a transaction is submitted correctly, its results will be stored in the database forever. Even if there are other failures after the transaction is submitted, the results of the transaction will be saved.
The role of affairs
Transaction management is crucial for enterprise-level applications. It ensures that every user operation is reliable, and even if abnormal access occurs, the integrity of the background data will not be destroyed. Just like a bank's automatic teller machine (ATM), an ATM can usually serve customers normally, but it is inevitable that it will encounter a sudden failure during operation. At this time, the transaction must ensure that the operation of the account before the failure is normal. It takes effect as if the user has never used the ATM machine just now, so as to ensure that the interests of both the user and the bank are not damaged.
Problems caused by concurrent transactions
For example, transaction A and transaction B manipulate the same resource. Transaction A has several sub-transactions, and transaction B also has several sub-transactions. In the case of high concurrency, various problems will occur between transaction A and transaction B. . "Various problems" can be summarized into five main types: the first type of lost updates, the second type of lost updates, dirty reads, non-repeatable reads, and phantom reads. Among the five types, the first type of lost updates and the second type of lost updates are not important. I won’t talk about them anymore. Let’s talk about dirty reads, non-repeatable reads and phantom reads.
1. Dirty reading
The so-called dirty read means that transaction A reads the data that transaction B has not yet submitted . For example, when withdrawing money from a bank, transaction A starts the transaction, then switches to transaction B, and transaction B starts the transaction --> takes away 100 yuan, then switches Returning to transaction A, what transaction A reads must be the original data in the database, because transaction B took away 100 yuan and did not submit it. The account balance in the database must still be the original balance. This is a dirty read.
2. Non-repeatable reading
The so-called non-repeatable read means that a certain data is read twice in a transaction, and the read data is inconsistent . Let's take the example of withdrawing money from the bank. Transaction A opens the transaction-->finds out that the bank card balance is 1,000 yuan. At this time, it switches to transaction B. Transaction B opens the transaction-->transaction B withdraws 100 yuan-->submit in the database. The balance becomes 900 yuan. At this time, switch back to transaction A. Transaction A checks again and finds that the account balance is 900 yuan. In this way, for transaction A, the account balance data read twice in the same transaction is inconsistent, which is impossible. Read repeatedly.
3. Phantom reading
The so-called phantom read refers to the discovery of unoperated data during operations within a transaction . For example, for student information, transaction A opens the transaction-->modifies the check-in status of all students on the day to false. At this time, it switches to transaction B, and transaction B opens the transaction-->transaction B inserts a piece of student data. At this time, it switches back to transaction A, and the transaction When A submitted, he found a piece of data that he had not modified. This was a phantom read, just like a hallucination. The premise for phantom reading to occur is that there are insertion and deletion operations in concurrent transactions.
transaction isolation level
Transaction isolation level was born to solve the above problems. Why is there a transaction isolation level? Because the higher the transaction isolation level, the fewer problems will occur under concurrency, but at the same time, the performance consumption will be greater . Therefore, many times a trade-off must be made between concurrency and performance. . Therefore, several transaction isolation levels have been established so that different projects can choose the appropriate transaction isolation level according to the concurrency conditions of their own projects. For concurrency problems that may occur outside the transaction isolation level, compensation is made in the code.
There are 4 transaction isolation levels, let’s take a look:
1、READ_UNCOMMITTED
Read uncommitted, that is, you can read data that has not been committed. Therefore, it is obvious that this level of isolation mechanism cannot solve any of dirty reads, non-repeatable reads, and phantom reads, so it is rarely used.
2、READ_COMMITED
Read committed, that is, you can read the data that has been submitted. It can naturally prevent dirty reads, but it cannot limit non-repeatable reads and phantom reads.
3、REPEATABLE_READ
Repeated reading means adding a lock after the data is read out, similar to "select * from XXX for update". It is clear that the data is read out for update, so a lock must be added to prevent others from modifying it. REPEATABLE_READ has a similar meaning. If a piece of data is read, and the transaction does not end, other transactions cannot modify the record. This solves the problems of dirty reads and non-repeatable reads, but the problem of phantom reads cannot be solved.
4、SERLALIZABLE
Serialization, the highest transaction isolation level, no matter how many transactions there are, all sub-transactions in another transaction can be executed only after running all sub-transactions in one transaction, thus solving the problems of dirty reads, non-repeatable reads and phantom reads. Problem
There are pictures on the Internet that list the concurrency problems solved by transaction isolation levels in table form:
It must be emphasized again that the higher the transaction isolation level is, the better. Setting the transaction isolation level higher means that means must be spent on locking to ensure the correctness of transactions, and the efficiency will be reduced. Therefore, the actual development There is often a trade-off between efficiency and concurrency correctness. Generally, it is set to READ_COMMITED. In this case, dirty reads are avoided and the concurrency is not bad. Later, other means are used to solve non-repeatable reads and phantom reads. Just read the question.
If you are using MySQL, you can use " select @@tx_isolation " to view the default transaction isolation level
View and modify transaction isolation levels
First, let’s explain several commands for viewing and modifying transaction isolation levels in MySQL:
- To view the transaction isolation level use select @@tx_isolation
- To modify the current session transaction isolation level, use SET session TRANSACTION ISOLATION LEVEL Serializable; (the parameters can be: Read uncommitted|Read committed|Repeatable read|Serializable)
- To modify the global transaction isolation level, use SET global TRANSACTION ISOLATION LEVEL Serializable; (the parameters can be: Read uncommitted|Read committed|Repeatable read|Serializable)
The transaction isolation level of the session has been modified. For example, in MyBatis, when getSqlSession() is used, it is only valid for the Session obtained this time; for example, the CMD command line is only valid for this window.
If the global transaction isolation level is modified, it will be effective for all subsequent sessions, and existing sessions will not be affected .