Spring transaction propagation properties and isolation level __ Transaction ISOLATION LEVEL

Reproduced from: https://www.cnblogs.com/jimmy-muyuan/p/5722708.html 1 propagation properties of Transaction (propagation)

1) REQUIRED, this is the default property

Support A current transaction, create a new one if none exists.
If there is a transaction, the current transaction is supported. If there is no transaction, a new transaction is opened.
When this level is set, a logical transaction domain is created for each method that is called. If the previous method has created a transaction, the following method supports the current transaction, and if no transaction is currently in place, the transaction is re-created.
As shown in the figure:

2) Mandatory

Support a transaction, throw an exception if none exists. Supports the current transaction and throws an exception if no transaction is currently present.

3) NEVER

Execute non-transactionally, throw an exception if a transaction exists.
Executes in a non transactional manner and throws an exception if there is a current transaction.

4) not_supported

Execute non-transactionally, suspend the current transaction if one exists.
Performs an operation in a non transactional manner, suspending the current transaction if there is currently a transaction.

5) Requires_new

Create a new transaction, suspend the current transaction if one exists.
Creates a new transaction and suspends the current transaction if there is currently a transaction.
As shown in the figure:

6) SUPPORTS

Support A current transaction, execute non-transactionally if none exists.
Supports the current transaction, which is performed in a non transactional manner if there are currently no transactions.

7) NESTED

Execute within a nested transaction if a transaction exists, behave like propagation_required else.
Supports current transaction, adds new savepoint point, commits or rolls back synchronously with current transaction.
A very important concept of nested transactions is that the inner transaction depends on the outer transaction. When the outer transaction fails, the actions of the inner-level transactions are rolled back. The failure of the inner transaction operation does not cause the rollback of the outer transaction.

Note: The difference between propagation_nested and propagation_requires_new

They are very similar and are like a nested transaction, and if there is no active transaction, a new transaction will be opened. With Propagation_requires_new, the inner transaction and the outer transaction are like two separate transactions, and the outer transaction cannot be rolled back once the inner transaction has been committed. Two transactions do not affect each other. Two transactions are not a true nested transaction. It also requires the support of the JTA transaction manager.
When using propagation_nested, the rollback of the outer transaction can cause a rollback of the inner transaction. The exception to the inner transaction does not result in the rollback of the outer transaction, which is a true nested transaction. 2 Isolation levels for transactions (isolation level)

1 First explain the three kinds of cases caused by transaction concurrency

I. Dirty reads dirty reading
A transaction is in the process of updating the data. However, the update has not yet been committed, and another transaction is also manipulating the set of data and reading data that was not committed by the previous transaction, and if the previous transaction failed to roll back, the latter transaction read the error data, causing dirty reads.

Ii. non-repeatable reads cannot be read repeatedly
A transaction reads the same data more than once, and when the transaction is not finished, the data was also manipulated by another transaction, and the data was updated by the second transaction between two times of the first transaction, so that the first transaction was read two times before and after it, resulting in a non repeatable read.

Iii. Phantom reads phantom reading
The first data is being queried for data that meets a certain condition. At this point, another transaction inserted a qualifying data, the first transaction in the second query to meet the same criteria data, found that a previous query when the data is not, as if the illusion, this is the Phantom reading.

Note: The difference between non repetition and phantom reading
Non-repeat reading means that the same query takes place more than once in the same transaction, and a different result set is returned at a time when the other submission transaction is modified or deleted. (A transaction rereads data It has previously read and finds that another committed transaction has or modified th E data. )

Phantom reading means that the same query takes place multiple times in the same transaction, and a phantom read occurs each time a different result set is returned due to an insert operation done by other commit transactions. (A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another Committ Ed transaction has inserted additional rows that satisfy the condition. )

On the surface, the difference lies in the fact that non repetitive reads can see the modification and deletion of other transaction submissions, and the Phantom can see the inserts that other transactions commit.

2) Default (defaults)
This is a Platfromtransactionmanager default isolation level that uses the default transaction isolation level of the database. The other four is corresponding to the isolation level of JDBC

3) read_uncommitted (read not submitted)
This is the lowest isolation level for a transaction, allowing another transaction to see uncommitted data for this transaction. This isolation level produces dirty reads, no repeat reads, and Phantom reads.

4) read_committed (read submitted)
Guarantees that a transaction can be modified before it is read by another transaction. Another transaction cannot read data that is not committed by the transaction. This transaction isolation level prevents dirty reads from appearing, but may occur with no repeatable reads and Phantom reads.

5) Repeatable_read (Repeatable Read)
This transaction isolation level prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur. In addition to ensuring that one transaction cannot read data that is not committed by another transaction, it also guarantees that it is not repeatable

6) SERIALIZABLE (serialized)
This is the highest-cost but most reliable transaction isolation level. Transactions are processed for sequential execution. In addition to preventing dirty reading, it is not repeatable to read, but also avoid phantom reading.

7 The isolation level solves problems caused by transaction parallelism
Dirty reads non-repeatable reads Phantom reads
Serializable, no, no, no.
Repeatable READ will not be
READ committed won't be able to
Read UNCOMMITTED will be

Introduction to the behavior of the dissemination of things:

@Transactional (propagation=propagation.required)
If there is a transaction, then join the transaction, if not, create a new one (by default)
@Transactional (propagation=propagation.not_supported)
Container does not open transaction for this method
@Transactional (propagation=propagation.requires_new)
Regardless of whether there is a transaction, create a new transaction, the original suspend, the new execution completed, continue to perform the old transaction
@Transactional (Propagation=propagation.mandatory)
Must be executed in an existing transaction, or throw an exception
@Transactional (Propagation=propagation.never)
Must be executed in a transaction that does not have an exception thrown (as opposed to propagation.mandatory)
@Transactional (Propagation=propagation.supports)
If the other bean calls this method and declares the transaction in the other bean, the transaction is used. If the other bean does not declare a transaction, it is not a transaction.

Things Timeout setting:
@Transactional (timeout=30)//default is 30 seconds

Transaction ISOLATION Level:
@Transactional (isolation = isolation.read_uncommitted)
READ UNCOMMITTED data (dirty reads and non-repeatable reads) basically not used
@Transactional (isolation = isolation.read_committed)
Read committed data (non-repeatable read and Phantom reads occur)
@Transactional (isolation = isolation.repeatable_read)
Repeatable reads (phantom reads occur)
@Transactional (isolation = isolation.serializable)
Serialization

MYSQL: Default to Repeatable_read level
SQL Server: Default to Read_committed

Dirty reads: One transaction reads the uncommitted update data for another transaction
Non-repeatable reads: The results returned by reading the same data multiple times in the same transaction are different, in other words,
Subsequent reads can read the updated data that has been committed by another transaction. Instead, repeatable reads are repeated in the same transaction
When reading data, it is guaranteed to be the same as read data, which means that subsequent reads cannot be read to another transaction that has been submitted for update data
Phantom reads: One transaction reads a committed insert data from another transaction

about nesting things

Maybe you don't know much about propagation_nested and feel the need to add it.
propagation_nested: Nested transaction type, which is relative to the six cases mentioned above (the above six should be called flat transaction types), for example, I now have a transaction mainly has a few parts:
1, from a user account inside the minus 100 yuan of money
2, add 100 yuan to the B user account
This looks like a different transaction than before, so now I have a special request is that a user has 3 accounts, B users have 2 accounts, now my request is as long as a user's 3 account any one minus 100 yuan, Add 100 yuan to any of the two accounts of User B.
Once you have this requirement, the nested transaction type is perfect for you. We can understand this,
one: Will "from a user account minus 100 yuan" and "to B user account inside the increase of 100 yuan" we temporarily think is a transaction operation
Two: Reduce the money in any account from a user's 3 account as "Subtract 100 yuan from a user account" "The sub-transaction of this level of transaction (second level transaction), the same as the back of the savings as another level two transactions.
Question one: When level two transactions are rollback level will not be rollback.
The answer is no, the second level of business rollback only for themselves.
Question two: When will this level of transaction commit, and when would it be rollback?
We mainly look at the situation in level two, when all level two transactions are commit and the first-level transaction does not fail, and the entire transaction is a successful transaction, the whole transaction is commit.
when any second level transaction is not commit, the entire transaction is failed and the entire transaction is roolback.
Take the example above to illustrate it. If I am in A's three accounts in the operation of the money reduction is the second level of business to rollback, that is, 3 of the account has not lost money success, the whole business will fail to be rollback. If a user account has three accounts which can be deducted and the B user's two accounts have an account that can increase the money, the whole business will be commit if it succeeds.
Look at the above example seems to be not very deep, look at this situation (a user's 3 accounts are credit lines, that is, can be overrun, but the amount of overruns are limited). But the principle is the same, the simple point is better to say a little, wish you good luck.