JPA 2.0的語義OPTIMISTIC_FORCE_INCREMENT

Question

我對JPA相當陌生，並且在JPA2.0中閱讀關於鎖定模式的文章this，這給我留下了一個關於LockModeType.OPTIMISTIC_FORCE_INCREMENT的問題。

這裏是從文章一例的印象：http://i.stack.imgur.com/dFjhZ.jpg

到目前爲止，據我所知，在事務T1明確的樂觀鎖是唯一必要的，如果我更新到實體A依賴於另一個實體B的狀態剛剛閱讀。

我也明白，使用OPTIMISTIC_FORCE_INCREMENT鎖導致B到更新的版本屬性，這將導致OptimisticLockException在嘗試更新B和讀過它發出鎖定之前，所有交易（即與舊版本值） 。

我的問題是：如果另一個事務T2在B版本增加後立即啓動，在T1提交之前更改B並完成，會發生什麼？

據我瞭解，T1應該得到一個OptimisticLockException。如果是這樣，這個鎖定點有什麼意義，因爲它只是略微減少了T1的脆弱時間窗口？這將意味着：如果我想確保B在T1完成前不被更改，我需要一個悲觀的鎖，對吧？

預先感謝明確告知我:)

Answer 1

你的榜樣的問題凸顯，爲什麼這個被稱爲「樂觀」鎖定。這並不完美，但是如果在現實世界中有很多情況就足夠了，並且它比硬鎖更少使用資源（包括時間）。

當使用這種類型的鎖定時，您正在進行性能交易，並且通常會改進可用性，並且認爲您的交易在大多數情況下都會正常工作，並且您可以確信，在不確定的情況下如果不行，你會收到通知（例外情況會被拋出），然後你可以退後一步，「做正確的事情」：再試一次，放棄，但是你選擇處理異常。

悲觀鎖定對於需要某種級別的鎖定的高性能事務系統可能是非常不合適的，但它們發生碰撞的可能性很小：xTunes的數百萬用戶中有多少人（名稱已更改以保護無辜..）「訂單」（更新）在任何時候，有多少人都訂購（更新）從同一個帳戶？

Answer 2

如果在B的版本 增加後又開始另一個事務T2，在T1提交之前更改B並完成之後會發生什麼？

不管RDBMS你要使用，即使它使用MVCC（多版本併發控制）或2PL（兩階段鎖定），當您更改表格行，排它鎖被收購，只有在當前正在運行的事務結束（提交或回滾）時纔會釋放。

因此，一旦您遞增B的版本，在您提交事務之前，沒有其他事務可以更改該記錄。

還值得一提的是​​和PESIMISTIC_FORCE_INCREMENT之間的區別。 OPTIMISTIC_FORCE_INCREMENT會在交易結束時執行版本增量，而PESIMISTIC_FORCE_INCREMENT則會立即執行版本。

如果在該特定實體上存在較大的爭用，那麼PESIMISTIC_FORCE_INCREMENT更具吸引力，因爲一旦獲得鎖定，就不允許其他事務修改該記錄，並且由於樂觀的版本不匹配，您的事務不會回滾故障。