1. Background of the problem
When I first came near the new company, the business is not yet familiar with, so I arranged to maintain the leadership of the existing system. Probably introduced to the project background, the project is divided into A request to call the project interface and call interface B project A project and the project's core business in the B section in Project A, interacting with third-party business in Project B, the front-end launch calling third party acquiring data (such legacy systems design).
After acquiring the data to determine whether the third-party database record (with a unique key), if the update operation is performed, is not new. And if a third party believe the data has expired, you need to delete (tombstone) from the database and return a successful third party to remove a callback, follow-up data will no longer be found expired.
Corresponding to the flowchart as follows
In the code that handles the transaction plus @Transactional comment on the whole process, that is based on a unique index will lock the bank at the time of the data deletion (tombstoned, actually update statement). In the production frequent item B Lock wait timeout exceeded; try restarting transaction exception, by the investigation to locate the function code, the code investigation found that the following function codes
Experienced students should already see the problem, there will be global exception capture, log errors, but the problem lies in a catch here, because the exception is catch swallowed, @ Transactional unable to get an exception, so it will not perform rollback rollback, lead has been occupied by the database row lock. (Exception here is to call a third-party interface failed due to call too often, third-party interfaces collapse, has done a follow-up here concurrency control) so that subsequent transaction when performing updates the bank records due to lack of lock and wait for failure, they reported the Lock wait timeout exceeded; try restarting transaction exception.
2. The impact of the problem
Since this interface is client-initiated calls, and calls B projects A project of the core projects A, B project because the deadlock can not return results, resulting in a large number of front-end project A request blocking, due to the limited number of tomcat support request thread, A direct result of this issue service downtime. The impact is more serious.
3. How to solve
Below that this problem-solving ideas, because the A project downtime, server logs may see a lot of the abnormality information, Lock wait indicate that there is a lock problem.
. A use SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX; view current affairs, using SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; view current lock transaction, using SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; view the current locks and other matters. Using the above three can be positioned substantially sql the code location.
B. After positioning the code, the code depends on the specific issue of the many reasons leading to the exception is not rolled back. Note here that a use @Transactional annotation, the default RuntimeException will only be rolled back, while IOException SQLException and will not trigger a rollback. If you want to two non-operation exception is rolled back, the need for @Transactional (rollbackForClassName = { "IOException", "SQLException"}) in a global or abnormal @Transactional Exception do rollback configured @Transactional (rollbackFor = Exception.class). After another or manually throw a RuntimeException capture IOException
to sum up
The above is a problem encountered by bloggers in practical work, recorded here with similar problems can quickly locate and solve the problem to facilitate future. I hope you can help us.