CN101196829A - 协同编辑中数据冲突模块的加锁方法 - Google Patents

Abstract

本发明公开了一种协同编辑中数据冲突模块的加锁方法，每个协作者对自己编辑位置范围的锁定都要得到自己所在组的主编节点的认可，每个协作者有且仅有一把锁，在锁定范围内可任意进行各种编辑操作；在每个节点都保存了一份组内成员的锁表，当本地加锁操作发生时，首先扫描本地的锁表，看有没有冲突，如果有，则首先要通过优先级的判断，之后，加锁的判断结果被发送到主编节点，由主编节点进行仲裁；本发明提出了人性化加锁方法，不仅可以提高协同编辑的效率，而且可以灵活的处理冲突；该加锁方法易于实现，解决了原始技术方案的弊病，具有良好的可扩展性；并且提供了一种有弹性的数据冲突解决方案，能够满足多人分布式协同编辑的协同需求。

Description

协同编辑中数据冲突模块的加锁方法

技术领域

本发明涉及协同编辑加锁方法，尤其是涉及一种协同编辑中数据冲突模块的加锁方法。

背景技术

随着大型编辑需求的产生和网络技术的不断发展，分布式的协同编辑系统应运而生并开始了飞速的发展。协同编辑系统结构分为主编辑节点和协编辑节点。主编辑节点创建会话，协编辑节点参与会话，在会话过程中，最重要的任务就是在保证效率的前提下，发现和解决多人同时编辑可能存在的冲突，于是便引入了对编辑对象加锁的机制，加锁机制主要有以下几种：传统的加锁法、tickle锁、floor控制、可逆执行(Undo/Redo)和操作转换等。

传统的加锁法最突出的优点是设计和实现较为简单，它能保证具体上下文的语义完整性，但是它在分布式协同编辑中无法保证加锁位置的一致性。tickle锁方法适合于分节加锁的实时分布式协同编辑的并发控制，然而，无法提供多个编辑者对节内的同时编辑。JCE(Java Collaborative Envirment)中的协同编辑采用了floor控制方法，每个协作编者只有获得floor才能进行编辑操作，较适合讨论式的协作编辑，不适合实时无约束的协作编辑。在可逆操作(Undo，Redo)算法中，操作可以立即执行，但与操作有关的信息将被保留下来，以便在必要的时候取消该操作。这种方法的用户响应性能良好，但其需要定义操作的全程时序，这是相当困难的。操作转换算法能自动地解决冲突而无需手工干预，有良好的实时响应性，能保持收敛性和维护意愿，但是它不能保证上下文的语义完整性。

加锁技术分为乐观锁技术和悲观锁技术。乐观锁不锁定任何东西，当事务更新记录时，事务会进行检查，看看自从自己上次读取了这条记录之后，是否有其它事务修改了这条记录，如果被其它事务修改了，这个事务通常会回滚，然后重新尝试，更新数据的时候执行这个代价不高的检查，能够避免弄丢其它数据的修改，而且，只有发现修改冲突的时候，才引起事务重来一遍的额外开销。

悲观锁机制假设并发更新冲突会发生，所以不管冲突是否真的发生，都会引入额外的锁开销，但是，这个额外开销比完全隔离事务的额外开销要小得多，使用悲观锁的事务会锁住读取的记录，防止其它事务读取和更新这些记录，其它事务会一直阻塞，直到这个事务的提交或者回滚释放了锁，悲观锁能够防止修改丢失，并且能够提供一定程度读取的一致性，因为它能防止本事务读取的记录被其它事务修改，然而，由于悲观锁不防止新纪录的增加，因而执行同样的查询可能返回不同的结果集。

与本发明相关的现有技术：

现有技术一的技术方案：

中国专利，申请号为200510049259.6，发明名称为《基于语义锁实现图案协同设计中的语义保持方法》，该技术方案的缺点：主要注重于语义的锁定，是在传统加锁方式之中添加了对语义的处理，但没有对加锁方式进行本质的改进，因而无法避免独占资源或者编辑内容被回滚的问题，同时，基于语义的应用在文字处理方面有一定的作用，但移植性差，无法广泛应用于各种协同编辑系统。

现有技术二的技术方案

中国专利，申请号为200510049260.9，发明名称为《图案协同设计中的语义一致性维护的方法》，该技术方案的的缺点：主要注重于语义冲突的避免，在没有使用加锁机制的情况下，从语义方面进行冲突的规避。由于没有引入加锁，使该方案无法适应其它的应用需求，移植性差；同时，在冲突的处理过程中，无法达到使用了加锁机制的效果，因此，该方案也无法广泛应用于各种协同编辑系统。

发明内容

本发明的目的是提供一种协同编辑效率高，处理冲突灵活、易于实现的协同编辑中数据冲突模块中的加锁方法，解决了目前的协同编辑加锁机制各自存在问题，无法做到人性化的协同、协调的问题。

为了达到上述目的，本发明采用如下技术方案：一种协同编辑中数据冲突模块的加锁方法，每个协作者对自己编辑位置范围的锁定都要得到自己所在组的主编节点的认可，每个协作者有且仅有一把锁，在锁定范围内可任意进行各种编辑操作；在每个节点都保存了一份组内成员的锁表，当本地加锁操作发生时，首先扫描本地的锁表，看有没有与别人的锁有冲突，如果有，则首先要通过优先级的判断，来确定该资源应该由那方使用，判断的结果有：

(1)、维持原始的加锁；这种情况下，请求加锁的操作不能进行；

(2)、抢夺原来的加锁；但是这个请求必须通过服务器的允许；

(3)、提示用户仲裁；这种情况发生在优先级相同的两个加锁冲突时，如果用户不愿意仲裁中断任务的进行，可以关闭仲裁而使用默认的乐观锁回滚方法；

之后，加锁的判断结果被发送到主编节点，主编节点判断：

(a)、是否有别的节点与该节点申请的锁位置范围冲突；如果没有，它将发回同意的消息，申请锁的节点原来的编辑操作生效；

(b)、如果有冲突，则主编节点需要按照上述的优先级方式判断协作者的资源分配请求是不是有效，有效的话，也发回同意，并且修改主编节点维护的锁表，通知各协作节点无条件接受该锁表；无效的话则拒绝该加锁判断，申请的节点也要无条件接受；

(c)、如果同时有多个关于加锁的判断，则主编节点要根据各节点的时间戳验证请求是不是超时，非超时请求根据优先级排队，并使用上述的加锁方式对所有节点的请求进行判断，之后主编节点根据判断结果，拟定自身的锁表，判断哪些节点需要回滚，哪些同意加锁，判断结束后，将锁表发回给所有节点，协编节点无条件接受；

收到主编节点发回的否定请求加锁信息的节点，按本地的取消操作集取消预先编辑操作，每个用户节点释放锁时，必须将释放锁的信息发给主编节点，主编节点释放该锁并将锁释放信息发给组内所有节点，每个节点收到该信息后更新自身的锁表，如果加锁的位置范围没有与本地的锁表冲突，那么本地的编辑操作仍继续进行，不必要等待远程主编的应答到来再操作。

所述协编节点在申请锁的过程中，本地编辑操作可预先进行，并保留这些操作作为取消操作集，取消操作集是在加锁失败的情况下会被回滚操作的集合，只有在释放锁的前一刻才会被添加到原始的编辑对象中。

所述锁表的冲突是指两把锁的锁定范围交叉、重叠或者包含。

锁由起始位置和长度来描述。

锁表包含所有锁的锁定位置和范围。

本发明在于在加锁的机制中加入了人性化的协同要素，当发生冲突的时候，首先试图通过优先级解决冲突，并在主编辑节点划分专门的缓冲区存放冲突的争议区域的内容；当优先级无法解决冲突的时候，主编辑端给两个编辑端提供链接，由编辑端协商决定，竞争胜利的一方获得加锁权限。

本发明的有益效果为：提出了人性化加锁方法，不仅可以提高协同编辑的效率，而且可以灵活的处理冲突；该加锁方法易于实现，无需特殊管理，解决了原始技术方案的弊病，具有良好的可扩展性；并且提供了一种有弹性的数据冲突解决方案，能够满足多人分布式协同编辑的协同需求。

附图说明

图1是本发明加锁方法的流程图；

图2是本发明中协编节点加锁处理流程图；

图3是本发明中主编节点的判别流程图。

具体实施方式

本发明中涉及到的缩略语和关键术语定义如下：

协编辑节点：作为协助者参与某个协同编辑会话的用户。

主编辑节点：第一个创建该主题会话的用户，它是本会话的协调者，主要负责本会话内协编结点锁申请的仲裁以及对该会话的管理。

参考锁：为申请锁时锁定位置的前一把锁，它是作为锁定位置转换的参考点。

相对位置：指从参考锁的结束位置到欲加锁的起始位置的距离。

锁的冲突：存在两把互斥锁的锁定范围出现交叉、重叠或者包含情形。本发明涉及到的协同编辑系统的结构：

协同编辑中数据冲突模块的加锁方法的系统结构常有集中式和分布式两种。集中式系统实现简单，但操作的响应慢；而分布式系统操作响应快，但并发控制难度大。为了达到良好的响应效果和自由的协作，本发明的协同编辑系统结构采用了分布式与集中式相结合的体系结构，让主编节点集中管理每个协编节点的会话、用户登陆信息以及每个会话的日志等信息，当登陆成功以后，各协作者之间的通信是完全分布式的，从而减轻了传统的C/s结构中服务器的负荷，也避免了服务器对系统的性能所造成的瓶颈，另外，各协编节点在进入会话以后采用的是完全分布式的结构，因此能够减少通信的时延，缩短响应时间，明显地提高系统的实时性，使本地用户的操作能够快速地反映给远端的协作者。另一个方面，采用分布式与集中式相结合，能避免完全分布式结构数据维护困难，管理混乱的缺点。

本发明的协同编辑系统由一个集中的会话管理者和若干协编节点所组成，会话管理者可以运行在单独的一台服务器上，也可以位于其中的一个协编节点上，其IP地址是公开的，因而成为整个系统的接入点，它主要管理协作者、会话以及会话的日志，这些与一个用户加入或离开会议时有关。同时，主编节点也可以执行或发送编辑操作，协编节点主要负责与主编节点的信息收发，与其它协编节点交换信息以及编辑信息的界面显示工作。管理节点有会话管理主线程，发送线程和接受线程，该节点具有众所周知的IP地址，会话管理主线程可以在编辑的同时等待来自于Internet上的协编节点的连接请求，一旦连接请求被接受，就分别创建一个接收线程和一个发送线程，去处理会话管理者与该协编节点之间的进一步通信，主线程继续工作，并等待其它节点的连接请求，接收线程还需要从每个会话的主编节点获取当前编辑的状态，其方式为主编节点向下进行广播，协编节点负责接收、更新并形成会话的日志，便于以后继续进行编辑。在这里，主编节点作为会话管理者。

节点主要包括以下几个线程(主编节点作为特殊的节点)：

(1)登陆线程：它主要负责向会议管理者提供用户的登陆信息，如果是新用户，要向会议管理者提供注册信息，如果登陆成功便激活主线程。

(2)主线程：它主要负责接收别的节点的连接请求并为每个新的连接分别创建一个编辑操作发送线程和编辑操作接收线程。主线程还负责对本地编辑操作的响应以及处理由编辑操作接收线程所接受的远程操作在本地窗口中的显示。主线程还有一个重要的任务是激活一个锁信息发送线程以及对锁信息接收线程接收的信息进行处理。在主线程内，有两个重要的数据结构：锁表和在线会话成员列表(包括用户名和IP地址)。

(3)编辑操作发送线程：主要负责将本地发生的编辑操作发送到远程的主编点或各个协编节点。

(4)编辑操作接收线程：主要负责接收远程协编节点所传来的远程编辑操作，并根据本地文本的状态对该远程操作进行恰当的转换，维护文本状态的一致性，同时可能需要通知主线程对锁表进行相应的改动。

(5)锁信息发送线程：主要负责向主编节点发送锁的请求。

(6)锁信息接收线程：主要负责接收主编节点发来的锁信息和锁表的变更信息，如果信息为肯定则继续本地的编辑操作，否则，该线程还要负责根据取消操作集将无效的操作取消。

对于主编节点来讲，它的锁信息接收线程主要负责接收本会话内其它协作者发来的锁请求，而锁信息发送线程主要负责向请求锁的线程发送应答信息，如果是肯定的应答，他还要向组内所有成员发送锁表变更的消息。

本发明协同编辑中数据冲突模块中的加锁方法的如图1、图2、图3所示：

本发明中的加锁方法基本采用乐观锁的思想，每个协作者对自己编辑位置范围的锁定都要得到自己所在组的主编节点的认可，每个协作者有且仅有一把锁，在锁定范围内可任意进行各种编辑操作，锁可由起始位置和长度来描述；在每个节点都保存了一份组内成员的锁定位置和范围一锁表，当本地加锁操作发生时，首先扫描本地的锁表，看有没有与别人冲突，锁的冲突是指两把锁的锁定范围交叉、重叠或者包含，如果有，则首先要通过优先级的判断，来确定该资源应该由那方使用，判断的结果可能是：

1.维持原始的加锁；这种情况下，请求加锁的操作不能进行(原始锁优先级高于当前加锁请求优先级)。

2.抢夺原来的加锁；但是这个请求必须通过服务器的允许(原始锁优先级低于当前加锁请求优先级)。

3.提示用户仲裁；这种情况发生在优先级相同的两个加锁冲突时。如果用户不愿意仲裁中断任务的进行，可以关闭仲裁而使用默认的乐观锁回滚机制。

但是，在申请锁的过程中，本地编辑操作可预先进行，并保留这些操作作为取消操作集。取消操作集是在加锁失败的情况下会被回滚的操作的集合，只有在释放锁的前一刻才会被添加到原始的编辑对象中。

之后，加锁的判断结果被发送到主编节点，主编节点判断：

1.是否有别的节点与该节点申请的锁位置范围冲突(该步骤通过图3中的按照单节点算法来判断，此单节点算法可以为已有的算法)；如果没有，它将发回同意的消息，申请锁的节点原来的编辑操作生效。

2.如果有冲突，则主编节点需要按照上述的优先级方式判断协作者的资源分配请求是不是有效，有效的话，也发回同意，并且修改主编节点维护的锁表，通知各协作节点无条件接受该锁表；无效的话则拒绝该加锁判断，申请的节点也要无条件接受。

3.如果同时有多个关于加锁的判断，则主编节点要根据各节点的时间戳验证请求是不是超时，非超时请求根据优先级排队，并使用上述的加锁方式对所有节点的请求进行判断。之后主编节点根据判断结果，拟定自身的锁表，判断哪些节点需要回滚，哪些同意加锁。判断结束后，将锁表发回给所有节点，协编节点无条件接受。

收到主编发回的否定请求加锁信息的节点，按本地的取消操作集取消预先编辑操作。

每个用户节点释放锁时，必须将释放锁的信息发给主编节点。主编节点释放该锁并将锁释放信息发给组内所有节点，每个节点收到该信息后更新自身的锁表。由上述加锁请求过程可看出，如果加锁的位置范围没有与本地的锁表冲突，那么本地的编辑操作仍继续进行，不必要等待远程主编的应答到来再操作，由于多个协作者同时竞争一个位置的可能性很小，因此发生锁申请不成功而取消操作的可能性也很小，因而系统编辑的效率很高，即使在产生了冲突的情况下，根据优先级进行加锁选择的方案可以最大限度地保证重要的编辑工作不被随便中断；同时，采用用户仲裁的方式更方便解决一些软件无法完善解决的冲突问题，而关闭用户仲裁后，加锁方案退化成基于优先级的乐观锁加锁仲裁方案，仍然具有很高的效率。

本发明涉及的协同编辑系统的管理：

从结构上来看，各节点的组成是相似的。主编节点和协编节点都维护一个锁表，该表内容为现在系统的加锁情况，其更新是同步的，由主编节点负责进行。主编节点需要更新锁表的时候，会向各协编节点进行广播，协编节点收到广播之后，必须无条件的按照主编节点的广播内容修改锁表，从而保持与其它节点的同步。

节点在向主编节点申请加锁的时候，需要动态的申请一块区域用于存放需要申请的加锁信息，即在本地锁表信息的一份拷贝的基础上进行修改，然后提供给主编节点，本地操作也动态申请一段内存区域，并拷贝加锁区域的信息，在该区域内编辑，作为取消操作集。当请求被批准以后，则节点撤销原始的锁表，使用修改后的锁表，并继续在取消操作集的内容基础上进行编辑，预防更高优先级的请求需要抢占。在编辑结束后，使用取消操作集取代原始锁定区域内容；若任何时候，加锁请求被驳回，则取消操作集的内容被回滚，并维持原始锁表，直到主编节点要求更新为止。

Claims (5)

1.一种协同编辑中数据冲突模块的加锁方法，其特征在于：每个协作者对自己编辑位置范围的锁定都要得到自己所在组的主编节点的认可，每个协作者有且仅有一把锁，在锁定范围内可任意进行各种编辑操作；在每个节点都保存了一份组内成员的锁表，当本地加锁操作发生时，首先扫描本地的锁表，看有没有与别人的锁有冲突，如果有，则首先要通过优先级的判断，来确定该资源应该由那方使用，判断的结果有：

(1)、维持原始的加锁；这种情况下，请求加锁的操作不能进行；

(2)、抢夺原来的加锁；但是这个请求必须通过服务器的允许；

(3)、提示用户仲裁；这种情况发生在优先级相同的两个加锁冲突时，如果用户不愿意仲裁中断任务的进行，可以关闭仲裁而使用默认的乐观锁回滚方法；

之后，加锁的判断结果被发送到主编节点，主编节点判断：

(a)、是否有别的节点与该节点申请的锁位置范围冲突；如果没有，它将发回同意的消息，申请锁的节点原来的编辑操作生效；

(b)、如果有冲突，则主编节点需要按照上述的优先级方式判断协作者的资源分配请求是不是有效，有效的话，也发回同意，并且修改主编节点维护的锁表，通知各协作节点无条件接受该锁表；无效的话则拒绝该加锁判断，申请的节点也要无条件接受；

(c)、如果同时有多个关于加锁的判断，则主编节点要根据各节点的时间戳验证请求是不是超时，非超时请求根据优先级排队，并使用上述的加锁方式对所有节点的请求进行判断，之后主编节点根据判断结果，拟定自身的锁表，判断哪些节点需要回滚，哪些同意加锁，判断结束后，将锁表发回给所有节点，协编节点无条件接受；

收到主编节点发回的否定请求加锁信息的节点，按本地的取消操作集取消预先编辑操作，每个用户节点释放锁时，必须将释放锁的信息发给主编节点，主编节点释放该锁并将锁释放信息发给组内所有节点，每个节点收到该信息后更新自身的锁表，如果加锁的位置范围没有与本地的锁表冲突，那么本地的编辑操作仍继续进行，不必要等待远程主编的应答到来再操作。

2.根据权利要求1所述的协同编辑中数据冲突模块的加锁方法，其特征在于：所述协编节点在申请锁的过程中，本地编辑操作可预先进行，并保留这些操作作为取消操作集，取消操作集是在加锁失败的情况下会被回滚的操作的集合，只有在释放锁的前一刻才会被添加到原始的编辑对象中。

3.根据权利要求1所述的协同编辑中数据冲突模块的加锁方法，其特征在于：所述锁表的冲突是指两把锁的锁定范围交叉、重叠或者包含。

4.根据权利要求1所述的协同编辑中数据冲突模块的加锁方法，其特征在于：锁由起始位置和长度来描述。

5.根据权利要求1所述的协同编辑中数据冲突模块的加锁方法，其特征在于：锁表包含所有锁的锁定位置和范围。

Images