使用clone解决hibernate+spring集成中的延迟加载问题及分析(no session or session was closed)
首先说明一下,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已经关闭而不能继续执行查询了。
![](/qrcode.jpg)
解决思路:
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方法默认为
- @Override
- protected Object clone() throws CloneNotSupportedException {
- return super.clone();
- }
要进行deep clone操作必须把protected改为 public,并且把返回的object改为具体的Bean对象。
3、执行clone操作。
首先,前提当然是确保事务结束之前session未被关闭,可以使用get实体的操作。
然后看下面例子
- public List<AccAlias> listAccAlias() {
- List<AccAlias> all = AccAliasDAO.findAll();
- if (all != null && !all.isEmpty())
- for (AccAlias accAlias : all) {
- try {
- Mailbox mailbox = accAlias.getMailbox();
- if(mailbox!=null){
- mailbox = mailbox.clone();
- accAlias.setMailbox(mailbox);
- }
- } catch (CloneNotSupportedException e) {
- e.printStackTrace();
- }
- }
- return all;
- }
后续问题研究:
姑且作为一个比较非主流的解决方案吧,是否适合还是要看大家需求的,没有一套方案是绝对适合的。
使用clone解决延迟加载的弊端:
1、clone的实际开销。
2、查询方式的依赖性。必须根据ID查询方式来查询实体。而且更可以认为耦合度提高了,因为业务层clone操作有时必须依赖DAO特定的查询方式。
当然这些弊端也幸好仅仅针对使用到需要解决延迟加载的时候触发。
经验分享,给大家提供多一套解决方案吧。鱼与熊掌,自己衡量使用。