phenomenon
The finished production version soon, will inform the competent database performance problems in the group, resulting in a deadlock.
This has not been implemented SQL end, cause the system to other services are performance problems.
background
This is a staff update the index log table in SQL, the role of this table is used to mark data which personnel changes.
This SQL module involving the functional background tasks and operations personnel data.
Background tasks need to get updates from this table, the data is synchronized to solr.
Function requires the operator marks the personnel data in this table is to be updated.
analysis
There may be a problem of two modules: one is the background task, a function of the operating personnel data.
If these two modules simultaneously update the same personnel, and the execution time of one long, uncommitted transactions, while the other commits the transaction at this time, it will create problems.
Background task
Logic is not complicated, and contains log table update operations of the business logic is simple, time-consuming issues.
The operator function data
Take for example the audit staff, audit staff includes a series of processes: check parameters, update information, update log table, call interface, send e-mail.
This series of processes are performed in the same transaction, the call interface and sending mail is more time-consuming operation. Originally nothing issue, but later added the update log table, this table method of operation is the table with a background task to update the index operation personnel is the same table.
The process of problem
1, the status of the personnel in the log table is not updated (other operating results in status is not updated)
2, is performing the audit of the personnel function, due to the longer time-consuming, the transaction has not yet submitted
3, a background task to traverse the staff when ready to update the status, there is a problem
Solution
Spring spread an understanding of the behavior of the transaction friend, you should know the solution. (Spring transaction propagation behavior is the default REQUIRED)
Since due to the audit action takes too much time, updated log table failed to submit the transaction, then think of ways to update the transaction log table to submit, do not take up too much time.
My method used here is to add on the method of updating the log table @Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW), meaning that there is a method to open a new transaction, when the end of the process to commit the transaction. As a result of this simple method can be submitted immediately to the operation log table, and not too time-consuming operation because the audit affairs occupied much time.
Use about Spring transaction, where the need to avoid a pit: "Spring's AOP call handling failure."
