我有一个关于悲观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
不需要处理业务用例。 :) –