oracle丢失更新与乐观锁定

      上一节介绍了oracle丢失更新问题的一种解决方法：悲观锁定，这一节将介绍乐观锁定。

      乐观锁定，即把所有锁定都延迟到即将执行更新之前才做。换句话说，我们会修改屏幕上的信息而不要锁。我们很乐观，认为数据不会被其他用户修改；因此，会等到最后一刻才去看我们的想法对不对。总之，就是当用户已经填好修改内容，点击修改按钮的时候，我们才去给要修改的记录加锁。

      这种锁定方法在所有环境下都行得通，但是采用这种方法的话，执行更新的用户“失败”的可能性会加大。这说明，这个用户要更新他的数据行时，发现数据已经修改过，所以他必须从头再来。

      实现乐观并发控制的方法有很多种。我们将介绍三种方法，分别是：

      1. 使用一个特殊的列，这个列由一个数据库触发器或应用程序代码维护，可以告诉我们记录的“版本”.

      2. 使用一个校验和或散列值，这是使用原来的数据计算得出的.

      3. 使用新增的Oracle 10g 特性ORA_ROWSCN.

      下面介绍第一种方法：

      这是一个简单的实现，如果你想保护数据库表不出现丢失更新问题，应对每个要保护的表增加一列。这一列一般是NUMBER或DATE/TIMESTAMP列，通常通过表上的一个行触发器来维护。每次修改行时，这个触发器要负责递增NUMBER列中的值，或者更新DATE/TIMESTAMP列。用户每次进行修改的时候，会拿自己取出的这一列的值与数据库中的进行比较，如果相同，说明还没有人修改过，反之，则已经修改过了！

      其实，，对于这么简单的工作，建议还是避免使用触发器，而让DML来负责。触发器会引入大量开销，而且在这种情况下没有必要使用它们。

      但是，也不能总是依赖各个应用来维护这个字段，原因是多方面的。例如，这样会增加应用程序代码，而且只要是表中需要修改的地方，都必须重复这些代码，并正确地实现。 在一个大型应用中，这样的地方可能很多。另外，将来开发的每个应用也必须遵循这些规则。应用程序代码中很可能会“遗漏”某一处，未能适当地使用这个字段。 因此，如果应用程序代码本身不负责维护这个LAST_MOD字段，我相信应用也不应负责检查这个LAST_MOD字 段（如果它确实能执行检查，当然也能执行更新！）。所以在这种情况下，我建议把更新逻辑封装到一个存储过程中，而不要让应用直接更新表。如果无法相信应用 能维护这个字段的值，那么也无法相信它能正确地检查这个字段。存储过程可以取以上更新中使用的绑定变量作为输入，执行同样的更新。当检测到更新了0行时，存储过程会向客户返回一个异常，让客户知道更新实际上失败了。

      个人感觉还是太麻烦，且看下面还有两个方法！

      注：oracle9i&10编程艺术阅读笔记