好吧,您正试图陷入僵局,并且成功了:-)
- Transaction1开始,与您的实体更新(和锁定)行。
- Transaction2尝试执行相同 *** 作,但由于行仍处于锁定状态而无法执行。因此它等待(并等待,然后等待)直到超过超时时间
现实生活中的 模拟将具有第一和第二实体管理器,以及在单独线程中进行适当的更新/交易。这样,您将拥有:
- Transaction1开始,与您的实体更新(和锁定)行。
- Transaction2尝试执行相同 *** 作,但由于行仍处于锁定状态而无法执行。因此它等待(然后等待,然后等待)…
- 同时,Transaction1已提交并且锁已释放
- 现在可以进行Transaction2
请注意,此时(上面的#4)您将覆盖Transaction1所做的更改。Hibernate可以使用乐观锁定和悲观锁定来防止这种情况的发生。
更新 (基于评论):
如果对实体进行版本控制,则Transaction2(上面的#4)将失败。但是,由于如上所述Transaction2无法获得锁,因此您发布的代码无法达到目的。如果要专门测试开放式版本控制是否正常工作,可以执行以下 *** 作:
- 获取em1,启动事务,获取您的实体, 提交 事务, 关闭 em1。
- 获取em2,开始事务,获取您的实体,更新您的实体,提交事务,关闭em2。
- 获取em3,启动事务,尝试更新您在步骤1中加载的实体-测试应在此处失败。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)