20XX 基于 web 粒度可配的编辑锁设计论文 今日我给大家带来了 20XX 基于 web 粒度可配的编辑锁设计，有需要的小伙伴一起来参考一下吧，希望能给大家带来帮助！ 提出了多人同时编辑同一 web 页面会引起版本冲突，抽象出问题的模型，针对问题设计了一种普通编辑锁，借助 Ajax 技术，有效地解决了多人同时编辑同一 web页面版本冲突问题，同时也避开的传统编辑锁长时间锁定被编辑页面的弊端。进一步提出粒度可配的编辑锁，除能有效解决普通编辑锁能解决的问题外，还可以通过配置细粒度来锁定更少的资源，使没必要被锁的资源处于可被编辑状态，提高系统被编辑的效率和缩短了其他用户的等待时间。 随着大规模协作时代的到来，发动社区内成员共同编辑协作，集众人之力，发挥每个人的特长，高质量地完成某项任务是一件非常有意义的事情。基于“多人协作”的主要工具为 wiki[1]，比较有代表性的有维基百科[2]、TraceWiki、HdWiki 等[3]，这些工具允许多人编辑同一词条，每编辑一次生成一个版本。近几年来，基于web 多人协作平台的迅速进展，相关讨论非常多，主要讨论焦点集中在一些宏观方面：比如在某方面的应用[4]，组织模型[5]等。大多忽视了微观小问题的讨论，比如：多人同时编辑同一页面时，发生冲突了怎么办？本文通过抽象出多人同时编辑同一 web页面存在冲突问题的模型，设计出数据库表，借助 ajax 技术，解决这个问题。 1 普通编辑锁的设计 问题抽象 存在多人同时协作时的场景：某 wiki网站，用户 A 在编辑词条 A，用户 B 也在编辑词条 A，此时，后提交的将覆盖前面提交的热荩造成冲突。假如词条很长，网站对词条进行了处理，将其分段，用户 A 编辑词条 A 的第一段，用户 B 同时编辑词条 A 的第二段，此时则不会造成冲突。 根据上述场景，将问题进行抽象，对于协作者来讲，不管是机构、客户端、网站用户等统统定义为用户 user，对于被编辑的对象不管是文章还是页面上的某个模块，只要是可以被单独编辑的对象，统统定义为资源 resource，问题就抽象为 user通过对 resource 加锁独享的问题。 数据库设计 数据库被简化成三张表：user{userId，userName}；resource{resourceId， resourceName ，content}；lock{lockId，userId，resourceId（unique），startTime，state，heartBeatTime}，User 表和 resource 表在一般系统中已经存在，只需添加 lock 表即可。其简单的ER 图如图 1 所示。 每...
