|
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-10-01
随着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)也不能省略），那么永远不会有事。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2009-10-01
感觉你的这个问题和ThreadLocal并没有直接关系！
你这个事业务上设计没有完备，而ThreadLocal是解决多线程间隔离共享资源，你的代码并没有显示出事ThreadLocal的问题！ |
| 返回顶楼 | |
|
发表时间：2009-10-02
danni505 写道 感觉你的这个问题和ThreadLocal并没有直接关系！ 你这个事业务上设计没有完备，而ThreadLocal是解决多线程间隔离共享资源，你的代码并没有显示出事ThreadLocal的问题！ 我并没有说ThreadLocal有什么问题，而是有些时候我们容易使用不当。比如，当每个service方法的一次执行都独占一个活动线程，即使没有set(curConn)也是可用的，但是省略set()方法的潜在危险就是一旦发生两个以上的service方法在同一线程中被执行（也许是因为软件升级），这个bug很可能让你无所适从，由于你潜意识里已经认为set()方法是不必要的，遇到bug的时候也就未必想得起来。 此外，ThreadLocal并不只是用来解决多线程共享资源隔离的，它对事务控制的贡献也不能磨灭，实际上本文正是侧重于后者的。 |
| 返回顶楼 | |
|
发表时间：2009-10-03
danni505 写道 此外，ThreadLocal并不只是用来解决多线程共享资源隔离的，它对事务控制的贡献也不能磨灭，实际上本文正是侧重于后者的。 胡扯，ThreadLocal同事务控制搭什么界？？？ |
| 返回顶楼 | |
|
发表时间：2009-10-03
ThreadLocal事务控制 没关系，而且用ThreadLocal控制事务很不好。
Hibernate3 用ThreadLocal来处理session 是个败笔。 |
| 返回顶楼 | |
|
发表时间：2009-10-04
smilerain 写道 ThreadLocal事务控制 没关系，而且用ThreadLocal控制事务很不好。
Hibernate3 用ThreadLocal来处理session 是个败笔。 请问这位前辈，哪种方式处理事务好？ |
| 返回顶楼 | |
|
发表时间：2009-10-04
最后修改：2009-10-04
ghyghost 写道 smilerain 写道 ThreadLocal事务控制 没关系，而且用ThreadLocal控制事务很不好。
Hibernate3 用ThreadLocal来处理session 是个败笔。 请问这位前辈，哪种方式处理事务好？ 看你的应用场景 1， 如果你只有一个resource 或者resource之间不需要事务协调， 那么直接通过ra使用resource本身提供的事务管理就可以了，这种方式也叫本地事务 2， 如果你有多个resource, 并且resource之间需要事务协调， 那么必须使用2pc协议， 在这种情况下，你必须要拥有一个RM， 并且通过这个RM 来协调各个ra 之间的事务关系。 这种方式也叫分布式事务，也叫全局事务。 没有那种事务方式比较好这种说法， 完全取决于你的应用场景。 THreadLoacal 和 事务没有任何关系， hibernate 将具有本地事务的ra（jdbc connection） 放在 ThreadLoaal中，企图有这种方式在线程级别同步多个ra之间的事务关系， 不符合2pc 协议， 也不能满足分布式事务的要求。具体反映在无法再多个ra上进行事务协调，后面的事务失败了， 前面的已经提交的事务无法回滚。这将导致各个ra所对应的resource上的数据发生不一致，而且事务补偿方式也很难和这种方式集成。所以这个设计只能工作在对单一ra上的多次操作上。但是这种情况通常来说并不需要使用ThreadLocal， 本地事务就可以工作的很好。 至于为什么要用ThreaLocal，通常是解决在分层设计中， 对于 ra 的处理通常比较棘手， 具体表现在跨层操作时候的参数传递上，例如 conn = open connection； dao1.doOpt(conn)； dao2.doOpt(conn); close conn; 1个业务操作需要访问同1个ra但要做多次操作 ，这种情况下， ra的跨层传递就变的棘手。 一种解决方式是，把conn 放在全局变量中， global conn = open connection； dao1.doOpt(); dao2.doOpt(); close conn; 这种方式确实可以解决一些问题， 至少在跨层操作时，避免了和业务无关的参数传递。但全局变量的使用并不是一个好的方式。所有了方式2 tl = new threadLocal(); conn = open connection; tl.put(conn); dao1.doOpt(); dao2.doOpt(); close conn; 这种方式避免了使用全局变量， 同时采用的合适的设计模式再加上一些aop 可以把这段代码在做精简。我想我不用再写下去了。 |
| 返回顶楼 | |
|
发表时间：2009-10-04
最后修改：2009-10-04
是啥意思啊？没看明白。
你明明是在service层控制事务，为什么要说在用ThreadLocal管理事务？你给出的这个代码：
MyTransactionManager transMgr = transMgr.getInstance();
Connection conn = transMgr.getCurrentConn();
transMgr.beginTransaction();
new DAO1().update1stBatch();
new DAO3().update3rdBatch();
transMgr.commitTransaction();
transMgr.closeConn(conn);
怎么管理事务？如果update1stBatch和update3rdBatch出错了，你在哪捕获并回滚呢？ 你用ThreadLocal的原因能说的具体一些么？ 看了mikewang的解答，明白了。真是表达方式上千差万别啊——管理事务... |
| 返回顶楼 | |
|
发表时间：2009-10-06
楼主 你到底是想讲线程还是想讲事务啊
|
| 返回顶楼 | |
|
发表时间：2009-10-09
pipilu 写道 是啥意思啊？没看明白。
你明明是在service层控制事务，为什么要说在用ThreadLocal管理事务？你给出的这个代码：
MyTransactionManager transMgr = transMgr.getInstance();
Connection conn = transMgr.getCurrentConn();
transMgr.beginTransaction();
new DAO1().update1stBatch();
new DAO3().update3rdBatch();
transMgr.commitTransaction();
transMgr.closeConn(conn);
怎么管理事务？如果update1stBatch和update3rdBatch出错了，你在哪捕获并回滚呢？ 你用ThreadLocal的原因能说的具体一些么？ 看了mikewang的解答，明白了。真是表达方式上千差万别啊——管理事务... 请大家不要望文生义，ThreadLocal名字叫“线程本地变量”，但对于其管理的资源而言，不需要考虑线程，因为对它们而言永远只有一个线程，就是当前线程。楼上同学问得好，我讲的只是事务，与线程无关。 对于“管理事务”的表达，我承认有些不妥，或许改用 “用ThreadLocal帮助管理本地事务”更好些？另外，to pipilu： 这段代码我加上try catch不就可以回滚事务了？如下：
MyTransactionManager transMgr = transMgr.getInstance();
Connection conn = transMgr.getCurrentConn();
transMgr.beginTransaction();
try {
new DAO1().update1stBatch();
new DAO3().update3rdBatch();
} catch (Exception e) {
conn.rollback();
e.printStatckTrace();
}
transMgr.commitTransaction();
transMgr.closeConn(conn);
这样，无论是DAO1, DAO3, 甚至DAO2的所有update操作都会回滚。 对于mikewang所说的分布式事务，自有复杂的JTA来解决，ThreadLocal模式只是低端产品线上的一个替代品，它本身也不是因事务而生的，准确地说，它管理的是Connection而不是事务。 |
| 返回顶楼 | |
