关于用 ThreadLocal 管理 Connection 的一些总结

    随着Hibernate3的流行，使用ThreadLocal管理事务的方式已然深入人心，在Hibernate3的项目里，如果不需要实现跨数据库的事务，使用Thread管理事务的效率比JTA这个庞然大物高很多，自然地成为了大家的首选。当然，既然ThreadLocal是JDK的一个基本实现（从JDK1.2起），它当然不独为Hibernate所有，即使我们只使用最基本的JDBC Connection，使用ThreadLocal Pattern也会给我们的系统设计带来许多好处。

    所谓用Thread管理事务，就是始终保证当前线程只有一个在使用中的Connection（或Hibernate Session，以下如无特别说明，关于Connection的表述都可套用在Session上），而且只要有需要，我们总有办法拿到与当前线程绑定了的唯一的Connection，比如：

public class AppService {
    ...

    public void updateDataService() {
        Connection conn = MyTransactionManager.getCurrentConn();
        MyTransactionManager.beginTransaction();

        new DAO1().update1stBatch();
        new DAO3().update3rdBatch();

        MyTransactionManager.commitTransaction();
        MyTransactionManager.closeConn(conn);
    }

    ...
}

public class DAO1 {
    ...

    public void update1stBatch() {
        Connection conn = MyTransactionManager.getCurrentConn();
        ...
        new DAO2().update2ndBatch();
    }
}

public class DAO2 {
    ...

    public void update2ndBatch() {
        Connection conn = MyTransactionManager.getCurrentConn();
        ...
    }
}

public class DAO3 {
    ...

    public void update3rdBatch() {
        Connection conn = MyTransactionManager.getCurrentConn();
        ...
    }
}

    在上面代码中，我们从AppService里的方法的开头取得一个当前线程的connection并开启它的事务，并在方法的末尾提交这个事务（异常处理及回滚已省略）。设计的期望是，在这个方法里所有执行的DAO们的方法的数据库操作都应该处于该事务的管理之下。问题是每个dao的方法都需要首先拿到一个Connection才能工作，如果这个Connection不是service方法开头提到的那个，那么它就不能被纳入我们所开启的事务里了。

让每个dao方法取得的Connection都与service方法里提到的Connection保持同一，是靠ThreadLocal来保证的。getCurrentConn()方法调用ThreadLocal变量的相关操作，获取当前执行线程中唯一的Connection对象，因此只要你的Connection是用getCurrentConn()方法获取的，那么每次拿到的都是那个家伙，dao嵌套也好（如dao2），绝不会错。

至于ThreadLocal Pattern具体如何实现，网上有大把文章可读，我在这里想提的是一个比较容易出错的地方。一般说来，系统设计如果使用service层，那么该层的每一个方法都应该代表了一个执行线程的开始和结束，至少对于ThreadLocal变量来说是这样，也就是说，service层的方法应该在最开始创建ThreadLocal变量，并在结束前销毁它。这里的问题是，应用服务器（如JBoss）如何判定一个线程的终结的。我遇到的问题是，如果使用AJAX的HttpRequest发出请求，后台service层执行相关的方法，再把结果返回给AJAX的回调函数，那么应用服务器是会把该线程终结的，这样每次service方法执行前，都会新建一个ThreadLocal 的Connection对象并一直使用它直到service方法结束。但是在JSP下面就完全不同，如果你在浏览器里连续两次进入同一个jsp，线程就不会因为在两次jsp访问之间被销毁一次，也因此ThreadLocal变量（Connection）也就不能被自然销毁。

当ThreadLocal变量（Connection）不能随着线程自然销毁，其问题是显而易见的，比如下面的代码：

public class AppService {
    ...

    public void updateDataService() {
        //获取单例类的实例
        MyTransactionManager transMgr = transMgr.getInstance();
        
        Connection conn = transMgr.getCurrentConn();
        transMgr.beginTransaction();

        new DAO1().update1stBatch();
        new DAO3().update3rdBatch();

        transMgr.commitTransaction();
        transMgr.closeConn(conn);
    }

    ...
}

//这是一个单例类
public class MyTransactionManager {
    //具体的ThreadLocal实现子类，用泛型指定管理对象是java.sql.Connection类
    private ConnectionThreadLocal currentConnManager;
    
    public MyTransactionManager getInstance() {...}

    public Connection getCurrentConn() {
        Connection curConn = currentConnManager.get();
        if (curConn == null) {
            curConn = openConn();
            //不必须但推荐，如ThreadLocal对象总能随着线程自然销毁就可以不用
            currentConnManager.set(curConn);
        }
        return curConn;
    }

    public Connection openNewConn() {...}

    public void closeConn(Connection conn) {
        try {
	    if (conn != null) {
		conn.close();
		conn = null;
                //不必须但推荐，如ThreadLocal对象总能随着线程自然销毁就可以不用
                currentConnManager.set(null);
	    }
	} catch (SQLException e) {
	    e.printStackTrace();
	}
    }
}

    上面的代码演示了，如果每次ThreadLocal变量总是能在正确的时候自然销毁，那么closeConn()里的currentConnManager.set(null)是可以省略的，有趣的是，此时可以连getCurrentConn()里的currentConnManager.set(curConn)也可以省略，道理如下（不想看可以跳过）：
Connection curConn = currentConnManager.get()已经让curConn成为了ThreadLocal管理器（currentConnManager)中的成员的引用，如果此时还没有打开任何ThreadLocal的Connection，那么它引用的值为null，下面执行conn = openNewConn()之后，curConn也就是currentConnManager的成员就取得了一个具体对象的引用了，这跟set(curConn)的效果是一样的。
    如果ThreadLocal变量不能自然销毁，而closeConn()里面又没有执行set(null)，那么ThreadLocal变量仍将持有该Connection的引用，尽管它已经被关闭了（由于是DataSource提供的Connection，这个对象并不是真的被销毁成null了，尽管它已经不能用了，除非用DataSource.getConnection()将它再次激活）。这下问题就来了，如果你在同一线程中连续两次执行了AppService的updateDataService()方法（比如两次访问同一JSP），在第二次updateDataService()的开始，当其试图取得currentConn的时候，它拿到的却是那个已经被DataSource放逐了的、尚未再次激活的Connection。于是，无论接下来你要用这个Connection做什么事都会被服务器拒绝（JBoss下的错误消息：Connection is not associated with a managed Connection...），因为它不是激活状态下的Connection。
    最后，无论你是否看懂了上面的文字表述，按照示例代码中的方式，老老实实地在closeConn()的时候为ThreadLocal变量set(null)（同时getCurrentConn()里的set(conn)也不能省略），那么永远不会有事。