我有一個關於悲觀LockModes,在休眠3.3.2.ga可用兩個問題:Hibernate的LockMode釋放和快速失敗如果鎖不能獲得
如果我使用鎖一組行lockmode UPGRADE,當你移出事務處理範圍時鎖是否被釋放?如果是的話,我們可以在交易中鎖定解鎖嗎?
對於以下情形,其中LockMode將是有用的
線程1,嘗試獲取鎖和鎖定一組行
線程2的,試圖在獲得鎖同一組行(此時被線程1鎖定)此時線程2得到一個異常,表示行被鎖定
這將是最好的pe ssimistic LockMode?
我有一個關於悲觀LockModes,在休眠3.3.2.ga可用兩個問題:Hibernate的LockMode釋放和快速失敗如果鎖不能獲得
如果我使用鎖一組行lockmode UPGRADE,當你移出事務處理範圍時鎖是否被釋放?如果是的話,我們可以在交易中鎖定解鎖嗎?
對於以下情形,其中LockMode將是有用的
線程1,嘗試獲取鎖和鎖定一組行
線程2的,試圖在獲得鎖同一組行(此時被線程1鎖定)此時線程2得到一個異常,表示行被鎖定
這將是最好的pe ssimistic LockMode?
的LockMode.UPGRADE使用select ... for update
,所以鎖被持有the whole duration of the current transaction。釋放鎖的唯一方法是提交或回滾事務。
A select ... for update
鎖將導致第二個事務等待第一個釋放鎖。如果你想快速失敗,你需要使用:UPGRADE_NOWAIT,它將使用select ... for update no wait
查詢,如果無法獲取鎖定(這由Oracle和PostgreSQL支持),則會引發異常。
或者,您可以使用Hibernate LockOptions
如下:
entityManager
.unwrap(Session.class)
.buildLockRequest(
new LockOptions(LockMode.PESSIMISTIC_WRITE)
.setTimeOut(LockOptions.NO_WAIT))
.lock(entity);
有關詳細信息,請參閱我的Transactions and Concurrency Control presentation從Voxxed天蘇黎世。
感謝弗拉德,試圖實現一個悲觀的鎖,在MySQL中沒有等待條件,但似乎不可能。將不得不採取樂觀的版本檢查策略。 –
這是你今天的作業嗎? – bish
不需要處理業務用例。 :) –