Isolation level and propagation properties of Spring transactions

SpringBoot project start transaction: start class plus @EnableTransactionManagement annotation

Transaction method calls non-transaction method: https://blog.csdn.net/u010235716/article/details/90171802

1. Isolation level

1) DEFAULT (default) 
This is the default isolation level of a PlatfromTransactionManager, using the database default transaction isolation level. The other four correspond to the isolation level of JDBC.
2) READ_UNCOMMITTED (read uncommitted) 
This is the lowest isolation level of the transaction, which allows another transaction to see the uncommitted data of this transaction. This isolation level will produce dirty reads, non-repeatable reads and phantom reads. 
3) READ_COMMITTED (read committed) 
guarantees that data modified by one transaction can be read by another transaction only after it is committed, and another transaction cannot read the uncommitted data of the transaction. This transaction isolation level can avoid dirty reads, but non-repeatable reads and phantom reads may occur. 
4) REPEATABLE_READ (repeatable read) 
This transaction isolation level can prevent dirty reads and non-repeatable reads, but phantom reads may occur. In addition to ensuring that one transaction cannot read the uncommitted data of another transaction, it also guarantees non-repeatable reading.
5) SERIALIZABLE (serialization) 
This is the most expensive but most reliable transaction isolation level, and transactions are processed as sequential execution. In addition to preventing dirty reads and non-repeatable reads, phantom reads are also avoided. 

1. Propagation

1) required (REQUIRED) (default attribute)
If there is a transaction, the current transaction is supported. If there is no transaction, start a new transaction. 
When set to this level, a logical transaction domain is created for each method called. If the previous method has created a transaction, then the latter method supports the current transaction, and if there is no current transaction, the transaction will be re-established. 

2) Mandatory (MANDATORY)
supports the current transaction. If there is no transaction currently, an exception will be thrown. 
3) never (NEVER)
is executed in a non-transactional manner. If there is a transaction currently, an exception is thrown. 
4) not_supported (NOT_SUPPORTED)
performs the operation in a non-transactional manner. If there is a transaction currently, the current transaction is suspended. 
5) requires_new (REQUIRES_NEW)
creates a new transaction. If there is a transaction currently, suspend the current transaction. 
6) supports (SUPPORTS)
supports the current transaction, if there is no transaction currently, it is executed in a non-transactional manner. 
7) nested (NESTED)
supports the current transaction, adds a Savepoint point, and commits or rolls back synchronously with the current transaction. 
A very important concept of nested transactions is that inner transactions depend on outer transactions. When the outer transaction fails, the actions made by the inner transaction will be rolled back. The failure of the inner transaction operation will not cause the rollback of the outer transaction. 
The difference between PROPAGATION_NESTED and PROPAGATION_REQUIRES_NEW:
they are very similar, they are like a nested transaction, if there is no active transaction, a new transaction will be started.

Three, there are several spring scopes

Singleton:  There is only one object instance in Spring's IoC container, and all references to this object share this instance . The Spring container will only create a unique instance of the bean definition. This instance will be stored in the cache, and all subsequent requests and references to the bean will return the object instance in the cache. In general, stateless beans are used The scope.

Prototype: A new instance will be created every time the bean is requested. In general, stateful beans use this scope.
request: Each http request will have its own bean instance, similar to prototype.
Session: In an http session, a bean definition corresponds to a bean instance.
Global session: In a global http session, a bean definition corresponds to a bean instance. Typically, it only works when portlet context is used.

Secondly, the default scope of spring (bean scope) is singleton

 

Will the transaction of the non-transactional method call the transactional method take effect?

No, because the non-transactional method in the same class calls the method with the current object instead of the proxy object generated by spring, which will cause the transaction to fail.

Solution:

1. Use AopContext.currentProxy() to get the proxy object

2. Annotate the springboot startup class: @EnableAspectJAutoProxy(exposeProxy = true)

 

 

 

Guess you like

Origin blog.csdn.net/qq_43037478/article/details/114868870