Optimistic Offline Lock乐观离线锁

  • 通过冲突检测和(发生冲突时的)事务回滚,来防止并发业务事务中的冲突.
    •  Optimistic Offline Lock乐观离线锁_第1张图片
    • 通常一个业务事务的执行,会跨越一系列的系统事务.
      • 一旦超出了单个系统事务的范围,就不能仅依靠DB管理程序来保证数据一致性.
    • 乐观离线锁
      • 假设冲突的发生可能性很小.
      • 使多用户并发地对同一份数据进行处理成为可能.
      • 在同一业务事务中,进行预验证和对数据的修改.
      • 一个成功的预验证可以视为得到一个锁,来表示能够成功地完成对数据的修改.
  • 运行机制
    • 原理:通过检查在(业务事务)会话读取一条记录后,没有其它的会话修改该记录来保证数据的一致性.
    • 可以在任何时间获取该锁,但是它只在获得该所的系统事务过程中有效.
      • 系统事务中只有有对DB的修改,就需对每个变更成员申请该锁.
    • 实现
      • 为每条记录关联一个Version.
        • 在加载记录时,由会话本身来维护版本号.
        • 获取锁的动作,就是将会话数据中的版本号与DB中记录当前的版本号进行对比.验证成功时,所有变化(包括版本号的增加)可以提交.
        • 通过增加版本号来避免不一致的记录.使用旧版本号的会话无法获得乐观离线锁.
        • 一条SQL语句就可以同时获取锁(根据会话的版本号来检索DB)和更新数据.
          • 通过检查SQL执行结果返回的行数得知是否成功.1代表成功.0代表记录被更改或删除.
          • 不成功时,要么取消业务事务,要么解决冲突并重试.
        • 除了Version,还可以附加上一下最后修改该记录的信息(Who,When).以便于冲突发生时的管理.
      • 在更新时的SQL语句中的where子句中包含对所有字段的检查.
        • 好处是不用增加版本号字段.
        • 但是造成了很长的where语句.损害性能.
      • 当事务只依赖于一个数据行的存在与否,或者仅是其中的一个字段.那么更应该使用条件判断而不是版本控制来提供灵活性.
      • 一个更简单的方式是把业务事务的所有步骤放在一个长的DB事务中.
      • 企业应用中的并发管理更是一个领域问题,而不是技术上的问题.
      • 乐观离线锁的实例:SCM
        • 当SCM检测到冲突时,会自动合并修改并重新提交.
        • 所以,配合了高效的合并策略后,乐观离线锁会更加的强大.
        • 在企业应用中,合并业务数据需要特殊的代码处理.
      • 该锁只会在最后的提交阶段时报告冲突.
        • 可以在之前的步骤中checkcurrent()来预判别人是否更改了数据.
  • 使用时机
    • 业务事务的冲突率很低时.
    • 并发管理的目标是尽可能增加对数据的并发访问,同时减少冲突.
    • 所以,应考虑的是光有乐观锁是不是还不够.需不需要补充上悲观离线锁.

 

你可能感兴趣的:(Lock)