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

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

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

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

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

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

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

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

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

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

锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。

我们以前采用过这样一种异常解锁机制：
假设有A/B两个用户，A用户先操作，通过checkout操作，对某条记录加锁。
随后B用户操作，这时给B用户一个提示：“A用户正在操作，是否需要强行进入？”
（这里B用户要和A用户进行系统外的沟通）
B用户可以选择强行进入，这时就直接把A用户的锁强行替换为B用户的锁，A用户如果试图对此记录进行操作，就会得到一个类似的提示：“B用户正在操作，是否需要强行进入？”

用户一般都可以接受这种操作模式的。

锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。

我们以前采用过这样一种异常解锁机制：
假设有A/B两个用户，A用户先操作，通过checkout操作，对某条记录加锁。
随后B用户操作，这时给B用户一个提示：“A用户正在操作，是否需要强行进入？”
（这里B用户要和A用户进行系统外的沟通）
B用户可以选择强行进入，这时就直接把A用户的锁强行替换为B用户的锁，A用户如果试图对此记录进行操作，就会得到一个类似的提示：“B用户正在操作，是否需要强行进入？”

用户一般都可以接受这种操作模式的。

你这里依然没有解决如何处理异常中断造成的不正常解锁问题！