. NET: offline optimistic lock code example to prevent concurrent modification (required by cainiao)

Document directory

• Set version field
• CAS
• Running Effect
• Notes

Background Xiao Ming and Xiao Qiang checked out the source code at the same time. If Xiao Qiang submitted the source code first, the submission was successful and James submitted the modification, at this time, the source code server will tell James that someone made a modification after reading it and asked him how to handle it. The source code server will ask James to merge the modification and submit it again. This is an optimistic lock policy. Of course, the source code service can also be configured as a pessimistic lock to avoid parallel modification.

Reasonable avoidance of concurrent modification is an unavoidable problem in enterprise applications. However, in actual scenarios, many teams have avoided this problem. Today, I will introduce how to use offline optimistic locks to process concurrent modifications.

Related Articles: Online pessimistic locks, offline pessimistic locks, online optimistic locks, and offline optimistic locks.

Concept CAS: Compare And Swap. the value to be modified is exchanged (modified) only when it is not modified after I read it ).

CAS is a term in the multithreading field. For example, the lockless annular queue is implemented based on this implementation. Because CAS is the same as Optimistic Locking, I will borrow it.

Let's take a look at the application scenarios of offline optimistic locks:

Contains the following information:

1. Reading thread A1 and modifying thread A2 are different threads, so they are called offline. For example, read data and modify a form.

2. The CAS Compare with the version number, and the Swap is the entire record. For example, EntityFramework allows you to specify which attributes are version attributes.

Code example: Set the version field

CAS

1 // <summary> 2 // execute the modification. 3 /// </summary> 4 public void Handle (TCommand command) 5 {6 var unitOfWork = ServiceLocator. current. getInstance <TUnitOfWork> (); 7 8 unitOfWork 9. getRepository <TRepository> () 10. markAsModified (command. aggregate); 11 12 unitOfWork. commit (); 13}

Running Effect

Notes

I. In the example, I will directly read the data read by the reading thread. After offline modification, I will pass a modification thread. In this way, the two threads only read the logic once, which ensures the correctness of Compare in CAS. In some scenarios, you may need to read the modified data at the same time in the modification thread, and then merge the modified data at the UI Layer. In this case, pay attention to the situation, you must manually specify the version number read by the first thread for the Compare operation. Otherwise, the version number read by the second thread is used.

2. Optimistic offline locks are only suitable for scenarios with Low Re-engineering costs. Otherwise, the user will go crazy after two hours of editing. This high-cost operation is suitable for "offline pessimistic locks ".

Remarks

I am a person who cannot keep up with thinking. because of laziness, I do not fully adopt optimistic locks in projects. The next project must be fully implemented.