使用JPA,我們可以手動使用OPTIMISTIC
或PESSIMISTIC
鎖定來處理事務中的實體更改。JPA和默認鎖定模式
我想知道JPA如何處理鎖定,如果我們不指定這兩種模式之一? 不使用鎖定模式?
如果我們沒有定義顯式鎖定模式,數據庫完整性是否會丟失?
感謝
使用JPA,我們可以手動使用OPTIMISTIC
或PESSIMISTIC
鎖定來處理事務中的實體更改。JPA和默認鎖定模式
我想知道JPA如何處理鎖定,如果我們不指定這兩種模式之一? 不使用鎖定模式?
如果我們沒有定義顯式鎖定模式,數據庫完整性是否會丟失?
感謝
我已經通過Java Persistence API 2.0 Final Release規範第3.4.4 鎖模式掃描,雖然我無法找到任何具體(它沒有說這是默認或類似的東西)有一個腳註說,以下。
鎖定模式類型NONE可能被指定爲鎖定模式的值 參數,並且還提供了註釋的默認值。
該部分是關於可用的LockModeType
值的種類和它們的用法,並描述哪些方法需要這種類型的參數和什麼。
因此,正如它所說的,LockModeType.NONE
是註釋的默認值(JPA,左右註釋),我猜你在使用EntityManager.find(Class, Object)
時使用默認的LockModeType
。
還有一些其他的,微妙的,暗示加強這一點。 3.1.1節EntityManager接口。
find方法(只要它會被調用在鎖定或與 LockModeType.NONE調用)並且是 在事務上下文中調用不需要的getReference方法。
它是有道理的。例如,如果你使用MySQL作爲你的數據庫,你選擇的數據庫引擎是InnoDB,那麼(默認情況下)你的表將使用REPEATABLE READ
,如果你使用其他的RDBMS或其他數據庫引擎,這可能會改變。
現在我不確定隔離級別與JPA鎖定模式有什麼關係(儘管看起來像這樣),但我的觀點是不同的數據庫系統有所不同,因此JPA無法爲您決定(在至少根據規範)默認使用哪種鎖定模式,所以如果不另外指示,它將使用LockModeType.NONE
。我也發現an article regarding isolation levels and lock modes,你可能想要閱讀它。
哦,並回答你最後一個問題。
如果我們沒有定義明確的鎖定模式,那麼數據庫 的完整性是否會丟失?
這取決於,但如果你有併發事務那麼答案很可能是肯定的。
由於JPA 2.1 FR
3.2版屬性
Version字段或屬性用於由持久性提供執行樂觀鎖。它是在執行實體實例的生命週期操作的過程中由持久性提供者訪問和/或設置的。 如果實體具有使用版本映射映射的屬性或字段,則會自動啓用實體進行樂觀鎖定。
因此,如果實體是版本化對象,如@Version已被指定,則默認持久性提供程序將執行樂觀鎖定。
在說明書persistence_2.0,第89頁:
如果一個版本的對象,否則更新或刪除,則實現必須確保LockModeType.OPTIMISTIC_FORCE_INCREMENT的 要求得到滿足,即使沒有明確的調用EntityManager.lock進行了 。以前在這裏提交的答案
形式,它似乎像JPA的行爲方式如下:如果我的實體有@Version註釋字段中沒有LockModeType已定,那麼LockModeType.OPTIMISTIC_FORCE_INCREMENT將被默認設置。它是否正確 ?
謝謝你的建設性答案和鏈接。我將再次閱讀並嘗試理解LockModeType.NONE以及這意味着什麼。事實是,我是JPA的新成員,我不確切知道應鎖定哪些實體以保持完整性。這可能無聊,但我會用事務模擬(Thread.sleep())來測試所有模式。再次感謝 –