jpa休眠死鎖，帶有簡單的查找更新-有解無憂

當 2 個事務正在執行時，我經常遇到死鎖：

entitymanager.find by id，特別是沒有鎖定模式
entitymanager.merge，特別是沒有鎖定模式

它們都在@Transactional 下，默認隔離是可重復讀取，在 mysql 5.7 下。物體作為id PK autoincrement 一樣常用。如果重要的話，沒有@Version...

發生的事情是這樣的：

txn A 找到行
txn B 找到行
txn A 嘗試更新并因此升級為獨占 X 鎖但等待，因為似乎在來自 txn B 的行上存在共享（S）（讀取）鎖
txn B 嘗試更新并因此升級為獨占 X 鎖，但它是在 txn A 之后，由 B 本身阻止。現在這被檢測為死鎖，因此其中一個 txn 將回滾。

SHOW ENGINE INNODB STATUS (SEIS) 顯示最后檢測到的死鎖。它清楚地表明存在共享 (S) 鎖。

這是我來自 prod 的 SEIS（為了隱私而重新標記）。

*** (1) TRANSACTION:
TRANSACTION 175274419, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 8 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 2
MySQL thread id 627088, OS thread handle 22952098592512, query id 365172765 192.168.1.100 mydatabase updating

update thing set needs_checkup=0 where id=1129

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 361 page no 25 n bits 144 index PRIMARY of table `mydatabase`.`thing` trx id 175274419 lock_mode X locks rec but not gap waiting


*** (2) TRANSACTION:
TRANSACTION 175274420, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
8 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 2
MySQL thread id 627077, OS thread handle 22952240928512, query id 365172766 192.168.1.100 mydatabase updating

update thing set needs_checkup=0 where id=1129

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 361 page no 25 n bits 144 index PRIMARY of table `mydatabase`.`thing` trx id 175274420 lock mode S locks rec but not gap
 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 361 page no 25 n bits 144 index PRIMARY of table `mydatabase`.`thing` trx id 175274420 lock_mode X locks rec but not gap waiting

*** WE ROLL BACK TRANSACTION (2)

令人驚訝的是：我在 org.hibernate.SQL 上啟用了休眠除錯級別以查看陳述句，并且沒有一個顯示任何“選擇...鎖定共享模式”（也沒有選擇...進行更新）。

（我加倍努力，使用wireshark通過埠3306對mysql協議進行了資料包嗅探，沒有任何特殊鎖定模式的提示，也沒有除了通常的“設定會話事務讀寫”與“.. . 只讀”不時，這對鎖定沒有影響）。

顯然在步驟 1 和步驟 3 之間有足夠的時間讓 txn B 潛入。所以我認為這個共享鎖不是更新陳述句的瞬間效果。如果是這樣，我們就不會那么容易陷入僵局。所以我認為共享鎖來自“查找”。

問題是這是在哪里配置的？對于我閱讀的所有檔案，默認鎖定模式是 LockMode.NONE。

如果我在 2 個會話中撰寫原始 sql，如下所示（并使用事務讀寫模式，默認）我不會遇到死鎖：

txnA: select * from foo where id = 1;
txnB: select * from foo where id = 1;
txnA: 更新 foo set x=x 1 where id = 1;
txnB：更新 foo 集 x=x 1000 其中 id = 1；

但是如果我寫這個，那么我會遇到同樣的僵局：

txnA: select * from foo where id = 1 lock in share mode ;
txnB: select * from foo where id = 1 lock in share mode ;
txnA: 更新 foo set x=x 1 where id = 1;
txnB：更新 foo 集 x=x 1000 其中 id = 1；

現在，我不想在查找中使用 X（或 U）鎖，如UPDATE 鎖如何防止常見形式的死鎖中所述？.

I want to just lock less, as the raw SQL seems to allow. So again, the question is where is this configured? why is this shared lock requested? How does hibernate even get to that point if none of the sql statement I see in the sniffed packets even hint at those shared locks?

Thanks.

uj5u.com熱心網友回復：

令人驚訝的是：我在 org.hibernate.SQL 上啟用了休眠除錯級別以查看陳述句，并且沒有一個顯示任何“選擇...鎖定共享模式”（也沒有選擇...進行更新）。(...) 問題是這是在哪里配置的？對于我閱讀的所有檔案，默認鎖定模式是 LockMode.NONE。

當然，默認鎖定行為是在 RDBMS 中配置的。它也稱為隔離級別。你說你的設定為REPEATABLE READ，所以讀鎖和寫鎖都保持到事務結束。

除非明確要求，否則您似乎對期望沒有使用鎖感到困惑。這根本不是它的作業原理。一個SELECT陳述句總是獲得一個讀鎖和UPDATE陳述句總是獲取寫鎖。百萬美元的問題是這些鎖何時被釋放，這就是隔離級別控制的內容。

我只想少鎖

那么，切換到更寬松的隔離級別 - READ COMMITED，如果您的用例不關心不可重復讀取。

或者，如果對 DB 行的爭用很少并且您的更新操作相對便宜，請使用樂觀鎖定，如@roccobaroccoSC 建議的那樣。

或者，如果爭用動態變化，請嘗試混合方法：首先，嘗試樂觀鎖定 n 次，如果失敗，則使用悲觀鎖定，并預先呼叫em.find(..., LockMode.PESSIMISTIC)。

uj5u.com熱心網友回復：

您對非鎖定讀取的期望是正確的，并且檔案明確指出相同：https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html，但是我確實相信您對情況的分析不完整 - 當您執行跟蹤時，您可能會忽略一些看起來與您無關的陳述句，但從 InnoDB 的角度來看，這些陳述句可能是有意義的，例如考慮以下資料庫結構：

mysql> create table t(id int(11), v int(11));
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> insert into t(id,v) primary key, values(1,1),(2,2);
Query OK, 2 rows affected (0.00 sec)

mysql> select * from t;
 ------ ------ 
| id   | v    |
 ------ ------ 
|    1 |    1 |
|    2 |    2 |
 ------ ------ 
2 rows in set (0.00 sec)

由于v列上的“缺少”索引，下一條陳述句實際上鎖定了整個表：

mysql> update t set v=4 where id<2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> show engine innodb status;
...
---TRANSACTION 3672, ACTIVE 2 sec
3 lock struct(s), heap size 1128, 2 row lock(s), undo log entries 1

這對我們來說是違反直覺的，但在檔案中有所描述：https : //dev.mysql.com/doc/refman/8.0/en/innodb-locks-set.html：

UPDATE ... WHERE ... 在搜索遇到的每條記錄上設定一個獨占的 next-key 鎖。但是，對于使用唯一索引鎖定行以搜索唯一行的陳述句，只需要索引記錄鎖。

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/380108.html

標籤：java mysql hibernate jpa deadlock

上一篇：為什么物體物件不相等，如果我用另一個具有集合元素的提取物件獲取該物件之一，盡管它們應該是？

下一篇：T-SQL：將int視為作業日

jpa休眠死鎖，帶有簡單的查找 更新

jpa休眠死鎖，帶有簡單的查找更新