7 Kinds of propagation levels for spring transactions

propagation_required, the default spring transaction propagation level, which is characterized by the addition of transactions to the transaction if a transaction already exists in the context, and the new transaction execution if no transaction exists in the current context. So this level is usually sufficient to handle most business scenarios.

Propagation_supports, literally known, SUPPORTS, supported, the characteristic of this propagation level is that if a transaction exists in the context, the transaction is supported to join the transaction, and if there is no transaction, it is executed in a non-transactional manner. So, not all of the packages in the Transactiontemplate.execute code will have transactional support. This is often used to deal with non-core business logic operations that are not atomic in nature. Fewer scenarios.

Propagation_mandatory, there must be a transaction in the context of this level of transaction requirements, or an exception will be thrown! Configuring the propagation level of this mode is a guarantee of effective control context calling code omission to add transaction control. For example, a piece of code can not be called to execute alone, but once it is called, it must have the situation of the transaction to use this propagation level.

propagation_requires_new, you can literally know, new, each time you want to start a transaction, the propagation level is characterized by a new transaction being created each time, and the transaction in the context is suspended, and the context transaction is resumed after the execution of the current new transaction completes.

This is a very useful level of communication, to give a scenario: now there is a send 100 red envelopes operation, before sending, to do some system initialization, verification, data logging operations, and then send 100 red envelopes, and then record the sending log, send log request 100% accurate, If the log is inaccurate, the entire parent transaction logic needs to be rolled back.
How do you deal with your entire 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.


propagation_not_supported, this can also be literally known, not supported, is not supported, the current level is characterized by the existence of transactions in the context, the transaction is suspended, the execution of the current logic, the end of the transaction to restore the context.

What are the benefits of this level? can help you to minimize the likelihood of a transaction. We know that the larger a transaction is, the more risk it has. Therefore, in the process of dealing with transactions, to ensure that the scope as narrow as possible. A piece of code, for example, must be called every time a logical operation, such as a non-core business logic operation that loops 1000 times. Such code, if wrapped in a transaction, is bound to cause the transaction to be too large, resulting in some difficult to consider well-rounded exceptions. So the level of communication at this level of the transaction comes in handy. Use the current level of the transaction template to pick it up.


Propagation_never, the transaction is more stringent, the above transaction propagation level is just not supported, there is a transaction suspended, and the Propagation_never propagation level requires the context of the transaction cannot exist, once the transaction, throw runtime exception, Force Stop Execution! At this level, life has a grudge against business.

propagation_nested, you can literally know, NESTED, nested-level transactions. The propagation level feature is that if a transaction exists in the context, the nested transaction executes, and if there is no transaction, the transaction is created.

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

Nesting is a child transaction that is executed in a parent transaction, a child transaction is part of a parent transaction, a rollback point is established by the parent transaction before the child transaction is entered, called Save Point, and then the child transaction is executed, and the execution of the child transaction is considered part of the parent transaction, and the child transaction execution ends and the parent transaction resumes execution. 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 actions before the parent transaction are not affected and are not automatically rolled back.

what happens if the parent transaction is rolled back?

The parent transaction is rolled back, and the child transaction is rolled back! Why, because the child transaction is not committed until the end of the parent transaction, we say that the child transaction is part of the parent transaction, and that is the truth. Then:

The submission of a transaction, what is the situation?

is the parent transaction committed first, then the child transaction commits, or the child transaction is committed first, and the parent transaction commits again? 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.

Now you can feel the "nesting", is that a little bit of meaning?

These are the 7 levels of communication for a transaction, and in everyday applications, it can usually meet a variety of business needs, but in addition to the level of propagation, in the process of reading a database, if two transactions are executed concurrently, how is the data between each other affected?

This article is from the "bottom Small tall" blog, please be sure to keep this source http://3157689.blog.51cto.com/3147689/1702197

7 Kinds of propagation levels for spring transactions