The summary of optimistic concurrency control and pessimistic concurrency control for high concurrency control solutions

Overview:

We can use two forms of concurrency control strategy: Optimistic concurrency control and pessimistic concurrency control.

Suppose Martin and David are both editing the customer file. If you use the optimistic lock strategy, all two of them can get a copy of the file and

can edit files freely. Assuming David is the first to finish the job, he can update his changes without any difficulty. However, when Martin wants to submit his changes, the concurrency control strategy will begin to work. The source control system detects a conflict between Martin's modifications and David's modifications and rejects Martin's submission, and Martin is responsible for pointing out how to handle the situation. If you use a pessimistic lock policy, others cannot edit the file as long as someone takes it out first. So, if Martin had taken the file first, then David would have to work on the file only after Martin had completed the task and submitted it.

If the optimistic lock is viewed as a conflict detection, then the pessimistic lock is about conflict avoidance. In the actual application of the source control system,

Both of these strategies can be used, but now most source code developers are more inclined to use optimistic locking strategies. (There is a reasonable argument that optimistic locking is not really a lock, but it is convenient and widely circulated so that it cannot be ignored.) ）

Both of these strategies have their pros and cons. The problem with pessimistic locks is the reduction of concurrent programs. When Martin was editing a file that he had locked,

The others can only wait. People who have used pessimistic source controls know what a frustrating thing it is. For enterprise data, the situation often gets worse, and as long as someone edits it, the other person can't read it, and it's more about editing.

The optimistic lock strategy allows people to be more liberal because it is only possible to encounter obstacles when submitting. The problem with this strategy is what happens when it comes to conflict. In fact, all of David's subsequent submissions had to read the version that David had modified, and he pointed out how to merge his and David's changes before submitting a new version that had been modified. With the source code control system, doing so does not have any trouble. In many cases, the source code control system is able to automate the merging operation, even when it is impossible to automatically merge, it makes it easy to see the difference between different file versions. However, business data is often difficult to merge automatically, so often you just throw away the original and start from scratch.

The criteria for choosing between optimistic and pessimistic locks are the frequency and severity of the conflict. If the conflict is small, or the consequences of the conflict are not serious, then it is usually preferable to choose an optimistic lock because it is better concurrency and easier to implement. However, if the outcome of the conflict is painful for the user, then a pessimistic strategy is needed.

The limitation of optimistic locking is that business transactions will fail only when data is submitted, and in some cases it can be costly to discover failures too late. It may take one hours for a user to enter the details of a lease, and too many errors can cause users to lose confidence in the system. Another approach is to use pessimistic locks, which can detect errors as early as possible, but they are difficult to program and can reduce the flexibility of the system.

(Note: The above is the optimistic lock strategy in concurrency control and pessimistic lock strategy concept and solution ideas of the text description, I will be the project specific how to implement optimistic locking strategy and pessimistic lock strategy description.) ）

Optimistic lock strategy implementation method:

is to use C # or SQL in the transaction to achieve the data operation is not successful roll back, personal sense of the railway station selling ticket system is also such operation, we saw a small number of tickets on the display, but we go to buy and can not come out.

Pessimistic lock strategy Implementation method:

1, the normal ASPX page, when the user point submitted, directly to the submission and related button Enabel to false, until the completion of the submission of the event, and then change back. Also in the data layer, each time you submit a data change, you need to determine whether the previous state of the data changes to prevent the occurrence of concurrent changes.

2, jquery, in jquery, you can set a global variable, submit, first judge the state of global variables, if not allowed to return directly, if allowed to submit, then the global variable to "do not allow to submit", after the start of submission, after the completion of the submission, In the callback method of the jquery post method, change the global variable to "allow commit".

3, pop-up window to modify the page, the modal mode pop-up, such as the Web page, you can use window.showModalDialog () to achieve modal mode to open the Modify page to ensure that only one modification page is always open. (This is a pessimistic lock on data from the data manipulation page, rather than pessimistic locking in the database)