Java Transaction Management (II)

　Database transaction and Spring Transaction is the general interview will be mentioned, many friends write accustomed to the code, very little time to collate these things, the result would have been something, incredibly hesitant to answer.

Here are some questions I've collected about Spring , and I hope to help you get through it.

　Transactions are the guarantee of the atomicity of logic, and by using transaction control, it is possible to avoid problems such as dirty data caused by logical processing failure .

The two most important features of a transaction are the level of communication and the data isolation levels of the transaction. The propagation level defines the scope of control of the transaction, and the transaction isolation level defines the scope of the transaction's control over the database read and write .

7 levels of propagation for a transaction:

1) 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, If a transaction does not exist in the current context, the new transaction executes. So this level is usually sufficient to handle most business scenarios.

2) propagation_supports , literally know,SUPPORTS, support, the characteristic of this propagation level is that if a transaction exists in the context, the transaction is supported to join the transaction, If there is no transaction, it is performed 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.

3) 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.

4) propagation_requires_new , you can literally know,new, each time you want to a fresh transaction, the characteristics of this propagation level is that each time a new transaction is created, And the transaction in the context is suspended at the same time, after the execution of the current new transaction completes, the context transaction resumes execution.

This is a very useful communication level, to give a scenario: now there is a send a red envelope operation, before sending, to do some system initialization, verification, data logging operations, and then send a red envelope, The log is then logged, the sending log requires 100% accuracy, and 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.

5) propagation_not_supported , this can also be literally learned,notsupported , unsupported, the current level is characterized by the existence of transactions in the context, Suspends the transaction, executes the current logic, and resumes the context's transaction after the end.

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 over a number of 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.

6) Propagation_never , the transaction is more stringent, the above transaction level is only not supported, a transaction hangs, and propagation_never The propagation level requires that a transaction cannot exist in the context and, once a transaction is present, throws a runtime exception and forces the execution to stop! At this level, life has a grudge against business.

7) propagation_nested , 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, the parent transaction establishes a rollback point, called savePoint, and then executes a child transaction, the execution of the child transaction is also considered a part of the parent transaction, and the child transaction execution is completed. The parent transaction continues execution. The point is that savepoints. See a few questions to understand:

What happens if a child transaction is rolled back?

The parent transaction rolls back to the savePoint 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. So:

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 requires an understanding of another feature of the transaction: the data isolation level

The data isolation level is divided into four different types:

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 the " Dirty Read " . This level applies to most systems.

4,readuncommitted : Ensure that the read process will not read illegal data.

The above explanation is actually a bit of a mouthful in each definition, which involves several terms: dirty reading, non-repeatable reading, and Phantom reading.
Here's an explanation:
Dirty Read:the so-called dirty reading, in fact, is read the other transaction before the rollback of dirty data. such as BusinessBdata was modified during executionX, before committing, the transactionARead theX, while the transactionBbut rolled back, so the businessAit forms a dirty read.
non-repeatable read: The literal meaning of non-repeatable reading is already clear, such as a businessAwhen a piece of data is read first, and then the logic is executed, the transactionBchanged the data, and then the transactionAread again, found that the data does not match, is the so-called non-repeatable read.
Phantom Reading: Small when counting fingers, first time dozens ofTen, the second number is OneOne, what's the matter? You have a hallucination?
So is the Phantom reading, the businessAfirst, based on the conditional index, getTenbar data, and then the transactionBchanged the database one piece of data, causing the transaction to also be compliantAthe search condition at that time, such a transactionAThe search again found that there was Onedata, a phantom reading is produced.

Java Transaction Management (II)