1.问题场景

　　a. 用户A打开应用的界面，看到数据库的某条记录

　　b.用户B打开应用的界面，看到同样一条记录

　　c. 用户A对记录做了修改

　　d. 对于web应用而言[假设没有应用comet类似技术]，通常B不知道这个修改，这时B也对同样这条记录做修改，那B就有可能覆盖A做的修改;

　　这个问题在数据库中被称为丢失更新问题

　　2.我自己对这个问题的理解过程是这样的：

　　a. 不知道这个问题

　　我在做开发好长时间之后才意识到这个问题，意识到这个问题之后，我后来发现很长一段时间内都没真正搞明白为什么这是个问题-_- 而且我发现现在周围的很多同事，尤其是新毕业的学生，其实也一直过了很长时间都没明白这个问题，这说明吧不知道这个丢失更新问题是一个非常普遍的问题：)

　　b.用信号量以及操作之前再次验证的方法解决

　　最开始的时候，测试发现了这样一个问题，要求解决，我把操作系统的教科书搬来，对照着写了一个信号量semaphore类[那时候还是jdk 1.4.2，jdk里面没有concurrent包]，花了好长时间测试这个semaphore的实现是正确的[重复发明轮子的血泪史..]，

　　然后用来控制这个操作，每次操作前获取信号量，然后验证，再做真正的数据库操作。。。相当于在应用层每次都只做一件事。

　　c. 再次理解

　　再后来，我看了Tom的这本9i和10g的书，书中提到前面的丢失更新过程，大概有点明白为什么这是个问题

　　但是其实我有个疑问，对于数据库中的记录而言，A做的修改本来就有可能被B覆盖的，为什么这会是一个丢失更新问题呢? 正好项目里面又出现了类似的情况，我仔细观察了下，终于明白为什么这是个问题，以及为什么要使用对应的乐观锁悲观锁方案了。下面对此做详细说明

　　3. 一个比较清楚的场景

　　下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题：

　　假设当当网上用户下单买了本书，这时数据库中有条订单号为001的订单，其中有个status字段是’有效’,表示该订单是有效的;

　　后台管理人员查询到这条001的订单，并且看到状态是有效的

　　用户发现下单的时候下错了，于是撤销订单，假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;

　　后台管理人员由于在b这步看到状态有效的，这时，虽然用户在c这步已经撤销了订单，可是管理人员并未刷新界面，看到的订单状态还是有效的，于是点击”发货”按钮，将该订单发到物流部门，同时运行类似如下SQL，将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001

　　如果当当的系统这样实现，显然不对了，肯定要挨骂了，明明已经取消了订单，为什么还会发货呢?而且确实取消订单的操作发生在发货操作之前啊。 因为在这样的实现下，后台管理人员无论怎么做都有可能会出错，因为他打开系统看到有效的订单和他点发货之间肯定有个时间差，在这个时间差的时候总是存在用户取消订单的可能。

　　4. 当时的详细解决方法。几年前当测试人员告诉我系统存在这个问题的时候，我的解决方法是这样的， 首先，先把操作系统的教科书搬来，然后对照着了一个semaphore,然后反复测试各种情况证明写的是正确的; 然后，

　　1. 获取一个信号量，保证每次只能有一个线程进入下面的步骤

　　2. 检查数据库，看这条订单是否状态是有效的

　　a. 如果有效则继续，进入发货步骤 b) 如果无效则返回，释放信号量，告诉用户状态已经发生改变

　　3. 发货，释放信号量

　　看到这里，也许很多人要骂我蠢了，直接把SQL语句改成下面这样吧就可以了么? update order_table set status = ‘已发货’ where order_id = 001 and status = ‘有效’ 是的，的确是这样。虽然我当时的项目的情况比和这个稍微复杂一点，涉及到多张表格，不能直接这么做，但当时的确不知道这个更新丢失问题，也没想到合适的类似方式，于是就在应用层做了这么一个每次实际上只能有一个用户在做真正的更新这样一个方式来解决，这样做的结果是，在应用层单独做了类似这么一个锁的机制。我记得当时的项目毕业答辩的时候，老师问我同步的这个问题不直接用数据库的锁的方案来解决?我当时胡乱回答了下，后来想起来，其实压根没理解老师的意思-_- 而且这样做有一个问题，假设在特殊情况下，这条订单被DBA直接修改了，没有经过应用，那么应用做这个操作也会是错的，因为在2.a到3之前的这段时间，有可能正好是DBA直接修改的时候。那么3做的操作也是不对的。 而且，现实情况是在后来的几年开发过程中，我也的确在一些不同的项目代码中看到，其他很多人也在使用类似的代码解决测试人员告诉他们的这些同步问题-_-

　　5.正确而简洁的解决方法

　　问题清楚了，也说明了我曾经使用的解决方案也是一个简洁直接的解决方案，纯粹是把简单问题复杂化，下面说说实际有效的解决方案; 就这个丢失更新问题，可以通过数据库的锁来实现，基本两种思路，一种是悲观锁，另外一种是乐观锁; 简单的说就是一种假定这样的问题是高概率的，最好一开始就锁住，免得更新老是失败;另外一种假定这样的问题是小概率的，最后一步做更新的时候再锁住，免得锁住时间太长影响其他人做有关操作;

　　6. 乐观锁的方法

　　这里先说web开发中常用的乐观锁的方法：

　　1.很简单，就是使用前面所说的这样一条SQL，这其实是所谓使用”前镜像”的方式来保证需要更新的数据是符合要求的，

　　update order_table set status = ‘已发货’ where order_id = 001 and status = ‘有效’ Tom的书上举的例子是对所有列做更新，所以他的SQL大致如下 Update table set col1 = newcol1value, col2 = newcol2value…. where col1 = oldcol1value and col2 = oldcol2value…. 这个我觉得需要根据应用具体分析，如果需要判断所有的值，那就判断所有的值，如果只关心其中一个或部分值，那只需要取相关的值就好了，就比如这里的订单的状态

　　2.使用版本列[比如时间戳

　　这个方法比较简单，也最常用，就是在数据库表格中加一列last_modified_date，就是最后更新的时间，每次更新的时候都将这列设成systimestamp，当前系统时间;

　　然后每次更新的时候，就改成这样 Update table set col = newvalue where id = ** and last_modified_date = old last_modified_date 这样，就可以检验出数据库的值是否在上次查看和这次更新的时候发生了变化，如果发生了变化，那么last_modified_date就变化了，以后的更新就会返回更新了0行，系统就可以通知用户数据发生了变化，然后选择刷新数据或者其他流程。

　　至于这个last_modified_date的维护，可以选择让应用每次都维护这个值，或者是使用存储过程来包装更新的操作，或者是使用触发器来更新相关的值。几种方法各有利弊，比如应用维护需要保证每段相关代码都正确的维护了这个值;存储过程有一定的开销，通常很多开发对写存储过程可能也不熟练;触发器是简单的实现，但是也是有开销的。具体使用哪种方法需要根据实际情况具体取舍。

　　3.使用校验或Hash值

　　这种方法和前面的方法类似，无非是根据其他有实际意义的列来计算出一个虚拟的列，我个人觉得TOM在介绍这个纯粹是介绍了一种”奇技淫巧”，反正我是在实际过程中不知道哪里会需要这样的解决方案，或许也是因为我知道的太少了吧：)

　　4.使用Oracle 10g的ORA_ROWSCN

　　这个就是利用10g的一个ora_rowscn特性，可以对每行做精确追踪，不过这个要求在create table的时候就指定相关参数，表格如果创建了以后就不能用alter table来修改了，因为这依赖于物理的实际存储。 同样，我觉得这也可以归为”奇技淫巧”一类; 具体如果有兴趣了解详情的话，可以参考Tom的书