语源科技BlogJava-javaEE参考

spring+hibernate连接泄漏之殇

terryxue — Wed, 07 Nov 2012 08:32:00 GMT

数据库连接泄漏是件可怕的事情，可能直接导致系统停止响应，另外因事务管理错误而导致数据出现不一致也是件可怕的事情，在后台系统中，这两个问题经常会结伴出现，本文将通过案例详解使用Spring+Hibernate时可能导致问题的几种情况，希望对大家有所帮助。

文章比较长，如果你是遇到了问题正急求解决方案的话，可以先只读这一条：检查你的dao是否有直接使用session，修改为使用hibernateTemplate。
如果你希望更多的了解session, hibernateTemplate, transaction，请继续。

以下案例基于Struts2.3.1+Spring3.1.1+hibernate3.5.4完成，案例场景为对系统参数进行管理，涉及如下四个类：

Action	PropertyAction
Service	PropertyService/PropertyServiceImpl
DAO	PropertyDAO（继承HibernateDaoSupport）
Entity	SysProperty

1. Action中直接调用dao，未使用getHibernateTemplate
在一个复杂的多层架构系统中，事务控制在service中完成是更合理的，不应交由view层来控制，本文假定你是这么做的。一般我们代码的处理顺序为action->service->dao，然而总会有人会打破这种逻辑，打破可以，但要注意如下问题。
假定Action中有如下代码：

1 @Autowired
2 private PropertyDAO propertyDAO;
3 @Override
4 public String execute() throws Exception {
5 model = propertyDAO.get(1L);
6 return null;
7 }

这里action直接访问了dao中的get方法，因事务配置在service层，因此这里是没有事务控制的。
接下来我们看dao中的get方法，假定你的定义如下：

1 public SysProperty get(Long id) {
2 return (SysProperty) getSession().get(SysProperty.class, id);
3 }

代码很简单，getSession是父类HibernateDaoSupport中提供的方法，这里直接通过实体Id get得到结果。
接下来发布一下系统，访问页面，好像一切OK，但是，再刷新几下看看，可能你的连接池配置的比较大，要刷新多次，最后你发会现你的系统停止了响应。更直接点，调用你采用的连接池中的相关API检测下当前连接占用情况，你会发现刷新一次，被占用连接增加一个，可怕的事情发生了。
小结：在无事务管理器控制的情况下，通过getSession()打开的session不会被关闭，这个session所占用的数据库连接也不会被释放。

接下来，来点更可怕的，假设你的action中是这样的：

1 private List<Long> ids;
2 @Override
3 public String execute() throws Exception {
4   for(Long id: ids) {
5     results.add(propertyDAO.get(id));
6   }
7   return null;
8 }
9

这时尝试一次传入多个id进行请求，请求结束后检查下连接数，你发现传入多少ID，就有多少连接被占用，也就是说每一次对dao的get调用都会占用一个不可释放的连接。
小结：如果没有配置事务管理器且直接使用getSession得到session，每次getSession都会创建一个新的session，每个session占用一个新的数据库连接，session无线程级别的共享。

2. Action中直接调用dao，使用getHibernateTemplate

当然，你可能没遇到过前面的情况，因为你会在DAO中这样写代码：

1 public SysProperty get(Long id) {
2 return getHibernateTemplate().get(getEntityClass(), id);
3 }

那么是否就一切OK呢？如果只是想解决连接泄漏这个问题的话，答案是Yes，尝试多次请求，检查下你的连接池状况，没有连接泄漏的情况出现。所以简单而可靠的办法就是不再直接使用getSession，而是使用getHibernateTemplate进行相应操作，当需要使用session时，可以用下面的方法：

getHibernateTemplate().execute(new HibernateCallback<T>() {
  public T doInHibernate(Session session) throws HibernateException {
    Query queryObject = session.createQuery(hql);
    //....
  }
});

But...如果你的系统真的出现了连接泄漏，可能你需要关注更多。
还是前面Action中根据ID循环查询的操作，在这个案例中，每一次Dao的get方法都将重复这样的逻辑：创建session，分配session一个连接，关闭session，释放session占用的连接，也就是说session不会在线程级别共享。让我们继续，进入第三种情况来进一步说明。

3. Service未合理配置事务管理器
绝大部分情况下我们会给service配置事务管理器，可能是通过xml或是@Transactional注解，但并非配置了就OK了。看下面的例子：

@Transactional

public class PropertyServiceImpl implements PropertyService {
    @Autowired
    private PropertyDAO propertyDAO;

    @PostConstruct
    public void init(){
        propertyDAO.get(1L);
    }
    //
}

当然，假定你的DAO还是写成了这样：

public SysProperty get(Long id) {
return (SysProperty) getSession().get(SysProperty.class, id);
}

你期望在service初始化好后做一些数据库操作，你也给service配置了事务管理器，接下来你启动应用，然后检查连接池中的连接数，你会发现有连接未被释放！可能你会果断的修改dao中的方法：

public SysProperty get(Long id) {
return getHibernateTemplate().get(getEntityClass(), id);
}

然后你会理所当然的认为，即使配置了事务管理器，依然不能使用getSession()，事实可能并非如此。
我们调整一下代码，不在init中调用dao中的get方法，改为如下：

public SysProperty getProperty(Long id) {
return propertyDAO.get(id);
}

然后DAO继续使用(SysProperty) getSession().get(SysProperty.class, id)，而action中的调用修改为：

@Autowired
private PropertyService propertyService;
@Override
public String execute() throws Exception {
model = propertyService.getProperty(1L);
return null;
}

重新发布，调用，检查连接数，发现无被占用连接存在。
小结：如果正确配置了事务管理器，getSession是安全的。

这时要清楚spring是通过AOP来实现事务控制的，而@PostConstruct方法不会受AOP控制，因此上面的init方法等于无事务管理器。
那么再回头来说，是否只要dao中使用getHibernateTemplate就不会有问题呢？
假定service中的@PostConstruct方法如下：

@PostConstruct
public void init(){
    SysProperty p = new SysProperty();
    p.setName("test_property_1");
    propertyDAO.save(p);
}

强调一下，前面已经提到这个方法不受spring的事务管理器控制。
假定DAO中的save方法如下：

public void save(SysProperty o){
getSession().save(o);
}

启动一下应用，检查一下连接数，再检查一下数据是否有存储到数据库中。因为我们直接使用了getSession，因此连接不会释放，这点前面已经提到，但同时我们还将发现数据没有被存储，当然这个也好理解，因为上面已经提到这个方法未配置事务管理器。
小结：通过getSession().save()保存数据时，事务不会自动提交。

现在再修改下DAO中的save方法：

public void save(SysProperty o){
getHibernateTemplate().save(o);
}

启动一下应用，检查一下连接数，再检查一下数据是否有存储到数据库中。因为我们使用hibernateTemplate，因此连接有释放，这点前面已经提到，但同时我们还发现数据也已存储到数据库中，说明hibernateTemplate会自动提交事务。
小结：如果未配置事务管理器，通过hibernateTemplate操作时，会自动创建并提交事务。

所以如果你觉得使用hibernateTemplate就OK了，那就要小心下面的代码了：

@PostConstruct
public void init(){
  //1. 从你的账号A中扣除一万块
  //2. 这里的代码抛出了异常
  //3. 将你的账号B中增加一万块
}

如果上面的第2步出现了异常，那么因为1的事务已经提交，而3却没有执行，最终导致了数据的不一致，后果和连接泄漏一样严重！
除了@PostConstruct，还有其它原因会导致@Transactional无效，假定我们的service配置了事务管理器，但存在如下代码：

pubic void someServiceMethod(){
  new Thread(){
    public void run(){
        doSomethingLater();
    }
  }
}

public void doSomethingLater(){
  //做一系列数据库操作
}

那么你可以去验证下doSomethingLater是否受事务管理器控制，事实上并不会，所以你需要理解spring AOP的机制，否则一个小坑会酿成灾难。
这里还有一种情况，你不是在类上面配置@Transactional，而是在方法上面配置，假定存在如下的代码：

//该方法不需要事务控制
public void method1(){
method2();
}

//下面的方法需要事务控制
@Transactional
public void method2(){
//do something
}

因为你需要给不同的方法配置不同的事务机制，因此你没有在类上面进行配置，然后你在客户端进行了如下调用：service.method1(); method2中的方法会受事务管理吗？可悲的是并不会。
上面讲到的线程调用和内部方法调用可以这样来处理：

@Autowired
private ApplicationContext context;
public void method1(){
    PropertyService service = context.getBean(PropertyService.class);
    service.method2();
}

小结：注意spring的AOP机制

4. Service合理配置事务管理器

最后补充一下，如果事务管理器配置正确的话会发生什么。这时不管你是用getSession还是getHibernateTemplate，结果都是一样，session将在thread级别共享，session只有一个。

总结：难得这周开始工作变得清闲，上班时间还能写写博客，想想前段日子真是自己何苦为难自己。回到话题，使用getSession没什么大错，因为你本应正确配置事务管理器。使用hibernateTemplate能解决所有连接泄漏的问题，但要小心他可能隐藏的事务问题。另外就是spring中内部方法调用时AOP的问题，创建新线程时的事务问题。最后希望这篇有点绕的文章能给你带来帮助。

terryxue 2012-11-07 16:32 发表评论

eclipse+JUnit测试Seam

terryxue — Fri, 29 Apr 2011 09:04:00 GMT

折腾了一天，junit终于可以跑起来了，分享一下，希望对大家能有帮助。
项目基于Maven搭建（Maven确实是个好东西）。使用的技术有jsf + richfaces3.3 + seam2.2 + hibernate3.3 + jasperreport3.7。感觉seam很强大，但没有spring方便，至少在测试方面要花费一翻功夫。
我没有将测试代码放到项目的测试目录下，而是另起了一个工程，专用于测试，以下就完整的介绍一下这个过程。更多是步骤描述了，为什么要这样做就不多解释了，也没能力解释清楚。
1. 建立测试工程：seamtest。最简单的maven工程即可。这里不介绍如何在eclipse中集成maven，读者可以搜搜m2eclipse，这是一个eclipse插件。

2. 配置seamtest的pom.xml，增加如下三个依赖：

<dependency>
    <groupId>org.jboss.seam.embeddedgroupId>
    <artifactId>hibernate-allartifactId>
    <version>beta3.SP10version>
dependency>
<dependency>
  <groupId>org.jboss.seam.embeddedgroupId>
  <artifactId>jboss-embedded-allartifactId>
  <version>beta3.SP10version>
dependency>
<dependency>
<groupId>org.jboss.seam.embeddedgroupId>
  <artifactId>thirdparty-allartifactId>
  <version>beta3.SP10version>
dependency>

3. 这三个依赖需要从jboss仓库下载，可以访问这个站点：https://repository.jboss.org/nexus/index.html，然后根据上面提供的构件Id进行搜索，或者直接将仓库指向：https://repository.jboss.org/nexus/content/repositories/releases/。如何在settings.xml文件中配置仓库地址不难，google下吧。

4. 将需要测试的项目及junit加到maven依赖中，我的配置为：

<dependency>
  <groupId>cn.terrygroupId>
  <artifactId>target-webartifactId>
  <version>0.0.1-SNAPSHOTversion>
  <type>wartype>
dependency>
<dependency>
  <groupId>junitgroupId>
  <artifactId>junitartifactId>
  <version>4.8.2version>
  <type>jartype>
dependency>

上面的“target-web”就是我要测试的基于maven构建的项目。

5. 保存配置后等待eclipse下载完所有依赖的jar包。

6. 将目标工程加到测试工程的依赖工程中。参考下图：

7. 下载Embedded JBoss，下载地址：http://sourceforge.net/projects/jboss/files/Embedded%20JBoss/Embedded%20JBoss%20Beta%203/。

8. 解压缩下载的压缩后，找到文件夹：bootstrap，除这个文件夹外，其它下载文件在我们这个案例里面都不需要用到。

9. 将bootstrap文件夹链接到测试工程的source下面，参考如下操作界面：

10. 将target-web的webapp目录链接到测试工程的source下面，这一步比较奇怪，不多解释了，照着做就行了。

11. 配置DataSource。在bootstrap/deploy下面有文件hsqldb-ds.xml，注意文件名的结尾部分是“-ds.xml”，你可以按这个命名规则建立自己需要的datasource文件，如oracle-ds.xml。datasource文件具体怎么写，就要参考hsqldb-ds.xml了，这个还是比较容易的。如果你的项目不需要dataSource的话就跳过这一步吧。

12. 接下来开始写测试代码了，如下二个类直接复制过去用：
MySeamTestBase: 其它测试类可以直接继承该类

package cn.terry.test;

import java.util.Properties;

import org.jboss.seam.mock.AbstractSeamTest;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

public class MySeamTestBase extends AbstractSeamTest {
    // static helper instance to call non static methods in
    // a static method
    private static MySeamTestBase seamTest = new MySeamTestBase();
    private static boolean batch = false;

    /*
     * JUnit test life cycle methods.
     */

    @BeforeClass
    public static void setUpBeforeClass() throws Exception {
        if (!batch) {
            seamTest.startContainer();
        }
    }

    @AfterClass
    public static void tearDownAfterClass() throws Exception {
        if (!batch)
            seamTest.stopContainer();
    }

    @Before
    public void setUp() throws Exception {
        setupClass();
        begin();
    }

    @After
    public void tearDown() throws Exception {
        end();
        cleanupClass();
    }

    /*
     * Helper methods
     */

    // starts the JBoss embedded ejb container
    public void startContainer() throws Exception {
        super.startSeam();
    }

    // stops the JBoss embedded ejb container
    public void stopContainer() throws Exception {
        super.stopSeam();
    }

    public boolean isBatch() {
        return batch;
    }

    // used by a JUnit.Suite runner to set the batch flag
    public void setBatch(boolean fBatch) {
        batch = fBatch;
    }
}

MySuiteRunner, 批量执行多个测试类：

package cn.terry.test;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;

import cn.terry.test.testcase.HelloTest;

@Suite.SuiteClasses({
    HelloTest.class
})
@RunWith(Suite.class)
public class MySuiteRunner {
    private static MySeamTestBase seamTest = new MySeamTestBase();

    @BeforeClass
    public static  void setUpBeforeClass() throws Exception {
        // set the flag to signal batch mode
        seamTest.setBatch(true);
        seamTest.startContainer();
    }

    @AfterClass
    public static void tearDownAfterClass() throws Exception {
        seamTest.stopContainer();
        seamTest.setBatch(false);
    }
}

下面的HelloTest是一个具体的测试类，模仿着写就行了：

package cn.terry.test.testcase;

import org.junit.Test;

import cn.terry.test.MySeamTestBase;

public class HelloTest extends MySeamTestBase {
    @Test
    public void testRollback() throws Exception{
        new FacesRequest() {
            protected void invokeApplication() throws Exception {
                Object seamInstance = getInstance("instanceName");
            }
        }.run();
    }

}

FacesRequest里面还有许多方法可以重写，自己翻翻手册吧。

13. 到执行这一步了，也不容易，如果是jdk6的话，要在运行时加上运行参数：-Dsun.lang.ClassLoader.allowArraySyntax=true。eclipse中如何配置请参考如下界面：

点击run，享受成果吧。

14，可能没有这么幸运，数据库连接池可能没有初始化。在我们的项目中，连接池是在一个servlet listener中初始化的，通过如上方式运行就没法自动初始化，导致测试时出现数据库连接失败的情况，这时候需要自己写些代码去初始化连接了。

总结：整个过程可能会出现没完没了的异常，别放弃，多google，总会成功的。

terryxue 2011-04-29 17:04 发表评论

glassfishv2中ejb的定义与调用

terryxue — Sat, 06 Mar 2010 13:08:00 GMT

摘要: glassfish中ejb的定义与调用，包括远程调用，本地调用，在web应用中的调用，在javaSE中的调用。阅读全文

terryxue 2010-03-06 21:08 发表评论

js压缩工具

terryxue — Fri, 18 Dec 2009 02:19:00 GMT

摘要: 当客户端代码越来越多时，我们面临着js文件过大的问题，另外你可能也不想将你公司的js代码直接暴露给最终用户，压缩混淆这时变得非常有必要。 yahoo提供了yuicompressor，这是一个非常不错的工具，但还不够好用，我在这个工具的基础上做了些改进，提供了gui界面和基于xml配置文件的批处理压缩功能，这个工具给我的开发工作带来了很大的便利，相信对大家一样会有帮助。阅读全文

terryxue 2009-12-18 10:19 发表评论