Encountering a bug that causes errors due to improper transaction control
When our shipping is reviewed, you must register the shipping order in the business record corresponding to the delivery unit, so that the user can see which delivery document is issued in the business record. of.
A few days ago, the customer reported a bug. After the service data was reviewed, the shipping number was not set; but the documents have been successfully reviewed; this bug is occasionally, there is no condition, there is no long time. Find the reason.
A few days ago, I thought of a stupid approach, putting a log file TRANLATE for this problem into a SQL script, and then finding the business documents of the problem and what modifications have been done in the corresponding delivery order, and finally found it. The reason for the problem is that it is caused by incorrect control of the transaction.
In the earlier versions of the system, the audit of the ship is specially implemented through a function. In this function, the delivery document is completed as an audited, modified inventory, etc., and judge in the function, success Commital otherwise Rollback, and only judge whether the review is successful, it is unsuccessful;
This did not have any problems, but after the original developers left, the programmers took over did not understand the design architecture of the original system. For the "Delivery Single number to set the business documents after the review", it is written. In the Click event of the "Audit" button, this audit operation is divided into two transactions, and a very bad problem is not commit in the newly added program! So the "Delivery Single number to set the business document after the audit" will be submitted to see what the user will do when the user will do after the review, generally submitted (I guess, when the window is directly closed Submitted), but if the user adds a new document after the audit, then cancel, then this operation will be by Rollback (there is rollback in cancellation), which will cause the bug mentioned earlier.
Lessons learned: 1. The first is that the commitment of the transaction should not be placed in the function. In the function, only logical judgment should be performed, and if it is successful, and the return result of the function function is detected, and the transaction is an event. The task, even if there are multiple function calls in the event, it can guarantee that there is only one transaction in an event; 2. Today, I will see an article on the "9CBS Development Master", telling that there should be no business logic in the incident. The business logic should be packaged in a separate method or function, and in the event, it should only be called and the return value should be detected, and the business logic should not be directly written directly, and the problem is deep; 3. After the operation of the database is completed, the transaction must be processed after the operation is completed; Write the comment of the program, which ensures that subsequent developers can understand the previous design ideas;
Go back to the development specifications to the development specifications.
