Hibernate 悲观锁,乐观锁

你是否正在寻找关于悲观锁的内容？让我把最新的东西奉献给你：

Hibernate 悲观锁,乐观锁

1.悲观锁

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

select * from account where for update

在更新的过程中，处于加锁状态，任何其他的针对本条数据的操作都将被延迟。本次事务提交后解锁。
而hibernate悲观锁的具体实现如下：

Stringsql="查询语句";
Queryquery=session.createQuery(sql);
query.setLockMode("对象"，LockModel.UPGRADE);

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

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

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

LockMode.UPGRADE：利用的forupdate字句加锁。

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

2.乐观锁

乐观锁定（optimisticlocking）则乐观的认为资料的存取很少发生同时存取的问题，因而不作层次上的锁定，为了维护正确的数据，乐观锁定采用应用程序上的逻辑实现版本控制的方法。

例如若有两个客户端，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控制，

以上就是关于悲观锁的全部内容，相信你一定会非常满意。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shenmilingyu/article-6654-1.html