During the duty process, through the self-service operation and maintenance platform, it was found that this Exception would be thrown every minute, and the database alarmed:
Obviously, deadlocked.
The granularity of database locks is row locks, and the Exception reported is when "printing the contract". This problem has also occurred before, and it is very regular, and several fixed functions will be deadlocked.
Solution：
1. The common solution is to kill the corresponding process of the database first. There are many tutorials in this process. We also find the id first, and then kill it. (However, without permission, I can only call the DBA to kill).
2. After killing, I found that the problem reappeared for a while. . . . . I rubbed it, like a whack-a-mole, killed it, and reappeared. . . .
think:
As mentioned above, killing the process is just a temporary solution, what is the source of the problem?
Because every time it is those few methods, this problem will be reported, so I have to look for the rules. Later, it was found that the methods marked by Spring's @Transaction are still quite large. After communicating with the DBA, it takes a few seconds to execute this transaction at the database level. Then the question can basically be thought from this direction:
The transaction is too slow, and the row lock is not released (there are both select and update in the print contract). As long as the problem of slow transaction is solved, this deadlock should be solved.
Strategy:
1. Split, put the code that does not need to be rolled back out of the transaction to shorten the transaction execution time.
2. Someone on the Internet said, for update, split into delete + inset, will it be very fast? No trials.
In short, to solve the problem, to find the source.