hibernate 锁机制

Hibernate 悲观锁,乐观锁 1.悲观锁

它指的是对数据被外界修改持保守态度。假定任什么时候刻存取数据时，均可能有另外一个客户也正在存取同一笔数据，为了保持数据被操做的一致性，因而对数据采起了数据库层次的锁定状态，依靠数据库提供的锁机制来实现。 基于jdbc实现的数据库加锁以下：

select * from account where name="Erica" for update

在更新的过程当中，数据库处于加锁状态，任何其余的针对本条数据的操做都将被延迟。本次事务提交后解锁。 而hibernate悲观锁的具体实现以下： String sql="查询语句"; Query query=session.createQuery(sql); query.setLockMode("对象"，LockModel.UPGRADE);

说到这里，就提到了hibernate的加锁模式：

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

这三种加锁模式是供hibernate内部使用的，与数据库加锁无关：

LockMode.UPGRADE：利用数据库的for update字句加锁。

在这里咱们要注意的是：只有在查询开始以前（也就是hiernate生成sql语句以前）加锁，才会真正经过数据库的锁机制加锁处理。不然，数据已经经过不包含for updata子句的sql语句加载进来，所谓的数据库加锁也就无从谈起。 但 是，从系统的性能上来考虑，对于单机或小系统而言，这并不成问题，然而若是是在网络上的系统，同时间会有许多联机，假设有数以百计或上千甚至更多的并发访 问出现，咱们该怎么办？若是等到数据库解锁咱们再进行下面的操做，咱们浪费的资源是多少？--这也就致使了乐观锁的产生。

2.乐观锁

乐观锁定（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，可是数据库的版本号为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会选择一个合适的锁定替换，而不是丢出一个例外。

转载：http://www.cnblogs.com/wblade/archive/2011/05/11/2042963.html