Table of contents
transaction concept
In fact, the first place we come into contact with the word transaction should be the database. We will know that transactions have four characteristics, namely:
- Atomicity: Indicates that any failure during transaction execution will cause any modifications made by the transaction to become invalid.
- Consistency: Indicates that when a transaction fails, all data affected by the transaction should be restored to the state before the transaction was executed.
- Isolation: Indicates that modifications to data during transaction execution are not visible to other transactions before the transaction is committed.
- Durability: Indicates that the status of the submitted data should be correct when the transaction execution fails.
To put it bluntly, a transaction is a set of sql instructions. Each sql is part of the transaction.
Assuming that each sql is executed successfully and is completed, it means that the execution of this set of sql takes effect. Although the transaction is executed, it does not affect Execution of the original sql; otherwise, if an error occurs, a transaction needs to be started. The transaction will roll back the previous sql one by one, and the transaction will end. The original sql will not be executed. This group of Transaction execution failed
Why transactions are needed
The same is true when it comes to Java. Sometimes our program will affect the database more than once. If one SQL execution fails and the previous SQL has been executed, then the previous data has been created or modified, and another one or Multiple pieces of data still have not changed, which is definitely not in line with normal logic: even if an error is reported, it cannot affect other businesses!
Just like Wozki once said: All glory is glory, everything is damaged. As long as there is a mistake in one place, the entire object is broken. In the avalanche, no snowflake is innocent.
Transactions are proposed to solve data security operations. Transaction control is actually to control the safe access of data.
Reason for transaction exception
For example, let's take a look at the reason for this transaction exception. First, let's take a look at the code:
Very good! A small transaction is nested within a large transaction, and then try-catch is used to capture the small transaction. As a result, there is no error message. The inner transaction throws an exception in certain scenarios, but the outer transaction uses try– catch caught it. So when the inner transaction is abnormal, the outer transaction continues to execute.
If there is just no exception prompt, we can find the cause of the error by debugging step by step. However, if the two transactions are associated with the same table or data, it will easily cause a bigger problem: lock wait timeout exceeded; try restarting transaction, that is, a deadlock problem. Two transactions compete for the same resource together, resulting in cyclic waiting. I will discuss this issue in detail when I have time.
solution
1. Option 1 (this is generally used)
If you are sure that the inner layer method does not need to use transaction annotations, annotate the inner layer with @Transactional, because the outer layer itself has transaction annotations, and the transaction will not be executed just because the inner layer method body is written to another place.
2. Option 2
If you are sure that the outer transaction will not modify the database (such as a query), you can remove the external @Transactional