在事务系统中很重要的一个概念就是“锁”。在事务系统中“事务”概念保证了数据访问的原子性，即单事务进程中一组数据访问的一致性，而“锁”的概念保证了数据访问的隔离性与排他性，即并发事务进程之间的同步访问的独立性。有一个数据分别有两个用户要去修改，我们需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。

一般在事务系统中的“锁”机制可以分为两种不同的模式：悲观锁模式以及乐观锁模式。这两种“锁”模式要解决的问题都大致一样：多程之间的同步访问的独立性问题。只是环境上下文有所不同。当然，这就会导致，解决该问题的方案有所区别。

乐观锁模式：乐观锁模式假设环境中需要同时访问同一数据的并发事务较多，但访问数据时间较短，事务进程可以忍受少量的数据修改失败。由于使用了如此假设，则使用的加锁方案策略就比较宽松。一般使用于数据本身相关的版本控制机制来实现。
   
    比较常见的手法就是用数据的一部分或另外增加一部分作为修改的版本号，在修改视校对版本号，一旦校对正确就同时修改数据本体与版本号；如果校对版本号失败则表示数据过期，可以回滚事务。使用该方式时，如果访问数据的事务进程都来自同一个系统，则完全可以达到隔离要求。然而，如果事务进程是来自不同系统，那么事情就比较麻烦了。因为，两个系统不是相同的“锁”方案就会导致混乱的局面。这时候可能就需要严格一些的乐观锁。
   
    较之前的乐观锁实现方案，还有一种比较严格的乐观锁方案。就是在版本号上做文章，使用数据完全关联的版本号。比如，对整个数据进行hash处理得出一个版本号。每当修改数据的任何一部分时都先检查校对版本号，一旦成功就更新的数据以及整个新的数据的hash版本号；如果校对版本号失败则表示数据过期，可以回滚事务。使用该策略，可以包保证的多系统访问独立性。然而，不论是把这个hash过程放在事务进程所在的系统还是放在数据所在的系统均会对整个体系的性能造成影响。

悲观锁模式：悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。其策略也就比较严格，在整个数据被访问的期间该“锁”都将锁住数据禁止他人访问。一般使用数据所在系统本身的功能来实现悲观锁。

举个具体例子：有些关系数据库管理系统支持select …for update功能。该功能表示，在用户使用该查询语句时，系统将锁住被选的数据项或数据表。这样就拒绝了其他用户访问，直到该用户主动解开锁，或者锁超时。

参考："POEAA", http://blog.sohu.com/members/walker/