锁（ locking ）
During the implementation of business logic, it is often necessary to ensure the exclusivity of data access. such as day-end settlement in the financial system
During processing, we want to process data at a certain cut-off time point, not during the settlement process
(It may be a few seconds, it may be a few hours), the data changes again. At this point, we need to pass some
system to ensure that these data will not be modified by the outside world during a certain operation. Such a mechanism, here, is also called the so-called
The "lock" is to lock the target data we selected so that it cannot be modified by other programs.
Hibernate supports two locking mechanisms: commonly referred to as "Pessimistic Locking"
and "Optimistic Locking".
Pessimistic Locking
Pessimistic locks, as the name suggests, refer to data that is locked by the outside world (including other current transactions in the system, as well as from
transaction processing) modification of external systems is conservative, therefore, during the entire data processing process, the data is locked
condition. The implementation of pessimistic locking often relies on the locking mechanism provided by the database (and only the locking mechanism provided by the database layer can
Truly guarantee the exclusivity of data access, otherwise, even if the locking mechanism is implemented in this system, it cannot guarantee the external system
system will not modify the data).
A typical database-dependent pessimistic locking call:
select * from account where name=”Erica” for update
This sql statement locks all records in the account table that meet the retrieval conditions ( name=”Erica” ).
Before the transaction is committed (the locks in the transaction process will be released when the transaction is committed), the outside world cannot modify these records.
Hibernate's pessimistic locking is also implemented based on the database locking mechanism.
Note that the lock will only be set before the query starts (that is, before Hiberate generates the SQL).
The locking process is really carried out through the locking mechanism of the database, otherwise, the data has passed through and does not contain for update
When the Select SQL of the clause is loaded, the so-called database locking is out of the question.
Optimistic Locking
Compared with pessimistic locking, optimistic locking mechanism adopts a more relaxed locking mechanism. Pessimistic locking mostly depends on
It is implemented by the locking mechanism of the database to ensure the maximum degree of exclusivity of the operation. But then came the database
Significant overhead in performance, especially for long transactions, is often unbearable.
For example, in a financial system, when an operator reads the user's data, and makes progress based on the read user data
When a row is modified (such as changing the user account balance), if the pessimistic locking mechanism is used, it means that the entire operation has been
During the process (from the operator to read the data, start the modification, and submit the modification result, and even include the operation
the time when the employee went to brew coffee), the database records are always in a locked state. It is conceivable that if faced with several
Hundreds of thousands of concurrent, what will be the consequences of such a situation.
The optimistic locking mechanism solves this problem to a certain extent. Optimistic locking, mostly based on data versioning
( Version ) Recording mechanism implementation. What is a data version? That is to add a version identifier to the data, based on
In the version solution of the database table, it is generally by adding a "version" field to the database table.
accomplish.
When reading data, read out this version number together, and add one to this version number when updating later. At this time, the
The version data of the submitted data is compared with the current version information of the corresponding records in the database table. If the submitted data is
If the version number is greater than the current version number of the database table, it will be updated, otherwise it is considered to be outdated data.
For the above example of modifying user account information, suppose there is an account information table in the database
The version field, the current value is 1; and the current account balance field (balance) is $100.
1 Operator A now reads it out ( version=1 ) and deducts $50 from its account balance
（ $100-$50 ）。
2 During the operation of operator A, operator B also reads this user information ( version=1 ), and
Deduct $20 ($100-$20) from their account balance.
3 Operator A completes the modification work, increases the data version number by one (version=2), and deducts the
The balance after division ( balance=$50 ) is submitted to the database for update. At this time, due to the large version of the submitted data
For the current version of the database record, the data is updated, and the database record version is updated to 2.
4 Operator B completes the operation and also increases the version number by one ( version=2 ) and tries to submit the number to the database.
According to the data ( balance=$80 ), but when comparing the database record version at this time, it is found that the operator B submitted the
The data version number is 2, and the current version of the database record is also 2, which does not satisfy the "submission version must be greater than the record.
The optimistic locking strategy of "update" can only be performed by recording the current version, therefore, operator B's commit is rejected.
In this way, operator B is prevented from overwriting the operation with the result of the old data modification based on version=1
The possibility of the result of the operation of member A.
As can be seen from the above example, the optimistic locking mechanism avoids database locking overhead in long transactions (operator A
During the operation with operator B, there is no lock on the database data), which greatly improves the system under large concurrency.
overall system performance.
It should be noted that the optimistic locking mechanism is often based on the data storage logic in the system, so it also has certain advantages.
limitations, as in the above example, since the optimistic locking mechanism is implemented in our system, users from external systems
Balance update operations are not under the control of our system and therefore may cause dirty data to be updated to the database. exist
In the system design stage, we should fully consider the possibility of these situations and make corresponding adjustments (such as
Implement the optimistic locking strategy in the database stored procedure, and only open the data update method based on this stored procedure to the outside world.
path, rather than exposing the database table directly to the outside world).