如果你所说的“6”是指tpcall()failed,tperrno=6的话，就很好解释了。这个错误发生就2种原因：客户端要调用的服务，在服务端不存在，那么一种可能是客户端调用错了，第二种可能是服务端的这个服务存在但是正好死了，导致客户端调用找不到服务。第一种原因很好排查，第二种原因的话，就不太好查了，服务死掉的原因挺多的，有时候是自己down掉了，有时候是处理请求超时，被Tuxedo的管理进程强制杀掉了。
具体的等你把信息贴上来，再帮你分析看看。
对于BEA的中间价产品TUXEDO，常采用C/C++语言编写后台服务程序，广泛应用于电信、金融等领域，因项目的需要，我们经常面临调TUXEDO服务的需求！对于JAVA调TUXEDO服务，有三种方法：一是通过JNI，二是通过WTC，三是通过JOLT！这三种方式各有优劣，简单的描述为：
JNI
优--无需购买License；发布TUXEDO服务无需做额外限制；无需借助于任何J2EE容器
劣--JNI影响系统移植；防止过度JNI带来性能问题
WTC（WEBLOGIC为TUXEDO定制）
优--因定制，存在一套和TUXEDO API相对应的JAVA API；发布TUXEDO服务无需做额外限制；双向调用
劣--需要购买License；依赖于WEBLOGIC容器，不能移植到其它J2EE容器（如WEBSPHERE，JBOSS）
JOLT
优--可用于但不依赖于J2EE容器（如WEBLOGICWEBSPHERE，JBOSS）；提供的API用WTC类似但不同；
劣--需要购买License；发布TUXEDO服务有些额外的要求；不提供集成的 WebLogic Server-Tuxedo 事务的机制
由此可知，第一，在受限于License经济压力或无法要求UXEDO服务方发布服务的情况下，我们可以选择JNI方式调TUXEDO服务；
第二，当需要一般 Java 客户端或其他 Web 服务器应用程序且 WebLogic Server 不是解决方案的一部分时，用户应使用 Jolt（而不使用 WTC）作为解决方案。
对于jolt方式调TUXEDO服务，3个必须的JAR包：jolt.jar、joltjse.jar、joltwls.jar，下面信息也许对您有帮助：
[转贴]不涉及wls的jolt客户端实现
1、如果不使用wls，同样可以使用jolt提供的pool功能，而这又分为两种：一种是基于web容器的servlet jolt
pool，另一种则是普通java客户端的jolt
pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，后者则未提供。
2、如果不使用jolt产品自带的pool，也可以自己实现。套路为：创建Jolt Session >
基于此session构建JoltRemoteService对象并发起tuxedo调用 >释放jolt
session。这里有个要点就是在使用session前需要用session.isAlive()来判断当前session是否可用，因为JSL的-T
参数及防火墙对idle连接的干扰都可能导致已有的session是无效的。
3、创建JoltRemoteSession时一定记得为三个超时属性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）进行
显式的设置。idle超时和tuxedo的JSL
-T属性对应，该设置将保证session.isAlive()返回正确的布尔值。RECV超时则控制client端自发起call至收到tuxedo
return这一过程的预期时常。
5、tuxedo侧在ubb里为相应的service配置了SVCTIMEOUT，所以service执行超时后会收到SIGKILL而被终止，这样一
来，客户端的call会收到TPESVCERR错，对应的异常为bea.jolt.ServiceException。客户端需要对此异常进行处理，此
外，客户端捕获此异常的时间点应当和ulog中该server被kill的时间点对应。
6、在客户端，时不时会发现由于达到RECVTIMEOUT而导致的客户端接收超时。客户的疑问是：当前RECVTIMEOUT设置为25s，而ubb中
相应SVCTIMEOUT设置为10s且scanunit为默认的10s，所以理论上不应发生25s的客户端RECVTIMEOUT超时。庹达人提出了一
种怀疑，即client端请求抵达tuxedo侧时，server出现排队情况，请求未被及时处理，这个排队时长决定了20s以外的时间差。对于此，建议
客户使用MSSQ，并监控pq的情况。
使用XMLink和Jolt实现IBM WebSphere与BEA Tuxedo的互连 第一部分
使用XMLink和Jolt实现IBM WebSphere与BEA Tuxedo的互连 第二部分
下面，我们重点关注下WTC，WebLogic Tuxedo Connector (WTC) 提供了 WebLogic Server 应用程序与
Tuxedo 服务之间的互操作性。WTC 允许 WebLogic Server 客户端调用 Tuxedo 服务，Tuxedo 客户端调用
WebLogic Server Enterprise Java Bean (EJB) 来响应服务请求，两者之间的简单关联关系如下图：
关于WTC的配置原则和最佳实践可参考下面的链接：
配置准则
最佳实践
为方便记，摘录过来：
配置准则
在配置 WebLogic Tuxedo Connector 时请使用以下准则：
最佳实践
以下部分提供了使用 WTC 时的最佳实践：
请参阅“WebLogic Tuxedo Connector 编程人员指南”中的应用程序错误管理。
请参阅“WebLogic Tuxedo Connector 管理指南”中的系统级调试设置。
将 Security 的值设置为 DM_PW。请参阅“WebLogic
Tuxedo Connector 管理指南”中的远程访问点的身份验证。
启用链接级加密并将 min-encrypt-bits 参数设置为
40，将 max-encrypt-bits 设置为 128。请参阅“WebLogic Tuxedo Connector 管理指南”中的链接级加密。
在 WebLogic Server 群集的所有节点上配置 WTC 实例。
每个群集节点中的每个 WTC 实例都必须具有相同的配置。
请参阅“WebLogic Tuxedo Connector 管理指南”中的如何管理群集环境中的
WebLogic Tuxedo Connector。
在配置连接策略时，请使用 ON_STARTUP 和 INCOMING_ONLY。
ON_STARTUP 和 INCOMING_ONLY 总是成对出现。例如，如果使用 ON_STARTUP 配置了
WTC 远程访问点，则必须将远程访问点的 Tuxedo 域配置的 DM_TDOMAIN 部分配置为 INCOMING_ONLY。在此情况下，WTC
总是充当会话发起方。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置访问点之间的连接。
避免使用连接策略 ON_DEMAND。首选连接策略是 ON_STARTUP 和 INCOMING_ONLY。这样会减少因路由ON_DEMAND 的语义而引起的服务请求失败。请参阅“WebLogic
Tuxedo Connector 管理指南”中的配置访问点之间的连接。
在设计应用程序时，请考虑使用以下 WTC 功能：链接级故障转移、服务级故障转移和负载平衡。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置故障转移和故障回复。
请考虑使用 WebLogic Server 群集提供额外的负载平衡和故障转移。要在 WebLogic Server 群集中使用 WTC，请执行下列操作：
如果 WTC 到 Tuxedo 的连接使用了 Internet，则要使用以下安全设置：
应用程序逻辑应该提供机制来管理和解释应用程序中的错误条件。
避免在 TypedFML32 缓冲区内使用嵌入的 TypedFML32 缓冲区。请参阅“WebLogic
Tuxedo Connector 编程人员指南”中的将 FML 用于 WebLogic Tuxedo
Connector。
如果应用程序处理重负载，请考虑配置更多的远程 Tuxedo 访问点并让 WTC 平衡访问点之间的工作负载。请参阅“WebLogic Tuxedo Connector 管理指南”中的配置故障转移和故障回复。
在使用事务应用程序时，尽量让同一事务中涉及的远程服务能够从同一远程访问点访问。请参阅“WebLogic Tuxedo Connector 编程人员指南”中的 WebLogic
Tuxedo Connector JATMI 事务。
从网关调度服务时，可用的客户端线程数可能会限制运行的并发服务数。没有任何 WebLogic Tuxedo Connector 特性可以增加可用线程的数量。在调用服务时请使用合理的线程模型。请参阅“配置
WebLogic Server 环境”中的线程管理和使用工作管理器优化调度的工作。
WebLogic Server 9.2 及更高版本提供了改进的路由算法，这增强了事务性能。具体说就是，当 2 阶段提交 (2PC) 事务中具有不止一项 Tuxedo 服务请求时，性能就会相应提高。如果应用程序仅向
Tuxedo 域执行单个服务请求，则可以通过设置以下 WebLogic Server 命令行参数来禁用此功能：
通过在缓冲区中使用最大数量的对象来调用构造方法 TypedFML32。即使是很难预测最大数量，提供合理的数量也可以提高性能。可以通过将字段的数量乘以
1.33 得到近似的最大数量。
注意：
注意，此性能提示不应用于 TypedFML 缓冲区类型。
例如：
如果在 TypedFML32 缓冲区类型中有 50 个字段，那么最大数量就是
63。调用构造方法 TypedFML32(63, 50) 比 TypedFML32() 执行得更好。
如果在 TypedFML32 缓冲区类型中有 50 个字段，并且每个字段最多可以有
10 个事件，则调用构造方法 TypedFML32(625, 50) 将会有比 TypedFML32() 更好的性能。
当配置 Tuxedo 应用程序（这些应用程序可以作为与 WTC 客户端互操作的服务器）时，请考虑平行问题，这一点可以通过在不同 Tuxedo 计算机上仔细配置不同服务器来实现。
要知道在 Tuxedo 应用程序中可能会存在数据库访问死锁现象。可以通过认真配置 Tuxedo 应用程序来避免死锁现象。
如果正在使用 WTC 负载平衡或服务级故障转移，BEA 建议不要禁用 WTC 事务关系。
针对负载平衡出站请求，为导入服务配置使用不同密钥的多个条目。导入服务将使用复合密钥来确定每个记录的唯一性。复合密钥的构成：服务名称 + 本地访问点 + 远程访问点列表中的主要路由。
下面是一个如何为 service1 在 TDomainSession(WDOM1,TUXDOM1) 和TDomainSession(WDOM1,TUXDOM2) 之间正确配置负载平衡请求的示例：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM2
TOLOWER2
下面是一个错误配置负载平衡请求的示例。下面的配置会导致 service1 具有相同的复合密钥：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM1
TOLOWER
在建立连接/会话前更改该会话/连接配置（本地 AP、远程 AP、密码和资源）：
接受更改并在新的会话/连接中实现这些更改。
在建立连接/会话后更改该会话/连接配置（本地 AP、远程 AP、密码和资源）：
接受更改，但是要到连接断开并重新连接后，才在现有的连接/会话中实现这些更改。请参阅“管理控制台联机帮助”中的定位
WTC 服务。
更改导入和导出服务配置：
接受更改并在下一个入站或出站请求中实现这些更改。BEA 建议不要使用此做法，因为这会让正在进行的请求处于未知状态。
更改 tBridge 配置：
对已部署的 WTC 服务进行任何更改都会导致异常。在进行任何 tBridge 配置更改前都必须先取消对 WTC 服务的定位。在取消定位和进行配置更改后，必须定位 WTC 服务以便实现更改。
在配置中可以有多种 WTC 服务。
只能将一种 WTC 服务定位到服务器实例。
WTC 不支持连接缓冲池。WTC 通过单个物理连接多路传输请求。
配置更改可按照如下方式实现：
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）