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

Today, the editor will share with you the relevant knowledge about the choice of optimistic lock or pessimistic lock in database concurrency control. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article, let's take a look at it.

In the actual production environment, if the concurrency is small, you can use the pessimistic locking method, which is very convenient and simple to use. But if the concurrency of the system is very large, pessimistic locking will bring great performance problems, so it is necessary to choose the optimistic locking method.

Pessimistic locks assume that there is a high probability that other users will attempt to access or change the object you are accessing or changing, so in a pessimistic lock environment, lock the object before you start to change it. and don't release the lock until you commit your changes. The downside of pessimism is that whether it is a page lock or a row lock, it may take a long time to lock, which may restrict the access of other users for a long time, that is to say, pessimistic locks have poor concurrent access.

Optimistic locks assume that there is little chance that other users will attempt to change the object you are changing, so optimistic locks do not lock the object until you are ready to commit the change, and do not lock it when you read and change the object. It can be seen that the locking time of optimistic lock is shorter than that of pessimistic lock, and optimistic lock can obtain better concurrent access performance with larger lock granularity.

But if the second user reads the object just before the first user commits the change, then when he completes his change and commits, the database will find that the object has changed, so the second user has to reread the object and make changes. This indicates that in an optimistic locking environment, the number of times concurrent users read objects is increased. Take the version control system as an example to talk about the two most basic concurrency problems.

Missing updates:

Xiao Zhang wants to modify the a method in the source code, and while she is modifying it, Xiao Li opens the file, modifies the b method and saves the file. After Xiao Zhang's modification is completed, the file is saved, and Xiao Li's changes are overwritten.

Inconsistent reading:

Xiao Zhang wants to know how many classes there are in the package, and the package is divided into two sub-packages: aMagneb. Xiao Zhang opened package an and saw seven classes. Suddenly Xiao Zhang received a call from his wife. when Xiao Zhang answered the phone, Xiao Li added two categories to bag an and three classes to bag b (there were five classes in package b).

After answering the phone, Xiao Zhang opened the b package, saw 8 classes, and naturally came to the conclusion that there were 15 classes in the package.

Unfortunately, 15 are never the right answers. Before Xiao Li revised it, the correct answer was 12 (7 / 5), and after revision it was 17 (9 / 8). Both answers are correct, although one is not current. But 15 is wrong, because the data read by Xiao Zhang is inconsistent.

Summary: inconsistent reading means that you want to read two kinds of data, both of which are correct, but not both at the same time.

Isolated and immutable:

In enterprise applications, two common means to solve concurrency conflicts are isolation and immutability.

Concurrency problems occur only when multiple activities (processes or threads) access the same data at the same time. A natural way of thinking is to allow only one activity to access data at a time. If Xiao Zhang opens the file, others are not allowed to open it, or others can only open the copy in a read-only way.

Isolation can effectively reduce the possibility of errors. We often see programmers get stuck in the quagmire of concurrency problems, which is too tiring to consider concurrency problems after every piece of code is written. We can use the isolation technology to create an isolated area, and when the program enters the isolated area, we don't have to worry about concurrency. Good concurrency design is to create such isolated areas and ensure that the code runs in them as much as possible.

Another way of thinking: concurrency problems can only be caused when you need to modify shared data, so we can make shared data "immutable" to avoid concurrency problems. Of course, we can't make all the data immutable, but if some data are immutable, we can relax our nerves when we operate on them concurrently.

Optimistic concurrency control, pessimistic concurrency control:

What if the data is variable and cannot be isolated? In this case, the two most commonly used controls are optimistic concurrency control and pessimistic concurrency control.

Suppose Xiao Zhang and Xiao Li want to modify the same file at the same time. If the optimistic lock is used, both of them can open the file to make changes. If Xiao Zhang submits the content first, there is no problem, and his changes will be saved to the server. But Xiao Li will encounter trouble when submitting, the version control server will detect the conflict between the two changes, Xiao Li's submission will be specific, and it is up to Xiao Li to decide how to deal with this situation (for most version control software, will read and identify the changes made by Xiao Zhang, and then it is up to Xiao Li to decide whether to merge or not.

If you use a pessimistic lock and Xiao Zhang checks out (check out) the file first, Xiao Li will not be able to check out the same file again until Xiao Zhang submits his changes.

It is recommended that you think of optimistic locks as a means of detecting conflicts, while pessimistic locks are a means of avoiding conflicts (strictly speaking, optimistic locks can't be called "locks", but the name has spread, so keep using them). Some old version control systems, such as VSS 6. 0, use pessimistic locking mechanisms. Modern version control systems generally support both, and optimistic locks are used by default.

The two locks have their own advantages and disadvantages. This lazy translation, it is clear that optimistic locks can improve the efficiency of concurrent access, but if there is a conflict can only be thrown up, and then start all over again; pessimistic locks can avoid conflicts, but will reduce efficiency.

The choice of which lock to use depends on the frequency of access and the severity of the conflict. If the probability of concurrent access to the system is very low, or the consequences after the conflict are not too serious (the so-called consequences should mean that the submission detected by the conflict will fail and must be repeated), you can use optimistic locks, otherwise use pessimistic locks.

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

Suppose both martin and David have to edit the Customer file at the same time. If the optimistic locking strategy is used, both of them can get the Copy of a file and are free to edit the file. Assuming that David finishes his work first, he can update his changes without difficulty. However, when Martin wants to commit his changes, the concurrency control strategy starts to work.

The source code control system detects a conflict between the modification of Martin and the modification of David and rejects the submission of Martin, and Martin is responsible for pointing out how to deal with this situation. If you use a pessimistic locking strategy, as long as someone takes out the file first, others cannot edit the file. Therefore, if Martin fetches the file first, David can operate on the file only after Martin completes the task and submits it.

If optimistic locking is about conflict detection, then pessimistic locking is about conflict avoidance. Both of these strategies can be used in practical source control systems, but now most source code developers prefer to use optimistic locking strategies.

There is a reasonable saying that an optimistic lock is not a real lock, but the term is so convenient and widespread that it cannot be ignored.

These two strategies have their own advantages and disadvantages. The problem with pessimistic locking is that there are fewer concurrent programs. When Martin is editing a file that he locks, others have to wait. Anyone who has used pessimistic source code control knows how frustrating this is. For enterprise data, things often get worse, and as long as someone is editing it, others cannot read it, let alone edit it.

The optimistic locking strategy allows people to be freer, because it is only possible to encounter obstacles when submitting. The question of this strategy is what happens when there is a conflict. In fact, everyone after David must read the modified version of David and figure out how to merge their own and David changes, and then submit a newly modified version.

With a source code control system, this won't be a hassle. In many cases, source code control systems do merge automatically, making it easy to see the differences between different file versions even when they cannot be merged automatically. However, business data is often difficult to merge automatically, so you often have to throw away the original stuff and start all over again.

The criteria for choosing between optimistic and pessimistic locks are the frequency and severity of conflicts. If conflicts are rare, or if the consequences of conflicts are not serious, you should usually choose an optimistic lock because it has better concurrency and is easier to implement. However, if the result of the conflict is painful for the user, then you need to use a pessimistic strategy.

The limitations of optimistic locks are:

It is only when the data is submitted that a business transaction is about to fail, and in some cases, it can be costly to discover that the failure is too late. It may take the user an hour to enter the details of a lease, and too many errors will make the user lose confidence in the system. Another approach is to use pessimistic locks, which can detect errors as early as possible, but are difficult to program and reduce the flexibility of the system.

Note: the above is a text description of the concepts and solutions of optimistic locking strategy and pessimistic locking strategy in concurrency control. Below, I will describe how to implement optimistic locking strategy and pessimistic locking strategy in the project.

The implementation method of optimistic locking strategy:

It is to use the transactions in C# or SQL to roll back if the data operation is not successful. I feel that the train station ticketing system also operates in the same way. we see a small amount of remaining tickets on the display screen, but we can't type them when we buy them.

The implementation method of pessimistic locking strategy:

1. For an ordinary aspx page, when the user points to submit, directly change the enabel of the submission and related buttons to false until the submission event is completed, and then change it back. In addition, in the data layer, every time a data change is submitted, it is necessary to determine whether the previous state of the data has changed in order to prevent concurrent changes.

2. In jquery, in jquery, you can set a global variable. When you submit, you first judge the status of the global variable. If you do not allow it, you will return it directly. If you allow a submission, you will first set the global variable to "do not allow submission", and then start the submission. After the submission is completed, change the global variable to "allow submission" in the callback method of jquery's post method.

3, pop-up window to modify the page, then use modal pop-up, such as web page, you can use window.show ModalDialog () to open the modified page to ensure that only one modified page is opened. This is pessimistic locking of data from the data manipulation page, rather than pessimistic locking in the database.

These are all the contents of the article "database concurrency control chooses optimistic lock or pessimistic lock". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

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.