多人操作数据的处理策略--讨论

这跟排它锁没什么关系，synchronized需要排队，而申请数据是将共用的数据申请为私有的数据，申请成功再进行操作，比如修改花了半个小时（由于是私有数据，别人无法操作，就不怕别人删除）；
修改数据或删除数据时，带有自己的用户信息（SQL的where条件中加入用户信息）。

就锁的本质效用而言是一样的，都需要排队访问临界区。唯一的区别可能就是是否block

update时候判断sql%rowcount，更新不为1，就抛错误，保证数据一致，ok了

用时间戳，还要设置多久没提交该时间戳失效。

1. 数据库表增加一个时间戳字段。
2. 查询显示数据时，将世界戳字段查询出，并带到表单中。
3. 表单修改提交后，时间戳字段一同提交，保存前校验此数据时间戳是否与数据库一致，不一致说明已经被别人修改，不允许执行操作。
4. 如果时间戳一致，将数据的时间戳赋予当前时间，并保存到数据库。

原则是所有人都可以查询，但是修改则只有在最后一个版本上修改的才算有效。

1，数据库本身事务看你的事务策略。
2，业务事务，也就是订单在某个状态下有什么操作。如:订单删除只有取消未发货才能删除.多人同时载入的时候肯定只有一个人能操作成功，其他的抛业务异常就可以了。
删除时候，可以做逻辑删除。
3，并发操作可以加锁，如：悲观锁，乐观锁。

正遇到这个问题，也在思考这个问题，如果并发量比较大怎么做呢？

我觉得楼主的困境应该在于两点：

1、B操作的数据可能被其他人操作了（甚至删除了）
    此时的解决方法是使用乐观锁，可以使用时间戳或者UUID。

2、工作量统计问题
   比如，A、B两人同时去操作同一数据（假设是填写复杂的表单），A花了30分钟去修改，B看了数据后，觉得没用，花了20秒钟的时间删除了它，因为B先提交，所以提交成功了（删除成功），而A不知道，还在那里卖力地填写，等到A提交的时候，提交失败，受影响的记录为0（Query OK, 0 rows affected），数据未保存。
  对于A来说，浪费了30分钟的时间去做“无意义”的事（结果未提交成功），如果要统计工作量的话，A这笔业务是无效的，如果一天下来，A倒霉地碰到了很多这样的情况，那要抓狂了，当然这不是A的原因，是系统设计的问题。

加个乐观锁字段就ok了吧

删除数据有点危险，应该设置数据的状态标志。如果某个工作人员觉得数据无用，可以给这行数据设置删除标志。这样下去库里面的数据量可能会增大。解决方案是定期删除库中设置了删除标志的数据。还有就是这种情况一定要采用乐观锁。更新的时候要检查数据的状态是否容许更新。