Oracle并发控制中的乐观锁

数据库的管理员要分散他们的数据库，以便处理基于Web，B2B，电子商务的访问，快速的硬盘读写以及更多的资源或许只能解决一部分问题。疲乏的锁机制甚至会削弱拥有很好资源的应用性能。乐观锁可以大大改善具有较多事务处理的数据库载入性能，比如基于web的客户端访问。

悲观锁引发的问题：

大多数Oracle开发者已经非常熟悉悲观锁，即在对数据进行更新之前给数据加锁。使用熟悉的SELECT...FOR UPDATE语法就可以实现悲观锁机制。一旦需要更新的数据被锁定，那么应用程序就可以对数据进行需要的修改，然后提交更改(commit)或者在事务进行期间数据锁自动丢失，那么该事务就进行回滚(rollback)。

如果在数据处理过程中有其他人想要获得该数据的锁，那么必须等待该事务完成之后才能得到。

上面提到的机制被称为悲观锁，因为它假设另外一个事务可能会在读数据与更新数据之间对数据进行更改。为了防止由于这种更改带来的数据不一致现象，读语句(read statement)便锁住数据来阻止任何其他进程对该数据进行更改。

虽然悲观锁应用起来很简单并且十分安全，与此同时却有两大问题：

1.锁定：应用的使用者选择一个记录进行更新，然后去吃午饭，但是没有结束或者丢弃该事务。这样其他所有需要更新该记录的用户就必须等待正在进行实务操作的用户回来并且完成该事务或者直到DBA杀掉该不愉快的事务并且释放锁。

2.死锁：用户A和B同时更新数据库。用户A锁定了一条记录并且试图请求用户B持有的锁，同时用户B也在等待获取用户A持有的锁。两个事务同时进入了无限等待状态即进入死锁状态。

如果你认为上述情况出现的几率很小，那么可以去咨询一下那些大型Rdb数据库的管理员。Rdb数据库只是提供悲观锁，即使是设计很好的系统，锁定与死锁现象仍然是非常频繁的。

通过详细的锁的树形机制，开发者必须以预先定义好的顺序来获取锁，但是这就要求新系统要进行的事务处理可以被数据库体系识别，并且确保开发人员都要遵守树的规则。即使数据库结构正确地识别了所有事务，并且开发者也严格遵守了锁的树形结构，但是软件的未来版本可能会增加一些不容易与锁的树形结构集成的事务。此外，基于web的应用图形化用户界面结构可以使用户通过多种不同的操作产生相同的结果。将这种用户驱动的复杂性映射到严格的锁树结构是非常困难的。

如果不是有成千上万的只会加剧由悲观锁导致的问题的事务，现代的服务器可以同时支持成百上千的事务操作。因为集群硬件系统也会被过量的锁机制拖得缓慢，因此分布的锁管理者尝试着在数据库的所有事务中调节每一个悲观锁，所以Oracle并行服务器可以极大地改善大型数据库的吞吐量。

引入乐观锁：

乐观锁对于上面提出的问题，给出了一个极好的解决方案。当数据被读入的时候，乐观锁并不对那些记录加锁，并且假设在读操作进行时，被更新的数据并没有并修改。由于在读记录操作的时候并没有加锁，因此如果用户在开启一个事务之后去吃午饭的话也没关系，死锁已经被全部消除了，以你为用户不用再等其他人的锁解除。

Oracle数据库默认使用的是乐观锁。任何一个以UPDATE...SET开始并且不是以SELECT...FOR UPDATE进行操作的命令就是一个乐观锁的例子。

然后，当乐观锁工作的时候并没有提供并发控制。并发控制是确保写回数据库中的数据与他第一次在数据库中读取的是一致的，即当该数据被读入以后没有其他事务对其进行更新。