连接池和延迟加载

来源：互联网发布：t口数据线线序编辑：程序博客网时间：2024/05/01 07:39

Hibernate的三种连接池设置 C3P0、Proxool和DBCPssh
以下三种连接都是以连接MySQl为例。

<property name="connection.driver_class">org.gjt.mm.mysql.Driver</property> <property name="connection.url">jdbc:mysql://localhost:3306/struts?useUnicode=true&characterEncoding=GBK</property> 
<property name="connection.username">root</property> 
<property name="connection.password">8888</property>

上面的一段配置，在c3p0和dbcp中，都是必需的，因为hibernate会根据上述的配置来生成connections，再交给c3p0或dbcp管理.但是，proxool则不能，虽然说服文档上说proxool也可以和hibernate结合,但我按照官方文档上的说明怎么配也出错，而且，到了 sun和hibernat有的官方网站上问了几天，都没有一个人回复。后来我只能让proxool自身来生成连接，这在下面再讲。

1 C3P0

只需在hibernate.cfg.xml中加入
<property name="c3p0.min_size">5</property>
<property name="c3p0.max_size">30</property>
<property name="c3p0.time_out">1800</property>
<property name="c3p0.max_statement">50</property>

还有在classespath中加入c3p0-0.8.4.5.jar

2 dbcp

在hibernate.cfg.xml中加入

还有在classespath 中加入commons-pool-1.2.jar 和commons-dbcp-1.2.1.jar.

3 proxool

在 hibernate.cfg.xml中加入

<property name="proxool.pool_alias">pool1</property>
<property name="proxool.xml">ProxoolConf.xml</property>
<property name="connection.provider_class">net.sf.hibernate.connection.ProxoolConnectionProvider</property>

然后，在和hibernate.cfg.xml同一个目录下，加一个ProxoolConf.xml文件，内容为

<?xml version="1.0" encoding="utf-8"?>

<something-else-entirely>
<proxool>
<alias>pool1</alias>

<driver-url>jdbc:mysql://localhost:3306/struts?useUnicode=true&characterEncoding=GBK</driver-url>
<driver-class>org.gjt.mm.mysql.Driver</driver-class>
<driver-properties>
<property name="user" value="root"/>
<property name="password" value="8888"/>
</driver-properties>

<house-keeping-sleep-time>90000</house-keeping-sleep-time>

<maximum-new-connections>20</maximum-new-connections>

<prototype-count>5</prototype-count>

<maximum-connection-count>100</maximum-connection-count>

<minimum-connection-count>10</minimum-connection-count>
</proxool>
</something-else-entirely>

并在classespath中加入proxool-0.8.3.jar

结论：

由于在 hibernate3.0中，已经不再支持dbcp了，hibernate的作者在hibernate.org中，明确指出在实践中发现dbcp有 BUG,在某些种情会产生很多空连接不能释放，所以抛弃了对dbcp的支持。我不知是否在dbcp最新版本中解决了这个问题，我以前在一个访问量不大的项目中用过dbcp，运行了一年多都没出现问题。不过在网上的确也有不少网友指出dbcp在大型的应用中会出现不稳定的情况。所以在真相未经证实的情况下，我觉得对dbcp持慎重的态度。

至于c3p0，有评论说它的算法不是最优的，而且，我在matrix中，见到有网友做了一个实验，在同一项目中分别用了几个常用的连接池，然后测试其性能，发现c3p0占用资源比较大，效率也不高。

所以，基于上述原因，我才花两晚的时间去研究proxool的配置，proxool不少行家推荐使用，而且暂时来说，是负面评价是最少的一个。在三星中也有项目是用proxool的。

欢迎大家就连接池的问题多研究，多多发表自己的经验心得。

---------------------------------------------------

全面讲解Hibernate二级缓存ssh
在向大家详细介绍Hibernate二级缓存之前，首先让大家了解下一级缓存，然后全面介绍Hibernate二级缓存。

Hibernate中提供了两级Cache，第一级别的缓存是Session级别的缓存，它是属于事务范围的缓存。这一级别的缓存由 hibernate管理的，一般情况下无需进行干预；第二级别的缓存是SessionFactory级别的缓存，它是属于进程范围或群集范围的缓存。这一级别的缓存可以进行配置和更改，并且可以动态加载和卸载。 Hibernate还为查询结果提供了一个查询缓存，它依赖于第二级缓存。

一. 一级缓存和二级缓存的比较：

第一级缓存第二级缓存存放数据的形式相互关联的持久化对象对象的散装数据缓存的范围事务范围，每个事务都有单独的第一级缓存进程范围或集群范围，缓存被同一个进程或集群范围内的所有事务共享并发访问策略由于每个事务都拥有单独的第一级缓存，不会出现并发问题，无需提供并发访问策略由于多个事务会同时访问第二级缓存中相同数据，因此必须提供适当的并发访问策略，来保证特定的事务隔离级别数据过期策略没有提供数据过期策略。处于一级缓存中的对象永远不会过期，除非应用程序显式清空缓存或者清除特定的对象必须提供数据过期策略，如基于内存的缓存中的对象的最大数目，允许对象处于缓存中的最长时间，以及允许对象处于缓存中的最长空闲时间物理存储介质内存内存和硬盘。对象的散装数据首先存放在基于内存的缓存中，当内存中对象的数目达到数据过期策略中指定上限时，就会把其余的对象写入基于硬盘的缓存中。缓存的软件实现在Hibernate 的Session的实现中包含了缓存的实现由第三方提供，Hibernate仅提供了缓存适配器(CacheProvider)。用于把特定的缓存插件集成到Hibernate中。启用缓存的方式只要应用程序通过Session接口来执行保存、更新、删除、加载和查询数据库数据的操作，Hibernate 就会启用第一级缓存，把数据库中的数据以对象的形式拷贝到缓存中，对于批量更新和批量删除操作，如果不希望启用第一级缓存，可以绕过Hibernate API，直接通过JDBC　API来执行指操作。用户可以在单个类或类的单个集合的粒度上配置第二级缓存。如果类的实例被经常读但很少被修改，就可以考虑使用第二级缓存。只有为某个类或集合配置了第二级缓存，Hibernate在运行时才会把它的实例加入到第二级缓存中。用户管理缓存的方式第一级缓存的物理介质为内存，由于内存容量有限，必须通过恰当的检索策略和检索方式来限制加载对象的数目。Session的 evit()方法可以显式清空缓存中特定对象，但这种方法不值得推荐。第二级缓存的物理介质可以是内存和硬盘，因此第二级缓存可以存放大量的数据，数据过期策略的maxElementsInMemory属性值可以控制内存中的对象数目。管理第二级缓存主要包括两个方面：选择需要使用第二级缓存的持久类，设置合适的并发访问策略：选择缓存适配器，设置合适的数据过期策略。

二. 一级缓存的管理：

当应用程序调用Session的save()、update()、savaeOrUpdate()、get()或load()，以及调用查询接口的 list()、iterate()或filter()方法时，如果在Session缓存中还不存在相应的对象，Hibernate就会把该对象加入到第一级缓存中。当清理缓存时，Hibernate会根据缓存中对象的状态变化来同步更新数据库。 Session为应用程序提供了两个管理缓存的方法： evict(Object obj)：从缓存中清除参数指定的持久化对象。 clear()：清空缓存中所有持久化对象。

三. Hibernate二级缓存的管理：

1. Hibernate二级缓存策略的一般过程如下：
1) 条件查询的时候，总是发出一条select * from table_name where …. （选择所有字段）这样的SQL语句查询数据库，一次获得所有的数据对象。
2) 把获得的所有数据对象根据ID放入到第二级缓存中。
3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。
4) 删除、更新、增加数据的时候，同时更新缓存。
Hibernate二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query Cache。

2. 什么样的数据适合存放到第二级缓存中？
1) 很少被修改的数据
2) 不是很重要的数据，允许出现偶尔并发的数据
3) 不会被并发访问的数据
4) 参考数据,指的是供应用参考的常量数据，它的实例数目有限，它的实例会被许多其他类的实例引用，实例极少或者从来不会被修改。

3. 不适合存放到第二级缓存的数据？
1) 经常被修改的数据
2) 财务数据，绝对不允许出现并发
3) 与其他应用共享的数据。

4. 常用的缓存插件 Hibernater二级缓存是一个插件，下面是几种常用的缓存插件：
◆EhCache：可作为进程范围的缓存，存放数据的物理介质可以是内存或硬盘，对Hibernate的查询缓存提供了支持。
◆OSCache：可作为进程范围的缓存，存放数据的物理介质可以是内存或硬盘，提供了丰富的缓存数据过期策略，对Hibernate的查询缓存提供了支持。
◆SwarmCache：可作为群集范围内的缓存，但不支持Hibernate的查询缓存。
◆JBossCache：可作为群集范围内的缓存，支持事务型并发访问策略，对Hibernate的查询缓存提供了支持。

5. 配置Hibernate二级缓存的主要步骤：
1) 选择需要使用二级缓存的持久化类，设置它的命名缓存的并发访问策略。这是最值得认真考虑的步骤。
2) 选择合适的缓存插件，然后编辑该插件的配置文件。

------------------------------------------

Hibernate延迟加载机制ssh
延迟加载：
   延迟加载机制是为了避免一些无谓的性能开销而提出来的，所谓延迟加载就是当在真正需要数据的时候，才真正执行数据加载操作。在Hibernate中提供了对实体对象的延迟加载以及对集合的延迟加载，另外在Hibernate3中还提供了对属性的延迟加载。下面我们就分别介绍这些种类的延迟加载的细节。
A、实体对象的延迟加载：
如果想对实体对象使用延迟加载，必须要在实体的映射配置文件中进行相应的配置，如下所示：
<hibernate-mapping>
<class name=”com.neusoft.entity.User” table=”user” lazy=”true”>
    ……
</class>
</hibernate-mapping>
通过将class的lazy属性设置为 true，来开启实体的延迟加载特性。如果我们运行下面的代码：
User user=(User)session.load(User.class,”1”);（1）
System.out.println(user.getName()); （2）
当运行到(1)处时，Hibernate并没有发起对数据的查询，如果我们此时通过一些调试工具(比如JBuilder2005的Debug工具)，观察此时user对象的内存快照，我们会惊奇的发现，此时返回的可能是User$EnhancerByCGLIB$$bede8986类型的对象，而且其属性为null,这是怎么回事？还记得前面我曾讲过session.load()方法，会返回实体对象的代理类对象，这里所返回的对象类型就是User对象的代理类对象。在Hibernate中通过使用CGLIB,来实现动态构造一个目标对象的代理类对象，并且在代理类对象中包含目标对象的所有属性和方法，而且所有属性均被赋值为null。通过调试器显示的内存快照，我们可以看出此时真正的User对象，是包含在代理对象的CGLIB$CALBACK_0.target属性中，当代码运行到（2）处时，此时调用user.getName()方法，这时通过CGLIB赋予的回调机制，实际上调用CGLIB$CALBACK_0.getName()方法，当调用该方法时，Hibernate会首先检查CGLIB$CALBACK_0.target属性是否为null，如果不为空，则调用目标对象的 getName方法，如果为空，则会发起数据库查询，生成类似这样的SQL语句：select * from user where id=’1’;来查询数据，并构造目标对象，并且将它赋值到CGLIB$CALBACK_0.target属性中。
    这样，通过一个中间代理对象，Hibernate实现了实体的延迟加载，只有当用户真正发起获得实体对象属性的动作时，才真正会发起数据库查询操作。所以实体的延迟加载是用通过中间代理类完成的，所以只有session.load()方法才会利用实体延迟加载，因为只有session.load()方法才会返回实体类的代理类对象。
B、        集合类型的延迟加载：
在 Hibernate的延迟加载机制中，针对集合类型的应用，意义是最为重大的，因为这有可能使性能得到大幅度的提高，为此Hibernate进行了大量的努力，其中包括对JDK Collection的独立实现，我们在一对多关联中，定义的用来容纳关联对象的Set集合，并不是java.util.Set类型或其子类型，而是 net.sf.hibernate.collection.Set类型，通过使用自定义集合类的实现，Hibernate实现了集合类型的延迟加载。为了对集合类型使用延迟加载，我们必须如下配置我们的实体类的关于关联的部分：
<hibernate-mapping>
    <class name=”com.neusoft.entity.User” table=”user”>
…..
<set name=”addresses” table=”address” lazy=”true” inverse=”true”>
<key column=”user_id”/>
<one-to-many class=”com.neusoft.entity.Arrderss”/>
</set>
    </class>
</hibernate-mapping>
通过将<set>元素的lazy属性设置为true来开启集合类型的延迟加载特性。我们看下面的代码：
User user=(User)session.load(User.class,”1”);
Collection addset=user.getAddresses();       (1)
Iterator it=addset.iterator();                (2)
while(it.hasNext()){
Address address=(Address)it.next();
System.out.println(address.getAddress());
}
当程序执行到(1)处时，这时并不会发起对关联数据的查询来加载关联数据，只有运行到(2)处时，真正的数据读取操作才会开始，这时Hibernate会根据缓存中符合条件的数据索引，来查找符合条件的实体对象。
这里我们引入了一个全新的概念——数据索引，下面我们首先将接一下什么是数据索引。在 Hibernate中对集合类型进行缓存时，是分两部分进行缓存的，首先缓存集合中所有实体的id列表，然后缓存实体对象，这些实体对象的id列表，就是所谓的数据索引。当查找数据索引时，如果没有找到对应的数据索引，这时就会一条select SQL的执行，获得符合条件的数据，并构造实体对象集合和数据索引，然后返回实体对象的集合，并且将实体对象和数据索引纳入Hibernate的缓存之中。另一方面，如果找到对应的数据索引，则从数据索引中取出id列表，然后根据id在缓存中查找对应的实体，如果找到就从缓存中返回，如果没有找到，在发起select SQL查询。在这里我们看出了另外一个问题，这个问题可能会对性能产生影响，这就是集合类型的缓存策略。如果我们如下配置集合类型：
<hibernate-mapping>
    <class name=”com.neusoft.entity.User” table=”user”>
…..
<set name=”addresses” table=”address” lazy=”true” inverse=”true”>
<cache usage=”read-only”/>
<key column=”user_id”/>
<one-to-many class=”com.neusoft.entity.Arrderss”/>
</set>
    </class>
</hibernate-mapping>
这里我们应用了<cache usage=”read-only”/>配置，如果采用这种策略来配置集合类型，Hibernate将只会对数据索引进行缓存，而不会对集合中的实体对象进行缓存。如上配置我们运行下面的代码：
User user=(User)session.load(User.class,”1”);
Collection addset=user.getAddresses();
Iterator it=addset.iterator();
while(it.hasNext()){
Address address=(Address)it.next();
System.out.println(address.getAddress());
}
System.out.println(“Second query……”);
User user2=(User)session.load(User.class,”1”);
Collection it2=user2.getAddresses();
while(it2.hasNext()){
Address address2=(Address)it2.next();
System.out.println(address2.getAddress());
}
运行这段代码，会得到类似下面的输出：
Select * from user where id=’1’;
Select * from address where user_id=’1’;
Tianjin
Dalian
Second query……
Select * from address where id=’1’;
Select * from address where id=’2’;
Tianjin
Dalian
我们看到，当第二次执行查询时，执行了两条对address表的查询操作，为什么会这样？这是因为当第一次加载实体后，根据集合类型缓存策略的配置，只对集合数据索引进行了缓存，而并没有对集合中的实体对象进行缓存，所以在第二次再次加载实体时，Hibernate找到了对应实体的数据索引，但是根据数据索引，却无法在缓存中找到对应的实体，所以Hibernate根据找到的数据索引发起了两条select SQL的查询操作，这里造成了对性能的浪费，怎样才能避免这种情况呢？我们必须对集合类型中的实体也指定缓存策略，所以我们要如下对集合类型进行配置：
<hibernate-mapping>
    <class name=”com.neusoft.entity.User” table=”user”>
…..
<set name=”addresses” table=”address” lazy=”true” inverse=”true”>
<cache usage=”read-write”/>
<key column=”user_id”/>
<one-to-many class=”com.neusoft.entity.Arrderss”/>
</set>
    </class>
</hibernate-mapping>
此时Hibernate会对集合类型中的实体也进行缓存，如果根据这个配置再次运行上面的代码，将会得到类似如下的输出：
Select * from user where id=’1’;
Select * from address where user_id=’1’;
Tianjin
Dalian
Second query……
Tianjin
Dalian
这时将不会再有根据数据索引进行查询的SQL语句，因为此时可以直接从缓存中获得集合类型中存放的实体对象。
C、       属性延迟加载：
   在Hibernate3中，引入了一种新的特性——属性的延迟加载，这个机制又为获取高性能查询提供了有力的工具。在前面我们讲大数据对象读取时，在 User对象中有一个resume字段，该字段是一个java.sql.Clob类型，包含了用户的简历信息，当我们加载该对象时，我们不得不每一次都要加载这个字段，而不论我们是否真的需要它，而且这种大数据对象的读取本身会带来很大的性能开销。在Hibernate2中，我们只有通过我们前面讲过的面性能的粒度细分，来分解User类，来解决这个问题（请参照那一节的论述），但是在Hibernate3中，我们可以通过属性延迟加载机制，来使我们获得只有当我们真正需要操作这个字段时，才去读取这个字段数据的能力，为此我们必须如下配置我们的实体类：
<hibernate-mapping>
<class name=”com.neusoft.entity.User” table=”user”>
……
<property name=”resume” type=”java.sql.Clob” column=”resume” lazy=”true”/>
    </class>
</hibernate-mapping>
通过对<property>元素的lazy属性设置true来开启属性的延迟加载，在Hibernate3中为了实现属性的延迟加载，使用了类增强器来对实体类的Class文件进行强化处理，通过增强器的增强，将CGLIB的回调机制逻辑，加入实体类，这里我们可以看出属性的延迟加载，还是通过CGLIB来实现的。CGLIB是 Apache的一个开源工程，这个类库可以操纵java类的字节码，根据字节码来动态构造符合要求的类对象。根据上面的配置我们运行下面的代码：
String sql=”from User user where user.name=’zx’ ”;
Query query=session.createQuery(sql);    (1)
List list=query.list();
for(int i=0;i<list.size();i++){
User user=(User)list.get(i);
System.out.println(user.getName());
System.out.println(user.getResume());    (2)
}
当执行到(1)处时，会生成类似如下的 SQL语句：
Select id,age,name from user where name=’zx’;
这时Hibernate会检索User实体中所有非延迟加载属性对应的字段数据，当执行到(2)处时，会生成类似如下的SQL语句：
Select resume from user where id=’1’;
这时会发起对resume字段数据真正的读取操作。

----------------------------------

Hibernate和Spring的延迟加载和 DAO模式ssh

Hibernate和延迟加载
Hibernate对象关系映射提供了两种对象初始化模式：延迟加载和非延迟加载。非延迟加载在加载时获取对象本身以及它关联的所有对象
。这可能导致在获取一个实例时，执行成百上千的select语句。当使用双向关联时，这个问题被放大，常常出现初始化请求时，整个数据
库都被载入。显然检查每个对象的关系，并手工删除他们会费点事，但最终我们可能会因此丢失使用ORM工具的优势。
一个明细的解决方式是使用hibernate提供的延迟载入机制。这种初始化策略在类成员被访问时只载入它的一个对象的一对多和多对多关
系。对开发人员来说，这种方式是透明的，并且只有最少数量的请求发生，这样就获得了最佳的性能。这种技术的一个缺点是延迟载入要
求当对象还在使用中时，Hibernate的Session必须保持打开状态。当尝试通过DAO模式抽象持久层时，这会引起一个重要问题。为了充分
地抽象持久层，所有的数据库逻辑，包括打开、关闭Session都不能在应用层出现。最常见的是，这些逻辑隐藏在DAO的实现类中。快速和
差一些的方案是：避免采用DAO模式，在应用层中包含数据连接的逻辑。这在小应用中是可行的，但在大系统中，这会是一个设计缺陷，
它损害了应用的扩展性。
在Web层使用延迟加载
幸运的是，Spring框架已经提供了一个DAO模式结合Hibernate延迟加载的Web方案。对于任何不熟悉Spring框架结合Hibernate人来说，我
在这里不会深入细节，但是我希望你去阅读“结合Spring框架的Hibernate数据库访问”章节。这个案例是一个Web应用，Spring提供了
OpenSessionInViewerFilter和OpenSessionInViewInterceptor。使用它们中的任一个都能获得同样的功能。这两者唯一不同的是
interceptor在Spring容器中运行，并且在web应用的上下文中配置；fitler在Spring前运行，并且在web.xml 中配置。不管使用哪一个，
他们都会在请求绑定到Session的当前线程期间打开Hibernate Session。一旦绑定到线程，打开的Hibernate Session能被DAO的实现类透
明地使用。Session会持续打开允许延迟加载访问数据库。一旦View逻辑完成，hibernate session会被关闭，无论是在Filter的doFilter
方法中还是在Interceptor的postHandle方法中。下面是一个配置实例：
Interceptor配置
<beans>
<bean id="urlMapping"
     class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
       <property name="interceptors">
         <list>
              <ref bean="openSessionInViewInterceptor"/>
         </list>
       </property>
       <property name="mappings">
...
</bean>
...
<bean name="openSessionInViewInterceptor"
    class="org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor">
       <property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>
</beans>
Filter配置
<web-app>
...
<filter>
    <filter-name>hibernateFilter</filter-name>
    <filter-class>
      org.springframework.orm.hibernate.support.OpenSessionInViewFilter
    </filter-class>
   </filter>
...
<filter-mapping>
    <filter-name>hibernateFilter</filter-name>
     <url-pattern>*.spring</url-pattern>
</filter-mapping>
...
</web-app>
使用打开的session的 HibernateDAO实现类很简单。实际上，如果你已经使用Spring框架实现Hibernate的DAO对象，最有可能的是，你不
需要做任何改动。DAO必须通过方便的HibernateTemplate工具访问Hibernate，这对数据库访问来说就是小菜一碟。下面是一个DAO的实例
。
DAO实例
public class HibernateProductDAO extends HibernateDaoSupport implements ProductDAO {
       public Product getProduct(Integer productId) {
              return (Product)getHibernateTemplate().load(Product.class, productId);
       }
       public Integer saveProduct(Product product) {
              return (Integer) getHibernateTemplate().save(product);
       }
       public void updateProduct(Product product) {
              getHibernateTemplate().update(product);
       }
}
在业务层使用延迟加载
甚至在表现层外，Spring框架也通过AOP拦截器HibernateInterceptor提供了便利的延迟加载支持。hibernate拦截器透明地拦截了配置在
Spring应用上下文中的业务对象的调用，在调用前打开hibernate session，在调用结束时关闭这个session。让我们通过一个简单的例子
来说明。假设我们有一个interface叫做BussinessObject：
public interface BusinessObject {
     public void doSomethingThatInvolvesDaos();
}
类 BusinessObjectImpl实现了BusinessObject接口：
public class BusinessObjectImpl implements BusinessObject {
    public void doSomethingThatInvolvesDaos() {
        // lots of logic that calls
        // DAO classes Which access
        // data objects lazily
    }
}
通过Spring上下文的一些配置，我们可以让HibernateInterceptor拦截对BusinessObjectImpl的调用，允许它的方法延迟访问数据对象。
看一下下面的片断：
<beans>
    <bean id="hibernateInterceptor" class="org.springframework.orm.hibernate.HibernateInterceptor">
         <property name="sessionFactory">
           <ref bean="sessionFactory"/>
         </property>
    </bean>
    <bean id="businessObjectTarget" class="com.acompany.BusinessObjectImpl">
       <property name="someDAO"><ref bean="someDAO"/></property>
    </bean>
    <bean id="businessObject" class="org.springframework.aop.framework.ProxyFactoryBean">
         <property name="target"><ref bean="businessObjectTarget"/></property>
         <property name="proxyInterfaces">
           <value>com.acompany.BusinessObject</value>
         </property>
         <property name="interceptorNames">
           <list>
              <value>hibernateInterceptor</value>
           </list>
         </property>
     </bean>
</beans>
当businessObject的实例被引用，HibernateInterceptor打开一个hibernate session并允许对BussinessObjectImpl的调用。当
BusinessOjbectImpl执行完成，HibernateInterceptor透明的关闭这个session。应用代码并不知道任何持久层逻辑，但它仍然能够使用
延迟加载访问数据对象。
在单元测试中使用延迟加载
最后，我们要在JUnit中测试我们的延迟加载应用。覆盖TestCase类的setUp和tearDown 方法非常容易。我更喜欢将这段代码放在一个简便
的抽象TestCase类中，作为我所有测试的基类。
public abstract class MyLazyTestCase extends TestCase {

        public void setUp() throws Exception {
     super.setUp();
     SessionFactory sessionFactory = (SessionFactory) getBean("sessionFactory");
     Session s = sessionFactory.openSession();
     TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(s));
        }
        protected Object getBean(String beanName) {
            //Code to get objects from Spring application context
        }

        public void tearDown() throws Exception {
     super.tearDown();
     SessionHolder holder = (SessionHolder) TransactionSynchronizationManager.getResource(sessionFactory);
     Session s = holder.getSession();
     s.flush();
     TransactionSynchronizationManager.unbindResource(sessionFactory);
     SessionFactoryUtils.closeSessionIfNecessary(s, sessionFactory);
        }
}