Analyse der Nutzungsprobleme der exklusiven Laravel-Sperre lockForUpdate()

                                                        Ar Das Folgende wird durch das aLaravel-Tutorial eingeführt.

Für die exklusive Sperre von MySQL habe ich einen Test durchgeführt, um zu sehen, ob es einen exklusiven Effekt gibt.

Test 1: Testen Sie die exklusive Sperre auf der Befehlszeile

Erster Test auf der Befehlszeile, öffnen Sie zwei Befehlszeilen

Fügen Sie zuerst eine exklusive Sperre auf Befehlszeile 1 hinzu:

Testen Sie dann den Zugriff auf Befehlszeile 2 :

Sie können sehen, dass es tatsächlich blockiert ist, nachdem der Commit in Befehlszeile 1 abgeschlossen wurde, und das Ausführungsergebnis auch in Befehlszeile 2 ausgeführt wird.
Es ist also kein Problem, die exklusive Sperre in der Befehlszeile zu testen.



Test 2: Testen Sie die exklusive Sperre in Laravel-Controller-Methode

Testen wir die exklusive Sperre in Laravel:

Zwei Routen:

Route::get('/locktest1','LockController@ LockTest1' );Route::get('/locktest2','LockController@LockTest2');LockTest1 und im Controller LockTest2 code>Der Inhalt dieser beiden Methoden ist derselbe:

DB::beginTransaction(); // 开启事务
$goods = Goods::lockForUpdate()->first();
print_r($goods);

Zuerst auf die Route /locktest1 zugreifen und die Daten normal ausdrucken. Ich persönlich vermute, dass die Transaktion zu diesem Zeitpunkt noch nicht abgeschlossen ist ist eine weitere Anfrage zum Zugriff auf die Datentabelle, die blockieren sollte.
Wenn ich hier also auf /locktest2 zugreife, werden die Daten normal ausgedruckt. Warum gibt es keine Sperrwirkung?
Route::get('/locktest1','LockController@LockTest1');
Route::get('/locktest2','LockController@LockTest2');
控制器中的 LockTest1和LockTest2这两个方法内容都一样：

DB::beginTransaction(); // 开启事务
$goods = Goods::lockForUpdate()->first();
print_r($goods);sleep(10);echo 'ddd';

先访问路由/locktest1，正常打印出数据，个人猜想此时事务没有关闭，如果再有访问数据表的请求，应该是阻塞的。
所以在此访问/locktest2，结果还是正常打印出数据，为什么没有产生阻塞效果呢？

测试3：laravel控制器方法与命令行混合测试排他锁

1、先在命令行里开启事务添加排他锁，同测试1里的命令行1的操作；
然后访问路由/locktest1，页面一直运行中，说明查询数据存在阻塞；
最后命令行里commit提交。
2、先访问路由/locktest1，正常打印出数据；
然后在命令行里开启事务添加排他锁，同测试1里的命令行1的操作，发现正常查询出数据，没有阻塞；说明laravel的控制器方法里的排他锁操作确实没有成功。

总结：为什么laravel的lockForUpdate()没有效果呢，还是说laravel控制器方法执行完毕后，会自动结束事务才导致没有阻塞效果的？

于是，再次做下面测试：
将路由1的控制器方法里加了一个sleep()方法：

rrreee

然后，访问路由1/locktest1，页面在等待刷新；再访问路由2/locktest2，页面也在等待刷新，说明应该是产生数据阻塞了，因为路由2中没有sleep()，正常情况下是立即执行的。
10秒过后，/locktest1页面打印出数据，同时/locktest2

Test 3: Laravel-Controller-Methode und Befehlszeilentest mit exklusiver Sperre

1 Öffnen Sie zunächst die Transaktion in der Befehlszeile, um eine exklusive Sperre hinzuzufügen, genau wie die Operation von Befehlszeile 1 in Test 1;

Dann greifen Sie auf die Route /locktest1 zu, die Seite wurde ausgeführt, was darauf hinweist, dass die Abfragedaten blockiert sind.

Schließlich in der Befehlszeile festschreiben. 2. Greifen Sie zuerst auf die Route /locktest1 zu und drucken Sie die Daten normal aus. Dann öffnen Sie die Transaktion in der Befehlszeile, um eine exklusive Sperre hinzuzufügen. Das wurde mit der gleichen Operation wie in Befehlszeile 1 gefunden Die Daten werden normal abgefragt. Es gibt keine Blockierung. Dies bedeutet, dass der exklusive Sperrvorgang in der Controller-Methode von Laravel nicht erfolgreich war.

🎜🎜🎜🎜🎜Zusammenfassung: Warum hat lockForUpdate() von Laravel keine Wirkung? Oder wird die Transaktion automatisch beendet, nachdem die Laravel-Controller-Methode ausgeführt wurde, was zu keiner blockierenden Wirkung führt? 🎜🎜🎜Führen Sie also den folgenden Test noch einmal durch: 🎜Fügen Sie eine Sleep()-Methode zur Controller-Methode von Route 1 hinzu: 🎜rrreee🎜Dann besuchen Sie Route 1 /locktest1, die Seite wartet darauf, geöffnet zu werden aktualisiert; dann Beim Zugriff auf Route 2 /locktest2 wartet die Seite ebenfalls auf die Aktualisierung, was darauf hinweist, dass Daten blockiert werden sollten, da in Route 2 kein Sleep () vorhanden ist und sie sofort ausgeführt wird normale Umstände. 🎜Nach 10 Sekunden druckt die Seite /locktest1 Daten aus, und die Seite /locktest2 druckt ebenfalls Daten aus. 🎜🎜🎜🎜 Demnach hat der obige Test 3 keinen Sperreffekt erzeugt, der durch das automatische Ende der Transaktion nach Beendigung der Controller-Methode verursacht werden sollte. 🎜🎜Das Obige ist eine persönliche Analyse. Wenn ein Meister vorbeikommt, hinterlassen Sie mir bitte eine Nachricht, um mir die richtige Antwort zu sagen! 🎜🎜Weitere Kenntnisse zum Thema Programmierung finden Sie unter: 🎜Programmierlehre🎜! ! 🎜

Das obige ist der detaillierte Inhalt vonAnalyse der Nutzungsprobleme der exklusiven Laravel-Sperre lockForUpdate(). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!