- 浏览: 1183149 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (350)
- Ajax研究 (2)
- javascript (22)
- struts (15)
- hibernate (12)
- spring (8)
- 我的生活 (28)
- jsp (2)
- 我的随笔 (84)
- 脑筋急转弯 (1)
- struts2 (2)
- ibatis (1)
- groovy (1)
- json (4)
- flex (20)
- Html Css (5)
- lucene (11)
- solr研究 (2)
- nutch (25)
- ExtJs (3)
- linux (6)
- 正则表达式 (2)
- xml (1)
- jetty (0)
- 多线程 (1)
- hadoop (40)
- mapreduce (5)
- webservice (2)
- 云计算 (8)
- 创业计划 (1)
- android (8)
- jvm内存研究 (1)
- 新闻 (2)
- JPA (1)
- 搜索技术研究 (2)
- perl (1)
- awk (1)
- hive (7)
- jvm (1)
最新评论
-
pandaball:
支持一下,心如大海
做有气质的男人 -
recall992:
山东分公司的风格[color=brown]岁的法国电视[/co ...
solr是如何存储索引的 -
zhangsasa:
-services "services-config ...
flex中endpoint的作用是什么? -
来利强:
非常感谢
java使用json所需要的几个包 -
zhanglian520:
有参考价值。
hadoop部署错误之一:java.lang.IllegalArgumentException: Wrong FS
今天就是元旦了,闲着没事,写点东西发上来!
1、Pessimistic Locking 悲观锁;
pessimistic [,pesi'mistik] adj. 悲观的,厌世的;悲观主义的
2、Optimistic Locking 乐观锁;
optimistic [,ɔpti'mistik] adj. 乐观的;乐观主义的
一、
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属性,例如:
view plaincopy to clipboardprint?
public class Account {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return 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>标签,如下:
view plaincopy to clipboardprint?
<hibernate-mapping>
<class name="onlyfun.caterpillar.Account" talble="ACCOUNT"
optimistic-lock="version">
<id...../>
<version name="version" column="VERSION"/>
....
</class>
</hibernate-mapping>
<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会选择一个合适的锁定替换,而不是丢出一个例外。
二、
乐观锁(Optimistic Locking)
相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。如一个金融系统,当某个操作员读取用户的数据,并在读出的用户数据的基础上进行修改时(如更改用户帐户余额),如果采用悲观锁机制,也就意味着整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全过程,甚至还包括操作员中途去煮咖啡的时间),数据库记录始终处于加锁状态,可以想见,如果面对几百上千个并发,这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本(Version)记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案,一般是通过为数据库表增加一个“version”字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。
对于上面修改用户帐户信息的例子而言,假设数据库中帐户信息表中有一个version字段,当前值为1;而当前帐户余额字段(balance)为$100。
1. 操作员A 此时将其读出(version=1),并从其帐户余额中扣除$50($100-$50)。
2. 在操作员A操作的过程中,操作员B也读入此用户信息(version=1),并从其帐户余额中扣除$20($100-$20)。
3. 操作员A完成了修改工作,将数据版本号加一(version=2),连同帐户扣除后余额(balance=$50),提交至数据库更新,此时由于提交数据版本大于数据库记录当前版本,数据被更新,数据库记录version更新为2。
4. 操作员B完成了操作,也将版本号加一(version=2)试图向数据库提交数
据(balance=$80),但此时比对数据库记录版本时发现,操作员B提交的数据版本号为2,数据库记录当前版本也为2,不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略,因此,操作员B 的提交被驳回。这样,就避免了操作员B 用基于version=1 的旧数据修改的结果覆盖操作员A的操作结果的可能。
从上面的例子可以看出,乐观锁机制避免了长事务中的数据库加锁开销(操作员A和操作员B操作过程中,都没有对数据库数据加锁),大大提升了大并发量下的系统整体性能表现。需要注意的是,乐观锁机制往往基于系统中的数据存储逻辑,因此也具备一定的局限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户余额更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。在系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如将乐观锁策略在数据库存储过程中实现,对外只开放基于此存储过程的数据更新途径,而不是将数据库表直接对外公开)。Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作,利用Hibernate提供的透明化乐观锁实现,将大大提升我们的生产力。
Hibernate中可以通过class描述符的optimistic-lock属性结合version
描述符指定。
现在,我们为示例中的TUser加上乐观锁机制。
1. 首先为TUser的class描述符添加optimistic-lock属性:
view plaincopy to clipboardprint?<hibernate-mapping> <class name="org.hibernate.sample.TUser" table="t_user" dynamic-update="true" dynamic-insert="true" optimistic-lock="version"> </class> </hibernate-mapping> …… <hibernate-mapping>
<class name="org.hibernate.sample.TUser"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version">
</class>
</hibernate-mapping>
……
optimistic-lock属性有如下可选取值:
none 无乐观锁
version 通过版本机制实现乐观锁
dirty 通过检查发生变动过的属性实现乐观锁
all 通过检查所有属性实现乐观锁
其中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现,同时也是Hibernate中,目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机制。因此,一般情况下,我们都选择version方式作为Hibernate乐观锁实现机制。
2. 添加一个Version属性描述符
+ expand sourceview plaincopy to clipboardprint?
<hibernate-mapping>
<class name="org.hibernate.sample.TUser"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version">
<id name="id" column="id" type="java.lang.Integer">
<generator class="native"></generator>
</id>
<version column="version" name="version" type="java.lang.Integer"/>
</class>
</hibernate-mapping>
……
<hibernate-mapping>
<class name="org.hibernate.sample.TUser"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version">
<id name="id" column="id" type="java.lang.Integer">
<generator class="native"></generator>
</id>
<version column="version" name="version" type="java.lang.Integer"/>
</class>
</hibernate-mapping>
……
注意version 节点必须出现在ID 节点之后。这里我们声明了一个version属性,用于存放用户的版本信息,保存在TUser表的version字段中。
此时如果我们尝试编写一段代码,更新TUser表中记录数据,如:
view plaincopy to clipboardprint?
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新UserType字段
tx.commit();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新UserType字段
tx.commit();
每次对TUser进行更新的时候,我们可以发现,数据库中的version都在递增。而如果我们尝试在tx.commit 之前,启动另外一个Session,对名为Erica 的用户进行操作,以模拟并发更新时的情形:
view plaincopy to clipboardprint?
Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Erica"));
List userList = criteria.list();
List userList2 = criteria2.list();
TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();
Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Erica"));
List userList = criteria.list();
List userList2 = criteria2.list();
TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();
执行以上代码,代码将在tx.commit()处抛出StaleObjectStateException异
常,并指出版本检查失败,当前事务正在试图提交一个过期数据。通过捕捉这个异常,我
们就可以在乐观锁校验失败时进行相应处理。
发表评论
-
Hibernate性能优化
2011-01-07 10:18 1283文章分为十三个小块儿 ... -
hibernate中session的三种状态
2011-01-05 16:43 2793Hibernate中的对象有三种状态: 瞬时状态 (Trans ... -
深入理解O/R Mapping
2011-01-04 22:39 2016什么是O/R Mapping? 广义 ... -
hbmdll.auto详解
2011-01-04 14:55 1318hibernate.cfg.xml 中hibern ... -
hibernate的事务处理
2010-12-31 23:09 2352在使用hibernate开发时, ... -
eccache的简单介绍
2010-12-31 22:59 1609关于缓存的话题,在坛 ... -
hibernate中队mappedBy的理解
2010-12-30 12:52 1923对于mappedBy的理解: a) 只有OneToOne, ... -
hibernate中openSesson和getCurrentSession的区别,面试时常会问到
2010-12-28 11:30 925异常信息是没有当前的Session的意思,我又仔细的看了 ... -
关于连接池的讨论
2009-09-28 16:44 1501Tomcat的连接池其实就是dbcp. 我比较过流行的 dbc ... -
hibernate 中distinct的使用
2008-07-30 14:50 5209JDBC中我们熟悉的sql: select distinct ... -
hibernate查询时出现的问题
2008-06-13 17:49 3367org.hibernate.InstantiationExce ...
相关推荐
Hibernate 锁机制_悲观锁和乐观锁 Hibernate 锁机制是指在... Hibernate 的锁机制可以分为悲观锁和乐观锁两种,悲观锁通过数据库层次的锁定来实现,而乐观锁通过应用程序上的逻辑实现版本控制的方法来维护正确的数据。
【Hibernate乐观锁与悲观锁详解】 在开发过程中,尤其是在并发环境下,确保数据的一致性和完整性至关重要。Hibernate,作为Java领域广泛使用的ORM框架,提供了一种处理并发数据访问冲突的手段,那就是锁机制。主要...
**Hibernate**作为一种流行的Java持久层框架,提供了多种机制来处理并发控制问题,其中最常用的就是**乐观锁**和**悲观锁**。本文将详细介绍这两种锁的原理、应用场景以及如何在Hibernate中实现。 #### 二、悲观锁...
在进行Hibernate的测试时,可以创建一个名为`hibernate_test`的项目,编写对应的实体类、映射文件以及测试用例,模拟并发场景,来深入理解并对比悲观锁和乐观锁的差异和效果。 总之,理解并合理运用悲观锁和乐观锁...
本文主要讨论的是Hibernate框架中两种锁机制的使用:乐观锁和悲观锁。 首先,让我们深入理解悲观锁(Pessimistic Locking)。悲观锁正如其名字所示,假设并发环境中数据会被频繁修改,所以在整个数据处理过程中,它...
### Hibernate的乐观锁和悲观锁 #### 一、引言 在软件开发中,尤其是在涉及大量并发操作的应用场景下,确保数据的一致性和完整性是非常重要的。对于基于Java Web的应用而言,Hibernate作为一款流行的ORM框架,提供...
在处理并发问题时,Hibernate提供了悲观锁和乐观锁两种机制。 悲观锁假设并发环境中的冲突是常态,因此在读取数据时就立即锁定,直到事务结束才释放。在Hibernate中,可以通过设置`@LockModeType.PESSIMISTIC_READ`...
3. **源码分析**:理解Hibernate的乐观锁和悲观锁机制,需要深入源码。在Hibernate的`Session`接口中,有相应的`lock()`和`update()`方法,它们在背后实现了锁的逻辑。通过对这些方法的调用和跟踪,可以了解其内部...
在Java的持久化框架Hibernate中,悲观锁和乐观锁是两种重要的并发控制策略,它们用于管理数据库中的数据在多线程环境下的访问安全。本文将深入探讨这两种锁机制的原理、应用场景及其区别。 首先,我们来理解悲观锁...
总结来说,Hibernate的悲观锁和乐观锁是两种不同的并发控制策略,悲观锁倾向于预防并发冲突,适合并发较低但需要保证数据一致性的情景;而乐观锁则在并发较高的情况下更优,通过版本控制减少锁定,但在冲突处理上...
悲观锁和乐观锁各有优缺点,选择哪种锁机制取决于具体的应用场景和需求。悲观锁适合数据修改频繁且对数据一致性要求较高的场景;而乐观锁适用于数据修改较少且并发量较大的场景。在实际应用中,可以根据具体情况灵活...
在本文中,我们将详细介绍 Hibernate 实现悲观锁和乐观锁的代码实现,并讨论 Hibernate 的隔离机制和锁机制。 Hibernate 的隔离机制 Hibernate 的隔离机制是基于数据库的事务隔离级别的。 Hibernate 提供了四种...
Hibernate乐观锁是数据库事务控制的一种策略,主要用于处理并发更新数据的情况。在乐观锁的机制下,假设并发用户很少会发生冲突,所以...在实际应用中,可以结合悲观锁和其他并发控制策略,以达到最佳的事务处理效果。
乐观锁和悲观锁是数据库和并发编程中常见的两种锁机制,它们主要用于解决多线程环境下的数据一致性问题。在Java面试中,理解这两种锁的概念、工作原理以及适用场景是非常重要的。 乐观锁是一种假设大多数情况下不会...
求助编辑百科名片相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销,特别是对长事务而言,...
【hibernate事务管理机制】是指在使用Hibernate框架进行数据库操作时,如何管理和协调事务的一系列规则和策略。事务管理是确保数据一致性、完整性和并发控制的重要机制。 **悲观锁**是预防性的锁定策略,它假设并发...
6. **性能分析**:通过模拟并发场景,对比使用乐观锁和悲观锁时的性能差异,理解在不同业务场景下选择合适锁策略的重要性。 7. **实战演练**:设计并执行一系列测试用例,包括正常更新、并发冲突等,以加深对乐观锁...