5-2. 两阶段锁协议在线视频

怎么样才能对事务的运行正确的加锁呢

人们经过研究提出了两阶段锁协议

两阶段锁协议，大家看这个ppt

这张ppt的图所示

它把一个事务的执行通过一个加锁点，把它分成两个阶段

在这个阶段之前，我们叫做封锁阶段，或者说锁的增长阶段

也就是说，事务从开始到这个加锁点

事务只能加锁，只能获得锁，而不能解锁

然后从事务的加锁点到事务的结束这个阶段

事务只能解锁，而不能获得锁

这样的话，实际上就相当于某一个事务在执行的时候

它必须先知道它需要对哪些数据项进行操作

然后才逐渐地对这些数据项一一进行加锁

然后再进行处理，处理完之后，接下来在后面开始进行解锁

解锁的过程当中不允许对任何事务进行加锁

这样的话就不会出现我们讲的第一个，不正确的加锁导致错误的情况

第一个我们的例子，不正确的加锁就是因为T1对某一个事务加锁再解锁

然后再对另外一个数据进行加锁、解锁

也就是说，它并不是按照两阶段这样一种方式

它因为自己非常随意的加锁、解锁

所以别的数就可以对它所要求的数据项进行加锁

这个时候才能造成数据的这样一种冲突，或者说数据的不一致性

那么我们说，遵循了两阶段锁协议的并发控制能够使得我们数据的结果是正确的

解决了第一个问题，但是它仍然对于死锁现象是没有解决的

解决不了死锁问题，这个是要知道的

另外对于饿死现象，也是一样

也就是说，对于这个级联回滚它也是解决不了

比如说像这个例子，它有事务T1、T2、T3

事务T1它在执行对A和B的一个写操作

T2也要对A进行写操作，T3可能要做一个其他的操作

按照时间轴，它是按照这样一种顺序进行排列

但是事务T3实际上它要读的数据是T2修改的

T2修改的数据A又是T1修改的

这样的话，如果说在某一个时刻T1要是产生了故障的话

显然T2读出来的数据是脏数据，T3读出来的数据也是脏数据

这样的话，如果T1回滚，T2和T3也会回滚

这样就会存在一个级联回滚的现象

那么怎么样避免级联回滚呢？

我们把这个锁协议进行一个严格化

我们前面说只要把事务分两个阶段进行加锁解锁，但是这个还不够

如果我们再要求事务持有的排它锁，就是X锁

必须在事务提交之后才可以释放的话

这个时候我们就可以解决级联回滚的问题

前面这个例子，T1必须要提交，T2才能读T1的更改

然后T2提交之后，T3才能读T2的修改

这样如果说，T1执行到某一个阶段，它发生了错误的话

它要是回滚，实际上这个时候T2还没有执行，T3更没有执行

所以也就发生不了级联回滚的现象

这是我们通过严格两阶段锁协议来避免级联回滚这样一种现象

还有一个锁协议叫做强两阶段锁协议

也就是在实践的过程之中，我们为了实现的简单

让事务保证它的正确性，也保证它的

比如说，极少的出现死锁这样一种现象

出现了强两阶段锁协议这样一种协议

强两阶段锁协议比严格两阶段锁协议更为的严格

它是指什么

它是指事务提交之前，不允许释放任何锁

也就是说，严格两阶段锁协议是不允许释放排它锁

但是强两阶段锁协议是不但不允许释放排它锁，也不允许释放共享锁

这样的话，就要求两个事务如果在某个阶段共享某一个数据资源的话

那么一个事务必须要等待另一个事务执行完了之后再进行

但实际上大部分商品化的数据库管理系统采用的都是严格两阶段锁协议

或者强两阶段锁协议

但是话又说回来了，如果我们采用这么严格的两阶段锁协议的话

显然我们是强制这两个事务，至少在这一个阶段是串行执行的

也就是说它并发程度特别的低，显然就是说它效率要低了

效率低也就是说用户提交的查询等待的时间长

为了提高效率，减少用户的等待时间

有人就提出来说，我实际上可以采用一些其他的方式来提高执行效率

什么方式呢，叫锁转换机制

锁转换机制指的是什么呢

就是说，一个事务，比如说事务T1它要对一系列数据进行写

但是它写之前一定是先读，它有可能是读进来之后

做一系列的操作之后，再去写

这样的话，如果还有其他的事务只是做一个读数据的话

比如说T2读一个数据然后显示一下，而且这个T2是一个短事务

像这种情况，我们就可以把T1对A加的锁，并不直接加写锁

我们先给它加共享锁，直到它要对这个数据进行写的时候

我们再把这个共享锁升级成写锁

通过这样的一种方式来提高T1和T2的并发程度

所以这就是通过更新锁机制来提高执行效率这样一种方式

我们ppt给出这样一个例子，就是更新锁机制这样的方式