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

Hibernate的Version是个好东西，JPA的annotaion中都有，看到了都觉得亲切，呵呵。
Version是需要在表上增加一个字段，用于表示数据操作的版本，用户更新一条记录时，将Version字段的值加1。当更新前发现Version字段的值不等于自己记录中的值时，说明被别人更新过了，需要进行异常处理。
用Hibernate的Version的话自己不需要做什么代码改动，只需要改配置文件，表中增加Version字段。不用Hibernate的话，自己实现也不复杂。
不知道楼主对一个任务中的多个操作是如何做事务管理的，感觉每一个任务定一个事务，将多个原子操作包括起来，当一处原子操作有Version的冲突，整个任务全部回滚。不知道这样对你的代码改动大不大

我认为用Version不是解决这类问题的正确方法。
的确，Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户，B用户一起做一个计划数据，搞了半天，B用户发现系统提示A用户已经做好了，你这不是浪费人力么？B用户肯定会说，为什么不让我在进入之前提示我A正在做了？或者我做了就提示A不要再做了。

拜托楼上看清楚人家的需求,电网调配只要不超过负荷就OK,管人家做多少计划呢.
不过,加上一个当前还有谁正在改同一个东西的功能还是很酷的, 又多一个卖点:这可是支持协同工作的产品哦

你说这是一个问题，那需求是不是“A只能修改他自己编辑的计划1，不能修改计划2”



这是一个用户需求 还是 你们的系统现在是这么设计但不符合用户需求？
另外，不同用户的计划间是否可能有冲突？如果产生冲突，业务上如何解决这个问题？




我认为这首先是一个业务问题。

这位老兄说得对，我们现在的需求就是这样的。既然要做这方面的功能处理，就要处理好，处理的人性话，尽量替用户着想！呵呵！

1.只要有操作权限，他什么计划都可以修改！
2.由于项目要求的比较紧，当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块，设计人员就没有考虑这个问题！现在项目不久之后就要投运了，用户才又提起这个需求的。
3.明确工作分工，A用户就只能对北方的电厂有操作权，B用户只能对南方的电厂有操作权，A B两个用户的业务划分不能有交集！

估计你有过CS程序的开发经验，如果你用PB开发实现这种要求很容易，bs应用，用这种方式简单想一下感觉很难或者不灵活。比如使用标志位，当A用户开始做计划，在数据库中记录A用户正在进行，这是后假设A不做了，关闭窗口（或者异常中断了），系统要怎么办，定时删除过期未更新的标志？还是不做处理，等待A用户下次有空了再来继续录入他的计划，在这个过程中其他用户统统不允许录入这个计划。这时候用户可能又要说了，我已经不录了，你为什么不让其他人录？你要怎么办？

现在这个问题由技术问题变成了管理问题了，在多年前找解决多人checkout提交时出现需要merge version问题时就已经在CVS手册上看到，类似的版本冲突什么的是个管理问题，而不是技术问题。和daoge的问题类似，所以在工具上如果用户不是强烈要求的话，建议不要加上太多的限制而仅仅是增加一些提示，剩下的问题是客户的管理问题，划分区域是一个好的解决办法。

是需求问题，不是设计问题。
流程性的需求有一个重要检查点就是并发性。

如果用户答应你的工作分工建议，这个事情就好办了，不过我猜用户未必肯答应。
因为存在一个工作替代的需求，万一负责南方电厂的人有事，那么就需要别人来替代他的工作。

一个电厂在一个时间周期内（比如一个月/一年）应该只有一份计划，但是只要有权限的人都可以编辑，直到下达为止。

建议以下设计方案：
在计划创建时，确保有一个唯一标识字段，使得不会创建业务上互相冲突的计划。
在每份计划上加一个标志位（锁），采用checkout/checkin的机制，确保任一时刻只有一个人可以修改计划。
（需要处理异常断线的情况）
对于版本的控制：保存最新的修改后的计划和每一次的修改记录（修改人/修改时间/修改内容），一般不需要保存每一次的版本。

我们也遇到这种问题,一般是记录的同步操作问题.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.

构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.

对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.

以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.