ssh中Hibernate懒加载,session问题的学习与理解-白红宇

ssh中Hibernate懒加载,session问题的学习与理解

阅读量：5237 次

发布时间：2019-06-14

本文共 5040 字，大约阅读时间需要 16 分钟。

交代本项目中要求获取session的方式如下：

public Session getCurrentSession() {        // 增删改使用的session,事务必须是开启的(Required，即propagation="REQUIRED")，否则获取不到        return sessionFactory.getCurrentSession();    }    public Session getQueryCurrentSession() {        // 查询使用的session,，该生成的session没有事务。        return sessionFactory.openSession();    }

问题1描述：

　　Component对Arch为多对多的关系，小明在页面需要展示Component的记录，然后展示出来有一条记录a是重复的,经过一番排查，发现记录a在中间表中对应着两条

记录b,c。即因为Component与Arch是多对多的关系，故在中间表中有两条a对应着不同的b,c。那为什么仅仅只是查询Component,页面会显示两条重复的a记录呢？原

来，本次项目中关闭了懒加载，开启了立即加载，并且小明在查询Component的时候使用的QBC查询。

1.什么是懒加载(延迟加载)？什么是立即加载？

　　当数据在需要用到的时候才去获取就是懒加载；不管数据用不用到一次性全部查询获取出来。由此可见立即加载会造成资源浪费，并且导致查询效率低下。

2.什么是QBC查询

　　QBC,即Query By Criteria，是Hibernate提供的一种查询方式，不需要写hql语句，直接使用方法实现，省略QBC的使用方法与步骤，通过如下配置让其在控制台打印

出对应的sql语句，来进行观察。


     
      true
     
     
      true

　　可以从控制台打印的一些sql语句，看出只要在实体类中配置了关联关系在进行QBC查询的时候，都会进行left outer join左外连接查询,a a aa a a ,好奇害死猫呀，这

就又让我去看看普通的hql语句是不是这样做的呢？果然不同。。。真的是，QBC与HQL两种查询的区别，大致在于QBC查询，只要在实体类中配置了关联关系在进行查

询的时候，都会进行left outer join左外连接查询，而hql查询是根据表字段来进行查询的并没有进行表关联查询，所以有可能就算你使用了立即加载，在查询的时候也不会

出现有重复记录的bug,a a a a a,也就不会有现在这一大堆的思考了。。不过这样也是很好很好的，让我又明白了并学习了当初并不懂的一些知识。。啊哈哈哈。。。。

　　回到上面的问题，重复记录的原因：因为使用了立即加载模式，查询的时候，多对多关联关系的Arch表进行了中间表的关联进行了左外连接查询故出现了2条重复的记录a

解决记录重复问题：

1.采用立即加载，在查询的时候，添加去重distinct

criteria.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);

2.关闭立即加载，使用懒加载（延迟加载），这样在查询Component的时候就不会进行中间表的左外连接查询,也就不会有重复记录

问题2描述：

　　使用方法1，跟使用方法2都可以解决问题，但是，使用方法2，现在又出了问题。使用方法2，可以解决小明重复的问题，但是凤姐又出问题了，由于凤姐通过

Component的id查询到的Component，是在dao层使用的openSession()获取的Session，即在dao层中就已经将session关闭了，现在又使用了懒加载，故凤姐在action表

现层无法通过Component对象来get到对应的Arch集合，这个时候会抛no session的异常。说完，要是跟我一样是小白新手的话，可能是懵比的，那就再简单介绍下本

此项目中所涉及到的知识：(也是折腾了一两天，才对其中的知识懵懵懂懂！！！！！！！！，只是个人表面肤浅的理解。。。。)

3.获取session的两种方式？

1.openSession(),直接打开一个新的session。需要自己手动去关闭。

2.getCurrentSession(),获取当前session，当session不存在，就新打开一个，否则获取已经有的session。不需要自己手动关闭，交由spring管理，当service层的事务被

提交完成后，session会自动关闭。

4.为什么要配置增删改获取的session，要在service层自动关闭？

　　了解以下hibernate事务提交过程就会知道了：

.....Session session=sf.openSession();Transaction tx=session.beginTransaction();.....tx.commit();s.close();

　　1.创建session实例

　　2.用session创建Transaction实例，开始一个事务。

　　3.利用session方法进行持久化操作。将实体对象的持久化到数据库中。

　　4.提交操作结果，结束事务。对实体对象的持久化操作结束后，必须提交事务。

　　5.关闭session，与数据库断开连接

知道了事务提交的过程，也就明白了为什么本次项目会要求增删改操作使用getCurrentSession(),查询操作使用openSession()。因为增删改要有事务的操作，而事务是作

用在service业务层的，并且是事务提交之后，session才能关闭。故不能在dao层立即关闭session,故不用openSession()。因为查询不需要事务，故使用openSession()，

也就不需要在查询的时候开启事务了，以免造成资源的浪费，就可以直接在dao层关闭session,对事务不造成影响。但是但是但是，问题来了，这就要求我们只能使用立

即加载，而不能使用延迟加载了，因为涉及到查询的操作，都是在dao层关闭了了session，在service层或表现层根本不能根据对象去获取多对多关系的集合属性，因为

session已经在dao层就关闭了。

　　所以绕来绕去，解决本次项目问题的方法，还是只能采用立即加载.

　　对于只能使用立即加载，当数据多了以后，这也会造成效率低的情况，所以最好建议不要这么做，但是这也是没有办法的事，毕竟现在本项目要求查询用的是

openSession()，并立即关闭。但是如果抛开本次项目，该如何解决懒加载的问题呢？如何做到使用懒加载而不抛异常呢?

　　个人认为只能更改本次项目中，查询操作获取session的方式，将openSession()也换为getCurrentSession(),虽然现在查询也需要加上事务了(事务必须是开启的,即

propagation="REQUIRED"，否则通过getCurrentSession()是获取不到session的。)，但是我也不知道，这个立即加载造成的效率跟查询开启事务，来比较，谁比较浪费资

源？？？？？？？？下面就说下，当查询操作的session变为getCurrentSession()后，如何解决懒加载问题。

再次声明此方法前提：在dao层以getCurrentSession()获取session来查询对象，这个时候dao层不会立即关闭sesion，交由spring来管理，在service层，当事务提交完成后，session会自动关闭。

项目中涉及到懒加载的位置，一般如下

1..在业务层service中，需要使用懒加载

　　这个时候session还没有关闭，就随便用啦

2.在表现层action中，需要使用懒加载

　　由于现在session，已经被关闭，所以在表现层中再用对象去获取多对多关系的集合属性，是会抛懒加载no session异常的。那么，如何解决？

解决懒加载（延迟加载获取不到对象的关联属性值）问题：　　

　　1.在session关闭前，即在业务层中将要获取的数据强行进行初始化，即初始化需要用到的集合属性，这样在表现层action中就再次获取的时候就是可以的，这里的

强行有很多种方法的，我就说下我用到的方法吧：

　　2.延长session的生命周期，让其在一次响应后结束(quest,response)后，才被关闭。

　　　　具体做法：在web.xml中配置


         
                
      
       openSessionInView
                 
      
       org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
          
             
             
      
       openSessionInView
              
      
       /*