2 回答

TA貢獻(xiàn)1871條經(jīng)驗(yàn) 獲得超8個(gè)贊
您遇到的更新被稱為丟失更新,這真的不是JPA級(jí)的問題,您可以在MySQL shell中輕松重現(xiàn)此問題。我假設(shè)您沒有在數(shù)據(jù)庫本身中進(jìn)行任何更改,因此您的默認(rèn)事務(wù)隔離級(jí)別是 。REPEATABLE READ
在MySQL中,不會(huì)檢測(cè)到可能的丟失更新(即使這是此隔離級(jí)別的常見理解)。您可以在SO和評(píng)論線程上查看此答案以了解更多信息。REPEATABLE READ
基本上,通過使用MVCC,MySQL試圖避免爭(zhēng)用和死鎖。在你的情況下,你將不得不做出權(quán)衡,并選擇為了一致性而犧牲一些速度。
您可以選擇使用語句或設(shè)置更嚴(yán)格的隔離級(jí)別,即(您可以對(duì)單個(gè)事務(wù)執(zhí)行此操作)。這兩個(gè)選項(xiàng)都將阻止讀取,直到并發(fā)事務(wù)提交/回滾。因此,您將在稍晚一點(diǎn)(或更晚,具體取決于應(yīng)用程序的要求)看到數(shù)據(jù)的一致視圖。SELECT ... FOR UPDATE
SERIALIZABLE
并發(fā)性很難。:)
更新:在考慮了下面的評(píng)論之后,您實(shí)際上還有另一種選擇:為數(shù)據(jù)模型實(shí)現(xiàn)樂觀鎖定。JPA對(duì)此有支持,請(qǐng)看這里和這里。您實(shí)現(xiàn)的目標(biāo)基本上是相同的,但是使用稍微不同的方法(您將不得不重新啟動(dòng)未能不匹配版本的事務(wù)),并且由于鎖定較少,因此爭(zhēng)用較少。

TA貢獻(xiàn)1818條經(jīng)驗(yàn) 獲得超7個(gè)贊
我認(rèn)為您面臨的問題是,F(xiàn)K 關(guān)系的屬性鎖定由關(guān)系的擁有方控制。
由于集合是用它注釋的,因此它不會(huì)控制鎖,因此另一端會(huì)這樣做,這意味著在更新集合時(shí),您將獲得兩個(gè)單獨(dú)的鎖,它們實(shí)際上并不能相互識(shí)別。book_reads
@OneToMany(mappedBy = "reader")
刪除和注釋應(yīng)該可以解決這個(gè)問題。Book_read.reader
mappedBy
所有這些實(shí)際上都適用于具有版本屬性的樂觀鎖定,這是無論如何都要執(zhí)行操作的推薦方法。
另請(qǐng)參閱Vlad Mihalcea關(guān)于該主題的文章:https://vladmihalcea.com/hibernate-collections-optimistic-locking/
添加回答
舉報(bào)