Optimistic Offline Lock乐观离线锁

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