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

This article mainly explains "how JPA uses optimistic locks to deal with high concurrency". Friends who are interested may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how JPA uses optimistic locks to deal with high concurrency.

Catalogue

JPA uses optimistic locks to deal with high concurrency

The Challenge of highly concurrent Systems

The problem of pessimistic lock

Optimistic locks are a good thing.

Add optimistic locks to the database

Optimistic lock-business judgment to solve high concurrency

JPA uses optimistic locks to meet the challenge of high concurrency and high concurrency systems

When deploying distributed systems, we usually deploy multiple micro-services in the intranet cluster, and then aggregate them with API gateways to provide external services. In order to do load balancing, multiple running instances are usually started for each micro-service and called through the registry.

So the problem arises, because there are multiple instances running the same application, although the microservice gateway forwards each request to only one instance, they may still operate on the same database table at the same time in the face of high concurrency. Will this cause any problems?

The problem of pessimistic lock

For example, in the commodity second kill system, which is common in e-commerce, there will be a large number of concurrent requests in the process of snapping up goods, and it is very likely to read and write a table containing the remaining quantity of goods at the same time, which generally has to lock the database. Otherwise, it is easy to oversell goods and missell them.

If you use the lock mechanism of the database, that is, pessimistic lock, lock the database when writing, other modification requests have to wait for the lock to be released, but this reduces the efficiency. Moreover, in high concurrency scenarios, requests that may not be able to grab the lock will be stuck there for a long time, resulting in request failure, and then there will be a large number of retries, and exceptions such as running out of connections may occur in the system.

Optimistic locks are a good thing.

Access to information found that optimistic lock is a good thing, it is for the database table to add an identification of the data version of the version field to achieve, read the data when reading the version field together, write to the database compared to the version field to know whether the data has been changed, if the version is not equal, it means that the holding is out of date data, can not be written, if equal can be written, and add version.

The optimistic lock will only check whether the data conflicts when it is written to the database. If the conflict is found, the write will be abandoned and the write failure information will be returned. Compared with the pessimistic lock, this is a lightweight way to lock the data and be able to cope with high concurrency requirements.

Add optimistic locks to the database

To say that optimistic locks are a good thing, first of all, we have to say that JPA is a good thing, because Spring Data JPA has built-in implementation of optimistic locks, it is easy to add optimistic locks to database tables, just add an integer field and add the @ Version annotation. JPA automatically checks the version every time the data is submitted.

@ Entity @ Table (name = "m_order") public class Order {. @ Version private int version;.} optimistic Lock-Business judgment to solve High concurrency

When solving the problem of high concurrency, if it is a distributed system, obviously we can only use the database-side locking mechanism to solve this problem, but this synchronization mechanism or database physical locking mechanism will sacrifice part of the performance. so optimistic locking mode is often used to solve this problem in another way.

It is a typical optimistic locking mode that two bank operators operate the same account at the same time.

For example, An and B operators read an account with a balance of 1000 yuan at the same time, An operator increases the account by 100 yuan, and B operator deducts 50 yuan from the account at the same time. In the end, the actual account balance was 1000-50,950 yuan, but it should have been 100000100-501050. This is a typical concurrency problem.

The optimistic locking mechanism solves this problem to some extent. Optimistic locks are mostly implemented based on data version (Version) recording mechanism. What is the data version? That is, to add a version identity to the data, which is generally achieved by adding a "version" field to the database table in the version solution based on the database table.

When reading out the data, read out the version number together, and then add one to the version number when it is updated. At this point, the version data of the submitted data is compared with the current version information recorded in the corresponding database table, and if the submitted data version number is greater than the current version number of the database table, it will be updated, otherwise it is regarded as out-of-date data.

For the above example of modifying user account information, assume that there is a version field in the account information table in the database with a current value of 1, while the current account balance field (balance) is 1000 yuan. Assume that operator A updates first and operator B updates later.

A, operator A now reads it out (version=1) and increases its account balance by 100,000,100,100,100.

B. During the operation of operator A, operator B also reads this user information (version=1) and deducts 50 (1000-50) from its account balance.

C, operator A completes the modification work, adds the data version number by one (version=2), together with the balance after account increase (balance=1100), and submits it to the database for update. At this time, because the submitted data version is greater than the current version of the database record, the data is updated and the database record version is updated to 2.

D, operator B completed the operation and added the version number (version=2) to attempt to submit data (balance=950) to the database, but at this time, when comparing the database record version, it was found that the data version number submitted by operator B was 2, and the current version of the database record was also 2, which did not meet the optimistic lock policy that "the submitted version must be greater than the current version of the record to perform the update". Therefore, the submission of operator B was rejected.

In this way, it is possible for operator B to overwrite the operation result of operator A with the result of old data modification based on version=1.

Operator An operates as follows:

Select id, balance, version from account where id= "1"; query results: id=1, balance=1000, version=1update account set balance=balance+100, version=version+1 where id= "1" and version=1select id, balance, version from account where id= "1"; query results: id=1, balance=1100, version=2

Operator B operates as follows:

Select id, balance, version from account where id= "1" Query results: id=1, balance=1000, version=1# operator A has been modified successfully, the actual account.balance=1100, account.version=2, operator B also added the version number (version=2) to attempt to submit data (balance=950) to the database, but when comparing the database record version, it was found that the data version number submitted by operator B was 2, and the current version of the database record was also 2. Does not meet the optimistic lock policy that the submitted version must be larger than the current version of the record to perform the update, so the submission of operator B is rejected. Update account set balance=balance-50, version=version+1 where id= "1" and version=1 select id, balance, version from account where id= "1"; query results: id=1, balance=1100, version=2

ORM frameworks or implementations such as Hibernate and JPA use the version number and then judge the value returned after UPDATE

At this point, I believe you have a deeper understanding of "how JPA uses optimistic locks to deal with high concurrency". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.