DRP Summary-pessimistic database lock

The problems left by DRP are that the videos left behind are not perfect, so they are not written into the blog in time.

I think it is really important to lock data. We are developing software, and most of these software is used to operate data, so there will be data correctness and security issues, the lock is designed to ensure data integrity. Next, let's talk about the lock mechanism that I have come into contact.

In the DRP project, the primary key of the distributor is generated using a separate table, so that multiple users can generate the primary key at the same time, that is, access to common resources, we all know that in this case, thread synchronization must be used to ensure that data can be accessed by at most one thread at any time to ensure data integrity. Currently, I know two solutions:

1. Using the synchronized keyword in Java to synchronize methods (adding synchronized to the method and synchronized (this) has the same meaning, and they all lock objects ).

2. You can use the pessimistic lock of the database. The following describes the pessimistic lock of the database, for example:

select value fromt_table_id where table_name=? for update

Pessimistic locks are implemented by the database mechanism (only the lock mechanism provided by the database layer can truly ensure the exclusive access to data. Otherwise, even if the lock mechanism is implemented in the system, cannot guarantee that the external system will not modify the data). After the data is locked, other users will not be able to view the data until the lock is released, and the lock will be released only after the transaction is committed or rolled back, this ensures data correctness. Note: The for update statement can only be placed in the SELECT statement, because it makes sense to lock the data during the query.

Extended: When Hibernate is used to operate data, the lock can be implemented through the database lock mechanism only when the lock is set before the query starts (that is, before the hiberate generates an SQL statement). Otherwise, data has been loaded through select SQL that does not contain the for update clause. The so-called database locking is impossible .)

There is also an optimistic lock, we will be exposed ......