如何处理并发操作

Question

测试人员开始测试所有功能的并发操作 比如登录账号后另开启几个浏览器或者选项卡 然后在共用一个Session的情况下对一条记录进行并发操作 或者是对互相依赖的记录进行操作(比如在我选择分类的时候同时将该分类删除掉)我现在不知道正常的处理方式是什么 我的处理方式是在更新记录之前将记录的ID记录到session或者application里 同时获得操作权限(比如一个唯一的版本号 保存到页面的某个HIDDEN域里或者其他什么地方) 然后进行更新操作的时候比较一下版本号与记录ID即可我不太清楚正常的做法是什么 所以发贴一问 希望大家踊跃参与 谢谢

Answer 1

楼主的问题很简单。问题肯定会有，必须加锁，唯一的区别是使用乐观锁，还是悲观锁的问题。
乐观锁，相信冲突是低概率事件，那么在commit时才进行检查。
    做法：
          1) 取数据时同时获取最后更新的时间戳或版本号。
          2) 再更新前，用锁记录的方式获取当前时间戳或版本号。
          3）若无法锁定，表示正被修改，放弃操作，要求用户重新查询。
          4）若可以锁定，比较时间戳或版本号。不同则按 3）进行操作，相同则更新记录，同时修改时间戳或版本号

Answer 2

我理解如果是java应用层面上的控制并发，一般都是通过在业务层方法加sychornized锁，如果是数据库层事务的控制并发，每个数据库厂商都有隔离级别，一般都是悲观锁，乐观锁的使用DBA会很慎重，因为如果并发很多且像楼主的同时影响一条相同数据的情况，启用乐观锁会导致大量的重复查询和验证操作

Answer 3

一个号称从来不看AV的男人居然还在论坛里面公然调戏MM

Answer 4

.....我貌似还是没把问题说明白
测试人员开始测试所有功能的并发操作 比如登录账号后另开启几个浏览器或者选项卡 然后在共用一个Session的情况下对一条记录进行并发操作 或者是对互相依赖的记录进行操作(比如在我选择分类的时候同时将该分类删除掉)
...看来我还是不太会问问题... 我说的业务上的操作就是用户的操作 在程序里可以做逻辑判断 但不是用程序的同步或者数据库的同步去解决 还没有到那个地步

Answer 5

用数据库的事务模式处理不会错的，相信我！
进入事务模式，COMMIT提交更新请求，如果执行成功则返回成功状态，如果失败就会ROLLBACK，回滚到执行前状态。