CN1527536A - 一种电信网管系统中对被管对象加锁的方法 - Google Patents

Abstract

本发明公开了一种电信网管系统中被管对象加锁的方法，包括以下步骤：对被管对象进行操作，锁定服务系统根据要操作的对象生成相应的加锁任务；取得此任务要锁定的对象相关联的所有父、子节点的各个节点应出现的锁的状态并进行校验；判断已经加锁的任务和内部任务列表中的各个任务是否有与本操作相冲突的任务存在，若没有则对此任务进行加锁，返回结束；否则将本任务填充入内部任务列表，同时提交线程阻塞；等待其它的锁定任务被释放时，依次唤醒内部任务列表中符合条件的任务，重新进行加锁判断。应用本发明的方法，在多用户并发操作的情况下可以实现对被管对象的锁定。

Description

一种电信网管系统中对被管对象加锁的方法

技术领域

本发明涉及对于并发访问的数据管理的安全技术领域，特别是涉及电信网管系统中对被管对象加锁的方法。

背景技术

在网管系统中，核心是对被管对象(MO，Managed Object)进行各种操作，随着计算机技术的发展，这种操作一般是多用户并发进行的，如多个用户同时对同一资源提出请求，例如阅读、修改或删除等。目前的电信网管系统，将采集到的对MO操作的有关信息保存在网管数据库中。由于关系型数据库的技术成熟，性能和稳定性好，通常网管采用关系型数据库进行数据的保存。使用关系型数据库，在用户进行MO的操作时，利用关系型数据库具备的事务机制来保证数据的安全性和完整性。

事务机制在多用户长时间类型的程序中，很容易发生用户操作的并发性。

若采用短事务机制，它是确定于提交或者回滚这样一个时间点，因此无法实现对于资源的主动性锁定。如图1举例说明，用户A在确定一条路径时，程序需消耗五分钟做各种选择，设这条路径要经过10个网元，在五分钟后提交的瞬间，在这个时间点开始事务机制，才发现10个网元中的某个网元被另一个用户B从网管上删除了，而导致操作失败。因此，短事务机制难以保证在用户A做这类操作的时候，相关联的数据不被其他用户进行删除或修改。

若使用高级别的事务隔离机制并使得事务延续长时间，仍以上例，如使用严格机制的事务隔离并让事务在五分钟中一直延续，则B用户可能无法进行任何操作，降低了网管在多用户并发操作情况下的性能。

同时，对于关系型数据库，无法预先知道在事务存在或者对数据库操作期间所影响的资源范围是多少，如行级别、页级别或表格级别。因此从编程者的角度来说，就无法考虑周全其程序事务存在或者对数据库操作期间所影响的资源范围，人为的限制了网管在多用户并发操作情况下的性能。

同时，由于无法实现用户在某个时间段对必需资源的独占式使用，即所述的锁定服务，在做涉及到多个表的关联操作的时候，若两个或两个以上的用户一起在等待被对方占据的资源，而且必需得到这些资源才能将自己的任务进行下去的时候，就形成了死锁现象。

发明内容

有鉴于此，本发明的主要目的在于提供一种电信网管系统中对被管对象加锁的方法，应用本发明的方法，使得用户在操作MO时，保证了其在某个时间段对必需资源的独占式使用，实现对被管对象的锁定。

实现本发明，需要以下步骤：

1、对被管对象(MO)进行操作时，通过锁定服务系统的MO加解锁接口或通过调用被管对象事例树的MO管理接口调用锁定服务系统，锁定服务系统根据此操作，生成与之相应的加锁任务；

2、根据生成的加锁任务，取得此任务要锁定的对象相关联的所有父、子节点的各个节点应出现的锁的状态；

3、判断已经加锁的任务和内部任务列表中的各个任务是否符合此任务的子节点和父节点的各个节点应出现的锁的状态，若符合则对当前任务进行加锁，返回结束；否则执行步骤D；

4、将本任务填充入内部任务列表进行保存，同时提交线程阻塞，使该任务对应的线程处于等待状态。

其中该方法进一步包括：有已加锁状态的任务被释放时，唤醒内部任务列表中的任务，将唤醒的任务作为加锁任务。且该任务加锁成功时，该任务同时从内部任务列表中删除。

其中该方法进一步包括：对单个MO读操作，相应的生成的加锁任务为：对单个MO读锁定；对单个MO写操作，相应的生成的加锁任务为：对单个MO写锁定；对以某个节点的所有子节点读操作，相应的生成的加锁任务为：对以某个节点的所有子节点读锁定；对以某个节点的所有子节点写操作，相应的生成的加锁任务为：对以某个节点的所有子节点写锁定；以某个节点的所有子节点删除操作，相应的生成的加锁任务为：以某个节点的所有子节点删除锁定；对多个独立关系的MO读操作，相应的生成的加锁任务为：对多个独立关系的MO读锁定；对多个独立关系的MO写操作，相应的生成的加锁任务为：对多个独立关系的MO写锁定；对多个独立关系的MO删除操作，相应的生成的加锁任务为：对多个独立关系的MO删除锁定。其中，读锁定要求：允许并发多个用户对锁定的对象进行读取操作，但不能进行写、删除操作。写锁定要求：不允许其它用户对锁定的对象进行读、写或删除操作。删除锁定要求：不允许其它用户对锁定的对象，以锁定的对象为根的被管对象树中的任何一个被管对象进行读、写或删除操作。

其中该方法进一步包括：所述的内部任务列表是采用两级排序列表结构的表，其中：一级列表为等待级任务队列，等待任务通过first指针指示开头，其余任务通过next指针进行连接；另一级列表为休眠级任务队列，各休眠任务通过stack指针进行连接。

相应的，对内部任务列表填充方法进一步包括：

1、若当前任务与已处于加锁状态的任务相冲突，将其填入内部任务列表中的等待级任务队列，用next指针进行连接；新加入的任务放在队尾，每个任务依次加一个序列号；

2、若当前任务与内部任务列表中已有的等待任务相冲突，将其填入内部任务列表中的休眠级任务队列，用stack指针进行连接；新加入的任务放在队尾，每个任务依次加一个序列号。

由上述方法可以看出，本发明使得用户在某个时间段对于必需的资源进行独占式使用，从而在多用户并发操作的情况下，通过本发明所述的方法实现对MO的锁定，防范了死锁的发生，从而保证了网管数据库的安全性和完整性，提高了电信网管的可靠性。

附图说明

图1为采用事务机制的长时间事务类型程序中的多用户并行操作的相互影响示意图。

图2为本发明的总技术方案的示意图。

图3为本发明的锁定的任务列表的两级链表示意图。

图4为加解锁时任务列表中两级链表指针调整示意图，由图4-1、图4-2、图4-3组成。

图5为实施例的加锁的流程图。

具体实施方式

本发明所述的加锁是指：某任务被执行时，与此任务有冲突的其它任务处于被禁止执行的状态。所述的解锁是指：正在执行的任务结束后，相应的处于被禁止执行的任务恢复到可以被执行的状态。

图2是总技术方案的示意图。如图，用户对MO进行操作的时候，会自动的调用被管对象事例树(MIT)的MO管理接口，而后MIT根据用户操作的语义，如读、写、创建、删除等，调用锁定服务系统(LockManager)的MO加解锁接口，实现LockManager对此操作的加解锁。MIT用于向外提供锁定服务的接口，和具体协议无关；LockManager提供了一套完整的加解锁方案，并提供了供MIT调用的加解锁的接口，用于对MO操作的锁定。同时，LockManager的MO加解锁接口也可以由用户直接调用。如用户A的调用过程，用户A调用MIT的MO管理接口对MO进行确定的操作，如读、写、修改、创建、删除等，MIT根据这些语义自动的调用LockManager的MO加解锁接口；又如用户B的调用过程，当用户B进行操作时，如先锁定一批MO然后逐个进行操作，直接调用LockManager的MO加解锁接口进行对MO的加锁。在维护检测时调用锁状态镜像接口对锁的状态进行读取。

由X.732建议可知，电信网管中的MO是以包容关系存在，所以可认为MIT是由各个MO的实例所构成的层次形状的实例树，对MO的应用等操作的过程抽象为就是调用LockManager对MIT某些节点进行加、解锁的过程。概括加锁MO能出现的状态，可以得到锁定状态有：1、对单个MO读锁定(LockMORead)；2、对单个MO写锁定(LockMOWrite)；3、对某个节点的所有子节点(Children)读锁定，简称读Children锁(LockChildrenRead)；4、对某个节点的所有子节点写锁定，简称写Children锁(LockChildrenWrite)；5、对某个节点的所有子节点删除锁定(LockChildrenDelete)；6、对多个独立关系的MO读锁定(LockMultiMORead)；7、对多个独立关系的MO写锁定(LockMultiMOWrite)；8、对多个独立关系的MO删除锁定(LockMultiMODelete)。

其中，读锁定要求：允许并发多个用户对锁定的对象进行读取操作，但不能进行写、删除操作。写锁定要求：不允许其它用户对锁定的对象进行读、写或删除操作。删除锁定要求：不允许其它用户对锁定的对象，以锁定的对象为根的被管对象树中的任何一个被管对象进行读、写或删除操作。

在电信网管中实际的MO的锁定情况中，同时访问MO的线程数目是有限的，最多是几十个；MO的锁定请求对应的MO个数可能是大量的，且这些请求要作为一个原子操作返回；要求一个访问线程在提交一个锁定请求后处于锁定状态时不能再提交下一个锁定请求。若定义左分叉(LFork)是从要锁定的节点但不包括该节点开始遍历父系直到根节点路径中各个节点的锁的情况，定义右分叉(RFork)是以该节点为根且包括该节点的整个子树中的各个节点的锁的情况，则在上述各种锁发生时其相关联的所有节点的情况均可以归结为LFork和RFork。则在上述八种MO锁定状态下，进行某种加锁操作可以成功的时候，对应的其相关各个节点的锁应存在的状态如下：

1、LockMORead成功的条件：

LFork：所有的父MO不能处于LockChildrenWrite或LockChildrenDelete状态；

RFork：此MO自身不能处于LockChildrenDelete或LockMOWrite状态。

2、LockMOWrite成功的条件：

LFork：所有的父MO不能处于LockChildrenWrite、LockChildrenRead或LockChildrenDelete状态；

RFork：此MO自身不能处于LockChildrenDelete、LockMOWrite或LockMORead状态。

3、LockChildrenRead成功的条件：

LFork：所有的父MO不能处于LockChildrenWrite或LockChildrenDelete状态；

RFork：以此MO为根的子树中每个MO，不能处于LockMOWrite、LockChildrenWrite或LockChildrenDelete状态。

4、LockChildrenWrite成功的条件：

LFork：所有的父MO不能处于LockChildrenWrite、LockChildrenDelete、LockChildrenRead状态；

RFork：以此MO为根的子树中每个MO，不能处于LockMORead、LockMOWrite、LockChildrenRead、LockChildrenWrite或LockChildrenDelete状态。

5、LockChildrenDelete成功的条件：

LFork：所有的父MO不能处于LockChildrenWrite、LockChildrenDelete或LockChildrenRead状态；

RFork：以此MO为根的子树中每个MO，不能处于LockMORead、LockMOWrite、LockChildrenRead、LockChildrenWrite或LockChildrenDelete状态。

6、LockMultiMORead成功的条件：

LFork：要锁定的多个独立关系的MO的每一个MO的所有父MO不能处于LockChildrenWrite或LockChildrenDelete状态；

RFork：要锁定的多个独立关系的MO的每一个MO自身不能处于LockChildrenDelete或LockMOWrite状态。

7、LockMultiMOWrite成功的条件：

LFork：要锁定的多个独立关系的MO的每一个MO的所有父MO不能处于LockChildrenWrite、LockChildrenRead或LockChildrenDelete状态；

RFork：要锁定的多个独立关系的MO的每一个MO自身不能处于LockChildrenDelete、LockMOWrite或LockMORead状态。

8、LockMultiMODelete成功的条件：

LFork：要锁定的多个独立关系的MO的每一个MO的所有父MO不能处于LockChildrenWrite、LockChildrenDelete或LockChildrenRead状态；

RFork：要锁定的多个独立关系的MO的每一个MO的以自身为根的子树中每个MO，不能处于LockMORead、LockMOWrite、LockChildrenRead、LockChildrenWrite或LockChildrenDelete状态。

对于上述八种MO的锁定状态，可分析出其相关的父节点和子节点的锁的状态在不满足条件的情况下，加锁必然失败，也就是说，上述八点归纳了八种锁定任务能成功的必要条件。

对MO的操作加锁的过程就是通过对需加锁节点各个父节点和子节点的遍历得到相关的所有锁的状态，来比较判断此节点是否可以进行加锁的过程。

本发明将由于某任务的存在，而不能获取锁的当前任务，即将加锁失败的任务填充在一个任务列表(LockInfoList)中，进行保存。如图3所示，LockInfoList是一个两级排序链表，通过next和stack指针共同进行排序。LockInfoList的填充方法如下：

1、若当前任务与已处于加锁状态的任务相冲突，而无法获得锁，将其依次填入LockInfoList，在LockInfoList中，通过first指针指示开头，其余通过next指针连接起来；新加入的任务放在队尾，每个任务依次加一个序列号，序列号循环使用。这种任务称为“等待任务”，在图3中用白色表格表示出来；

2、若当前任务与LockInfoList中已有的等待任务相冲突，而无法获得锁，将其依次填入LockInfoList，用stack进行连接，stack指针依次顺序连接指向这些“休眠”任务，next指针则跳过此任务。这种任务称为“休眠任务”，在图3中用灰色表格表示出来。

举例说明：有五个MO：A，B，C，E四个MO相互独立，D是C的子MO。已经处于加锁成功的锁定状态有：读A锁(LockMORead)，写B锁(LockMOWrite)。现在有以下七个加锁请求依次顺序来到：1，读B、C锁(LockMultiMORead)；2，读E锁(LockMORead)；3，写C童锁(LockChildrenWrite)；4，写B锁(LockMOWrite)；5，写A锁(LockMOWrite)；6，写D锁(LockMOWrite)；7，删E童锁(LockChildrenDelete)。

由各任务的各自LFork和RFork依次与已经加锁的任务和LockInfoList中的任务进行比较，确定是否可以加锁。如，读B、C锁的LFork和Rfork状态中要求B不能处于写锁的状态，和已经加锁的任务写B锁相冲突，因此读B、C锁任务不能获得锁，填入LockInfoList。读E锁任务的LFork和Rfork状态中没有和已经加锁的任务和LockInfoList中的任务相冲突的，因此获得锁。写C童锁的因为LockInfoList中已经填入读B、C锁任务，与之相冲突，因此写C童锁不能获得锁，填入LockInfoList，且用stack指针与读B、C锁连接起来。同理，各个任务依次进行加锁判断，结果如下：

锁定状态的MO有：读A锁(LockMORead)、写B锁(LockMOWrite)、读E锁(LockMORead)；其他按照上述填充方法填入LockInfoList，参见图4-1，读B、C锁(LockMultiMORead)、写C童锁(LockChildrenWrite)、写B锁(LockMOWrite)、写A锁(LockMOWrite)、写D锁(LockMOWrite)、删E童锁(LockChildrenDelete)依次填入LockInfoList中；LockInfoList中任务1、4、6处于等待状态，next指针依次指向任务1、任务4、任务6、然后在循环返回指向任务1；LockInfoList中任务2、3、5处于休眠状态，stack指针依次指向任务2、任务3、任务5。

当有已加锁的任务释放锁时，依次唤醒LockInfoList中的等待任务，LockInfoList进行相应指针排序的调整，调整方法如下：next指针依次顺序下移，把LockInfoList中的等待任务对应的线程依次唤醒重新进行加锁判断。若某等待任务获得锁，则该任务加锁同时将其从LockInfoList中删除；同时检查此任务是否连接了一些“休眠”任务，如是，则将这些“休眠”任务和其余的“等待”任务按照上面所述的LockInfoList的填充方法重新排序进行排序指针的调整。

例如上述图4-1所示例子中已锁定的读A锁(LockMORead)、写B锁(LockMOWrite)任务顺序结束各自的线程为例，按照上述LockInfoList指针排序调整的方法，LockInfoList进行相应排序指针调整。读A锁(LockMORead)对应的线程执行结束，解锁读A锁(LockMORead)任务，则等待任务1、4、6依次进入加锁判断，由这些等待任务的各自LFork和RFork依次与已经加锁的任务和LockInfoList中的任务进行比较。如图4-2，任务4加锁出列，任务1、6仍处于等待状态，next指针依次指向任务1、任务6、任务1；stack指针依次指向任务2、任务3、任务5。

写B锁(LockMOWrite)对应的线程执行结束，解锁写B锁(LockMOWrite任务)，任务1、6进入加锁判断，如图4-3，任务1加锁出列，因为任务1连接休眠任务，调整休眠任务和等待任务排序重新排序，由这些休眠任务的各自LFork和RFork依次与已经加锁的任务和LockInfoList中的任务重新进行比较，和等待任务重新进行排序。next指针依次指向任务2、任务3、任务6、任务2；stack指针依次指向任务5。从链表指针的调整可知，此二级链表防范了任务1读B、C锁(LockMultiMORead)和任务3写B锁(LockMOWrite)同时出列造成死锁的情况。

因此，采用这种链表结构和上述的填充方法可以防范在多用户并行操作情况下死锁的发生。

以一个MO的加锁流程为例，参见图5所示，对本发明的加锁方法进一步详细说明：

步骤501：由对MO的操作，MIT根据用户操作的语义，自动调用LockManager的MO加解锁接口，使LockManager生成相应加锁任务。如，MIT根据读某个MO信息的命令，自动调用LockManager的MO加解锁接口，从而使LockManager生成一个对此MO节点的加读锁任务，即LockMORead。

步骤502：根据生成的加锁任务，取得此任务若成功加锁时，相关联的所有子节点和父节点的各个节点应出现的状态，即取得在加锁成功条件下，LFork和Rfork应有的状态。

步骤503：比较已经锁定的任务和LockInfoList中的各个任务是否符合此任务LFork和RFork的状态要求，若符合，则说明与此任务相冲突的相关节点任务不存在，此加锁任务能够成功，则此任务的线程执行下去，并加锁返回，等此任务对应的线程结束后再进行释放锁；否则，说明与此任务相冲突的相关节点任务存在，加锁失败，执行步骤504将任务填入LockInfoList中。

步骤504：按照前文所述LockInfoList的填充方法，将此任务顺序加到LockInfoList中，处于等待或休眠状态。同时采用等待对应该线程的信号量或者直接挂起的方法提交线程阻塞，使该任务对应的线程处于等待状态。

步骤505：有其它的加锁任务被释放时，依次唤醒LockInfoList中符合条件的所有的等待任务，按照前文所述LockInfoList指针排序调整的方法进行相应排序指针调整。

唤醒的任务重复步骤502到505，再次进行加锁。

加锁的锁定状态不仅可针对整个MO，也可只针对MO的一种属性，如进一步细分可以针对MO进行故障、配置、性能等某一种属性进行锁定。所以本发明不局限于所述的八种锁定状态和对应各锁定状态存在时所有的MO的锁情况。如下段程序，是分别定义锁的类型和要锁定MO某类型属性：

enum LOCKTYPE{LOCKMO，LOCKMULTI，LOCKCHILDREN，LOCKTYPEALL}

enum ATTRTYPE{FLT，CFG，PFM，PTH，ATTRALL}

此处不再详叙。

本发明和具体的数据库、具体的操作系统、具体的协议无关。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1、一种电信网管系统中被管对象的加锁方法，其特征在于包括以下步骤：

A、锁定服务系统根据对被管对象的操作，生成与之相应的加锁任务；

B、根据生成的加锁任务，取得此任务要锁定的对象相关联的所有父、子节点的各个节点应出现的锁的状态；

C、判断已经加锁的任务和内部任务列表中的各个任务是否符合此任务的子节点和父节点的各个节点应出现的锁的状态，若符合则对当前任务进行加锁，返回结束；否则执行步骤D；

D、将本任务填充入内部任务列表进行保存，同时提交线程阻塞，使该任务对应的线程处于等待状态。

2、根据权利要求1所述的方法，其特征在于步骤A所述的生成加锁任务的方法进一步包括：有已加锁状态的任务被释放时，唤醒内部任务列表中的任务，将唤醒的任务作为加锁任务。

3、根据权利要求1所述的方法，其特征在于步骤A所述的锁定服务系统生成加锁任务的方法进一步包括：通过锁定服务系统的MO加解锁接口调用锁定服务系统，或通过调用被管对象事例树的MO管理接口调用锁定服务系统。

4、根据权利要求1所述的方法，其特征在于步骤C进一步包括：若当前的加锁任务是被唤醒的内部任务列表中的任务，则该任务加锁成功时，同时将该任务从内部任务列表中删除。

5、根据权利要求1所述的方法，其特征进一步包括：

A1、对单个被管对象读操作，相应生成的加锁任务为：对单个被管对象读锁定；

A2、对单个被管对象写操作，相应生成的加锁任务为：对单个被管对象写锁定；

A3、对以某个节点的所有子节点读操作，相应生成的加锁任务为：对以某个节点的所有子节点读锁定；

A4、对以某个节点的所有子节点写操作，相应生成的加锁任务为：对以某个节点的所有子节点写锁定；

A5、以某个节点的所有子节点删除操作，相应生成的加锁任务为：以某个节点的所有子节点删除锁定；

A6、对多个独立关系的被管对象读操作，相应生成的加锁任务为：对多个独立关系的被管对象读锁定；

A7、对多个独立关系的被管对象写操作，相应生成的加锁任务为：对多个独立关系的被管对象写锁定；

A8、对多个独立关系的被管对象删除操作，相应生成的加锁任务为：对多个独立关系的被管对象删除锁定。

6、根据权利要求1所述的方法，其特征在于步骤C进一步包括：所述的内部任务列表是采用两级排序列表结构的表，其中：

一级列表为等待级任务队列，等待任务通过first指针指示开头，其余任务通过next指针进行连接，每个任务依次加一个序列号；

另一级列表为休眠级任务队列，各休眠任务通过stack指针进行连接，每个任务依次加一个序列号。

7、根据权利要求6所述的方法，其特征在于对内部任务列表填充方法进一步包括：

D1、将新加入的任务放在内部任务列表中任务队列的队尾；

D2、若当前任务与已处于加锁状态的任务相冲突，将其填入内部任务列表中的等待级任务队列；

D3、若当前任务与内部任务列表中已有的等待任务相冲突，将其填入内部任务列表中的休眠级任务队列。

Images