细谈Hibernate悲观锁和乐观锁解决hibernate并发

锁（ locking ），这个概念在我们学习多线程的时候曾经接触过，其实这里的锁和多线程里面处理并发的锁是一个道理，都是暴力的把资源归为自己所有。这里我们用到锁的目的就是通过一些机制来保证一些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。Hibernate 支持两种锁机制：即通常所说的“悲观锁（Pessimistic Locking ）”和“乐观锁（ Optimistic Locking ）”。

悲观锁（ Pessimistic Locking ）
悲观锁，正如其名，他是对数据库而言的，数据库悲观了，他感觉每一个对他操作的程序都有可能产生并发。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
一个典型的倚赖数据库的悲观锁调用：

 

select * from account wherename=”Erica” forupdate

这条 sql 语句锁定了 account 表中所有符合检索条件（name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。Hibernate 的悲观锁，也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁：

 

 

String hqlStr ="from TUser as user where user.name=‘Erica‘";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加锁
List userList = query.list();// 执行查询，获取数据

query.setLockMode 对查询语句中，特定别名所对应的记录进行加锁（我们为TUser 类指定了一个别名“user”），这里也就是对返回的所有 user 记录进行加锁。
观察运行期Hibernate 生成的 SQL 语句：

select tuser0_.id as id, tuser0_.name as name,tuser0_.group_id
as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
from t_user tuser0_ where (tuser0_.name=‘Erica‘ )for update

这里Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。

 

 

Hibernate 的加锁模式有：
LockMode.NONE ：无锁机制。
LockMode.WRITE ：Hibernate 在 Insert 和 Update 记录的时候会自动获取。
LockMode.READ ：Hibernate 在读取记录的时候会自动获取。

 

以上这三种锁机制一般由 Hibernate 内部使用，如Hibernate 为了保证 Update过程中对象不会被外界修改，会在 save方法实现中自动为目标对象加上 WRITE 锁。
LockMode.UPGRADE ：利用数据库的 for update 子句加锁。
LockMode. UPGRADE_NOWAIT ： Oracle 的特定实现，利用 Oracle 的 for update nowait 子句实现加锁。
上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode
Query.setLockMode
Session.lock

注意，只有在查询开始之前（也就是 Hiberate 生成 SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含 for update 子句的 Select SQL 加载进来，所谓数据库加锁也就无从谈起。

 

在Hibernate使用悲观锁十分容易，但实际应用中悲观锁是很少被使用的，因为它大大限制了并发性，并且利用数据库底层来维护锁，这样大大降低了应用程序的效率。

下面我们来看一下hibernateAPI中提供的两个get方法：

Get（Classclazz，Serializable id，LockMode lockMode）

Get（Classclazz，Serializable id，LockOptions lockOptions  ）

 

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

 

乐观锁（Optimistic Locking）

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

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>
    <classnameclassname="com.bzu.hibernate.pojos.People"table="people">
        <idnameidname="id"type="string">
            <columnnamecolumnname="id"></column>
            <generatorclassgeneratorclass="uuid"></generator>
        </id>

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

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

    </class>
</hibernate-mapping>

 

 

注：不要忘记在实体类添加属性version

 

配置基于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>
    <classnameclassname="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>

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


    </class>
</hibernate-mapping>

下面我们就模拟多个session，基于version的来进行一下测试：

 

/*
         * 模拟多个session操作student数据表
         */

        Sessionsession1=sessionFactory.openSession();
        Session session2=sessionFactory.openSession();
        Studentstu1=(Student)session1.createQuery("from Student s wheres.name='tom11'").uniqueResult();
        Studentstu2=(Student)session2.createQuery("from Student s wheres.name='tom11'").uniqueResult();

        //这时候，两个版本号是相同的
       System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());

        Transactiontx1=session1.beginTransaction();
       stu1.setName("session1");
        tx1.commit();
        //这时候，两个版本号是不同的，其中一个的版本号递增了
       System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());

        Transactiontx2=session2.beginTransaction();
       stu2.setName("session2");
        tx2.commit();

 

运行结果：

Hibernate: insert into studentVersion (ver, name,id) values (?, ?, ?)
Hibernate: select student0_.id as id0_, student0_.ver as ver0_, student0_.nameas name0_ from studentVersion student0_ where student0_.name='tom11'
Hibernate: select student0_.id as id0_, student0_.ver as ver0_, student0_.nameas name0_ from studentVersion student0_ where student0_.name='tom11'
v1=0--v2=0
Hibernate: update studentVersion set ver=?, name=? where id=? and ver=?
v1=1--v2=0
Hibernate: update studentVersion set ver=?, name=? where id=? and ver=?
Exception in thread "main" org.hibernate.StaleObjectStateException:Row was updated or deleted by another transaction (or unsaved-value mapping wasincorrect): [Version.Student#4028818316cd6b460116cd6b50830001]

 

     可以看到，第二个“用户”session2修改数据时候，记录的版本号已经被session1更新过了，所以抛出了红色的异常，我们可以在实际应用中处理这个异常，例如在处理中重新读取数据库中的数据，同时将目前的数据与数据库中的数据展示出来，让使用者有机会比较一下，或者设计程序自动读取新的数据

 

来源：http://blog.csdn.net/csh624366188/article/details/7654996