Shulou(Shulou.com)06/01 Report--

Recently organized technical training within the team, Liu Congwei shared a case (bug) related to transactions and writing databases. Be careful with business!

I. Fault phenomenon

There are two nodes (engineering items) A and B in the vehicle delivery performance process. A modifies a data record item (work order) and then sends a message to B. B will also modify the item.

Failure phenomenon, sometimes (not necessarily) feel A did not successfully modify the item this data, and the log shows that A successfully modified the data item!

Look at the specific code implementation. The following figure shows the project A code, and the three red boxes act in turn.

1. Open the transaction

2. Modify work order record item

3. Send mq message to downstream node

The following figure shows Node B consuming mq messages downstream. The red box indicates that JPA technology is used to modify the data record item.

II. Cause analysis

There are five steps to this process, as shown below.

1. Node A opens a transaction to modify a data item in the data table.

2. A sends an mq message to B and does something else, commits the transaction

3. Node B consumes mq messages

4. Node B reads data item

Node B modifies some fields of the data item in memory and writes them back to the database.

Note that steps 1 and 2 are in one transaction. There is a possibility that Node B receives the mq message and executes step 4. After reading the item data, the transaction in steps 1 and 2 is submitted. Because of the database transaction isolation level, in this case, the data read in step 4 is not the data written by node A in step 1, and dirty data has been read. When the data is written back in step 5, it may cause the old data to overwrite the new data written by A.

There are two subscenarios here.

1. Modify the same field in steps 1 and 5. In this case, step 4 reads dirty data

2. Modify different fields in steps 1 and 5. Step 4 reads the oldvalue of the col2 field. Step 5 modifies the value of col3, but some default writing of jpa or mybatis updates the oldvalue of col2 back to the database.

The general ORMapping framework uses a vo object to write database records, and the unmodified fields are not updated (the value of col2 is not changed in the code), but after reading the data in step 4, the data item is modified in step 1. The default library method checks for changes in records and updates the value of the col2 field. This creates a problem where the old values overwrite the new ones.

III. SOLUTIONS

Considering the implementation cost, if different fields are modified, there is no competition. Just specify the update field in Step 5 to write the library to quickly resolve this problem. In fact, production environments are also the option for temporary repairs.

Solution 1 is obviously not good enough. Better yet, remove the mq message sent in step 2 from the transaction and wait for step 1 to commit before sending the mq message. This approach involves some logical combing (there will be a lot of if... else in the business code), code changes. This process is still not perfect, step 1 is completed, step 2 fails to do what? It may take some extra code work to ensure that step 2 is executed successfully.

If the business pressure is not large, you can also consider solving this problem from the transaction isolation level of the database.

4. Business, steps 1 to 5 If strong consistency is needed, understand distributed transactions

https://www.jianshu.com/p/16b1baf015e8

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.