Lock Mode Type 之 Optimistic 使用场景

最新推荐文章于 2024-02-20 17:23:32 发布

Iconoclast_wu

最新推荐文章于 2024-02-20 17:23:32 发布

阅读量4k

点赞数 3

分类专栏： JPA

本文链接：https://blog.youkuaiyun.com/u012807459/article/details/52186702

版权

本文探讨了在JPA中Lock Mode的Optimistic类型的作用，特别是在事务中对象A的改变依赖于对象B的情况。Optimistic锁在事务提交前检查B对象的版本，确保没有被其他事务修改。当数据库隔离级别为Repeatable Read时，可能导致预期的乐观锁定失败，而通过设置隔离级别为Read Committed可以解决此问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

JPA规范中，Lock Mode的值中包含了Optimistic，一看就知道是用于乐观锁控制，但是我一直被这个问题困扰，原因在于，在Entity中，已经使用@Version做了乐观锁控制，Hibernate会自动更新比对，version值，那么设置Lock Mode 为Optimistic又有何用处呢？
先看一段代码

    @PersistenceContext
    EntityManager entityManager;
    @Transactional()
    public Order t3(String str) {
        Order order67 = entityManager.find(Order.class, 67L, LockModeType.OPTIMISTIC);
        order67.setCancelReason(str);
        return order67;
    }

这段代码中使用了entity manager查询order，并且指定了乐观锁，然后在更新order，最初我以为这段代码会触发两条sql语句

select ... from `order` ...;
update `order` set .... where id = ? and version = ?;

但是出乎我意料的是，我看到了第三条sql语句

select version from `order` where id = ?;

于是乎我在find时，去除了Optimistic的配置，发现这第三条sql就不会触发。我百思不得其解，这Optimistic如同鸡肋一样。无意中找到在stack overflow上找到一篇帖子，看到其中一段对话，豁然开朗&#

最低0.47元/天解锁文章