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

交代本项目中要求获取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语句,来进行观察。

<prop key="hibernate.show_sql">true</prop>

<prop key="hibernate.format_sql">true</prop>

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

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

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

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

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

  回到上面的问题,重复记录的原因:因为使用了立即加载模式,查询的时候,多对多关联关系的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中就再次获取的时候就是可以的,这里的

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

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

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

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

<!--
延长session的生命周期:
关联关系 需要加载的时候就去查找 不需要用到的时候就不查找
比如:加载部门名字 这个时候em.dm.name会用到关联关系
-->
<filter>
<filter-name>openSessionInView</filter-name>
<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
</filter> <filter-mapping>
<filter-name>openSessionInView</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

 

===============================================================

真的是整理的好累好累,虽然还是不咋地,但是就这样吧。啊啊啊啊啊。。。。。。。。。。。。。。。。

思考花絮:

1.凤姐现在在Component模块中需要用到对应的Arch对象

实现方法:通过Component的id获取到Component后,通过Component对象来get到对应的Arch集合

由于在service层通过id获取到Component采用OpenSesssion()打开session 要在service层手动关闭session

故当在action表现层就获取不到对应的Arch集合,因为此时是延迟加载模式,然后session又已经被关闭了

如何解决?

方法1:采用立即加载模式

方法2:采用延迟加载模式,在service层通过getCurrentSession()方式获取session,此中方式会在事务完成后

(本查询结束离开service层)自动进行提交,然后在web.xml里面配置spring的openSessionInView,来延长session的

生命周期,让其不自动在离开service层就关闭,而是让session在一次请求响应(request,response)结束后才进行自动关闭,

即加上这个配置后,在session在action表现层也是可以作用的。此时就可以在变现曾拿到对应的Arch对象

1.session

如何获取session?两种方式

两种方式的区别

2.懒加载

何为懒加载?懒加载有什么作用?

如何解决项目中懒加载问题?

立即加载与懒加载如何选择?

使用立即加载带来的问题?

比如使用hql查询与qbc查询的区别 而带来的异常

hql查询不使用关联关系查询  直接利用表字段什么的

qbc查询使用hibernate.format_sql在控制台打印数据库查询语句  可以观察到 只要配置了关联关系

  就会发出左外连接查询left join

因此 使用qbc查询 当存在多对多的关系时,开启了立即加载的模式,此时,查询 会出现一条记录重复的现象

解决办法:1.去重 distinct

     2.使用延迟加载

那么问题来了  对于在action表现层 如何使用延迟加载  需要使用spring来延长session的生命周期(request,response结束后才关闭session)或者使用getCurrentSession()来获取session,并在session关闭前,将要使用的数据进行初始化获取

对于小白,对,没错,说的就是我这样的, 啊哈哈哈哈。。。一些业务方法 会喜欢写在表现层 最好的是 把一些处理业务逻辑的方法  写在业务层  这样 也就不用延长session的生命周期了  真的是

上一篇:Python机器学习笔记:K-Means算法,DBSCAN算法


下一篇:各类聚类(clustering)算法初探