hibernate的锁

业务实现过程中，难免需要保证数据访问的排他性。如金融系统的日终结算中，我们会针对某个截止点的数据进行处理，在此同时，不希望在结算的这段时间里（几秒钟或者几个钟头），数据再有变动，不然我们的统计也无效了。这种时候，我们为了保证某些数据在某个操作中不被外界修改，就引入了我们hibernate的锁机制，一旦我们给目标上锁，其他程序则不能去修改。hibernate中锁是两种，悲观和乐观锁。、

悲观锁，自然，它指的是对数据被外界（包括本系统当前的其他事物，以及来自外部系统的事务处理）修改，保持保守态度，因此整个处理过程中，数据一致处于被锁定的状态【额....还真是够悲观的..】，悲观锁的实现，往往依靠数据提供的锁机制（也只有数据库层提供的锁机制，才能真正保证排他性，否则本系统中实现加锁机制，并不能一定保证外部系统不会修改数据）。

下面，这是一个典型的，依赖数据库实现的悲观锁的调用：

select*fromaccountwherename="Erica"forupdate

通过for update子句，sql锁定了account中，所以符合名字等于erica的记录。即在本次事物提交之前(事物提交时会释放事物过程中的锁)，外界无法修改这些记录。hibernate的悲观锁，也是基于数据库的锁机制实现的，下面代码实现了对查询记录的加锁：

StringhqlStr="fromUseruserwhereuesr.name='Erica'";
Queryquery=session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE);//加锁
ListuserList=query.list();//获得数据

当运行后，我们通过show_sql可以看见，原生的sql语句仍然在最后面加上了for update，可以看出hibernate通过数据库的for update自己来实现了悲观锁的机制。

Hibernate的加锁模式则分为：LockMode.NONE：无锁 LockMode.WRITE:hibernate在insert和update记录的时候会自动获取 LockMode.READ: hibernate在读取数据的时候会自动获取。

以上的3中机制，一般由hibernate内部使用，如hibernate为了保证update过程中对象不被外界修改，会在save方法实现中自动为目标对象加上WRITE锁，这些都是hibernate内部数据的锁定机制，与数据库无关。

而LockMode.UPGRADE:利用数据的for update子句加锁， LockMode.UPGRADE_NOWAIT: oracle特定的实现，利用oracle的for update nowait子句实现加锁。

上面这两种所机制是我们比较常用的，依赖数据库的悲观锁机制。加锁方式一般有：Criteria.setLockMode ； Query.setLockMode ； Session.lock，注意，只有在查询开始前（也就是hibernate生成sql前）设定加锁，才会真正通过数据库的锁机制来加锁处理，否则，数据已经通过不包含for update的子句的select 语句加载了，锁机制也无从谈起。

乐观锁，则采取更加宽松的机制加锁。悲观的大都靠数据库的for update实现，在保证了独占性外，性能会相对消耗较大。对于长事物而言，基本无法承受额样的开销。而乐观锁则是通过给数据库增加一个version字段，通过比较版本信息，从而实现加锁机制。下面我们打个比方，就知道了。

数据库的accout表中，记录着张三的账户上有100块钱，此时银行还未上班，张三也未存取或转账，这时，乐观锁情况下，这个100块是version=1的，而然在上班之后，银行操作员a，将账户查了出来，在进行扣除，他想着要扣多少钱才好，于是他边喝咖啡边想，这时候，操作员b也来了，查到了张三的账户也想扣他的钱，这时a想好了，先行扣了张三的50块，即100-50，然后愉快的提交了，此时张三账户的version字段被+1，成为version=2了。后来b了想好了，扣了它20块，即100-20，他也想提交，但是突然报出提示，不能提交，缘故是提交的版本必须大于记录的版本才能执行，哦，他这才知道原来张三的账户已经被修改过了，所以才被驳回。

从上面的例子可以看出，乐观锁避免了长事务中的数据加锁的开销，操作员a和b在操作时，都未加锁，从而大大提升了大并发量的系统的整体的性能表现。而hibernate在其数据访问引擎中内置了对乐观锁的实现。如果不考虑外部系统对数据库的更新操作，利用hibernate提供的透明化的乐观所机制将大大提升生产力。

比如，我们为之前几篇博文中的User表加上乐观锁，即添加optimistic-lock属性：

<hibernate-mapping>
<classname="com.entity.Uesr"table="User"dynamic-update="true"dynamic-insert="true"optimistic-lock="vsersion">
<spanstyle="white-space:pre;"></span><versioncolumn="version"name="version"type="java.lang.Integer"/>
......
</class>
</hibernate-mapping>

上面的optimistic-lock属性则可选为none（无乐观锁）；version（通过版本机制实现乐观锁）；dirty（通过检查发生变动的属性实现乐观锁）； all（通过检查所有属性实现乐观锁），其中version方式是hibernate官方推荐的方式，所以我在上面的举例，也是通过version的方式。

下面，我们尝试去更新User的记录，代码如下：

Criteriact=session.createCriteria(User.class);
ct.add(Expression.eq("name","Erica"));

ListuserList=ct.list();
Useruser=(User)userList.get(0);

Transactiontx=session.beginTransaction();
user.setUserType(1)';//更新UserType字段为1
tx.commit();

每次去更新的时候，我们可以发现，数据库的version一直在加1。如果我们在tx.commit之前，再启动一个session去对Erica进行更新，以模拟并发更新的话，那么代码就是这样的：

Sessionsession=getSession();
Criteriact=session.createCriteria(User.class);
ct.add(Expression.eq("name","Erica"));

Sessionsession2=getSession();
Criteriact2=session.createCriteria(User.class);
ct.add(Expression.eq("name","Erica"));

Listlist1=ct.list();
Listlist2=ct2.list();
Useruser1=(User)list1.get(0);
Useruser2=(User)list2.get(0);

Transactiontx1=session.beginTransaction();
Transactiontx2=session2.beginTransaction();

user2.setUserType(99);
tx2.commit();
user2.setUserType(1);
tx1.commit();

那么，这段代码执行时会在tx1.commit()处，抛出StaleObjectStateException异常，指出版本检查失败，通过这个异常，我们就可以进行相应的处理。