A detailed explanation of spring transactions

first, the propagation properties of spring transactions
Propagation (propagation property)
required– supports the current transaction and creates a new transaction if there is no current transaction. This is the most common choice.

//调用methodA的时候如果没有事务将开启事务，这时候再调用methodB的时候发现已经有事务，此时methodB会加入到methodA的事务中，无论methodA和methodB中任何一个地方出现异常都会回滚事务，例如：methodB方法已经提交，//但是methodA出现异常回滚，methodB方法也会跟着回滚@transactional methodA(){  ServiceB.methodB(); }}@transactionalServiceB{methodB(){}}

supports– supports the current transaction and is executed in a non-transactional manner if no transaction is currently in use.
The mandatory– supports the current transaction and throws an exception if there is no current transaction.
requires_new– a new transaction, suspending the current transaction if a transaction is currently present.

servicera{//When executing to MethodB, MethodA's transaction will be suspended, MethodB will start a new transaction, and the MethodA transaction will be executed when the MethodB execution is complete . //Due to two transactions, MethodA, METHODB transaction rollback does not affect each other @Transactional (propagation = propagation.required)  MethodA() {ServiceB. MethodB(); }}@Transactional (propagation = propagation.requires_new)serviceb{ MethodB (){}} The above two examples are all transaction calls between service, and the following is a call inside the same service method: servicec{//Service internal call if the MethodA transaction propagation property overrides the MethodB transaction propagation property, even if MethodA no transaction overwrites and ignores the METHODB transaction, the entire method runs without a transaction //Description: MethodB equivalent to a section of code within the MethodA two methods there is no transaction propagation, if the MethodB throws an exception is handled in the MethodA method, it is equivalent to the entire method of the exception has been processed, no transaction rollback MethodA (){@transactional//default propagation=required MethodB() {} }}

The not_supported– executes the operation in a non-transactional manner, suspending the current transaction if a transaction is currently present.
The never– is executed in a non-transactional manner and throws an exception if a transaction is currently present.
nested– nested things.
Propagation. Required and propagation.requires_new are often used to control the nesting of transactions
For example:

servicea{//MethodB after failure METHODC will continue to execute , three method transaction commits do not affect each other  @transactional (propagation = propagation.required)   MethodA  () { ServiceB .methodb   (); Servicec.methodc  (); }}@transactional (propagation = Propagation.REQUIRES_NEW)  serviceb  { methodb ()  {}}< Span class= "Hljs-at_rule" >@transactional (propagation = propagation.requires_new)  servicec  { methodc ()  {}} 

second, the isolation level of spring transactions
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.
We'll start by talking about 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's inconsistency was because the data set he was trying to get was changed (like total data), but the inconsistency of the data that Phantom reads was reading was not the change in the dataset he was reading, but the change in his conditional data set.

A detailed explanation of spring transactions