>>> 4 isolation levels
There are four isolation levels for database transactions, from low to high: Read uncommitted, Read committed, Repeatable read, and Serializable. Moreover, dirty reads, non-repeatable reads, and phantom reads may occur during concurrent operations of transactions. The following examples explain their concepts and connections one by one.
Read uncommitted
Read uncommitted , as the name implies, means that a transaction can read data from another uncommitted transaction.
Example: The boss wants to pay the programmer, and the programmer's salary is 36,000 per month. But when the salary was paid, the boss accidentally pressed the wrong number, which was 39,000 per month. The money had already been transferred to the programmer's account, but the transaction had not been submitted. At this moment, the programmer went to check his salary for this month. I found that it was 3,000 yuan more than usual, and I thought I was very happy with the salary increase. But the boss discovered something was wrong in time, and immediately rolled back the transaction that was almost submitted, and changed the number to 36,000 before submitting.
Analysis: The actual programmer's salary this month is still 36,000, but the programmer sees 39,000. What he saw was the data before the boss submitted the transaction. This is dirty read .
So how to solve dirty read? Read committed! Read commit can solve the dirty read problem.
Read committed
Read commit , as the name implies, means that a transaction cannot read data until another transaction commits.
Example: A programmer takes a credit card to enjoy life (of course there is only 36,000 in the card), when he pays the bill (programmer affairs open), the billing system detects in advance that there are 36,000 in his card, at this moment! ! The programmer's wife has to transfer all the money out for household use and submit it. When the charging system is ready to deduct money, it checks the amount in the card again and finds that there is no money (of course, the second check of the amount has to wait for the transaction of the wife to transfer the amount to be submitted). The programmer will be very depressed, obviously Kari is rich...
Analysis: This is read commit. If a transaction performs an UPDATE operation on the data, the read operation transaction must wait for the update operation transaction to be committed before reading the data, which can solve the dirty read problem. But in this case, two identical queries within a transaction range return different data, which is non-repeatable read .
So how to solve the possible non-repeatable read problem? Repeatable read!
Repeatable read
Repeated reading means that when data is read (transaction is open), modification operations are no longer allowed
Example: A programmer takes a credit card to enjoy life (of course there is only 36,000 in the card), when he pays the bill (the transaction is opened, UPDATE modification operations of other transactions are not allowed), the charging system detects in advance that there are 36,000 in his card . At this time, his wife cannot transfer the amount. Then the payment system can be deducted.
Analysis: Repeated reading can solve the problem of non-repeatable reading. After writing here, one thing that should be understood is that non-repeatable read corresponds to modification, that is, UPDATE operation. But there may still be phantom reading problems. Because the phantom read problem corresponds to the INSERT operation, not the UPDATE operation.
When do phantom reads occur?
Example: A programmer spends 2,000 yuan on consumption one day, and then his wife checks his consumption record for today (full table scan FTS, wife affairs open), and sees that it is indeed 2,000 yuan. At that time, the programmer spent 10,000 yuan to buy a computer, that is, added a consumption record with INSERT, and submitted it. When the wife printed the programmer's consumption record list (submitted by the wife's affairs), she found that she had spent 12,000 yuan, and she seemed to have hallucinations. This is phantom reading .
So how to solve the phantom reading problem? Serializable!
Serializable serialization
Serializable is the highest transaction isolation level. At this level, transactions are executed in serial order, which can avoid dirty reads, non-repeatable reads, and phantom reads. However, this transaction isolation level is inefficient and consumes more database performance, so it is generally not used.
It is worth mentioning that the default transaction isolation level of most databases is Read committed, such as Sql Server, Oracle. Mysql's default isolation level is Repeatable read.
>>> 4 features
If a database claims to support transactional operations, then the database must have the following four characteristics:
(1) Atomicity
Atomicity means that all operations included in the transaction either succeed or fail and roll back. This is the same concept as the function of the transaction introduced in the previous two blogs. Therefore, if the operation of the transaction is successful, it must be fully applied to the database. If the operation A failure cannot have any effect on the database.
(2) Consistency
Consistency means that the transaction must change the database from one consistent state to another consistent state, that is to say, a transaction must be in a consistent state before and after execution.
Take the transfer as an example, assuming that the sum of the money of user A and user B is 5000, then no matter how the money is transferred between A and B, how many times the money is transferred, the sum of the money of the two users should be paid after the transaction is over. It is 5000, which is the consistency of the transaction.
(3) Isolation
Isolation means that when multiple users access the database concurrently, such as when operating the same table, the transactions opened by the database for each user cannot be interfered by the operations of other transactions, and multiple concurrent transactions must be isolated from each other.
That is to achieve such an effect: For any two concurrent transactions T1 and T2, from the perspective of transaction T1, T2 either ends before T1 starts, or starts after T1 ends, so that each transaction feels different. until other transactions are executing concurrently.
Regarding the isolation of transactions, the database provides various isolation levels, which will be introduced later.
(4) Durability
Persistence means that once a transaction is committed, the changes to the data in the database are permanent, even if the database system encounters a failure, the operation of committing the transaction will not be lost.
For example, when we use JDBC to operate the database, after submitting the transaction method, the user is prompted to complete the transaction operation. When our program is executed until we see the prompt, we can identify the transaction and submit it correctly. Even if there is a problem with the database at this time, we must Our transaction must be fully executed, otherwise it will cause us to see a major error that prompts that the transaction has been processed, but the database did not execute the transaction due to a failure.
—————————————————
Article reference:
https://blog.csdn.net/qq_33290787/article/details/51924963