Propagation characteristics of Spring transactions

Spring transaction One is misinformation very broadly: one transaction method should not invoke another transaction method, otherwise two transactions will be generated. As a result, developers shackled in the design of transaction methods, fearing that they would step on a mine accidentally.

In fact, this is a misunderstanding of the spring transaction propagation mechanism, and spring's support for transaction control is described in the Transactiondefinition class, which has several important interface methods:

• int Getpropagationbehavior (): The propagation behavior of a transaction
• int Getisolationlevel (): The isolation level of the transaction
• int GetTimeout (): The expiration time of the transaction
• Boolean isreadonly (): the Read and write characteristics of the transaction.

Obviously, in addition to the propagation behavior of the transaction, other features of the transaction spring is done with the functionality of the underlying resources, and spring is nothing more than a proxy role. But the spread of the transaction is spring's ability to provide the developer with its own framework, the most precious gift that spring offers to developers, and misinformation's claim to tarnish the most beautiful aura of the spring transaction framework.

The so-called transaction propagation behavior is how transactions are propagated between these methods when multiple transactional methods are called each other. Spring supports 7 types of transactional propagation behavior:

• Propagation_required If there is currently no transaction, create a new transaction, if one is already in the transaction, add it to the transaction. This is the most common choice.
• Propagation_supports supports the current transaction and is executed in a non-transactional manner if no transaction is currently in use.
• Propagation_mandatory uses the current transaction, and throws an exception if there is no current transaction.
• Propagation_requires_new a new transaction, suspending the current transaction if a transaction is currently present.
• The propagation_not_supported executes the operation in a non-transactional manner, suspending the current transaction if a transaction is currently present.
• The propagation_never is executed in a non-transactional manner and throws an exception if a transaction is currently present.
• Propagation_nested executes within a nested transaction if a transaction is currently present. If there is currently no transaction, perform a similar operation as propagation_required.

Spring's default transactional propagation behavior is propagation_required, which is suitable for most situations. Assuming that Servivex#methodx () is working in a transactional environment (that is, it is enhanced by Spring transactions), assume that the following call chain exists in the program: Service1#method1 ()->service2#method2 () SERVICE3#METHOD3 (), then the 3 methods of these 3 service classes work in the same transaction through Spring's transaction propagation mechanism.

Propagation characteristics of Spring transactions