Pessimistic and Optimistic locking

事务隔离通常通过锁定任何对事务中资源的访问来实现的。总的来说，有两种方法针对事务的锁定：乐观锁(Pessimistic locking)和悲观锁(Optimistic locking)

悲观锁（Pessimistic locking）

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

悲观锁的缺点在于，资源第一次的访问就会被事务锁定，除非事务完成，资源始终是不可访问的。如果大量事务都是仅仅对事务进行检索而不是更新操作，那么这种排它锁会大量阻塞，引起锁的争用。这种情况下，乐观锁会是一种更好的方案。在使用悲观锁的情况下，是通过请求失败来保证并发安全性的。以银行系统为例，一旦一个账户通过事务来访问，那么就会锁定整个账户。其他的事务尝试访问账户都会被延迟，阻塞，直到之前的事务结束（完成或者回滚）。悲观锁会一直存在，直到事务提交或者回滚。

乐观锁（ Optimistic Locking ）

乐观锁（ Optimistic Locking ）相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。那么我们如何实现乐观锁呢，一般来说有以下2种方式：

使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

在使用乐观锁的时候，资源并不会在第一次由事务访问的时候就锁定，相反，资源的状态会使用悲观锁的方式锁定。当其他事务并发的访问资源，并且访问资源的时候，是可能出现冲突的。当提交的时候，资源将要持久化到存储的时候，会重新读取资源的状态，然后对比事务第一次访问的时候所锁定的状态，如果两个状态不同，就会有冲突，从而事务会回滚。

同样以银行应用为例，账户第一次由事务访问的时候，就记录了账户的余额。当事务修改了账户的余额的时候，账户的信息会在执行更新之前再次查询账户的余额。如果余额在事务期间有变化，那么事务就会失败，如果余额没有变化，那么这次修改就会被持久化到存储中。

乐观并发控制(Optimistic concurrency control)

乐观并发控制（OCC）是一种应用到事务系统中的并发控制方法，比如在关系数据库管理系统以及软件事务内存等。OCC的理论依据是多数事务在执行更新的时候，是不会影响到彼此的。在运行时，事务使用资源是不需要获取资源的锁的，但是在提交之前，每个事务都会验证并没有其他的事务在修改数据。如果检查碰到了更新冲突，那么事务的提交会回滚，然后重新执行。

前面提到了OCC的理论依据，所以OCC一般用于低数据冲突的环境。当争用很少的时候，事务就能够几乎不需要付出管理锁的代价，也不需要等待其他事务完成了。这样可以比其它并发控制带来更高的吞吐。当然了，如果数据资源频繁出现争用的话，那么事务的重启就会严重的影响性能了。这个时候使用其他并发控制可能更好。然而，基于锁的方法(悲观锁)在锁定数据的时候，会严重限制并发性能。