JPA的锁机制

JPA 各种实体锁模式的区别

字数2084 阅读304 评论0 

为了能够同步访问实体,JPA提供了2种锁机制。这两种机制都可以避免两个事务中的其中一个,在不知情的情况下覆盖另一个事务的数据。

通过实体锁,我们通常希望避免在两个并行事务中产生如下情形:

  1. Adam的事务读取数据 X
  2. Barbara的事务读取数据 X
  3. Adam的事务修改数据 X,并将其修改为 XA
  4. Adam的事务写入数据 XA
  5. Barbara的事务修改数据 X,并将其修改为 XB
  6. Barbara的事务写入数据 XB

结果是,Adam所做的修改完全被Barbara所覆盖掉了,但是Barbara对此却毫不知晓。像这样的情况通常被称为“脏读”。显然,我们希望的结果是Adam写入 XA,而Barbara需要在写入 XB之前检查对 XA 的修改。

乐观锁的工作原理

乐观锁基于的假设是实际中冲突很少发生,即使发生,抛出一个错误也比想办法避免它们更容易接受和简单。在乐观锁中,允许一个事务正确完成,但另一个事务需要抛出异常并回滚,并且必须被重新执行或者丢弃。

我们还以Adam和Barbara为例,下面是一个使用乐观锁可能发生的情形:

  1. Adam的事务读取数据 X
  2. Barbara的事务读取数据 X
  3. Adam的事务修改数据 X,并将其修改为 XA
  4. Adam的事务写入数据 XA
  5. Barbara的事务修改数据 X,并将其修改为 XB
  6. Barbara的事务试图写入数据 XB,但是收到一个错误
  7. Barbara需要读取数据 XA(或者重新开始一个新的事务)
  8. Barbara的事务修改数据 XA,并将其修改为 XAB
  9. Barbara的事务写入数据 XAB

如你所见,Barbara被强制要求检查Adam的修改,并且她可以选择继续修改Adam的结果并保存(合并修改)。最后的数据将同时包括Adam和Barbara的修改。

乐观锁完全由JPA控制。它需要在DB表中额外存储一个版本号列。它完全依靠于底层用来存储关系型数据的DB引擎来工作。

悲观锁的工作原理

对于某些人来说,悲观锁更容易接受。当事务需要修改一个可能被其他事务同时修改的实体时,事务会发起一个命令将实体锁住。所有的锁会持续到事务结束后再自动释放。

使用悲观锁的情形可能如下所示:

  1. Adam的事务读取数据 X
  2. Adam的事务锁住 X
  3. Barbara的事务希望读取数据 X,但是因为 X 已经被锁住,只好等待
  4. Adam的事务修改数据 X,并将其修改为 XA
  5. Adam的事务写入数据 XA
  6. Barbara的事务读取数据 XA
  7. Barbara的事务修改数据 XA,并将其修改为 XAB
  8. Barbara的事务写入数据 XAB

如你所见,Barbara又一次被强制的写入 XAB,同时也包含了Adam的修改。但是,这个方案与乐观锁完全不同——Barbara需要等待Adam的事务完成以后才能够读取数据。更甚的是,为了让该场景正确工作,我们需要在两个事务中都手动发起一个lock命令。(因为我们并不确定那个事务先运行,所以两个事务都需要在修改数据前先进行锁定)虽然乐观锁要为每个实体增加一个版本列,比悲观锁工作略多,但是之后我们不需要再在事务中发起锁操作了。JPA会自动完成所有的检查,我们只需要处理可能的异常即可。

悲观锁使用底层数据库提供的锁机制来锁住表中已有的记录。JPA需要知道如何触发这些锁,并且尚不能完全支持某些数据库。

即使是JPA规范中也说到,不需要提供PESSIMISTIC_READ(因为许多DB只支持WRITE锁):

允许JPA实现用LockModeType.PESSIMISTIC_WRITE来代替LockModeType.PESSIMISTIC_READ,但是反之不可。

JPA中可用的锁类型

首先,我想说,对于实体中有添加了@Version注解的列,JPA会自动对该实体使用乐观锁。你不需要使用任何锁命令。但是,你可以在任何时候发起一个以下类型的锁:

  1. LockModeType.Optimistic
    1. 这就是默认的锁类型。也是如ObjectDB所说通常被大家所忽略的锁类型。在我的印象中,只有在需要动态获取并传递锁类型时,才会用到它,即使我们很清楚最后的锁是OPTIMISTIC的。虽然这个例子不太恰当,但是一个好的API设计,即使是默认值也应该为其提供一个可选项。
    2. 示例:Java
LockModeType lockMode = resolveLockMode();
A a = em.find(A.class, 1, lockMode);
  1. LockModeType.OPTIMISTIC_FORCE_INCREMENT

    1. 这个选项很少被用到。但是如果你希望用另一个实体来锁住对当前实体的引用,就需要使用它。换句话说,即使当前实体没有被修改,但是其他实体可能因为当前实体被修改,你就可以用它来锁住对当前实体的引用。
    2. 示例:
      1. 假设我们有两个实体“书(Book)”和“书架(Shelf)”。我们可以将书添加到书架中,但是书不持有对其书架的引用。我们需要对所有移动书到其他书架的动作加锁,以避免一本书被放在2个书架上。为了锁住这个动作,光锁住当前的书架实体是不够的,因为书可能还没有放到某个书架上。锁住所有书架也不合理,因为他们在不同的事务中可能都是不同的。唯一合理的是锁住书实体本身,即使在我们这个例子中它并没有发生变化(因为它并不持有其书架的引用)。
  2. LockModeType.PESSIMISTIC_READ

    1. 这个模式类似于LockModeType.PESSIMISTIC_WRITE,但是有一点不同:如果没有事务对实体加写锁,那么就不能阻塞对该实体的读取。它还允许其他事务使用LockModeType.PESSIMISTIC_READ来加锁。WRITE锁和READ锁之间的区别,已经被这两篇文章(here (ObjectDB) 和 here (OpenJPA))很详细的说明了。但是,不仅因为规范中允许,而且许多实现也没有分开处理,所以该锁模式经常被等价于LockModeType.PESSIMISTIC_WRITE
  3. LockModeType.PESSIMISTIC_WRITE

    1. 这是LockModeType.PESSIMISTIC_READ的增强版。当WRITE锁发生时,JPA在数据库的帮助下,会阻止其他事务读取实体,而不像READ锁那样只禁止写入。
  4. LockModeType.PESSIMISTIC_FORCE_INCREMENT

    1. 这是另一个很少使用的锁模式。但是,它可以用来结合PESSIMISTICOPTIMISTIC时使用。在以下场景中,单独使用PESSIMISTIC_WRITE是无效的:

      1. 事务A使用乐观锁并读取实体E
      2. 事务B请求实体E上的WRITE锁
      3. 事务B提交并释放E上的锁
      4. 事务A更新E并提交
    2. 在步骤4中,如果事务B没有增加版本列的值,那么就无法阻止事务A覆盖B的修改。即使事务B使用的是悲观锁,锁模式LockModeType.PESSIMISTIC_FORCE_INCREMENT也会强制事务B更新版本号,并让事务A失败并抛出OptimisticLockException

为了发起一个指定类型的锁,JPA提供了以下方法:

你可以使用JPA中这两种锁机制中的任意一种。如果需要,也可以选择悲观锁类型PESSIMISTIC_FORCE_INCREMENT,把二者混起来用。

转自:http://www.jianshu.com/p/4bc01d3c980a

posted @ 2016-05-23 17:03 Jeremy_software 阅读(...) 评论(...) 编辑 收藏