During the implementation of business logic, it is often necessary to ensure the exclusivity of data access. For example, in the day-end settlement
processing , we want to process the data at a certain cut-off time point, and we do not want the data to be processed during the settlement process
(which may be several seconds or several hours). change again. At this time, we need to use some
mechanisms to ensure that these data will not be modified by the outside world during a certain operation. Such a mechanism, here, is the so-called
"lock", that is, to the target data we selected. lock so that it cannot be modified by other programs.
Hibernate supports two locking mechanisms: the so-called "pessimistic locking (Pessimistic Locking)"
and "optimistic locking (Optimistic Locking)".
Pessimistic Locking Pessimistic Locking
, as its name implies, refers to a conservative attitude towards data being modified by the outside world (including other current transactions in the system, as well as transactions from
external systems), therefore, during the entire data processing process , the data
is . The realization 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 be guaranteed that the external
system will not change the data).
A typical database-dependent pessimistic lock 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 only if the lock is set before the query starts (that is, before Hiberate generates SQL), the locking process will
be performed through the database locking mechanism. Otherwise, the data has been
loaded through Select SQL without the for update clause. The so-called database locking is impossible to talk about.
Compared with pessimistic locking, optimistic locking adopts a looser
locking mechanism. In most cases, pessimistic locking
relies on the locking mechanism of the database to ensure maximum exclusivity of operations. But with it comes a lot of overhead in database
performance , especially for long transactions, which is often unbearable.
For example, in a financial system, when an operator reads the user's data and makes modifications on the basis
of (such as changing the user's account balance), if the pessimistic locking mechanism is adopted, it means that the entire operation has been completed.
During the whole process (from the operator reading the data, starting the modification to submitting the modification result, and even including the time when the
operator goes to brew coffee halfway), the database records are always locked. It is conceivable that if faced with
hundreds of Thousands of concurrent, such a situation will lead to what consequences.
The optimistic locking mechanism solves this problem to a certain extent. Optimistic locks are mostly
implemented based on the data version (Version) recording mechanism. What is a data version? That is to add a version identifier to the data. In the version solution based on 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 version data of the
submitted data is compared with the current version information of the corresponding records in the database table. If the version number of the submitted data
is greater than the current version number of the database table, it will be updated; otherwise, it is considered to be expired data.
For the above example of modifying user account information, suppose there is a
version field in the account information table in the database, 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 his account balance
( $100-$50 ).
2 During the operation of operator A, operator B also reads this user information ( version=1 ) and deducts $20 ( $100-$20 )
from his account balance.
3 Operator A completes the modification work, adds one to the data version number (version=2), and submits it to the database for update together with
the (balance=$50). At this time, since 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.
4 Operator B completes the operation and also increases the version number by one ( version=2 ) and tries to submit data to
the ( balance=$80 ), but when comparing the database record versions, it is found that the
data version number submitted by operator B is is 2, and the current version of the database record is also 2, which does not satisfy the optimistic locking strategy of "the submitted version must be greater than the current version of the
record to perform the update" , therefore, operator B's submission is rejected.
In this way, the possibility of operator B overwriting the operation result of
operator .
As can be seen from the above example, the optimistic locking mechanism avoids the database locking overhead in long transactions (operator A
and operator B do not lock database data during the operation process), which greatly improves the performance of 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
limitations . For example, in the above example, since the optimistic locking mechanism is implemented in our system, the user
balance from the external system Update operations are not under the control of our system and therefore may cause dirty data to be updated into the database. In the
system design stage, we should fully consider the possibility of these situations and make corresponding adjustments (for example
, 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 , rather than The database table is directly exposed to the outside world)