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

加個flag 做標記，用軟刪除是否可以？

你说的等待时间只有几十毫秒的时间，指的是一个事务完成业务逻辑的时间，而按照LZ的意思 是在查询出订单就必须加锁，并返回到页面上，再让客服点修改或者删除按钮这段时间，这个订单都必须锁住。这段时间肯定不是你说的几十毫秒。

我引用《heberate 悲观锁和乐观锁》这篇文章的，乐观锁第二段说明一下这段时间吧：
如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。

原文地址：http://www.360doc.com/content/07/0327/10/11192_415808.shtml

所以你开始说的悲观锁肯定行不通。
用乐观锁的话，理论上倒是没问题，像你说的lz的系统有分布式的话就不能用了，而且 如果这样的事情真发生 肯定会耽误客服的时间。


我觉得，如果lz的系统不是集群，用的人也不多，可以像前面有朋友说的那样，我再改进一下，首先你的系统只需要加入一个过滤器servlet，你的系统的所有业务的jsp、.do之类的请求由这个servlet过滤。如果是你的查询单一订单的页面请求就加锁，如果是其他页面就解锁。
现在详细说说怎么加锁、解锁。这个过滤器里面就只需要 管理两个静态hashmap，其中一个以订单id作为key，员工id作为value，另一个相反。如果员工进入到打开订单页面，首先查看两个map是否当前订单被锁，如果有就直接跳到其他页面，如果没有 过滤器就把员工id和当前查询出来的订单id，分别作为key和value放入这两个map中。如果员工在其他页面，过滤器就先查询当前员工id是否锁有订单，没有就继续，有就删除两个map里这个员工和它曾经锁住的订单id。

我觉得这个方法比加乐观锁和悲观锁的方式都要强，你只需要添加一个过滤器并配置它。


如果想做得更友好一些，就在你的订单列表页面查询显示前，遍历你的map锁，看当前页面的 订单是否已经有人锁定，展示的时候分别表示。
这样做的好处是，如果十个客服要处理十张订单，而且任何人都有权利处理任何一张订单，当十个客服几乎同时打开列表页，能看到哪些已经被锁定，哪些还没有，最倒霉的那个人最多也就几次就能打开一张没有锁定的订单进行处理了。

JavaEye上面的。。。水平越来越低。哎！

楼主的应用场景只能让我想起一个词：秒杀。

只有这个场景下，会有那么多人对同一行进行操作。
有关这方面的技术，我个人觉得不是单单讨论锁能够解决的。

而且貌似当年秒杀这个概念刚炒热的时候，就有很多相关帖子。楼主可以翻出来看看啊。

很失败的架构，建议设计分单系统，避免锁机制

如果条件不允许，尽量考虑乐观锁，简单一点，version标志位