多用户操作并发限制

[wuhongyao3]

目前，有这样一个问题，有一个病人列表页面，多个用户可能会同时操作同一病人，（并不仅仅是数据库操作，有可能是给病人打电话），这样就会出现重复操作。

想要实现效果
比如用户A操作病人A时，用户B就不能操作病人A。

请问一下这种方式该如何解决呢？

[堆代码的爱因斯坦]

SQL锁与事务控制

[kingdom_0]

Object thisLock = new Object();
lock (thisLock)
{
    // Critical code section
}

[以专业开发人员为伍]

[Quote=引用楼主 wuhongyao3 的回复:]
想要实现效果
比如用户A操作病人A时，用户B就不能操作病人A。
[/Quote]你的这个需求分析很成问题。比如说一个人操作的时候去上厕所去了，其它人是不是即使这个病人要死了也救不不了他呢？必须等着这个人回来，并且这个人还必须不再操作病人了，别人才能操作？

所谓的“数据库锁”就是这种思路，貌似靠谱，实际上数据库锁只是针对持续1、2秒的具体事务，不是针对长事务的。做系统需求分析，需要从业务层面设计出协同、协作流程，简单地引用一下技术术语的需求分析，会让你的客户再也不把项目给你做了。

[以专业开发人员为伍]

具体的实现方法，首先要调研业务流程，依据业务流程去深入地去设计。如果你是做一个毕业设计，还是先忽略考虑什么限制问题，在不限制的情况下做出一个beta版的系统来，然后等别人看了你的系统的详细内涵、控制流程，才好深入地去重构出来“限制”部分。

[bdmh]

是的，把业务搞清楚，一般要避免这种情况，多人操作一个病人，不应该

[以专业开发人员为伍]

比如说“别人给病人打电话”，那么电话会占线的，也就是说你的系统调用底层系统的接口时底层会抛出异常的。诸如此类的知识有上百个，设计者有很多有用的问题要去解决，而空想出“这种方式该如何解决呢”这种问题可能是过早了。

[isjoe]

对A的操作都要标记，其他对A的操作都要检测标记。。。。。。。

[Daqing]

可以加一个字段来控制。

[窗户纸]

[Quote=引用楼主 wuhongyao3 的回复:]
想要实现效果
比如用户A操作病人A时，用户B就不能操作病人A。

请问一下这种方式该如何解决呢？
[/Quote]
这样做医院的大夫高兴死了，可病人得把这系统骂死，还是别指望你实现的好。:0

[窗户纸]

从提的需求的架势，就是冲着在交互窗体打开时就BEGIN Transaction的，那样长时间占着事务，再来几个SELECT 能锁的都给锁掉，并发用户不可能多。貌似应该是不能同时对同一病例进行修改操作更靠谱些。

[wuhongyao3]

[Quote=引用 3 楼 sp1234 的回复:]
引用楼主 wuhongyao3 的回复:
想要实现效果
比如用户A操作病人A时，用户B就不能操作病人A。
你的这个需求分析很成问题。比如说一个人操作的时候去上厕所去了，其它人是不是即使这个病人要死了也救不不了他呢？必须等着这个人回来，并且这个人还必须不再操作病人了，别人才能操作？

所谓的“数据库锁”就是这种思路，貌似靠谱，实际上数据库锁只是针对持续1、2秒的具体事务，不是针对长事务的。……
[/Quote]
目前有一个成型的版本了，但是当初没有考虑到这个问题。
客户在使用中会遇到一些问题。
比如用户A和B同时点一个病人进去，A打过电话，还没有点保存，B又打电话了。这样会有重复操作。

[wuhongyao3]

此时还并没有涉及到数据库的操作。。

[格拉]

可以用个后台服务去处理这些

[wuhongyao3]

[Quote=引用 3 楼 sp1234 的回复:]
引用楼主 wuhongyao3 的回复:
想要实现效果
比如用户A操作病人A时，用户B就不能操作病人A。
你的这个需求分析很成问题。比如说一个人操作的时候去上厕所去了，其它人是不是即使这个病人要死了也救不不了他呢？必须等着这个人回来，并且这个人还必须不再操作病人了，别人才能操作？

所谓的“数据库锁”就是这种思路，貌似靠谱，实际上数据库锁只是针对持续1、2秒的具体事务，不是针对长事务的。……
[/Quote]

1.我们目前只是回访病人的。
2.必须等着这个人回来，并且这个人还必须不再操作病人了，别人才能操作？，不会这么死板。


我想的是能否这样
用户A操作病人A时，会在数据库做个标记，然后有个服务检测，用户A操作病人A超过一定时间没有释放的话，系统自动释放。。

[wuhongyao3]

目前解决方法：
新建一张表，用来记录操作员、病人、锁定时间及功能代码。

加一些逻辑判断。。。

结贴。