CN101702176A

CN101702176A - 一种基于局部路径锁的xml数据并发控制方法

Info

Publication number: CN101702176A
Application number: CN200910228692A
Authority: CN
Inventors: 康宏; 袁晓洁; 黄晓骋; 官莹; 孙博实
Original assignee: Nankai University
Current assignee: Nankai University
Priority date: 2009-11-25
Filing date: 2009-11-25
Publication date: 2010-05-05
Anticipated expiration: 2029-11-25
Also published as: CN101702176B

Abstract

本发明属于数据库技术领域，具体提出了一种新型的基于局部路径加锁模型的XML数据并发控制方案。具体内容包括：XML数据模型的定义、锁模型的定义、锁协议制定、并发控制的实现方案制定。通过本发明提出的并发控制方案，可以实现在对XML进行事务操作时，只对根据XQuery定位到的节点或者其父节点进行加锁，避免了传统的从根节点到目标节点的路径加锁方式，减少了对锁的频繁请求，提高了事务的并发度和执行效率。

Description

一种基于局部路径锁的XML数据并发控制方法

【技术领域】：本发明属于数据库技术领域，具体提出了一种新型的基于局部路径加锁模型的XML数据并发控制方法。通过本发明提出的并发控制方法，可以实现在进行XML事务操作时，只对根据XQuery定位到的节点或其父节点进行加锁。避免了传统的从根节点到目标节点的路径加锁方式，减少了对锁的频繁请求，提高了事务的并发度和执行效率。

【背景技术】：随着XML相关标准的推广和应用，如何有效地存储、查询、更新XML数据已经成为了数据库领域的一个研究热点。在存储方面，研究者采用了多种方法将XML文档存储到数据库中。其中，借助传统关系数据库系统存储XML数据是目前流行的一种方式。在查询方面，XQuery语言已经成为了公认的XML数据查询的标准语言。在更新方面，W3C提出了XML数据更新的语法和语义规范：XQuery Update Facility 1.0。在XML数据更新中，事务的并发控制是一个重要的组成部分。传统的并发控制方式[1][2][3]主要是针对XML片段模型的路径加锁方式，即：从对根节点到目标节点的路径上的所有节点进行加锁。这样的加锁方式会导致在一个事务中，从根节点到目标节点的整个路径都被锁住。在这种情况下，如果存在与目标节点及其父节点无关，但是存在于路径上的节点的事务，则该事务不能被执行。因此，这样的控制策略，造成了一个调度中整体事务的并发度不高。此外，这种加锁策略，需要从根节点到目标节点进行加锁，如果根节点到目标节点存在较高的深度，就会造成大量的加锁、解锁操作，从而产生较大的时间和空间的消耗。

【发明内容】：本发明目的是解决传统的并发控制方式针对XML片段模型的路径加锁，即：从对根节点到目标节点的路径上的所有节点进行加锁，从而造成了一个调度中整体事务的并发度不高的问题，提供一种基于局部路径锁的XML数据并发控制方法。

本发明提供的基于局部路径锁的XML数据并发控制方法，包括XML数据模型的定义、锁模型的定义、锁协议以及并发控制操作方案，具体过程如下：

1.定义XML数据模型

定义1：一篇XML文档D可以表示为一个序列(Sequence)：S＝{s1→s2→…sn}其中，Si是一个四元组(ID，tag，type，value)，表示XML中的某个节点。四元组中各个项目的定义如下：ID为此节点在关系型表中的标识；type∈{Document，Element，Attribute，Value}表示节点的类型；tag为节点的名称；value为节点的值；n为XML节点的个数，且n＝|S|。

·如果s1的type是Document，则表明此序列为一棵XML文档树

·如果s1的type是Element，则表明此序列为一个XML文档的片段

例如，图1是一篇XML文档，图2是按照定义1所定义的该文档的DOM树。按照模式映射的方法[4][5]，将此文档存储到对应的关系数据库的关系表中，其具体结构如表1所示。

ID	Tag	Type	Value
ID	Tag	Type	Value	1	1(BOOK)	1(Document)	Null
1.1	2(ISBN)	2(Attribute)	1-55860-438-3	1	1(BOOK)	1(Document)	Null
1.1	2(ISBN)	2(Attribute)	1-55860-438-3	1.3	3(SECTION)	1(Element)	Null
1.3.1	4(TITLE)	1(Element)	Bad Bug	1.3	3(SECTION)	1(Element)	Null
1.3.1	4(TITLE)	1(Element)	Bad Bug	1.3.3	---------	4(Value)	Nobody loves bad bugs
1.3.5	5(FIGURE)	1(Element)	Null	1.3.3	---------	4(Value)	Nobody loves bad bugs
1.3.5	5(FIGURE)	1(Element)	Null	1.3.5.1	6(CAPTION)	2(Attribute)	Sample Bug
1.5	7(PRICE)	1(Element)	25	1.3.5.1	6(CAPTION)	2(Attribute)	Sample Bug

表1：存储XML文档片断的关系表结构

本发明中所定义的XML数据模型，具有如下的特点：

1.DOM树的每一个节点，在系统表的存储是一行。

2.每个节点进行编码时使用智能节点ID，这种节点编码蕴含了节点之间的父子关系，因此，在更新事务执行时的加锁申请过程中，可用于快速判断某个节点的祖先后裔是否存在更新操作。

2.XML事务操作时加锁模型的制定

2.1锁的类型

本发明定义了6种锁，分为两类：一类是物理锁，另一类是逻辑锁。

逻辑锁与物理锁的差别是：逻辑锁仅仅是逻辑持有，而不需要向锁管理器申请，在事务之间冲突检测过程中，通过查询函数来判断逻辑锁是否被节点持有。

物理锁包括以下几种：

锁I：意向锁，节点N持有此锁，意向N的孩子或者兄弟正在进行值修改或者插入操作。

锁X：节点级排他锁，节点N持有此锁，表明N正在进行重命名或者正在进行值修改操作。

锁T：子树级排他锁，简称子树锁。锁的粒度为以N为根节点的整个子树，节点N持有此锁，表明以N为根的整棵子树已经被加入了排他锁。

逻辑锁包括以下几种：

锁TA：逻辑锁。通过查询函数判定节点N的祖先(包括父亲)节点上是否持有T锁。如果有，则认为N上持有TA锁。

锁TD：逻辑锁。通过查询函数判定节点N的后裔(包括孩子)节点上是否持有T锁。如果有，则认为N上持有TD锁。

锁XD：逻辑锁。通过查询函数判定节点N的后裔(包括孩子)节点上是否持有X锁，如果有则认为N上持有XD锁。

2.2定义T/X表结构及查询函数以判断是否持有TA、TD、XD锁

目标节点上是否逻辑持有TA、TD和XD锁，需要通过查询函数来进行判定。为此，定义相关的结构和查询函数，如下所示：

定义2.T/X表

一个存在于内存中的T表(X表)表示如下：

T/X＝{id₁，id₂，id_i…id_n}

其中id为事务中所操作的某节点N的智能ID；当且仅当节点N被加上T/X锁时，N的智能节点ID被记录到T表(X表)当中。

定义3.查询函数Scan()

Scan：(ID_n，m，v)→Boolean

其中，m∈{T，X}；v∈{ascend，descend}。此函数将节点N的智能节点ID与T表(X表)中的智能节点ID进行比较，用来判断T表(X表)中是否含有N的祖先或者后裔。

查询函数的执行条件：

当数据库启动侦听外界请求时，系统将构建T/X表，并将其存放于系统的底层内存中。为避免内存的访问冲突，在进行查询的时候，首先要对T/X表进行封锁。这样就保证在某个时刻，只有一个事务对T/X表进行操作，从而保证了查询函数返回正确的结果。

查询函数的算法内容如下表示：

函数.Scan()

输入：节点N的智能id，T/X表，A/D祖先后裔标志符

输出：若表中存在符合关系的id，返回true，否则返回false

步骤：

①id＝GetID(n) /*获取节点N的智能id*/

/*通过遍历查找T/X表中是否含有节点N的祖先节点或者后裔节点.查到则退出*/

②While(T/X≠Φ)

③{

④ idt＝getNextID(T/X) /*遍历获取T/X表中的智能id*/

⑤ {

⑥ if(true＝＝Compare(id，idt))

⑦ return true

③ else

⑨ T/X＝T/X-{idt}

⑩ }

}

return false

时间复杂度分析：

查询函数Scan()中进行祖先/后裔节点判断时，Compare()函数可以在O(1)时间内完成。假设，XML文档的叶子节点数为k，则根据T表的定义，T表中最多的id数目为k。因此，节点判断的时间复杂度，最坏情况下为O(k)。考虑到要查找的id在T表中存在的位置是均匀分布的。则查询函数scan()的平均时间复杂度为O(k)/2。

2.3、XML不同事务之间的各种锁的冲突相容性矩阵定义

不同事务之间的冲突相容矩阵如表2所示。其中由I、T、X锁构成的冲突矩阵，是由真正加在节点上的锁构成的，这些锁通过锁管理器进行申请和释放；表中剩余的部分由TA、TD、XD逻辑锁构成，这些锁通过查询函数的返回值来判断是否被持有。

表2：不同事务之间的冲突相容矩阵

3.定义目标节点加锁条件

基于前面所描述的XML数据模型。在进行XML数据更新时，通过XQuery表达式将可以定位到其中的某一个或者多个节点作为加锁目标节点。在此基础上，定义更新操作应满足的条件，如下所示：

目标节点在进行更新操作时必须锁住，不允许在此节点上执行任何其他的更新操作。

将要对目标节点N进行删除操作时，N的孩子和后裔节点中，不能有节点正在进行删除，插入，重命名或者更新操作。如果有，则需要等到孩子节点更新操作完成以后，才能对节点N进行删除。

将要对目标节点N进行删除操作时，N的父亲以及祖先节点不能进行删除操作。如果有，则等待，直到父亲或者祖先节点完成删除操作后，才能对N进行删除。

将要对目标节点N进行重命名操作时，N的父亲及祖先节点不能正在或即将被删除。如果有，则等待，直到父亲或祖先节点删除操作完成。

将要对目标节点N的孩子进行插入操作时，N节点以及N的祖先节点不能正在被删除。如果有，则等待，直到删除操作完成。此外，N节点也不能正在被修改值或重命名。

将要对目标节点N进行插入左右兄弟时，N节点及N的祖先节点不能正在被删除。如果有，则等待，直到删除操作完成。此外，N节点本身也不能正在执行任何更新操作。

将要对目标节点N进行修改值的操作时，不能允许其父亲以及祖先节点正在被删除。如果有，则等待，直到删除操作完成。此外，N节点的父亲节点不能执行任何更新操作。

4.锁协议制定

在冲突相容矩阵的基础上，本发明制定了锁协议，其特征如下所示：

■申请锁的规则：事务在执行任何一种操作的时候，必须根据操作的具体类型进行合适类型锁的申请。如表3所示：

表3：各种操作下，加锁的节点以及申请锁的类型

其中，S_d为目标节点的XQuery定位语句，S_s为源节点的XQuery定位语句。

■冲突检测规则：当一个事务需要对不同的节点均需要加上锁时，只要其中任何一个节点的锁没有被加上，则必须根据冲突矩阵，等待其锁的加上，然后继续后续的更新操作。

■每一个事务必须满足2PL协议。即在锁增长阶段申请锁，在锁缩减阶段释放锁。

5.局部锁协议的正确性证明：

为了证明本文提出锁协议的正确性，需要证明基于此协议的任何一个事务均满足冲突可串行化。借鉴2PL的证明思路，即需要证明本协议下的I，X，T锁均不会在事务的前驱图中产生环。

定义4：操作、事务、调度

操作：依据XML的节点操作模型，将一个操作表示为O(N)_T，其中，T是一个事务。N为根据XQuery语句所定位的目标节点。根据XQuery Update Facility规范，O是Insert、Replace Node、Replace Value、Rename、Delete中的任何一种。

事务：一个事务是一个有限序列T＝{O₁→O₂→…On}，序列中的每个元素均是一个操作O。

调度：一个调度S是若干个事务的交叉执行。

对于一个调度来讲，为了实现其中事务的冲突可串行化，最简捷的方式是依据2PL协议，对于事务中的每一个操作O，在锁增长阶段申请加锁Lock O，在锁缩减阶段释放加在O上的锁Unlock O。为此，首先提出如下命题：

命题1：

假设，事务中的一个操作O的对象为节点X，依据2PL，则必有Lock V O(x)＜O(x)＜UnlockV O(x)；其中，符号＜表示操作的执行顺序。如果O1＜O2，表明，O1要在O2之前执行。

根据O的不同类型，并且依据局部路径锁协议下的申请锁的规则，在进行申请锁的过程中分别加上I锁、X锁、T锁，或判定其逻辑持TA锁、TD锁和XD锁，即V∈{I，X，T，TA，TD，XD}。

命题2：如果某个事务T_i中的操作O(x)i与另外一个事务Tj的操作O(x)j冲突，则根据命题1和冲突相容矩阵，必然存在：Unlock V O(x)i＜Lock V O(x)j或者Unlock V O(x)j＜Lock VO(x)i。

由命题2进行延伸，提出引理1：

引理1：

假设一个调度中存在n个事务T1，T2…Tn。T1在T2之前提交，T2在T3之前提交，等等。以此类推，也必然存在Unlock V O(x)1＜Lock V O(x)n。

证明：

根据命题2，在一个调度中，假设存在2个事务T1，T2。T1要在T2之前进行提交。在T1中和T2中分别存在冲突的2个操作O(x)1和O(x)2。则必然存在UnlockV O(x)1＜LockV O(x)2。

不失一般性，假设一个调度中存在n个事务T1，T2…Tn。T1在T2之前提交，T2在T3之前提交，等等，以此类推。也必然存在UnlockV O(x)1＜LockV O(x)n。

证毕。

根据引理1，可得出如下结论：

结论：

基于局部路径锁协议，所有的调度均可串行化。

证明：

为了证明所有调度的可串行化，可以参照2PL的证明思路，即证明任何一个调度，其事务的前驱图不存在环，利用反证法。

假设某个事务的前驱图中存在一个环，即T1→T2→…Tn→T1，则依据引理1，必然存在Unlock V O(x)1＜Lock V O(x)n＜O(x)n＜Unlock V O(x)n＜Lock V O(x)1。很显然，此结论与命题1矛盾。

因此，此协议下定义的调度可以实现冲突可串行化。

证毕。

通过这个结论表明，本发明所提出的锁协议是正确的，其中定义的锁模型也是正确的。

6.局部路径锁协议下XML数据并发控制方案制定

在上述内容的基础上，本发明制定了XML数据并发控制方案。并发控制方案包括2部分：只读事务与更新事务的并发控制以及更新事务之间的并发控制。分别描述如下：

1)采用多版本化协议实现只读事务与更新事务的并发控制

本发明采用的多版本化协议，对于只读事务从不加锁。因此，多版本化协议具有只读事务永不阻塞的优点。同时更新事务也不会被只读事务阻塞。利用协议中经典的“快照隔离”特性定义只读事务与更新事务的并发控制方法。步骤如下所示：

步骤1：当一个只读事务T启动时，赋给此事务一个全局事务版本号。

步骤2：当调度器接收到只读事务T对节点N的读请求时，对该事务读取的最近已提交版本并进行判断。如果节点N被更新事务删除，说明此版本不存在，则执行步骤4；否则执行步骤3。

步骤3：选择该事务开始时的最近已提交版本，进行事务提交。

步骤4：返回固定信息码以表示节点N不存在，进行事务提交。

2)采用局部路径锁协议实现更新事务之间的并发控制

根据本发明所提出的局部路径锁协议，可以制定出更新事务之间并发时的控制方法。其步骤如下所示：

步骤1：一个更新事务T启动，根据冲突相容矩阵，对目标节点N加I锁。

步骤2：通过查询函数对T表、X表进行检测，事务T确定目标节点上是否持有逻辑锁TA，TD和XD，并将目标节点的ID插入到T表或X表中。

步骤3：事务T对目标节点N申请加T锁或者X锁。如果加锁成功(冲突矩阵检测通过)，进行更新操作。否则，删除T表和X表的目标节点记录，事务T进入等待。

更新事务并发控制执行流程如图5所示：

本发明的优点和积极效果：

传统的DOM树加锁方式，采用的是从根结点到目的节点的整个路径加锁，对目的节点改值时，路径加IX锁，目的节点加X锁。而采用本发明的局部路径锁协议，根据操作性质的不同仅仅对目标节点或者其父节点加锁，避免了传统的从根节点到目标节点的路径加锁方式，减少了对锁的频繁请求，从而提高了事务的并发度和执行效率。

例如，图3和图4是传统的路径加锁方式和本发明的局部路径加锁方式的加锁实例比较：

图3中，假设T1：修改book的标签；T2：要对节点/bib/book/author/last进行修改值。根据传统的路径加锁协议，T1执行时，book需要加X锁，从根节点到bib到book节点之间的路径加锁IX；T2执行时，last需要加X锁，从根节点到bib到last节点之间的路径加锁IX。但是由于T1和T2在路径上有冲突，结果T1和T2无法实现并发执行。此外，假设T1在T2之前执行，对T2来讲，要从last节点至根节点逐层加锁，但加锁到根节点时，发现与T1路径冲突，加锁不成功，则需要进行事务等待或者事务退出。这样就会造成大量的加锁、解锁操作或者由于等待而长时间占用系统资源，最终造成的结果是事务的执行效率不高。

图4中，假设同样执行T1和T2。根据局部路径锁协议，T1执行时，book需要加X锁。T2执行时，last需要加X锁。假设T1在T2之前执行。首先，T1对book加X锁，并将book的智能节点id存入X表中。此时T2执行，T2对last申请加X锁，首先检查冲突矩阵，没有发现TA锁，则对last加上X锁。从而实现了T1和T2事务的并发。而且，依据这种加锁策略，仅仅在book和last节点上加了X锁，从而减少了系统资源消耗。

从图3和图4对比可见，本发明提出了只针对XQuery定位到的节点和其父节点进行加锁的方式，避免了传统的从根节点到目标节点的路径加锁方式，减少了对锁的频繁请求，提高了事务的并发度和执行效率。

【附图说明】：

图1是XML文档片断结构示意；

图2是XML文档片断的DOM树型结构；

图3是传统DOM树路径加锁协议操作实例；

图4是局部路径加锁协议操作实例(NIL表示无锁)；

图5是更新事务之间的并发控制方案图；

图6是实施例1中的XML文档片断结构示意

图7是实施例1中的执行过程(第一)的示意图

图8是实施例1中的执行过程(第二)的示意图

图9是实施例1中的执行过程(第三)的示意图

图10是实施例1中的执行过程(第四)的示意图

图11是实施例1中的执行过程(第五)的示意图

【具体实施方式】：

实施例1：本发明所描述的局部路径加锁协议下的多个事务并发的实例：

1.根据本发明提出的局部路径锁协议下XML数据并发控制方案。以图6所示的XML文档片断为例进行详细说明：

假设：针对这个XML文档片断，存在5个事务，如下所示：

事务T1：对节点bib/book[2]进行删除操作；

事务T2：对节点bib/book/@year进行改值操作；

事务T3：对节点/bib/book/author/last进行删除操作

事务T4：对节点/bib/book/author进行replace node替换操作；

事务T5：对节点/bib/book[1]下插入一个孩子节点。

当5个事务同时进行操作的时候，具体的执行过程如下：

第一、事务T1需要对book[2]加T锁，通过Scan函数检查T表后，发现没有其后裔或者祖先节点加了T锁，同时，通过Scan函数检查X表以后，没有孩子节点加锁X。则，事务T1对book[2]直接加T锁。操作过程如图7所示。

第二、事务T2进入，此时的DOM树中正在进行T1的针对book[2]的删除操作，T2需要修改/bib/book/@year的值。因此，T2先要对year加X锁，它首先通过Scan函数发现祖先节点中未含有T锁，则事务T2直接对year加X锁。此时，T2与T1同时操作，实现了并发。操作过程如图8所示。

第三、事务T3进入，对bib/book/author/last进行删除操作。T3需要对Last节点加T锁。加T锁前，通过Scan函数检查T表后，发现其后裔或者祖先节点未加T锁；同时，检查X表发现孩子节点未加X锁。则事务T3对bib/book/author/last加T锁。操作过程如图9所示。

第四、事务T4进入，对bib/book/author进行replace node操作。T4需要对author节点进行删除，加T锁。因此，T3首先通过Scan函数进行T表检测，发现其孩子中含有T锁节点，因此，author节点不能加T锁。所以T4被迫等待，直到T3完成才能进行后续操作。操作过程如图10所示。

第五、事务T5进入，对bib/book[1]下插入孩子节点。T5需要对/book[1]节点加I锁。与前述步骤类似，经过T表分析和冲突相容性矩阵分析，T5可以与T1，T2，T3共同进行。操作过程如图11所示。

实施例2：产生并发冲突时，依据局部路径加锁协议制定的可串行化调度的实例：

在图1中所定义的文档片断上，假设事务T1对节点/book/section/figure进行删除操作，事务T2对节点/book/section进行replace node替换操作。并且T1在T2之前执行。T1对figure节点加T锁，申请T锁前，根据查询函数scan()进行T表和X表检测，发现figure节点没有持有TA锁、TD锁和XA锁，则事务T1对figure申请T锁成功，并将figure的id存入到T表中。事务T2执行时，需要对section节点进行删除，并对section节点加T锁，因此，T2首先根据查询函数scan()进行T表检测，发现其孩子figure节点，这表明section节点逻辑持有TD锁，根据冲突相容矩阵，则产生冲突。因此，T2被迫等待，直到T1完成后才能继续操作。一个依据局部路径加锁协议的可行的并发调度如表4所示：

表4：事务T₁和T₂的一个并发调度实例

实施例3：局部路径锁协议下的各种操作算法

3.1与本发明所提出的算法中有关的一些概念和函数定义

1)定位函数Pos()

设Path表达式∈{XPath表达式，XQuery表达式}，则定位函数y＝Pos(Path表达式)

说明：此函数通过一个路径表达式获得目标节点序列S中的序号集合。本文中Path表达式的2个实例分别为：DesPath目标序列路径和SrcPath源序列路径。

2)加锁函数：Lock()

设N为任意一个XML节点，Lockmode∈{I，X，T}，则，加锁函数y＝Lock(N，Lockmode)。此函数表示对XML节点N加上I，X，T锁。

3)冲突检测函数Conflict()

设N为任意一个XML节点，Lockmode∈{I，X，T}，则冲突检测函数y＝Conflict(N，Lockmode)；y∈{True，False}。

此函数表示在XML节点N上需要申请新锁Lockmode时，根据冲突矩阵对申请锁进行冲突判断，返回值为True表示冲突，False表示不冲突。

2.2根据局部路径锁协议下，制定针对XML节点的各种操作算法，描述如下：

算法1.删除操作的处理算法：

输入：一条XQuery语句

输出：如果事务更新成功，返回true；如果事务等待，返回false

步骤：

①N：＝Pos(XQuery)，/*定位到目标节点N*/

/*利用Scan函数查找T/X表，确定N的祖先和后裔是否存在更新操作*/

②IF(Scan(N，T，Ascend)＝＝true||Scan(N，T，Descend)＝＝true)

③{N上逻辑持有锁TA或TD}

④ELSE IF(Scan(N，X，Descend)＝＝true)

⑤{N上逻辑持有逻辑锁XD}

/*将T锁带入到冲突矩阵中进行冲突检测。如果冲突，事务等待，否则对节点N加T锁*/

⑥IF(Conflict(N，T)＝＝true)

⑦{Waiting；

⑧return false}

⑨ELSE

⑩{Lock(N，T)；

Add(T，GetId(N))；/*将N的智能节点ID放入T表中*/

return true}

ENDIF

算法2.插入操作的处理算法：

输入：DesXQuery目标节点定位语句，SrcXQuery源节点定位语句

步骤：

①N：＝Pos(DescXQuery)/*根据目标XQuery定位到目标节点N*/

②SN：＝Pos(SrcXQuery)/*根据源XQuery定位到源节点SN*/

/*根据冲突相容矩阵，对节点N加I锁，如果成功执行步骤3，否则等待*/

③IF(Conflict(，I)＝＝true)

④{Waiting；

⑤return false}

⑥ELSE

⑦{Lock(N，I)；

/*利用Scan函数查找T/X表，确定SN的祖先是否存在更新操作*/

⑧IF(Scan(SN，T，Ascend)＝＝true)

⑨{SN上逻辑持有锁TA}

/*将T锁带入到冲突矩阵中进行冲突检测。如果冲突，事务等待，否则对节点SN加T锁*/

⑩IF(Conflict(SN，T)＝＝true)

{Waiting；

return false}

ELSE

{Lock(SN，T)；

Add(T，GetId(SN))；/*将SN的智能节点ID放入T表中*/

return true}

ENDIF

算法3.重命名操作的处理算法：

输入：DesXQuery目标节点定位语句

步骤：

①N：＝Pos(XQuery)，/*定位到目标节点N*/

②IF(Scan(N，T，Ascend)＝＝true)

③{N上逻辑持有锁TA}

/*将X锁带入到冲突矩阵中进行冲突检测。如果冲突，事务等待，否则对节点N加X锁*/

④IF(Conflict(N，X)＝＝true)

⑤{Waiting；

⑥return false}

⑦ELSE

⑧{Lock(N，X)；

⑨Add(X，GetId(N))；/*将N的智能节点ID放入X表中*/

⑩return true}

ENDIF

算法4.Replace Value操作的处理算法：

输入：DesXQuery目标节点定位语句，SrcXQuery源节点定位语句

步骤：

①N：＝Pos(DesXQuery)，/*根据目标XQuery定位到目标节点N*/

②SN：＝Pos(SrcXQuery)/*根据源XQuery定位到源节点SN*/

/*根据节点N分属于Attribute类型或者Element类型，分别进行不同处理*/

③IF(type(N)＝＝‘Attribute’){

/*根据冲突矩阵，对节点N的父节点加I锁，如果成功执行后续步骤，否则等待*/

④IF(Conflict(Parent(N)，I)＝＝true)

⑤{Waiting；

⑥return false}

⑦ELSE

⑧{Lock(N，I)}

/*利用Scan函数查找T表，确定N的祖先是否存在更新操作*/

⑨IF(Scan(N，T，Ascend)＝＝true)

⑩{N上逻辑持有锁TA}

IF(Conflict(N，X)＝＝true)

{Waiting；

return false}

ELSE

{Lock(N，X)；

Add(X，GetId(N))；/*将N的智能节点ID放入X表中*/

return true}

ENDIF}

ELSE/*N的类型是Element*/

{

IF(Scan(N，T，Ascend)＝＝true||Scan(N，T，Descend)＝＝true)

{N上逻辑持有锁TA或TD}

ELSE IF(Scan(N，X，Descend)＝＝true)

{N上逻辑持有逻辑锁XD}

IF(Conflict(N，T)＝＝true)

{Waiting；

return false}

ELSE

{Lock(N，T)；

Delete(Child(N))；/*将N的孩子删除*/

Insert(SN)

return true}

ENDIF

}

算法5.Replace Node操作的处理算法：

输入：DesXQuery目标节点定位语句，SrcXQuery源节点定位语句

步骤：

①N：＝Pos(DesXQuery)，/*根据目标XQuery定位到目标节点N*/

②SN：＝Pos(SourXQuery)/*根据源XQuery定位到源节点SN*/

③对目标节点N执行算法2

/*利用Scan函数查找T表，确定SN的祖先是否存在更新操作*/

④IF(Scan(SN，T，Ascend)＝＝true)

⑤{SN上逻辑持有锁TA}

⑥IF(Conflict(SN，X)＝＝true)

⑦{Waiting；

⑧return false}

⑨ELSE

⑩{Lock(SN，T)；

Add(T，GetId(SN))；/*将N的智能节点ID放入X表中*/

对目标节点N执行算法3

return true}

ENDIF

参考文献

[1]XMLTM：Efficirnt Transaction Management for XML Documents(In proceedingsof the 2002 ACM CIKM International Conference on Information and KnowledgeManagement)

[2]Lock-based Protocol for Protocol for Cooperation on xml Documents(In 14thInternational WorkShop On database and exper systems Application)

[3]Evaluating Lock-based Protocols for Cooperation on Xml Documents

[4]Wang Xin，Yuan Xiaojie，Wang Chenying，et al.XN-Store：A Storage Scheme forNative XML Databases.Journal of Computer Research and Development，45(7)：1211-1220，2008.(in Chinese)(王鑫，袁晓洁，汪陈应，等.XN-Store：一种原生XML数据库的存储方案.计算机研究与发展，45(7)：1211-1220，2008.)

[5]汪陈应，袁晓洁，王鑫，刘众奇.BSC：一种高效的动态XML树编码方案.计算机科学，32(3).2008。

Claims

1.一种基于局部路径锁的XML数据并发控制方法，其特征在于该方法包括相应的XML数据模型的定义、锁模型的定义、锁协议以及并发控制操作方案，具体过程如下：

第1、XML数据模型定义

此数据模型将一篇XML文档D表示为一个序列(Sequence)：S＝{s1→s2→...sn}其中，Si是一个四元组(ID，tag，type，value)，表示XML中的某个节点；四元组中各个项目的定义如下：ID为此节点在关系型表中的标识；type∈{Document，Element，Attribute，Value}表示节点的类型；tag为节点的名称；value为节点的值；n为XML节点的个数，且n＝|S|；根据模式映射的方法，将文档D存储到对应的关系数据库的关系表中；

第2、XML事务操作时加锁模型的制定

第2.1、锁的类型

第2.1.1、物理锁：

I锁：意向锁

IX锁：节点级排他锁

T锁：子树级排他锁

第2.1.2、逻辑锁：

TA锁：表征节点的祖先有删除动作

TD锁：表征节点的后裔有删除动作

XD锁：表征节点的后裔有值更新动作

第2.2、定义T/X表结构及查询函数以判定是否持有TA、TD、XD锁

第2.2.1、一个存在于内存中的T表(X表)表示如下：

T/X＝{id₁，id₂，id_i…id_n}

其中id为事务中所操作的某节点N的智能ID；当且仅当节点N被加上T/X锁时，N的智能节点ID被记录到T表(X表)当中；

第2.2.2、定义查询函数Scan()：

Scan：(ID_n，m，v)→Boolean

其中，m∈{T，X}；v∈{ascend，descend}；此函数将节点N的智能节点ID与T表(X表)中的智能节点ID进行比较，用来判断T表(X表)中是否含有N的祖先或者后裔；

如果：

·函数Scan(ID_n，T，ascend)返回值为真，表明N的祖先存在删除操作，则判定N上逻辑持有锁TA

·函数Scan(ID_n，T，descend)返回值为真，表明N的后裔存在删除操作，则判定N上逻辑持有锁TD

·函数Scan(ID_n，X，descend)返回值为真，表明N的后裔存在修改值或者重命名操作，则判定N上逻辑持有锁XD

第2.3、XML不同事务之间的各种锁的冲突相容矩阵定义

根据2.1中对于锁的描述，制定了各种锁的冲突相容表

其中由I、T、X锁构成的冲突矩阵，是由真正加在节点上的锁构成的；这些锁通过锁管理器进行申请和释放；表中剩余的部分由TA、TD、XD逻辑锁构成，这些锁通过查询函数的返回值来表明是否被逻辑持有；

第2.4、锁协议的制定

第2.4.1、申请锁的规则：事务在执行任何一种操作的时候，必须根据操作的具体类型进行相应类型锁的申请；

第2.4.2、冲突检测规则：当一个事务需要对不同的节点均需要加锁时，只要其中任何一个节点的锁没有被加上，就必须根据冲突矩阵，等待其锁的加上，之后再继续后续的更新操作；

第2.4.3、每一个事务必须满足2PL协议，即在锁增长阶段申请锁，在锁缩减阶段释放锁；

第2.5、XML数据并发控制方案的制定

第2.5.1、采用多版本化协议实现只读事务与更新事务的并发控制

第2.5.2、采用局部路径锁协议实现更新事务之间的并发控制。