Weblogic中因为IP变更导致SubCoordinator not available，Transaction Rollba

Weblogic中因为IP变更导致SubCoordinator not available，Transaction Rollba2010-12-26 BlogJava 走走停停又三年Weblogic中因为IP变更导致SubCoordinator not available，Transaction RollbackException问题调查

这几天在做一些Transaction方面的研究，碰到一个诡异的问题。问题大概是这样的，之前我的测试一直在公司做，今天把工作带到家里了，结果因为如下问题，导致我没法工作了。

weblogic.transaction.RollbackException: SubCoordinator "server_2+10.182.216.189:7021+driver_test_domain+t3+" not available
at weblogic.rjvm.ResponseImpl.unmarshalReturn（ResponseImpl.java:215）
at weblogic.rmi.internal.BasicRemoteRef.invoke（BasicRemoteRef.java:224）
at weblogic.transaction.internal.CoordinatorImpl_923_WLStub.commit（Unknown Source）
at weblogic.transaction.internal.TransactionImpl.commit（TransactionImpl.java:324）
at weblogic.transaction.internal.TransactionManagerImpl.commit（TransactionManagerImpl.java:283）
at weblogic.transaction.internal.TransactionManagerImpl.commit（TransactionManagerImpl.java:277）
at test.jdbc.DriverTest.xaTest（DriverTest.java:293）
at test.jdbc.DriverTest.main（DriverTest.java:49）
Caused by: weblogic.transaction.RollbackException: SubCoordinator "server_2+10.182.216.189:7021+driver_test_domain+t3+" not available
at weblogic.transaction.internal.TransactionImpl.throwRollbackException（TransactionImpl.java:1809）
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit（ServerTransactionImpl.java:331）
at weblogic.transaction.internal.ServerTransactionImpl.commit（ServerTransactionImpl.java:227）
at weblogic.transaction.internal.CoordinatorImpl.commit（CoordinatorImpl.java:101）
at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke（Unknown Source）
at weblogic.rmi.internal.BasicServerRef.invoke（BasicServerRef.java:553）
at weblogic.rmi.internal.BasicServerRef$1.run（BasicServerRef.java:443）
at weblogic.security.acl.internal.AuthenticatedSubject.doAs（AuthenticatedSubject.java:363）
at weblogic.security.service.SecurityManager.runAs（SecurityManager.java:147）
at weblogic.rmi.internal.BasicServerRef.handleRequest（BasicServerRef.java:439）
at weblogic.rmi.internal.BasicServerRef.access$300（BasicServerRef.java:61）
at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run（BasicServerRef.java:983）
at weblogic.work.ExecuteThread.execute（ExecuteThread.java:209）
at weblogic.work.ExecuteThread.run（ExecuteThread.java:181）

初看到这个异常，家里做测试，Tx的subcoordinator怎么会用到公司的IP（10.182.216.189）呐？怎么着也应该是 192.168.0.51吧？第一感觉是我的datasource配置有问题，仔细检查了一下，没什么问题。再检查检查server2的listen address，也没有问题。见鬼了，怎么会这样？还有什么地方能跟IP有关系呢？tlog？没错，的确好像跟tlog有关系，当时想直接把tlog删掉，重起一下算了。毕竟自己最近在做JTA的调查，干脆自己彻底debug一下算了。

重新启动客户端测试程序，debug一下客户端transaction信息。顺便提一下，weblogic中transaction在 client、server之间是通过PropagationContext来回传递的，一次RMI调用，会导致一次传递来回。 PropagationConext中一般包括如下信息：

Xid: 事务ID

CoordinatorURL: 事务主coordinator的URL（最终事务提交在对应的server上完成）

scURLs: subcoordinator url列表，每个involve到该tx中的server url都在其中。coordinator通过这个url通知每个subcoordinator完成事务的提交、回滚。

resNames: involve到该tx中所以resource的名字列表

......

从异常上来看，这个问题跟subCoordinator有关，所以在客户端，我只debug了scURLs，如下，

从debug信息来看，server2的scURL应该是没有问题的。回头再看看这个异常，因为异常是在客户端发起提交请求的时候，server端抛出的，问题是，我传递过去的是个正确的scURL（192.168.0.51），server端怎么会解析出一个错误的 url（10.182.216.189）呢？

继续debug server端，server端收到coordinatorImpl_stub的commit（）时，它需要先从PropagationContext中 restore transaction信息，包括根据scURLs还原scInfoList, 根据resNames还原resourceInfoList。问题出在了还原scInfoList的时候。如下：

1       if （scURLs ！= null） {
2             for （int i = 0; i < scURLs.length; i++） {
3                 String scURL = scURLs[i];
4                 if （tm.isLocalCoordinator（scURL）） continue;
5                 SCInfo sci = tx.getOrCreateSCInfo（scURL）;
6                 sci.setState（scStates[i]）;
7                 if （scSyncRegs[i] == 1） sci.setSyncRegistered（true）;
8             }
9       }