作者：peter holditch


发生问题的情形是这样的，有两个ejb组件分布在两台不同的服务器上。当在服务器1上的bean 1在jta交易背景下执行时，调用了服务器2上的bean 1，此时，交易扩展到了服务器2上。而当bean1的方法结束后，交易就被提交。
当交易提交后，事实上交易就被终止了。随之而来的是含义模糊的异常消息：javax.transaction.heuristicmixedexception。由于这种情况多次发生，我想我应该将这篇文章贡献出来，以便告诉大家这是怎么回事。

委婉一点说：在交易的世界里，交易管理器不愿意表现得太消极，如果它们认为已经到了世界末日，那么它们就不再从事多余的工作，因为那样有可能干扰系统管理员。它们只是平静地表示有一个“heuristic outcom”结果产生了。这意味着您精心组织的acid交易由于潜在的数据不一致已经结束了，您最好去检查一下您的数据库。换句话说：世界末日已经到了。

这样解释可能有点不着边际，让我们看看这里究竟发生了什么事情。

调用bean1会启动一个交易，并与控制线程相联系，而且会波及数据库的更新以及类似的操作。调用bean2，将导致请求由服务器1流向服务器2。交易的转移一般伴随着rmi请求。通常，在wls中，服务器到服务器之间的通讯是通过t3协议完成的。利用t3的好处之一就是能够将有关交易请求的信息附加上去。这样，在内部，两个weblogic实例已将交易的相关信息作了交换，它们都能够以单独的身份参与、以及随后提交或者终止交易。

题外话

关于这一点，我们有必要说一点题外的话。最新版本wls 7.0是完全的j2ee 1.3认证版本，除去其它之外，它要求必须支持ejb2.0。这反过来要求应用服务器必须经由rmi/iiop进行互操作。iiop协议和t3很相象，允许诸如活动交易这样的上下文信息与方法调用一起被传送过去。因此，在wls 7.0中，同样的情形也会发生，很可能一个服务器是wls实例，而另一个是其它的应用服务器（尽管我不知道您为什么要这么做－但我偏向于这么想）。让我们回到正题上吧…

到现在为止，我还没有提到有关安全的问题。客户端发起与服务器1的连接请求后，在某处调用initialcontext时需要将用户名和口令传送过去。当bean1的方法被调用时，ejb容器会检查该登录用户是否有执行此方法的权限。同理，服务器2的ejb容器在访问bean2的方法之前会做同样的检查。这意味着安全id会和交易id一起在交易过程中传送，这是t3协议的另外一个能力，而这也刚好是ejb2.0 对容器互操作性的另一个要求－将用户的身份证明通过iiop连接传送给调用csiv2的协议。wls 7.0 也支持这个功能。

交易内容、用户id伴着请求一起从服务器1传送到服务器2，并在那儿执行，直到结果返回。到现在为止，一切都好。现在，bean1返回到客户端，如果交易是容器管理的（container-managed），则容器会调用提交（commit）。这就到了交易协调者（本例为服务器1中的jta子系统的一部分）工作的时候了，它要将交易的准备阶段和提交阶段进行同步。此时，它会发现服务器2也是交易的参与者，因而会发送信息给服务器2要求进行两阶段提交中的准备阶段。恰在此时，问题来了。这个调用无法由客户端代理完成，相反，是由jta子系统发起的。那么，在线路上传送的是哪一个安全id呢？事实上，只能由weblogic的“system”用户代理执行准备阶段的工作。如果任何用户，张三，李四等都可以随机地对交易进行准备或提交，那将是相当严重的安全缺陷，因此，使用系统id避免了这个安全漏洞。我们再看一眼wls 6对安全模式所做的强化工作（这一点在wls 7中已被进一步巩固）。在版本6中，如果两个服务器拥有相同的系统口令，这两个服务器可以相互信任。没有任何信任度会超过系统用户之间的相互信任，因此，要使准备（包括随后的提交）阶段的工作继续进行，两个服务器必须拥有相同的系统口令。

回到新闻组…

作为结论，每当这个问题在新闻组中出现（记住，？？这是我们开始的地方），解决方案就是确保所有参加交易的wls实例都有相同的相同口令。需要提请注意的是，交易可能在不知不觉中就发生了，如，当您向远程jms队列发送一条消息，jms子系统就有可能代理您发起一个交易。记住，下次看见heuristicmixedexception，一定别忘了检查您的系统口令！

参考资料

l weblogic server交易新闻组：

news://newsgroups.bea.com/weblogic.developer.interest.transaction

or

http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=xover&group=weblogic.developer.interest.transaction&utag=.