• 每次只允许一个业务事务来访问数据,以防止并发业务事务中的冲突.
  •  
  • 离线并发处理通常会出现多个业务事务操作同一数据.
  • 最简单的办法是为整个业务事务保持一个系统事务.但是事务系统不适合于处理长事务.
  • 首选乐观离线锁.
  • 而悲观离线锁,作为它的补充.从一开始就避免冲突.
    • 它要求业务事务在对数据进行操作前就必须获取该数据的锁.
    • 一旦开始了一个业务事务,就确信不会再提交时由于并发冲突而被迫回滚数据.
• 运行机制
  • 决定使用哪种锁
    • exclusive write lock独占写锁.写目的的会话数据时使用,当对数据的读取要求不高时.
    • exclusive read lock独占读锁.仅是为了读目的时的数据.限制了并发性.
    • read/write lock读/写锁.
      • 读锁和写锁互斥,同一数据记录上只能被附加上一种.
      • 允许并发的读锁.读锁会防止其他业务事务修改数据.但是允许其他业务事务读取记录.
      • 允许同时读增加了系统的并发性.但是其实现复杂.
  • 构建锁管理对象
    • 该对象负责授予或者拒绝业务事务获取/释放锁的请求.
    • 必须知晓被锁住的资源,和锁的拥有者(业务事务).
    • 只能有一张关于锁的表.该表存在于内存或者SQL语句实现的.
    • 锁必须是管理对象的私有域.业务事务只能与管理对象交互,而不能直接操作锁对象.
  • 定义业务事务使用锁管理对象的协议
    • 对什么加锁,
      • 通常仅在ID或主键加锁,因为使用它们来查找对象.
    • 何时加锁,
      • 通常在读取数据之前获取锁.保证加锁的是最新数据时采取加锁.
    • 何时释放锁,
      • 在业务事务完成时释放.
    • 当无法获得锁时的动作.
      • 可能会在业务事务一开始就因为无法获取锁而终止事务.
    • 对于相互等待对象的锁资源造成的死锁.
      • 让锁管理对象在锁不可用时抛出异常即可.直接避免死锁.
    • 丢失的会话中锁的超时.Client端在事务进行中崩溃了.
      • 让应用服务器的超时机制处理.
      • 给每个锁加上时间戳,定时清除超过一定时间的锁.
• 使用时机
  • 适合于冲突率很高的并发会话中.
  • 也用于冲突处理代价很高时.
  • 它只能作为乐观锁的补充,不推荐使用.
  • 可以考虑使用长事务.其实现比悲观锁简单.