并发控制五(封锁的粒度)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Dream_Ryoma/article/details/81949359

封锁对象的大小称为封锁粒度。封锁对象可以是逻辑单元,也可以是物理单元。以关系数据库为例,封锁对象可以是这样一些逻辑单元:属性值、属性值的集合、元组、关系、索引项、整个索引直至整个数据库;也可以是这样一些物理单元:页(数据页或索引页)、物理记录等。

封锁粒度与系统的并发度和并发控制的开销密切相关。直观地看,封锁的粒度越大,数据库所能够封锁的数据单元就越少,并发度就越小,系统开销也越小;反之,封锁的粒度越小,并发度越高,但系统开销也就越大。

一个系统中同时支持多种封锁粒度供不同的事务选择是比较理想的,这种封锁方法称为多粒度封锁。选择封锁粒度应该考虑封锁开销和并发度这两个因素。

  • 多粒度封锁

多粒度封锁,首先要定义多粒度树。多粒度树的根节点是整个数据库,表示最大的数据粒度。叶节点表示最小的数据粒度。

如下是一个三级粒度树。根节点为数据库,数据库的子节点为关系,关系的子节点为元组。

还可以定义四级粒度树,如数据库、数据分区、数据文件、数据记录。

多粒度封锁协议允许多粒度树中的每个节点被独立地加锁。对一个节点加锁意味着这个节点的所有后裔节点也被加以同样的类型。因此,在多粒度封锁中一个数据对象可能以两种方式封锁,显示封锁和隐式封锁。

显示封锁是应事务的要求直接加到数据对象上的锁;隐式封锁是该数据对象没有被独立加锁,是由于其上级节点加锁而使该数据对象也加上了锁。

多粒度封锁方法中,显式封锁和隐式封锁的效果是一样的,因此系统检查封锁冲突时不进要检查显示封锁还要检查隐式封锁。例如事务T要对关系R1加X锁,系统必须搜索其上级节点数据库、关系R1以及R1的下级节点,即R1中的每一个元组,上下搜索。如果其中某一个数据对象已经加了不相容锁,则T必须等待。

一般地,对某个数据对象加锁,系统要检查该数据对象上有无显式封锁与之冲突;再检查其所有上级节点,看本事务的显式封锁是否与该数据对象上的隐式封锁冲突;还要检查其所有下级节点,看他们的显式封锁是否与本事务的隐式封锁冲突。显然,这样的检查方法效率很低。为此人们引进了一种新型锁,称为意向锁。有了意向锁,数据库管理系统就无须逐个检查下一级节点的显式封锁。

  • 意向锁

意向锁的含义是如果对一个节点加意向锁,则说明该节点的下层节点正在被加锁;对任一节点加锁时,必须先对它的上层节点加意向锁。如:对任一元组加锁,必须先对它的数据库和关系加意向锁。

意向锁分为三种:意向共享锁(IS)、意向排他锁(IX)、共享意向排他锁(SIX)。

(1)意向共享锁(IS)

如果对一个数据对象加IS锁,表示它的后裔节点拟(意向)加S锁。例如事务T1要对R1中某个元组加S锁,则首先对关系R1和数据库加IS锁。

(2)意向排他锁(IX)

如果对一个数据对象加IX锁,表示它的后裔节点拟加X锁。例如事务T1要对R1中某个元组加X锁,则首先要对关系R1和数据库加IX锁。

(3)共享意向排他锁(SIX)

如果对一个数据对象加SIX锁,表示对它加S锁,再加IX锁。例如对某个表加SIX锁,则表示该事务要读整个表,同时会更新个别元组。

在具有意向锁的多粒度封锁方法中,任意事务T要对一个数据对象加锁,必须先对它的上层节点加意向锁。申请封锁时应该按自上而下的次序进行,释放封锁时则应该按自下而上的次序进行。

如:事务T1要对关系R1加S锁,则要首先对数据库加IS锁,检查数据库和R1是否已加了不相容的锁(X或IX)。不再需要搜索和检查R1中的元组是否加了不相容的锁(X)。

猜你喜欢

转载自blog.csdn.net/Dream_Ryoma/article/details/81949359
今日推荐