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