I. Introduction
Affairs has always been a mysterious and mysterious thing, which is very difficult to understand. It's not because of the difficulty of the transaction itself that it is difficult to understand, but because the concept of transaction is packaged in various ways, so that people are confused and confused. For example, various abstract concepts, consistency, persistence, atomicity, persistence, read uncommitted, read committed, repeatable read, serialization, Spring also abstracts the propagation properties of transactions, and the database itself has various locks , so we got dizzy. Today, let's take a look at affairs and see the essence of affairs under the gorgeous coat. This blog combines Shen Xun's sharing, plus some of my own summaries.
2. The final problem to be solved by transactions - "consistency"
Consistency is a noun. In fact, it should be understood as a verb here. Multiple participants have reached an agreement, reached a consensus, and did not argue with each other. It may be more abstract to say this, and give an example from life.
One day, Pharaoh and Pharaoh's wife went to the bank to withdraw money at the same time. Pharaoh checked the bank card account with 1W yuan, so he took it out. Suppose Lao Wang's wife and Pharaoh checked at the same time and saw that there was 1W yuan, So I clicked on the withdrawal, and finally found that there was no money to withdraw, so I had to argue, which was inconsistent.
Use a common phrase to describe the consistency of affairs: the participants in all affairs, what they see is what they get. In the above example, Lao Wang's wife saw that there was 1w on the card, but she couldn't get it, so she was about to argue. That's what strict conformance defines.
Let's analyze the above example in detail.
First, the concept of transaction unit is introduced. A transaction unit is the smallest unit that completes a specific business. The above example contains two transaction units. According to the normal timeline, if you want to avoid fussing, you should see the following execution sequence.
But the bullshit happened, the two transaction units were parallelized, and the following execution sequence appeared. Transaction unit 2 is shifted to the left, in parallel with transaction unit 1.
The above scenario seems familiar, in fact, it is exactly the same as what thread safety describes, "Understanding Java Concurrency and Thread Safety in an Article" . into the following code:
public class Consistency {
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
int balance = query();// 查询余额
if (balance > 0) {
drawingOutCash();// 取出现金
}
} catch (Exception e) {
} finally {
lock.unlock();
}
}
}For strong consistency, all transaction units are executed serially, which is SERIALIZABLE in the transaction isolation level, which leads to the transaction isolation level.
3. Transaction isolation level
Strong consistency, all transaction units must be executed serially, which is the SERIALIZABLE (serialization) in the isolation level, but the performance of this system is conceivable and almost unusable, so the requirements for locks need to be relaxed, so Other isolation levels emerged. The isolation level of the transaction is the destruction of consistency for performance reasons, and it appears to destroy consistency, not to maintain consistency.
There are only four relationships between transaction units and transaction units: read-read, read-write, write-read, write-write
SERIALIZABLE (serialization)
To further improve performance, read-write locks appear, and there are two isolation levels: REPEATABLE_READ (repeatable read) and READ_COMMITED (read committed)
REPEATABLE_READ (repeatable read):
Read locks cannot be upgraded to write locks, so writes to shared resources cannot come in, so "read and read" can be parallelized, and phantom reads will occur, because at this level, the table will not be regarded as a Shared resources, so you can insert
READ_COMMITED (read committed):
The read lock can be upgraded to a write lock, then when the shared resource is being read, it can be upgraded to a write lock by a write request, so that "read-read" and "read-write" can be parallelized, so phantom reads and non-repeatable reads appear. etc. phenomenon
READ_UNCOMMITTED
Only write locks are added, and readers do not need to apply for locks, so that "read-read", "read-write", and "write-read" can all be parallelized, but "write-write" cannot be parallelized, so all writes are serial, so there are Dirty reads, non-repeatable reads, phantom reads, etc.
This is the truth of the transaction isolation level. The lower the transaction isolation level, the better the parallelism and the lower the consistency.
Four, one sentence summary
Transaction consistency is exactly the same as thread safety. To maintain consistency, two points need to be guaranteed: the visibility of shared variables and the sequentiality of code access in critical sections.
Happiness comes from sharing.
This blog is original by the author, please indicate the source for reprinting