第五章 分布式数据库中的并发控制
比较的DB2 ORACLE MSSQL SYBASE INFORMIX并发控制机制
在关系数据库（DB2，Oracle，Sybase，Informix和SQL Server）最小的恢复和交易单位为一个事务（Transactions）,事务具有ACID(原子性，一致性，隔离性和永久性)特征。关系数据库为了确保并发用户在存取同一数据库对象时的正确性（即无丢失更新、可重复读、不读\脏\数据，无\幻像\读），数据库中引入了并发（锁）机制。基本的锁类型有两种：排它锁（Exclusive locks记为X锁）和共享锁（Share locks记为S锁）。
排它锁：若事务T对数据D加X锁，则其它任何事务都不能再对D加任何类型的锁，直至T释放D上的X锁；一般要求在修改数据前要向该数据加排它锁，所以排它锁又称为写锁。
共享锁：若事务T对数据D加S锁，则其它事务只能对D加S锁，而不能加X锁，直至T释放D上的S锁；一般要求在读取数据前要向该数据加共享锁，所以共享锁又称为读锁。
DB2数据库
IS、IX、SIX方式用于表一级并需要行锁配合，他们可以阻止其他应用程序对该表加上排它锁。
如果一个应用程序获得某表的IS锁，该应用程序可获得某一行上的S锁，用于只读操作，同时其他应用程序也可以读取该行，或是对表中的其他行进行更改。
如果一个应用程序获得某表的IX锁，该应用程序可获得某一行上的X锁，用于更改操作，同时其他应用程序可以读取或更改表中的其他行。
如果一个应用程序获得某表的SIX锁，该应用程序可以获得某一行上的X锁，用于更改操作，同时其他应用程序只能对表中其他行进行只读操作。
S、U、X和Z方式用于表一级，但并不需要行锁配合，是比较严格的表加锁策略。 如果一个应用程序得到某表的S锁。该应用程序可以读表中的任何数据。同时它允许其他应用程序获得该表上的只读请求锁。如果有应用程序需要更改读该表上的数据，必须等S锁被释放。
如果一个应用程序得到某表的U锁，该应用程序可以读表中的任何数据，并最终可以通过获得表上的X锁来得到对表中任何数据的修改权。其他应用程序只能读取该表中的数据。U锁与S锁的区别主要在于更改的意图上。U锁的设计主要是为了避免两个应用程序在拥有S锁的情况下同时申请X锁而造成死锁的。
如果一个应用程序得到某表上的X锁，该应用程序可以读或修改表中的任何数据。其他应用程序不能对该表进行读或者更改操作。
如果一个应用程序得到某表上的Z锁，该应用程序可以读或修改表中的任何数据。其他应用程序，包括未提交读程序都不能对该表进行读或者更改操作。
ORACLE数据库
1.2.1 Oracle 多粒度锁机制介绍
根据保护对象的不同，Oracle数据库锁可以分为以下几大类： (1) DML lock（data locks，数据锁）：用于保护数据的完整性；
(2) DDL lock（dictionary locks，字典锁）：用于保护数据库对象的结构（例如表、视图、索引的结构定义）；
(3) Internal locks 和latches（内部锁与闩）：保护内部数据库结构； (4) Distributed locks（分布式锁）：用于OPS（并行服务器）中； (5) PCM locks（并行高速缓存管理锁）：用于OPS（并行服务器）中。
在Oracle中最主要的锁是DML（也可称为data locks，数据锁）锁。从封锁粒度（封锁对象的大小）
角度看，Oracle DML锁共有两个层次，即行级锁和表级锁。
1.2.2 Oracle的TX锁行级锁、事务锁
许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行，其实不然。TX的本义是Transaction（事务）当一个事务第一次执行数据更改（Insert、Update、Delete）或使用SELECT? FOR UPDATE语句进行查询时，它即获得一个TX（事务）锁，直至该事务结束（执行COMMIT或ROLLBACK操作）时，该锁才被释放。所以，一个TX锁，可以对应多个被该事务锁定的数据行（在我们用的时候多是启动一个事务，然后SELECT? FOR UPDATE NOWAIT）。
在Oracle的每行数据上，都有一个标志位来表示该行数据是否被锁定。Oracle不像DB2那样，建立一个链表来维护每一行被加锁的数据，这样就大大减小了行级锁的维护开销，也在很大程度上避免了类似DB2使用行级锁时经常发生的锁数量不够而进行锁升级的情况。数据行上的锁标志一旦被置位，就表明该行数据被加X锁，Oracle在数据行上没有S锁。
1.2.3 Oracle意向锁
意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。如：对表中的任一行加锁时，必须先对它所在的表加意向锁，然后再对该行加锁。这样一来，事务对表加锁时，就不再需要检查表中每行记录的锁标志位了，系统效率得以大大提高。
由两种基本的锁类型（S锁、X锁），可以自然地派生出两种意向锁：
S、X）与意向锁类型（IS、IX）之间还可以组合出新的锁类型，理
论上可以组合出4种，即：S+IS，S+IX，X+IS，X+IX，但稍加分析不难看出，实际上只有S+IX
有新的意义，其它三种组合都没有使锁的强度得到提高（即：S+IS=S，X+IS=X，X+IX=X，这里的\指锁的强度相同）。所谓锁的强度是指对其它锁的排斥程度。
排它锁（Shared Intent Exclusive Lock,简
称SIX锁）：如果对一个数据库对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。例如：事务对某个表加SIX锁，则表示该事务要读整个表（所以要对该表加S锁），同时会更新个别行（所以要对该表加IX锁）。
具有意向锁的多粒度封锁方法中任意事务T要对一个数据库对象加锁，必须先对它的上层结点加意向锁。申请封锁时应按自上而下的次序进行；释放封锁时则应按自下而上的次序进行；具有意向锁的多粒度封锁方法提高了系统的并发度，减少了加锁和解锁的开销。
比较分析悲观与乐观并发控制机制的异同
业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算处理中，我们希望针对某个cut-off时间点的数据进行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。
Hibernate支持两种锁机制：即通常所说的“悲观锁（Pessimistic Locking）”和“乐观锁（Optimistic Locking）”。
悲观锁
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
乐观锁
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎