使用clone解决hibernate+spring集成中的延迟加载问题及分析(no session or session was closed)

 

使用clone解决hibernate+spring集成中的延迟加载问题及分析(no session or session was closed)

分类： Spring Hibernate 2009-03-01 20:46 1920人阅读 评论(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方法默认为

@Override
protected Object clone() throws CloneNotSupportedException {
    return super.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;
}

    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特定的查询方式。

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

经验分享，给大家提供多一套解决方案吧。鱼与熊掌，自己衡量使用。