封锁

封锁就是事务T在对某个数据对象（表、记录等）操作之前，先向系统发出请求，对其枷锁
加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象
封锁是实现并发控制的一个非常重要的技术

封锁类型

基本封锁类型
- 排它锁（eXclusive lock，简称X锁）
- 共享锁（Share lock，简称S锁）

排它锁

排它锁又称为写锁、X锁
- 若事务T1对数据对象A加上X锁，则只允许T1读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T1释放A上的X锁

共享锁

共享锁又称为读锁、S锁
- 若事务T1对数据对象A加上S锁，则其它事务只能再对A加S锁，而不能加X锁，直到T1释放A上的S锁

封锁类型的相容性

	$T_{1}$
$T_{2}$		X	S	-
	X	N	N	Y
	S	N	Y	Y
	-	Y	Y	Y

Y=Yes，相容的请求
N=No，不相容的请求

封锁粒度

X锁和S锁都是加在某一个数据对象上的
封锁的数据对象可以是逻辑单元
- 属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等
封锁的数据对象也可以是物理单元
- 页（数据页或索引页）、块等
封锁对象可以是大或者很小
- 对整个数据库加锁
- 对某个属性值加锁
封锁对象的大小称为封锁的粒度
封锁粒度与系统的并发度和并发控制的开销密切相关

封锁的粒度	被封锁的对象	并发度	系统开销
大	少	低	小
小	多	高	大

选择封锁粒度时必须同时考虑开销和并发度两个因素，进行权衡，以求的最优的效果

封锁粒度一般原则

需要处理大量元组的用户事务
- 以关系为封锁单元
需要处理多个关系的大量元组的用户事务
- 以数据库为封锁单位
只处理少量元组的用户事务
- 以元组为封锁事务

封锁协议

在运用X锁和S锁数据对象加锁时，需要约定一些规则，这些规则为封锁协议（Locking Protocol）
- 何时申请X锁或S锁
- 持锁时间
- 何时释放
两种封锁协议
- 三级封锁协议——保证数据一致性
- 两段锁协议——保证并行调度可串行型

三级封锁协议

一级封锁协议
- 事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放
  - 正常结束（commit）
  - 非正常结束（rollback）
- 一级封锁协议可防止丢失修改，并保证事务T是可恢复的
- 在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所有它不能保证可重复读和不读“脏”数据

二级封锁协议
- 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即释放S锁
- 二级封锁协议可以防止丢失修改和读“脏”数据

三级封数据锁协议
- 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放
- 三级封锁协议可防止丢失修改、读“脏”数据和不可重复读

三级协议的主要区别

什么操作需要申请封锁以及何时释放锁（持锁时间）

	X锁		S锁		一致性保证
	操作结束释放	事务结束释放	操作结束释放	事务结束释放	不丢失修改	不读“脏”数据	可重复读
一级封锁协议		✔			✔
二级封锁协议		✔	✔		✔	✔
三级封锁协议		✔		✔	✔	✔	✔

两段锁协议

可串行型是并行调度正确性的唯一准则
“两段”锁的含义
- 在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁
- 在释放一个封锁之后，事务不再获得任何其他封锁
事务分为两个阶段
- 第一阶段是获得封锁，称为扩展阶段
- 第二阶段是释放封锁，称为收缩阶段
事务1的封锁序列：SlockA...SlockB...XlockC...UnlockB...UnlockA...UnlockC 遵守2PL
事务2的封锁序列：SlockA...UnlockA...SlockB...XlockC...UnlockC...UnlockB 不遵守2PL
并行执行的所有事务均遵守两段锁协议，则对这些事务的所有并行调度策略都是可串行化的
所有遵守两段锁协议的事务，并行执行的结果一定是正确的
事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件
即可串行化的调度中，不一定所有事务都必须符合两段锁协议

死锁和活锁

封锁技术可以有效地解决并行操作的一致性问题
但也带来了一些新的问题
- 死锁
- 活锁

活锁

什么是活锁
- 系统可能使某个事务永远处于等待状态，得不到封锁的机会这种现象称为“活锁”

如何避免活锁
- 采用先来先服务的策略
  - 当多个事务请求封锁同一个数据对象时，封锁子系统按请求封锁的先后次序对这些事务排队
  - 该数据对象上的锁一旦释放，首先批准申请队列中第一个事务获得锁

死锁

什么是死锁
- 系统中有两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执行，这种现象称系统进入了“死锁”

解决死锁的两类方法
- 死锁的预防
  - 产生死锁的原因是两个或多个事务都已经封锁了一些数据对象，然后又都请求对已为其它事务封锁的数据对象加锁，从而出现死等待
  - 预防死锁的发生就是要破坏产生死锁的条件
  - 预防死锁的方法
    - 一次封锁法
      - 一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行
      - 一次封锁法存在的问题：
        
        降低并发度
        
        一次就将以后要用到全部数据加锁，势必扩大了封锁的范围从而降低了系统的并发度
        
        难于事先精确确定封锁对象
        
        数据库中数据是不断变化的，原来不要求封锁的数据，在执行过程中可能会变成封锁对象，所以难事先精确地确定每个事务所要封锁的数据对象
    - 顺序封锁发
      - 顺序封锁是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁
      - 顺序封锁法存在的问题：
        
        维护成本高
        
        数据库系统中可封锁的数据对象极其众多，并且随数据的插入、删除等操作而不断地变化，要维护这样极多而且变化的资源的封锁顺序非常困难，成本很高
        
        难于实现
        
        事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也很难按规定的顺序去施加封锁
        
        例子：规定数据对象的封锁顺序为ABCDE，事务 $T_{3}$ 起初要求封锁数据对象BCE，但当它封锁了后，发现还需要封锁A，这样就破坏了封锁顺序
- 结论
  - 在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点
  - DBMS在解决死锁的问题上更普遍采用的是诊断并解除死锁的方法
- 死锁的诊断与解除
  - 诊断方法
    - 有DBMS的并发控制子系统定期监测系统中是否存在死锁，一旦检测到死锁，就要设法解除
    - 超时法
      - 如果一个事务的等待时间超过了规定的时限，就认为发生了死锁
      - 优点：实现简单
      - 缺点：有可能误判死锁、时限若设置的太长，死锁发生后不能及时发现
    - 等待图法
      - 用事务等待图动态反映所有事务的等待情况
        
        事务等待图是一个有向图 $G= \left ( T,U \right )$
        
        T为结点的集合，每个结点表示正运行的事务
        
        U为边的集合，每条边表示事务等待的情况
        
        若 $T_{1}$ 等待 $T_{2}$ ，则 $T_{1},T_{2}$ 之间划一条有向边，从 $T_{1}$ 指向 $T_{2}$
      - 并发控制子系统周期性地（如每个1min）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁
  - 死锁的解除
    - 解决死锁
      - 选择一个处理死锁代价最小的事务，将其撤销
      - 释放此事务持有的所有锁，使其它事务能继续运行下去