乐观锁与悲观锁

Hibernate事务与并发问题处理（乐观锁与悲观锁）

一、数据库事务的定义

　　数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID(原子性、一致性、隔离性和持久性)属性。

　　1. 原子性(atomic)，事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行（要么都执行，要么都不执行）

　　2. 一致性(consistent)，事务在完成时，必须使所有的数据都保持一致状态。（事务完成时，所有数据必须保持一致的状态）

　　3. 隔离性(insulation)，由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。（并发事务所作的修改与其他并发事务所作的修改保持隔离）

　　4. 持久性(Duration)，事务完成之后，它对于系统的影响是永久性的。

（永久性的影响）

二、数据库事务并发可能带来的问题

　　如果没有锁定且多个用户同时访问一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。由于并发操作带来的数据不一致性包括：

丢失数据修改、读”脏”数据（脏读）、不可重复读、产生幽灵数据：

假设数据库中有如下一张表：

　　1. 第一类丢失更新(lost update)： 在完全未隔离事务的情况下，两个事物更新同一条数据资源，某一事物异常终止，回滚造成第一个完成的更新也同时丢失。

　　在T1时刻开启了事务1，T2时刻开启了事务2，在T3时刻事务1从数据库中取出了id="402881e535194b8f0135194b91310001"的数据，T4时刻事务2取出了同一条数据，T5时刻事务1将age字段值更新为30，T6时刻事务2更新age为35并提交了数据，但是T7事务1回滚了事务age最后的值依然为20，事务2的更新丢失了，这种情况就叫做"第一类丢失更新(lost update)"。

　　2. 脏读(dirty read)：如果第二个事务查询到第一个事务还未提交的更新数据，形成脏读。

在T1时刻开启了事务1，T2时刻开启了事务2，在T3时刻事务1从数据库中取出了id="402881e535194b8f0135194b91310001"的数据，在T5时刻事务1将age的值更新为30，但是事务还未提交，T6时刻事务2读取同一条记录，获得age的值为30，但是事务1还未提交，若在T7时刻事务1回滚了事务2的数据就是错误的数据(脏数据)，这种情况叫做" 脏读(dirty read)"。

 

　　3. 虚读(phantom read)：一个事务执行两次查询，第二次结果集包含第一次中没有或者某些行已被删除，造成两次结果不一致，只是另一个事务在这两次查询中间插入或者删除了数据造成的。

　　在T1时刻开启了事务1，T2时刻开启了事务2，T3时刻事务1从数据库中查询所有记录，记录总共有一条，T4时刻事务2向数据库中插入一条记录，T6时刻事务2提交事务。T7事务1再次查询数据数据时，记录变成两条了。这种情况是"虚读(phantom read)"。

　　4. 不可重复读(unrepeated read)：一个事务两次读取同一行数据，结果得到不同状态结果，如中间正好另一个事务更新了该数据，两次结果相异，不可信任。

　　在T1时刻开启了事务1，T2时刻开启了事务2，在T3时刻事务1从数据库中取出了id="402881e535194b8f0135194b91310001"的数据，此时age=20，T4时刻事务2查询同一条数据，T5事务2更新数据age=30，T6时刻事务2提交事务，T7事务1查询同一条数据，发现数据与第一次不一致。这种情况就是"不可重复读(unrepeated read)"。

　　5. 第二类丢失更新(second lost updates)：是不可重复读的特殊情况，如果两个事务都读取同一行，然后两个都进行写操作，并提交，第一个事务所做的改变就会丢失。

　　在T1时刻开启了事务1，T2时刻开启了事务2，T3时刻事务1更新数据age=25，T5时刻事务2更新数据age=30，T6时刻提交事务，T7时刻事务2提交事务，把事务1的更新覆盖了。这种情况就是"第二类丢失更新(second lost updates)"。

 

三、数据库事务隔离级别

为了解决数据库事务并发运行时的各种问题数据库系统提供四种事务隔离级别：
1. Serializable 串行化
2. Repeatable Read 可重复读
3. Read Commited 可读已提交
4. Read Uncommited 可读未提交

隔离级别与并发性能的关系：

每一个隔离级别可以解决的问题：

 

四、使用Hibernate设置数据库隔离级别

在Hibernate的配置文件中可以显示的配置数据库事务隔离级别。每一个隔离级别用一个整数表示：

8 - Serializable 串行化
4 - Repeatable Read 可重复读
2 - Read Commited 可读已提交
1 - Read Uncommited 可读未提交

在hibernate.cfg.xml中使用hibernate.connection.isolation参数配置数据库事务隔离级别。

 

五、使用悲观锁解决事务并发问题

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

　　一个典型的依赖数据库的悲观锁调用：select * from account where name=”Erica” for update；这条sql语句锁定了account表中所有符合检索条件（ name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。悲观锁，也是基于数据库的锁机制实现。

在Hibernate使用悲观锁十分容易，但实际应用中悲观锁是很少被使用的，因为它大大限制了并发性：

图为Hibernate3.6的帮助文档Session文档的get方法截图，可以看到get方法第三个参数"lockMode"或"lockOptions"，注意在Hibernate3.6以上的版本中"LockMode"已经不建议使用。方法的第三个参数就是用来设置悲观锁的，使用第三个参数之后，我们每次发送的SQL语句都会加上"for update"用于告诉数据库锁定相关数据。

LockMode参数选择该选项，就会开启悲观锁。　　T1,T2时刻取款事务和转账事务分别开启，T3事务查询ACCOUNTS表的数据并用悲观锁锁定，T4转账事务也要查询同一条数据，数据库发现该记录已经被前一个事务使用悲观锁锁定了，然后让转账事务等待直到取款事务提交。T6时刻取款事务提交，T7时刻转账事务获取数据。

 

 

六、使用乐观锁解决事务并发问题

　　相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个"version"字段来实现。
　　乐观锁的工作原理：读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

 

 

乐观锁定（optimistic locking）则乐观的认为资料的存取很少发生同时存取的问题，因而不作数据库层次上的锁定，为了维护正确的数据，乐观锁定采用应用程序上的逻辑实现版本控制的方法。
　例如若有两个客户端，A客户先读取了账户余额100元，之后B客户也读取了账户余额100元的数据，
A客户提取了50元，对数据库作了变更，此时数据库中的余额为50元，B客户也要提取30元，根据其所取得的资料，100-30将为70余额，若此时再对数据库进行变更，最后的余额就会不正确。
　在不实行悲观锁定策略的情况下，数据不一致的情况一但发生，有几个解决的方法，一种是先更新为主，一种是后更新的为主，比较复杂的就是检查发生变动的数据来实现，或是检查所有属性来实现乐观锁定。

　Hibernate 中透过版本号检查来实现后更新为主，这也是Hibernate 所推荐的方式 ，在数据库中加入一个 VERSON 栏记录，在读取数据时连同版本号一同读取，并在更新数据时递增版本号，然后比对版本号与数据库中的版本号，如果大于数据库中的版本号则予以更新，否则就回报错误。
　以刚才的例子，A客户读取账户余额1000元，并连带读取版本号为5的话，B客户此时也读取账号余额1000元，版本号也为5，A客户在领款后账户余额为500，此时将版本号加1，版本号目前为6，而数据库中版本号为5，所以予以更新，更新数据库后，数据库此时余额为500，版本号为6，B客户领款后要变更数据库，其版本号为5，此时将版本号加1，版本号目前为6。但是数据库的版本号也为6，此时不予更新，B客户数据重新读取数据库中新的数据并重新进行业务流程才变更数据库。
　以Hibernate 实现版本号控制锁定的话，我们的对象中增加一个version属性，例如：
public class Account {
  private int version;
  .... 

  public void setVersion(int version) {
      this.version = version;
  } 

  public int getVersion() {
      return version;
  }
}

而在映像文件中，我们使用optimistic-lock属性设定version 控制，<id> 属性栏之后增加一个
<version>标签，如下：

<hibernate-mapping>
  <class name="onlyfun.caterpillar.Account" talble="ACCOUNT"
         optimistic-lock="version">
      <id...../>
      <version name="version" column="VERSION"/>
       ....
  </class>
</hibernate-mapping>


设定好版本控制之后，在上例中如果B 客户试图更新数据，将会引发StableObjectStateException例外 ，我们可以捕捉这个例外，在处理中重新读取数据库中的数据，同时将 B客户目前的数据与数据库中的数据秀出来，让B客户有机会比对不一致的数据，以决定要变更的部份，或者您可以设计程式自动读取新的资料，并重复扣款业务流程，直到数据可以更新为止，这一切可以在背景执行，而不用让您的客户知道。
 但是乐观锁也有不能解决的问题存在：上面已经提到过乐观锁机制的实现往往基于系统中的数据存储逻辑，在我们的系统中实现，来自外部系统的用户余额更新不受我们系统的控制，有可能造成非法数据被更新至数据库。因此我们在做电子商务的时候，一定要小心的注意这项存在的问题，采用比较合理的逻辑验证，避免数据执行错误。

　也可以在使用Session的load()或是lock()时指定锁定模式以进行锁定。
　如果数据库不支持所指定的锁定模式，Hibernate会选择一个合适的锁定替换，而不是丢出一个例外

Hibernate为乐观锁提供了3中实现：

1. 基于version

2. 基于timestamp

3. 为遗留项目添加添加乐观锁

配置基于version的乐观锁：

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="com.suxiaolei.hibernate.pojos.People" table="people">
<id name="id" type="string">
<column name="id"></column>
<generator class="uuid"></generator>
</id>

<!-- version标签用于指定表示版本号的字段信息 -->
<version name="version" column="version" type="integer"></version>

<property name="name" column="name" type="string"></property>

</class>
</hibernate-mapping>

配置基于timestamp的乐观锁：

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="com.suxiaolei.hibernate.pojos.People" table="people">
<id name="id" type="string">
<column name="id"></column>
<generator class="uuid"></generator>
</id>

<!-- timestamp标签用于指定表示版本号的字段信息 -->
<timestamp name="updateDate" column="updateDate"></timestamp>

<property name="name" column="name" type="string"></property>

</class>
</hibernate-mapping>

遗留项目，由于各种原因无法为原有的数据库添加"version"或"timestamp"字段，这时不可以使用上面两种方式配置乐观锁，Hibernate为这种情况提供了一个"optimisitic-lock"属性，它位于<class>标签上：

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="com.suxiaolei.hibernate.pojos.People" table="people" optimistic-lock="all">
<id name="id" type="string">
<column name="id"></column>
<generator class="uuid"></generator>
</id>

<property name="name" column="name" type="string"></property>
</class>
</hibernate-mapping>

将该属性的值设置为all，让该记录所有的字段都为版本控制信息。

总结：悲观锁只是简单的通过DB来进行数据的锁定，简单的理解就是我要对某些数据要有更新的操作，所以我要将这些数据都锁定，所以其他人就不能访问，所以也就避免了数据不同步的问题；

   乐观锁就是通过版本号的比较来控制事务的同步，通过逻辑上的控制来达到锁定的目的。