7 Kinds of propagation behavior of spring-affairs

Specifying spring transaction propagation behavior at the code level indicates the scope of control for the transaction.

7 Kinds of propagation behavior of spring transaction:

1) propagation_required, the default spring transaction propagation level, if a transaction already exists in the context, is added to the transaction execution, and if no transaction exists in the current context, the new transaction executes. So this level is usually enough to handle most business scenarios.

2 Propagation_supports, if there is a transaction in the context, the transaction join transaction is supported, and if there is no transaction, it is performed in a non transactional manner. Therefore, not all the packages in the Transactiontemplate.execute code will have transaction support. This is usually used to deal with Non-core business logic operations that are not atomic. Less application scenarios.

3) Propagation_mandatory (coercion), the transaction requirement context in this level must have a transaction, or it will throw an exception. Configuring the propagation level of this method is effective in controlling the context call code omission to add transaction control to the guarantee means. For example, a piece of code cannot be invoked alone, but once invoked, it must have a transaction involved, and the propagation level can be used.

4) Propagation_requires_new, a new transaction is created each time, and the transaction in the context is suspended, and the context transaction resumes execution after the current new transaction completes.

This is a very useful level of communication, to give a scenario: now there is a 100 red envelopes to send the operation, before sending, to do some system initialization, verification, data recording operations, and then send 100 red envelopes, and then record send log, send log request 100% Accurate, if the log is inaccurate, Then the entire parent transaction logic needs to be rolled back.
How to deal with the whole business needs? It is through this propagation_requires_new level of transaction propagation control can be done. A child transaction that sends a red envelope does not directly affect the commit and rollback of the parent transaction.

5 propagation_not_supported, the current level is characterized by the existence of transactions in the context, then suspend the transaction, execute the current logic, and then restore the transaction of the context.

What is the benefit of this level? can help you reduce the likelihood of a transaction. We know that the larger a transaction, the more risk it will have. So in the process of dealing with the transaction, make sure to narrow the scope as far as possible. For example, a piece of code, is every logical operation must be invoked, such as a loop 1000 times a non-core business logic operation. Such code, if wrapped in a transaction, is bound to cause too much business, resulting in some difficult to consider the abnormal situation. So the level of communication for this transaction is useful. Use the current level of the transaction template to pick up on it.

6 Propagation_never, the transaction is more stringent, the above one transaction propagation level is only not supported, there is a transaction hangs, and Propagation_never propagation level requirements context can not exist transactions, once there is a transaction, throw runtime exception, Force stop execution. This level of life and business has a grudge.

7 propagation_nested, literally also known, NESTED, nesting level transactions. The propagation level feature is that if a transaction exists in the context, the nested transaction executes, and if no transaction exists, the new transaction is created.

So what is a nested transaction? Many people do not understand, I have read some blogs, are some understanding of the deviation.

Nesting is a child transaction set that executes in a parent transaction. A child transaction is part of a parent transaction, before the child transaction is entered, the parent transaction establishes a rollback point, called save points, and executes the child transaction, which is also part of the parent transaction, and then the child transaction executes and the parent transaction continues. The point is that save points. See a few questions to understand:

What happens if a child transaction is rolled back.

The parent transaction rolls back to the save point that was established before entering the child transaction, and then tries other transactions or other business logic, and the operation before the parent transaction is not affected and is not automatically rolled back.

What happens if the parent transaction rolls back.

The parent transaction is rolled back and the child transaction is also rolled back. Why, because child transactions are not committed until the end of the parent transaction, and we say that the child transaction is part of the parent transaction. So:

What happens when a transaction is committed.

The parent transaction commits first, then the child transaction commits, or the child transaction is committed first, and the parent transaction is resubmitted. The answer is the second case, or the sentence, the child transaction is part of the parent transaction and is submitted uniformly by the parent transaction.

Spring Configuration declarative Transactions:

* Configure DataSource
* Configuration transaction Manager
* The propagation characteristics of the transaction
* Those classes those methods use the transaction

In the spring configuration file, there are always three components in the transaction configuration, namely the DataSource, TransactionManager, and proxy mechanisms, regardless of the configuration, the general change is only the agent mechanism of this part.

DataSource, TransactionManager These two parts only according to the data access mode changes, such as using hibernate for data access, DataSource is actually sessionfactory, The implementation of TransactionManager is Hibernatetransactionmanager.

Depending on the agent mechanism, there are several different ways to configure the spring transaction:

The first way: Each bean has an agent

The second way: all beans share a proxy base class

The third way: using interceptors

Fourth: Interceptors configured using the TX tag

The fifth way: full annotation

Note the point:

1. Spring's transaction boundary starts before invoking the business method, which executes a commit or rollback after the business method has been executed, depending on whether the runtime exception is thrown.