A detailed description of the propagation behavior and isolation level of spring transactions

There are 7 propagation behaviors and 4 isolation levels for a transaction on spring.

I. The conduct of the Communication of affairs

@Transactional (readOnly = false, Rollbackfor = Exception.class)

@Transactional (readOnly = false, Rollbackfor = exception.class, propagation = propagation.required,timeout=30)

1, propagation_required: If there is no transaction, create a new transaction, if present, join the transaction (such as not specified propagation behavior

Propagation, default is ropagation_required).

2. Propagation_supports: Supports the current transaction, if no transaction is currently performed in a non-transactional manner.
3, Propagation_mandatory: Use the current transaction, if there is no transaction at present throws an exception.
4. Propagation_requires_new: Creates a new transaction and suspends the current transaction if there is a transaction currently in place.
5. Propagation_not_supported: Executes the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.
6. Propagation_never: Executes in a non-transactional manner and throws an exception if the current transaction is present.

7. propagation_nested: Executes within a nested transaction if there is currently a transaction, and performs an operation similar to propagation_required if no transaction is currently present.

Second, isolation level (transaction isolation):
1, Serializable: The strictest level, the transaction serial execution, the resource consumes the most;
2. Repeatable READ: Ensures that a transaction does not modify data that has been read by another transaction but not committed (rolled back). "Dirty reads" and "non-repeatable reads" are avoided, but more performance losses are incurred.
3. Read COMMITTED: The default transaction level for most mainstream databases ensures that one transaction does not read to another data that has been modified but not committed by a parallel transaction, avoiding "dirty reads". This level applies to most systems.
4, READ UNCOMMITTED: Ensure that the read process will not read illegal data. The isolation level is a concurrency problem that handles multiple transactions.
We know that parallelism can improve the throughput and efficiency of the database, but not all concurrent transactions can run concurrently, which requires viewing the serializable condition of the database textbook.
There is no elaboration here.
The first thing we say is that there are 3 things that might not be pleasing in the concurrency.
1:dirty reads--read dirty data. In other words, the uncommitted (and still cached) data for transaction A is read by transaction B, and if transaction a fails to roll back, the data read by transaction B is wrong.
2:non-repeatable reads--data cannot be read repeatedly. For example, the value of reading data-total-two places in transaction a. At the first reading, total is 100, then transaction b changes the total data to 200, and transaction a reads again, and the result is that total turns out to be 200, causing transaction a data chaos.
3:phantom reads--Phantom reads the data, which is similar to non-repeatable reads and is also a problem that is inconsistent with multiple reads in the same transaction. But non-repeatable reads is inconsistent because the data set he wants to take is changed (such as total data), but the inconsistency of the data that Phantom reads to read is not a change in the data set that he wants to read, but a change in his conditional data set. For example, select Account.id where account.name= "ppgogo*", the first time to read 6 eligible IDs, the second time, because transaction B to the name of an account from "DD" to Change to "Ppgogo1", As a result, 7 data were taken out. Dirty reads non-repeatable reads Phantom reads
Serializable not going to be
Repeatable READ will not be
READ COMMITTED will not be
Read UNCOMMITTED will be




Third, readOnly
The readonly flag in the transaction attribute indicates that the corresponding transaction should be optimized for read-only transactions.


This is one of the most optimized tips. In some cases, some transaction strategies can have a significant optimization effect, such as avoiding dirty checking (attempting to "refresh") when using the Object/relational mapping tool (such as Hibernate or TopLink).


D. Timeout


There is also an option to define a value of "timeout" in the transaction properties, specifying a transaction timeout of several seconds. In JTA, this is simply passed to the transaction coordinator of the Java EE server and is interpreted accordingly.

For the design, transactions are best independent, if the nesting will pay attention to the location of the problem, find the root of the problem to solve the problem!

A detailed description of the propagation behavior and isolation level of spring transactions