关于Web应用中的数据库的并发性的一个解决方案(转载)

我先把流程说出来，，比如修改一个记录：
当用户点修改时，从数据库读出数据并显示到编辑菜单中，然后再编辑数据，再点确定保存到数据库中。如果多个用户，当A用户点修改到保存该数据这一时间段，，B用户不能修改，，这个好像不能用事务来做吧，，，大家给个解决方案，，但是我觉得还有点矛盾。当这一时间段用户能修改，那么对于A用户来说数据就已经不一致了，A用户看到的是B用户没有修改前的数据，如果不能修改，也不现实，，如果B用户点了修改还没点确定，，然后用户出去办急事或WC，，那A用户不是一直等，，，
网上经常举卖车票的例子，当售票员A听到买票人后开始查询，发现有2张，，买票人正好要2张，，在查询和售出这一时间段，如果其它窗口不能卖，，好像不太现实，，有时这一时间段还是很长的，，一分钟左右吧，，其它10多个窗口窗口不能卖这一车次的不是很要命，并且每个窗口都会差不多占一车次的查询，，如果在查询到确定出售这一价段其它窗口可以卖，，也出现问题了，，售票员A查询发现剩两张，，告诉买票的人，正好剩两张，，这时客户确定要，如果在这一时间段，其它窗口卖一张，，那在确定卖出去时将会失败，难道要跟买票人解释。，，这问题其它也困我很久了，，谢谢大家给我一个解决方案，，也许是我想错了，，在线等

 

 

 

看来LZ没有做过实际案例啊,现在我给你透露下实际售票系统中的一个方案例子:

  首先没有那么复杂的锁,实际应用会尽量从业务角度考虑避免冲突:

  实际售票系统是这样: 
 
  1.售票中,"座位号" 才是竞争资源;
  2.售票中,查看票是不发生锁号的.
  3.售票中,有个选票(选座位号)的动作,选座位号确定时,才发生锁号(即锁住改作为号,即使这锁号,也只是修改标记,表示自己暂时锁住);
  4.等客户交钱后,就确定提交交易完成,这时候,就成为售出该票了(当然,被锁的号,要修改为对应的已售标记,及其他流程操作).

从这个过程看,几乎没有那么多冲突出现(只有选号时,有可能已被别人选了,这也应该知道的,可以另选号),这就是方案.

 

 

引用 7 楼 xjlqlqlq 的回复:
看来LZ没有做过实际案例啊,现在我给你透露下实际售票系统中的一个方案例子:

首先没有那么复杂的锁,实际应用会尽量从业务角度考虑避免冲突:

实际售票系统是这样:

1.售票中,"座位号" 才是竞争资源;
2.售票中,查看票是不发生锁号的.
3.售票中,有个选票(选座位号)的动作,选座位号确定时,才发生锁号(即锁住改作为号,即使这锁号,也只是修改标记,表示自己暂时锁住);
4.等…

关键是第三步。我理解买票的时候虽然外面只是一个买入键的敲击动作，但后台应该是分为1、锁定当前记录，2、锁定成功后修改该票属性 两个动作的。只有第一个动作成功，才能做第二个动作。
我倾向于不是用SQL语句来锁住某行，而是在该行有某字段，修改成功就表示锁定。锁表对性能有影响。

 

 

我也觉得应该是第三步，，但我细节我不赞成，，我认为，选票时，锁定该记录（不一定非要用锁，可以加一个字段锁定，此时将它改为锁定状态，）当客户交钱提交交易完成　时，再改该记录的已售状态，当取消交易时，，再把锁定改为非锁定状态，，，不知道理解对没

 

 

"如果不用锁，，去改锁定字段时，好像也有问题，，当去修改锁定字段为锁定状态时，，此时要是机了重启了，，那不是一直在锁定"


说的没错,既然是两阶段提交,自然有可能发生意外在中间过程中,

象你说的中途死机了,这个需要解决的,实际中当然会考虑周全的,有另外解决之道.
所以说,这是个工程,有系列问题要解决. 


如果是死机,可以有方案解决(这个可以自己考虑,各公司可能策略不同),简单的方法是, 客户端有缓存日志记录,如果死机,启动的时候,自然会知道上次未完成的事情; 当然,如果有好方案也可以在后台来解决.总之这个就很多途径.

 

转载:http://topic.csdn.net/u/20090520/10/d2eac176-afca-4321-9384-45d82a6f010b.html?68881