Summary of using pessimistic locking in Laravel transactions

Laravel provides a convenient and fast way to use database transactions. I have encountered several places that are easily confused and misled during use. I will make a record here. I hope some experts can give me some pointers on where I am wrong.

laravel transactions are divided into manual and automatic methods, but if we are using the sharedLock or lockForUpdate lock table method provided by laravel, in order to avoid unnecessary trouble and errors, it is recommended to use manual submission of transactions, as shown below:

Let’s talk about the difference and impact of sharedLock (shared lock) and lockForUpdate (pessimistic lock) in use

sharedLock (shared lock)

sharedLock is equivalent to the SQL statement when used *select from transaction_test where type = 1 lock in share mode;**

In the transaction It will take effect only when sharedLock is used, and the row where the data is located will be locked. At this time, the locked data is not allowed to be modified by other operations, but the locked data has no impact on the query operation, whether it is a normal query or a query in a transaction Operation will not be affected. The locked data will not be released until the transaction is committed or rolled back.

lockForUpdate (pessimistic lock)

lockForUpdate is equivalent to the SQL statement *select when used from transaction_test where type = 1 for update;**

lockForUpdate will only take effect in a transaction. When using lockForUpdate, the row where the data is located is locked. At this time, lock table operations in other transactions will wait for the current transaction to be submitted. Execution, but there are no restrictions on non-locking tables and ordinary query operations. What is affected is only the locking table operations you also perform in the transaction.

In short, whether it is a shared lock or a pessimistic lock, the affected Only the table locking operation performed in the transaction has no effect on ordinary query operations and non-locking table operations in the transaction.

At the same time, it should be noted that whether the pessimistic lock or the shared lock is involved when the SQL statement involves the index , and use the index as the basis for query or judgment, then mysql will use row-level locks to lock the rows to be modified, otherwise it will use table locks to lock the entire table, so you must pay attention to using the index when using it, otherwise it will lead to high Concurrency issues;

The above is the detailed content of Summary of using pessimistic locking in Laravel transactions. For more information, please follow other related articles on the PHP Chinese website!