|
锁定老帖子 主题：讨论：用户操作唯一性管理
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-12-30
rtdb 写道 需要开一个CHECKOUT表，重要资源还要有编码。
当用户申请CHECKOUT某资源时， 查表看该资源是否已被别人CHECKOUT， 若有，CHECKOUT失败， 若无记录，增加一记录，表明该资源已被该用户CHECKOUT，返回成功。 CHECKIN时简单地确认是同一用户CHECKOUT的，则删除该记录即可。 按楼主的说法,请问那Checkout 表的操作用什么来保证操作唯一性? |
| 返回顶楼 | |
|
发表时间：2006-12-30
奇怪，大家都觉得自己理解需求了吗？这么迫不及待的给技术解决方案啊……
我问个需求澄清问题： 是否存在以下这种情况，一个模块中有多个实例记录？ 比如编辑计划 存在着多份计划，A/B两个用户都有编辑计划的权限， 在同一时刻A/B都能使用编辑计划这个功能，但是只能编辑不同的计划，而不能编辑相同的计划。 |
| 返回顶楼 | |
|
发表时间：2006-12-30
daoger 写道 Lucas Lee 写道 这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。 实际上，就是加了一个排他锁，想进入则先获得此锁。 我们现在的想法和你的说法差不多；可问题是用户进入的时候我可以比较容易的实现排他锁，现在的困难就是怎么让他进行完操作后释放排他锁，让其他用户获得！ 不知你有没有好的解决方法？ |
| 返回顶楼 | |
|
发表时间：2006-12-30
clamp 写道 奇怪，大家都觉得自己理解需求了吗？这么迫不及待的给技术解决方案啊……
我问个需求澄清问题： 是否存在以下这种情况，一个模块中有多个实例记录？ 比如编辑计划 存在着多份计划，A/B两个用户都有编辑计划的权限， 在同一时刻A/B都能使用编辑计划这个功能，但是只能编辑不同的计划，而不能编辑相同的计划。 是这样的，每个人制定的计划都是根据各自对业务的理解而来的，一样的可能性不大！ 还有一点就是，我们的功能基本全部实现了，现在正在由用户进行功能测试，项目再有几个月就要投运了！如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的！ 昨天又问了一下项目经理，如果暂时没有好的解决方法，就只能从权限上控制，暂时每一个模块只有一个具有操作权限的用户！ 唉！ 各位以前的B/S项目中没遇到这样的需求吗？ |
| 返回顶楼 | |
|
发表时间：2006-12-30
XMLDB 写道 daoger 写道 Lucas Lee 写道 这个问题，我以前在学习Louts workflow的时候见过它的处理方式，可以借鉴一下：
任何排他性的操作之前有一个申请的动作，要进入实际操作前必须申请，申请动作其实就是做一个并发操作控制，申请后则自动获得实际操作的权利，然后其他用户无法申请进行此操作了。 实际上，就是加了一个排他锁，想进入则先获得此锁。 我们现在的想法和你的说法差不多；可问题是用户进入的时候我可以比较容易的实现排他锁，现在的困难就是怎么让他进行完操作后释放排他锁，让其他用户获得！ 不知你有没有好的解决方法？ 看来能尽快解决的方法就只能用标志位了! |
| 返回顶楼 | |
|
发表时间：2006-12-30
按标志位来，在不远的将来就可以看到有一些谁都不能操作的数据了，哈哈
|
| 返回顶楼 | |
|
发表时间：2006-12-31
daoger 写道 clamp 写道 奇怪，大家都觉得自己理解需求了吗？这么迫不及待的给技术解决方案啊……
我问个需求澄清问题： 是否存在以下这种情况，一个模块中有多个实例记录？ 比如编辑计划 存在着多份计划，A/B两个用户都有编辑计划的权限， 在同一时刻A/B都能使用编辑计划这个功能，但是只能编辑不同的计划，而不能编辑相同的计划。 是这样的，每个人制定的计划都是根据各自对业务的理解而来的，一样的可能性不大！ 还有一点就是，我们的功能基本全部实现了，现在正在由用户进行功能测试，项目再有几个月就要投运了！如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的！ 昨天又问了一下项目经理，如果暂时没有好的解决方法，就只能从权限上控制，暂时每一个模块只有一个具有操作权限的用户！ 唉！ 各位以前的B/S项目中没遇到这样的需求吗？ 看来是我的表达方式有点问题，再重复一下，有没有这样的情况： A做了计划1，B做了计划2。 A可以改计划1，B可以改计划2，这两个操作可以同时进行 A也可以改计划2，B可以改计划1，这两个操作也可以同时进行 A/B不能同时改计划1 A/B不能同时改计划2 |
| 返回顶楼 | |
|
发表时间：2006-12-31
clamp 写道 daoger 写道 clamp 写道 奇怪，大家都觉得自己理解需求了吗？这么迫不及待的给技术解决方案啊……
我问个需求澄清问题： 是否存在以下这种情况，一个模块中有多个实例记录？ 比如编辑计划 存在着多份计划，A/B两个用户都有编辑计划的权限， 在同一时刻A/B都能使用编辑计划这个功能，但是只能编辑不同的计划，而不能编辑相同的计划。 是这样的，每个人制定的计划都是根据各自对业务的理解而来的，一样的可能性不大！ 还有一点就是，我们的功能基本全部实现了，现在正在由用户进行功能测试，项目再有几个月就要投运了！如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的！ 昨天又问了一下项目经理，如果暂时没有好的解决方法，就只能从权限上控制，暂时每一个模块只有一个具有操作权限的用户！ 唉！ 各位以前的B/S项目中没遇到这样的需求吗？ 看来是我的表达方式有点问题，再重复一下，有没有这样的情况： A做了计划1，B做了计划2。 A可以改计划1，B可以改计划2，这两个操作可以同时进行 A也可以改计划2，B可以改计划1，这两个操作也可以同时进行 A/B不能同时改计划1 A/B不能同时改计划2 做好的计划都存在数据库中，从库中读取计划时不区分哪个计划是哪个用户编辑的，正是这样就存在了A可以修改计划1，也可以修改计划2的问题！ 计划下达之后就不能再修改，数据就被锁定了！计划下达前有操作权限的用户就可以对现有的所有计划进行修改！ 我搜索了一下，这个问题的解决方法不多，呵呵！也可能是我搜索的不全面！我觉得这可能就是项目最初设计时的一个疏漏！ 看来如果不能从技术上解决那就只能从业务上解决：工作分工！ |
| 返回顶楼 | |
|
发表时间：2006-12-31
XMLDB 写道 按标志位来，在不远的将来就可以看到有一些谁都不能操作的数据了，哈哈
说得也对，一个标志位可能也解决不了问题，标志位多了就怕自己都搞乱了！唉! |
| 返回顶楼 | |
|
发表时间：2006-12-31
在你的环境下,要把冲突分为两种:
1.多个计划的冲突 2.多个用户对同一个计划的冲突 第一个我上面已经说了,要使用带条件的更新,操作完后确认结果正确.在你的例子里如果超出可分配电量范围,很明显就需要返回业务异常提示用户. 第二个,和第一个方法一样,如果发现在更新后发现结果不是自己那个,则需要提示用户或让用户决定是放弃还是覆盖. 在一个操作里,都必须做上面两个检查. |
| 返回顶楼 | |
