JPA 各种实体锁模式的区别

Wesley13
• 阅读 452

为了能够同步访问实体,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);

  2. LockModeType.OPTIMISTIC_FORCE_INCREMENT

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

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

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

    1. 这是另一个很少使用的锁模式。但是,它可以用来结合PESSIMISTIC和OPTIMISTIC时使用。在以下场景中,单独使用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,把二者混起来用。

原文地址

简书地址,欢迎各位打赏!

点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
待兔 待兔
4个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
Easter79 Easter79
3年前
TiDB 性能竞赛 11.16
TiDB实现了快照隔离级别的分布式事务,支持悲观锁、乐观锁,同时也解决了大事务的难点。事务是数据库的基础,提供高效的、支持完整ACID的分布式事务更是分布式数据库的立足之本。事务是数据库执行的最小单元,允许用户将多个读写操作组合为一个逻辑单元。事务需要满足原子性、一致性、隔离性和持久性,也就是ACID。数据库有多种并发控制方法,乐观并发控制(
Wesley13 Wesley13
3年前
MySQL 乐观锁和悲观锁
前言  1)在数据库的锁机制中介绍过,数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和一致性以及数据库的一致性。  2)加锁是为了解决更新丢失问题更新丢失  两次更新同时进行,后一次更新覆盖了前一次更新的情况,更新丢失是数据没有保证一致性导致的。事务A查询余额,
Wesley13 Wesley13
3年前
MySQL 空事务
   问题描述;   研发同事反应MySQL数据库有锁,检查innodb\_trx时,发现有很多长时间未结束的空事务。   这些事务的trx\_mysql\_thread\_id都为0,因此不能通过kill  id的方式强制关闭这些长时间未结束的僵尸事务。           SELECT       tr
Wesley13 Wesley13
3年前
MySQL数据库InnoDB存储引擎Log漫游(1)
作者:宋利兵来源:MySQL代码研究(mysqlcode)0、导读本文介绍了InnoDB引擎如何利用UndoLog和RedoLog来保证事务的原子性、持久性原理,以及InnoDB引擎实现UndoLog和RedoLog的基本思路。00–UndoLogUndoLog是为了实现事务的原子性,
Wesley13 Wesley13
3年前
mysql面试题总结
1.Mysql中的myisam与innodb的区别?2.InnoDB存储引擎的四大特性?3.什么是事务?4.数据库事务的四大特性?5.不考虑事务的隔离性,会发生几种问题?6.MySQL数据库提供的四种隔离级别?7.有多少种日志?8.事务是如何通过日志来实现的?9.数据库的乐观锁和悲观锁是什么?10.什
Wesley13 Wesley13
3年前
(二)分布式数据库tidb
tidb既然是分布式数据库,所以它的事务应该可其它数据库事务有着不同的区别。我们来了解下tidb的数据库事务。(一)事物  1.几种数据库的默认隔离级别:tidb是乐观锁 !(https://img2018.cnblogs.com/blog/1766027/201909/1766027201909062133
Wesley13 Wesley13
3年前
MySQL常见问题
事务四大特性原子性:不可分割的操作单元,事务中所有操作,要么全部成功;要么撤回到执行事务之前的状态一致性:如果在执行事务之前数据库是一致的,那么在执行事务之后数据库也还是一致的;隔离性:事务操作之间彼此独立和透明互不影响。事务独立运行。这通常使用锁来实现。一个事务处理后的结果,影响了其他事务,那么其他事务会撤回。
线上SQL超时场景分析-MySQL超时之间隙锁 | 京东物流技术团队
前言之前遇到过一个由MySQL间隙锁引发线上sql执行超时的场景,记录一下。背景说明分布式事务消息表:业务上使用消息表的方式,依赖本地事务,实现了一套分布式事务方案消息表名:mqmessages数据量:3000多万索引:createtime和statuss