【问题标题】:Optimistic Locking in Hibernate by defaultHibernate 中默认的乐观锁定
【发布时间】:2012-04-12 08:10:13
【问题描述】:

我有一个关于 Hibernate 中的乐观锁定的问题。我正在尝试深入了解 Hibernate 的乐观锁定,但我有一个疑问。 Hibernate 使用版本方法(整数或时间戳)来实现乐观锁定。要进行配置,您可以使用 @Version 注释(或 xml 配置)并创建版本属性。另一个选项是使用optimistic-lock="all" 属性在不进行版本控制的情况下进行配置。

我的问题是,如果您没有定义任何版本控制属性并且您没有指定乐观锁属性,那么在这种情况下哪种策略使用 Hibernate?悲观锁定我很确定不是,所以我认为这是乐观锁定,但不知道如何。

非常感谢您的关注。

【问题讨论】:

    标签: hibernate optimistic-locking


    【解决方案1】:

    如果您没有将 Hibernate 配置为使用乐观锁定,那么它根本不使用任何锁定。所以,在这种情况下,最后一次更新总是获胜。

    为了清楚起见,请注意 Hibernate 乐观锁定与 DBMS 事务隔离完全不同。 Hibernate 乐观锁定仅适用于您在一个事务中加载对象、修改它并稍后在另一个事务中保存它的情况。在这种情况下,乐观锁定可确保其他一些事务在两者之间没有更改数据库中的该对象。但是,乐观锁定不会影响并发事务的隔离——因此,无论是否启用 Hibernate 锁定,DBMS 内部用于实现事务隔离的锁(乐观或悲观)仍然有效。

    【讨论】:

      【解决方案2】:

      @axtavt,你说得对,但是关于 hibernate 如何在没有@Version 列的情况下实现乐观锁定的问题。

      今天有四个OptimisticLockType 可用选项:

      /**
       * Perform no optimistic locking.
       */
      NONE,
      /**
       * Perform optimistic locking using a dedicated version column.
       *
       * @see javax.persistence.Version
       */
      VERSION,
      /**
       * Perform optimistic locking based on *dirty* fields as part of an expanded WHERE clause restriction for the
       * UPDATE/DELETE SQL statement.
       */
      DIRTY,
      /**
       * Perform optimistic locking based on *all* fields as part of an expanded WHERE clause restriction for the
       * UPDATE/DELETE SQL statement.
       */
      ALL
      

      我认为这足以回答最初的问题。

      【讨论】:

      猜你喜欢
      • 2016-07-18
      • 2018-10-22
      • 2018-03-29
      • 1970-01-01
      • 1970-01-01
      • 2015-05-14
      • 1970-01-01
      • 2016-11-20
      • 2013-09-16
      相关资源
      最近更新 更多