Hibernate在应用层对并发事务的控制

Hibernate与事务处理一文中,介绍了事务以及并发事务处理时的问题,和针对于这些问题在数据库层所能做的隔离级别,但是在选择read commit和repeatable read两个隔离级别时,如果考虑到performance和scalability,可以选择一个折衷的方案,也就是在数据库中的隔离级别选择read commit,而通过对应用程序的控制,可以达到repeatable read的效果。Hibernate在程序中控制并发的事务处理上,也有自己的方法,本文在 Hibernate与事务处理基础上,对Hibernate的这些并发事务处理方法进行介绍。
数据库隔离级别可以通过设置hibernate的属性文件,来改变数据库默认的隔离级别:
xml 代码
  1. 1:Read umcommited  
  2. 2:Read commited  
  3. 3:Repeatable read  
  4. 4:Serializable  

在这里设置hibernate.connection.isolation=2;但需要注意的是,如果hibernate用在了应用服务器上,该应用服务 器对数据库连接提供了受管理的控制,则这里设置的isolation级别失效,采用的是app server定义的级别,可以通过改变app server的配置来改变该隔离级别。
因为这里设置的隔离级别是read commit,那如果想达到repeatable read,则需要设置version number或者timestamp。

如果某个项目从头到尾开始设计和开发,考虑到事务处理,则在需要并发控制的数据库表字段上,添加和hibernate的version number相对应的字段。例如对Student表的并发控制,则需要在TSTUDENT表上添加STU_VERSION字段,在ORM的映射文件中需要在标识符属性下添加,例如:
java 代码
 
  1. <class name="Student" table="TSTUDENT">  
  2. ...  
  3. class>  

在Student.java的pojo文件中添加:
java 代码
 
  1. public class Student {  
  2. ....  
  3. private int version;  
  4. ...  
  5. }  

version属性是不能被应用所改变的,所以仅仅提供get方法即可。但是version number是怎样在应用层提供对事务的并发处理机制呢?原理是这样的:在hibernate的事务A(在这里假设事务的范围和Session范围一致,每个Session对应一个persistent context)中,执行每一个DML操作,都会先检查一下对象的version属性,假如从数据库中得到的student实例的version属性是1,此时student已经加载到Session对应的persistent context中,如果对student对象进行改变,在Session.flush()的时候,则将persistent context中的student对象的version属性设置为2,然后在保存student对象时,将对象对应的记录version字段更新为2。
注意的是,如果并发的另一个事务B在事务A进行保存操作之前,已经将version更新为2或者更高值的student存入数据库,那A在保存student之前,需要检查该persistent object对应的记录的version为1(因为在从数据库取得persistent object的时候,version为1)的行的个数,如果行数为0,则抛出 StaleObjectStateException,表明存在其他的事务更新了数据库,那这样的话,A事务的更新操作就不会覆盖B事务的更新操作,达到了避免(3)问题中的second lost update(见 Hibernate与事务处理)。
当然避免了second lost update是不够的,因为是不是这样就能够具有repeatable read的隔离级别呢?比较一下read commit和repeatable read的隔离级别的差别,read commit是读事务允许其他事务并发执行,而repeatable read是读事务不允许写事务并发执行,在hibernate中,通过Session对应的persistent context来实现后者,具体是在一个事务A中(假设事务的范围和Session范围一致),读取student对象到persistent context,此时事务B更改了student对象对应的记录并进行持久化,根据数据库的默认隔离级别read commit,那么A事务如果再读取student对象,那就是产生unrepeatable read,其实不然,正是因为hibernate的persistent context,使得A事务再次读取student不是从数据库中读取,而是从当前的Session读取,因此避免了unrepeatable read,同时使得具有类似于数据库隔离级别repeatable read的隔离效果。

当然我们这里假设的是事务的范围和Session范围一致,但是当用户操作中途停留时间过长,则需要将不同的事务在同一conversation下实现,要保证不同事务共用Session可以通过Hibernate的FlushMode来实现。当然也可以保证Session和事务的对应,通过在不同Session中传递detached object来实现。

对于Hibernate在应用层对并发事务的控制方法还有timestamp,pessimistic locking,这里先不做介绍。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值