讨论：用户操作唯一性管理

我们的项目是一个具有工作流特性的B/S系统；现在处于功能测试阶段，前几天一个同事提出一个问题：

系统中的很多工作都必须有步骤的进行，比如，先做计划，然后实施，再查看结果。
系统中的用户权限分为浏览和操作，用户在模块中的权限是交错的，在一个模块可以操作而在另一个模块
只能浏览操作结果。

现在的情况是如果在同一时间有两个或多个对同一模块具有操作权限的用户在这一模块中进行操作的话，可能会引起
操作结果冲突的现象；比如A和B两个人都可以做发电计划，A、B两个人如果在同一时间都给电厂分配电量，那么电厂接到的
发电计划会冲突或者造成数据丢失！

现在我们想到的解决方法是

1.在数据库中给每一个模块建立一个操作步骤存储表，根据步骤标志位的判断解决冲突！

2.在服务器上作一个托盘，实时检测用户登录，当有一个用户在这一模块中进行操作时，进入这一模块的另一用户不管权限大小都
只分配浏览权限，并给用户以提示！

3.通过权限控制，两个对同一模块都具有操作权限的用户，谁先登录本模块谁就有操作权，后登录的只有浏览权；设定先登录用户
使用时间，时间一到再进行操作就需要重新登录，再进入时如果已经有用户在操作就给他分配浏览权限！


第一种方法实现最简单，但是数据交互量增加，交互频繁！
第二种方法实现起来应该比较麻烦，但是更能符合需求；
最后一种缺乏人性化！

请知各位是怎样解决这一问题的？请不吝赐教！
请积极拍砖！

评论

15 楼 XMLDB 2006-12-30  

按标志位来，在不远的将来就可以看到有一些谁都不能操作的数据了，哈哈

14 楼 daoger 2006-12-30  

XMLDB 写道

daoger 写道

Lucas Lee 写道

这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。

实际上，就是加了一个排他锁，想进入则先获得此锁。

我们现在的想法和你的说法差不多；可问题是用户进入的时候我可以比较容易的实现排他锁，现在的困难就是怎么让他进行完操作后释放排他锁，让其他用户获得！

不知你有没有好的解决方法？

在BS这种异步应用环境下,就别想CS的加锁解决方案了,前人已经总结了加version标志,更新后查询是否操作正确是最实用的方法.

看来能尽快解决的方法就只能用标志位了!

13 楼 daoger 2006-12-30  

clamp 写道

奇怪，大家都觉得自己理解需求了吗？这么迫不及待的给技术解决方案啊……

我问个需求澄清问题：
是否存在以下这种情况，一个模块中有多个实例记录？
比如编辑计划
存在着多份计划，A/B两个用户都有编辑计划的权限，
在同一时刻A/B都能使用编辑计划这个功能，但是只能编辑不同的计划，而不能编辑相同的计划。

是这样的，每个人制定的计划都是根据各自对业务的理解而来的，一样的可能性不大！

还有一点就是，我们的功能基本全部实现了，现在正在由用户进行功能测试，项目再有几个月就要投运了！如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的！

昨天又问了一下项目经理，如果暂时没有好的解决方法，就只能从权限上控制，暂时每一个模块只有一个具有操作权限的用户！

唉！

各位以前的B/S项目中没遇到这样的需求吗？

12 楼 XMLDB 2006-12-30  

daoger 写道

Lucas Lee 写道

这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。

实际上，就是加了一个排他锁，想进入则先获得此锁。

我们现在的想法和你的说法差不多；可问题是用户进入的时候我可以比较容易的实现排他锁，现在的困难就是怎么让他进行完操作后释放排他锁，让其他用户获得！

不知你有没有好的解决方法？

在BS这种异步应用环境下,就别想CS的加锁解决方案了,前人已经总结了加version标志,更新后查询是否操作正确是最实用的方法.

11 楼 clamp 2006-12-30  

奇怪，大家都觉得自己理解需求了吗？这么迫不及待的给技术解决方案啊……

我问个需求澄清问题：
是否存在以下这种情况，一个模块中有多个实例记录？
比如编辑计划
存在着多份计划，A/B两个用户都有编辑计划的权限，
在同一时刻A/B都能使用编辑计划这个功能，但是只能编辑不同的计划，而不能编辑相同的计划。

10 楼 XMLDB 2006-12-30  

rtdb 写道

需要开一个CHECKOUT表，重要资源还要有编码。
当用户申请CHECKOUT某资源时，
查表看该资源是否已被别人CHECKOUT， 若有，CHECKOUT失败，
若无记录，增加一记录，表明该资源已被该用户CHECKOUT，返回成功。

CHECKIN时简单地确认是同一用户CHECKOUT的，则删除该记录即可。

按楼主的说法,请问那Checkout 表的操作用什么来保证操作唯一性?

9 楼 rtdb 2006-12-29  

需要开一个CHECKOUT表，重要资源还要有编码。
当用户申请CHECKOUT某资源时，
查表看该资源是否已被别人CHECKOUT， 若有，CHECKOUT失败，
若无记录，增加一记录，表明该资源已被该用户CHECKOUT，返回成功。

CHECKIN时简单地确认是同一用户CHECKOUT的，则删除该记录即可。

8 楼 LucasLee 2006-12-29  

daoger 写道

Lucas Lee 写道

这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。

实际上，就是加了一个排他锁，想进入则先获得此锁。

我们现在的想法和你的说法差不多；可问题是用户进入的时候我可以比较容易的实现排他锁，现在的困难就是怎么让他进行完操作后释放排他锁，让其他用户获得！

不知你有没有好的解决方法？

简单的，就是一个标志位（比如存在数据库中），0则可被获取，1则已被锁定。
用户完成后，提交时则重置标志。

这是最简单的。可以在此基础上变化。

7 楼 daoger 2006-12-29  

rtdb 写道

就是Checkout/Checkin么。
用户操作前先要Checkout，加锁成功后获得更新权限，
完成后要Checkin，在Checkin时保存数据及释放锁定。

能说得具体一些吗？

6 楼 rtdb 2006-12-29  

就是Checkout/Checkin么。
用户操作前先要Checkout，加锁成功后获得更新权限，
完成后要Checkin，在Checkin时保存数据及释放锁定。

5 楼 daoger 2006-12-28  

Lucas Lee 写道

这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。

实际上，就是加了一个排他锁，想进入则先获得此锁。

我们现在的想法和你的说法差不多；可问题是用户进入的时候我可以比较容易的实现排他锁，现在的困难就是怎么让他进行完操作后释放排他锁，让其他用户获得！

不知你有没有好的解决方法？

4 楼 LucasLee 2006-12-28  

这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。

实际上，就是加了一个排他锁，想进入则先获得此锁。

3 楼 daoger 2006-12-28  

leelun 写道

用Hibernate的Version字段,控制每次只能由一人保存数据,如果出现Version冲突,就回滚并重新读取数据

一个步骤中有很多任务，一个任务也可以出现很多结果，这很多结果可能都是正确的；如：给电厂分配发电量，只要是在机组发电负荷之下的都可以认为是正确的！

我没用过Version字段，不知道是不是要修改数据库，即便是现在修改代码，工作量也不小啊！

再说这是依赖于hibernate，如果用其他映射框架呢？

查查用Hibernate的Version字段的用法，呵呵！

2 楼 XMLDB 2006-12-28  

做version control不就好了?
old = getNewestValue();
while(old != new) {
  updateChangeFromNew(old,new);
  old = getNewestValue();
}

1 楼 leelun 2006-12-28  

用Hibernate的Version字段,控制每次只能由一人保存数据,如果出现Version冲突,就回滚并重新读取数据