关闭

no session or session was closed处理方法

693人阅读 评论(0) 收藏 举报
分类:

首先说明一下,hibernate的延迟加载特性(lazy)。所谓的延迟加载就是当真正需要查询数据时才执行数据加载操作。因为hibernate当中支持实体对象,外键会与实体对象关联起来。如果没有这一特性,当查询某一个含有外键的实体对象时,hibernate会把其他实体对象的数据都查询出来。

简单的来说,当你想查询某个对象时,实际上调用了多条查询语句。有了延迟加载特性,就避免了这种情况的发生,当你真正的使用get另外一个实体对象时,才再执行下面一条查询语句。

但有些时候,这个特性却会给我们应用中带来一些问题。

这个问题相信大家并不陌生了,hibernate的延迟加载(lazy)特性的确不错的优点,如果没了这个特性,我相信大家在处理一些外键的对象时会头大起来,因为效率十分的低。甚至很多人都觉得使用jdbc要比hibernate要高效甚至方便得多,而迫使不去使用hibernate。

我想说,没错,使用jdbc在效率上的确可能要快许多,但差距也不会太大的,因为hibernate本身就支持多种查询方式,SQL、HQL、 DetachedCriteria等。而相反的,hibernate在维护性上比jdbc强很多,因为是实体对象的关系。我相信如果您使用过jdbc来实现注册功能的话,会深有体会。

提示session已关闭(no session or session was closed)

触发这个问题的原因在于,hibernate在查询操作完毕的时候会自动的把session关闭掉,为了降低使用的资源。但问题也这样产生了,不要忘了之前所说的hibernate特性,此时再调用get实体方法的时候就会有可能出现这个错误。因为session已经关闭而不能继续执行查询了。

解决思路:

1、关闭延迟加载特性。

操作起来比较简单,因为hibernate的延迟加载特性是在hbm配置里面可控制的。默认lazy="true",具体配置可以查看一下相关文档,就不详细叙述了。
但使用这个解决办法带来的隐患是十分大的。
首先,出现no session or session was closed就证明了您已经在使用外键关联表,如果去掉延迟加载的话,则表示每次查询的开销都会变得十分的大,如果关联表越多,后果也可以想象得到。所以不建议使用这个方法解决。

2、在session关闭之前把我们想要查询的数据先获取了。

首先需要了解一下session什么时候关闭,也就是它的生命周期。通常情况下hibernate会在查询数据关闭session,而使用getHibernateTemplate().get方法查询后会延迟关闭的时间。会在事务结束后才关闭。

使用拦截器(Interceptor)或过滤器(Filter)控制session。

spring为解决hibernate这一特性提供的解决方案,可以有效的控制session生命周期。

使用这两个方法的详细描述就不多介绍了网上也有不少的文章。这里主要是介绍自己的一套方案。

使用CLONE解决延迟加载问题。

使用Interceptor和Filter,弊端是所有session都一概而论了,无论是否需要延迟session关闭都统统把session关闭的时间延迟了。这里带来了一些资源开销的问题,虽然没必要这么钻牛角尖。但也只是继续本着研究的精神吧。这里的影响程度也是有级别的,因为控制在业务层或者是视图层,影响也有不同的。还有的时候会与其他继承冲突,例如又用了spring的security框架,貌似会有些冲突发生。


在这里想了一下有没有更好的解决办法呢?能在我们需要的时候把数据获取掉,而又不会出现session关闭的情况。

这时我想到了两点,第一,findById方法时候的session会延迟。第二,clone方法。

对于第一点,只能使用get方法来实现也不是绝对的,我们也可以使用DetachedCriteria查询。

第二点有些朋友有些疑问或者陌生,稍微讲解一下。

为什么使用clone?

因为在session关闭之前使用get实体获取的对象没错你也可以查询得到,但是session关闭后,这些数据就不能访问了。如果直接赋值结果还是一样的,因为只是址传递,所以我们必须使用clone方法来把获取后的数据做拷贝操作,而必须还是deep clone,shadow clone也是不行的。


具体操作

1、实现Cloneable接口。

因为我们要进行deep clone操作,所以BO对象必须作以下操作。

implements Cloneable

2、重写(override)clone方法。

clone方法默认为

  1. @Override  
  2. protected Object clone() throws CloneNotSupportedException {   
  3.     return super.clone();   
  4. }  

 

要进行deep clone操作必须把protected改为 public,并且把返回的object改为具体的Bean对象。

3、执行clone操作。

首先,前提当然是确保事务结束之前session未被关闭,可以使用get实体的操作。


然后看下面例子

  1. public List<AccAlias> listAccAlias() {   
  2.     List<AccAlias> all = AccAliasDAO.findAll();   
  3.     if (all != null && !all.isEmpty())   
  4.         for (AccAlias accAlias : all) {   
  5.             try {   
  6.                 Mailbox mailbox = accAlias.getMailbox();   
  7.                 if(mailbox!=null){   
  8.                     mailbox = mailbox.clone();   
  9.                     accAlias.setMailbox(mailbox);   
  10.                 }   
  11.             } catch (CloneNotSupportedException e) {   
  12.                 e.printStackTrace();   
  13.             }   
  14.         }   
  15.     return all;   
  16. }  

 

后续问题研究:

姑且作为一个比较非主流的解决方案吧,是否适合还是要看大家需求的,没有一套方案是绝对适合的。


使用clone解决延迟加载的弊端:

1、clone的实际开销。

2、查询方式的依赖性。必须根据ID查询方式来查询实体。而且更可以认为耦合度提高了,因为业务层clone操作有时必须依赖DAO特定的查询方式。


当然这些弊端也幸好仅仅针对使用到需要解决延迟加载的时候触发。


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:9924次
    • 积分:344
    • 等级:
    • 排名:千里之外
    • 原创:24篇
    • 转载:3篇
    • 译文:0篇
    • 评论:1条
    文章分类
    最新评论