This article will introduce the following concepts: mode of transmission services, transaction isolation level, spring affairs. In introducing the concept of a transaction will lead atomicity, transaction isolation level when introducing the concept would lead dirty reads and phantom read.
Affairs
What is a transaction?
The transaction is the beginning of the concept of the database, it is the unified series of operations as a whole, the series of operations at the same time either succeed or fail at the same time. A basic operation of the transaction are:
- Open affairs
- If an error occurs, roll back
- If no error occurs, the transaction is committed
Why have affairs?
When we deal with simple operations, such as an insert data, it will only get two results, either insert the success or failure of insertion, which corresponds to the code logic is very simple.
We call such operations are atomic.
But our business is often not as simple as just insert a data, a user might click on a button, we need to insert a piece of data, and delete data. Since each operation are likely to succeed and fail, at this time we have 2 ^ 2 = 4 cases, which under the program up trouble.
In order to facilitate programming (and to meet the actual business logic), we introduce the beginning of the transaction mechanism, the two operations in a single transaction, provided that the atoms of these two operations, so that much more convenient service processing of the .
Transaction isolation level
Above we talked about when the operation of the database will be used in the transaction, the next question is introduced: in the database, it will inevitably case of multiple transactions occur at the same time operating data, then a different set of database transaction isolation level, there will be different the results of data manipulation, classic dirty reads and phantom reads are also born here.
First given concurrent access, Fact Sheet under different transaction isolation level:
| Transaction isolation level | Dirty read | Non-repeatable read | Magic Reading |
|---|---|---|---|
| read uncommitted read uncommitted | meeting | meeting | meeting |
| read committed READ COMMITTED | will not | meeting | meeting |
| Repeatable Read repeatable read | will not | will not | meeting |
| serializable serialization | will not | will not | will not |
The higher the transaction isolation level can be seen, the fewer the problems, but the corresponding performance decreases, the following problems set forth several examples of different transaction isolation levels:
Uncommitted Read
When the transaction is set to read uncommitted isolation, the problem is most prone to dirty read. Read uncommitted means that the current transaction can read uncommitted data from other transactions: Suppose a father to his son to play live on, but had accidentally month 2000 tremor hit more than 1000 turned into 3000, when his son to shops consumption, balance inquiry when he more than 3,000. As the father of the transaction have not submitted, then immediately roll back the transaction, re-fight past 2000 the cost of living.
This time the balance is the son read dirty data, the cause is to read data other uncommitted transactions.
READ COMMITTED
As long as the transaction isolation level is set to READ COMMITTED dirty read can solve the above problem, he can ensure that the current transaction can only read data other matters that have been submitted. But reading submitted will face a new problem: non-repeatable read.
For example, his son took the card to store consumption, pay for the time (to open the current transaction), the system detects the card is only 500 yuan. This time father to his son turn the 2000 cost of living, when his son prepare deductions and then check balances discovery to 2,500 yuan (This query occurs after his father's transfer transaction commits)
In the same transaction, the value of the balance of his son read at different times is not the same, which is non-repeatable read problem. Want to solve this problem, the transaction isolation level is set to repeatable read
Repeatable read
In the case of repeatable read, the current transaction prohibits other transactions to update the data being operated on, this way, the father of the transfer transaction will wait until the end of his son after the account deductions, non-repeatable read from solving the problem.
But the next level a repeatable read problem may also occur called phantom reads, for example as follows: son out today consume 1,000 yuan, the father to see his son one day consumption records (open transaction), found that a total of 1,000 yuan. This time his son and consumption of 1,000 yuan (father of the transaction is still in progress), then print the son of the father of today's consumer records and found that somehow turned into a 2,000 yuan, more than a consumer record.
The current transaction like this in the course of the operation, due to the addition or deletion of data other matters, leading to the current transaction data operation suddenly increases or fewer cases, called phantom reads. We want to solve the phantom read, the need to upgrade the transaction isolation level serialization
Serialization
When the transaction isolation level is serialized, all transactions are executed serially, corresponding to the above example: the father to see the day when the consumer records, his son is not consumption. This way the problem can be resolved to bring transaction concurrency, but inefficient.
Spread
In the commonly used database Orcale default transaction isolation level is read committed, and Mysql default is repeatable read. In the Mysql InnoDB engine, although the transaction isolation level is repeatable read, phantom read but also can solve the problem, the principle behind this is to add locks gap between the data line, to prevent the insertion and deletion of data.
The specific choice of what kind of transaction isolation level depends on the specific business needs
Transaction propagation behavior
The propagation of the transaction is also very good understanding of the literally: disseminate want to happen is necessary to have two or more objects, and here refers to the two methods should be carried out in a transaction, A calls another method when a transaction transaction method B, another transaction method B how to run.
Spring has defined seven kinds of transaction propagation behavior (how to run the affairs Method B):
| Propagation behavior | meaning |
|---|---|
| PROPAGATION_REQUIRED | If no transaction creates a new transaction, if there is already a transaction, added to this transaction (which is the most common choice, but also the spread of the default behavior of the spring Affairs) |
| PROPAGATION_SUPPORTS | Support the current transaction, if no transaction is executed in a non-transactional way |
| PROPAGATION_MANDATORY | Use the current transaction, if no transaction, throw an exception |
| PROPAGATION_REQUIRES_NEW | New Transaction, if the current transaction exists, the current transaction suspension |
| PROPAGATION_NOT_SUPPORTED | Non-transactional way to perform an operation, if the current transaction exists, put the current transaction pending |
| PROPAGATION_NEVER | Performed in a non-transactional way, if the current transaction exists, an exception is thrown |
| PROPAGATION_NESTED | If the current transaction exists, it is executed within nested transactions. If no transaction is performed with a similar operation PROPAGATION_REQUIRED |
We usually most commonly used is PROPAGATION_REQUIRED, which is the spring of default propagation behavior of affairs, it can reasonably understand the derivation of other transaction propagation behavior.
For example, we currently have the following code:
@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
methodB();
// do something
}
@Transactional(propagation = Propagation.REQUIRED)
public void methodB() {
// do something
}- Suppose we perform methodA, not because of the current transaction, so he created a new business.
- When calling methodB in methodA, because methodA already exists in the transaction, so methodB eliminates the need to create a new transaction, added directly to methodA of affairs can be.
to sum up
- Transactions can make a series of different operations atomic. (Of course, the transaction includes four ACID properties, emphasis herein is in the initial introduction of atoms)
- Transaction isolation levels define the access rules for transactions concurrent operation.
- Transaction propagation behavior defines the transaction in the implementation of the method how to use transactions.
Reference article:
transaction isolation level: https: //www.cnblogs.com/ubuntu1/p/8999403.html
transaction propagation behavior: https: //blog.csdn.net/weixin_39625809/article/details/80707695
the propagation of transaction: https : //www.cnblogs.com/softidea/p/5962612.html