① java通过WTC调用tuxedo服务,报错:Could not get a Tuxedo session有人知道什么原因吗谢谢
在web.xml中增加session-timeout
<session-config>
<session-timeout>30</session-timeout>
</session-config>
试试～～～
② TUXEDO调服务时，客户端返回tpcall错误：tpforward tpacall failure TPENOENT - no entry found。
Tuxedo介绍 原创
2016-04-02 21:23:02
11点赞
waterxcfg304
码龄14年
关注
1、Tuxedo介绍
Tuxedo 是什么？
Tuxedo是BEA公司（现已被Oracle公司收购）的一个客户机/服务器的“中间件”产品，它在客户机和服务器之间进行调节，以保证正确地处理事务。它用C语言技术开发的并且有很高性能。
TUXEDO是在、Internet 这样的分布式运算环境中开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。它具备分布式事务处理和应用通信功能，并提供完善的各种服务来建立、运行和管理关键任务应用系统。开发人员能够用它建立跨多个硬件平台、数据库和操作系统的可互操作的应用系统。
Tuxedo 的主要作用是：
屏蔽分布式环境中各种通信协议、硬件体系结构、操作系统、数据库和其它应用服务等方面的差异，使分布于网络节点上的应用程序的各个单元部件之间能够进行互操作，并协调操作的一致性和完整性，最大限度地节省系统资源，提高系统性能。
* Tuxedo 已经广泛地应用于金融、电信、制造业等各行各业的核心业务系统。
三层架构
从左边往右依次为：客户端层（表现层），中间件服务层（业务逻辑层），数据库服务器层（数据层）。这种典型的三层架构应用非常广泛。对于应用weblogic中间件的系统一般采用的B/S架构，绝大部分采用HTTP协议，少量的系统用java编写的客户端，使用的是RMI 协议，或J2EE里的其它协议。
对于tuxedo中间件使用的是tuxedo协议，前端开发工具可以是各式各样，VC++ 、java 、Delphi 、VB 等。
Tuxedo 的通讯过程
Tuxedo 服务器处理请求的方式与apache有本质的区别。
Apache服务器处理请求，由客户端发出请求到服务器，由服务器对请求进行处理后将数据返回给客户端。
Tuxedo 服务器一次请求需要两次进行两次交互，Tuxedo有两个负责通讯的进程，一个为WSL，WSL的数量可以进行配置，典型的配置一般两、三个；WSH可以有N多个。客户端通过IP地址和端口号与WSL建立连接，由WSL认证请求是否合法，在WSL的响应中包含了另外一个IP地址和端口号；然后，客户端通过拿到的新的IP地址和端口号去请求WSH 。
客户端程序由GUI 与 Tuxeo通讯两部分组成，GUI部分主要由开发人员关心如何设计，通讯部分可能设计成几个函数供开发人员调用。对于性能测试人员可能更关心客户端与服务器之间的通讯过程。
2、tuxedo相关概念
IPC: Inter-Process Communication 进程间通信: 管道、信号量（semaphore）、共享内存（shared memory）、消息队列（Message Queue）。
管道是UNIX系统IPC的最古老形式，数据只能单向流动。
Tuxedo在客户机和服务器通信中大量使用UNIX系统的消息队列。
SSSO(Single Server Single Queue)模式：每个客户机都有一个响应队列来接受客户端请求。
MSSO(Multiple Server Single Queue)模式：多个服务器共享同一个请求队列。
信号量包含一个计数器，表示某个资源正在被访问和访问的次数，用来控制多线程对共享数据的访问。
Tuxedo使用共享内存存储公告牌，用来公告进程状态信息和需要在进程间共享或传递的数据。
-------------------------------------------------------------
Tuxedo的配置文件称为UBBCONFIG或ubb，包含了域（Domain）、逻辑机器(Machine)、服务器组(Group)、服务进程(Server)、服务(Service)的定义。运行前，需要把UBBCONFIG装载成二进制文件，称为TUXCONFIG。
Tuxedo服务启动时，执行tpsvrinit()函数，可以打开一些如数据库之类的资源供以后使用
Tuxedo服务停止时，执行tpsvrdown()函数，关闭资源
服务程序调用tpreturn()函数来结束服务请求，并返回一个缓冲区，必要时，将它传给客户程序。
--------------------------------------------------------
ATMI环境支持的C/S通信方式：请求/应答式通信、回话通信、队列通信、事件代理通信、消息通知
请求/应答式通信：同步调用(tpcall)、异步调用(tpacall)、嵌套调用、转发调用(tpforward)
转发调用和嵌套调用类似，不同的是最里层的嵌套服务可以直接给客户程序一个响应，而不必按照调用栈 逐级返回。
回话方式：tpsend()/tprecv() 基于事件，分通告和代理
void (**p)(): 定义了一个指向函数指针的指针p
tpsetunsol(p) : 将p指向的函数func设置为客户机的事件处理器。
tpchkunsol(): 检查意外事件
事件代理： tppost()/tpsubscribe() 消息发布/订阅
Tuxedo提供了两个事件代理器(TMUSREVT TMSYSEVT)来处理订阅请求。
队列存储： tpenqueue() / tpdequeue()
Tuxedo/Q用到了Tuxedo提供的两个服务器：消息队列服务器(TMQUEUE)和消息转发服务器(TMQFORWARD)
---------------------------
多系统多机之间通信需要每台机器上都有一个Bridge进程，通过TCP/IP通信，Bridge进程维持一个长连接，一旦建立不会断掉。
TUXEDO应用系统的客户端访问TUXEDO服务器上的服务的过程图:
说明：
WS（Workstation Extension Proct）用于指TUXEDO产品的客户端部分
WSC Workstation Client
WSL（Workstation Listener） TUXEDO系统自带的一个SERVER，它侦听一个指定的端口，WSC最初与该SERVER建立连接
WSH（Workstation Handler）TUXEDO系统自带的一个SERVER，由它处理WSC与TUXEDO SERVER之间的通讯。
Bulletin Board（公告板）TUXEDO把系统的配置保存在一个共享内存中，该共享内存称为公告板（BB）
BBL TUXEDO的管理进程，主要对公告板等进行管理
Workstation Client与TUXEDO SERVER建立连接的过程为：
1． WSC 调用tpinit()或tpchkauth()
2． WSC采用在WSNADDR中指定的IP地址与服务端的WSL建立连接
3． WSL为该WSC指定一个WSH，并把该WSH的侦听端口返回给WSC
4． WSC采用返回的端口与指定的WSH建立连接，并与WSL断开连接，这之后WSC与TUXEDO SERVER之间的通讯通过WSH进行处理，与WSL无关。
5． tpinit()或tpchkauth()调用返回。
----------------------------------------------------------
单域模式Single-Domain Model。单机模式 Single Host Model, 多机模式Multi-Processor Model
多域模式Multi-Domain Model
③ java通过WTC调用tuxedo服务,报错:TPESYSTEM(12):0:0:TPED_MINVAL(0):QMNONE(0):0 有人知道什么原因吗谢谢
1、TPENOENT(6):0:0:TPED_MINVAL(0):QMNONE(0):0:No local or remote domain available xxx服务
服务没有调到。
请检查tuxedo domain 与 weblogic domain连通
请检查xxx服务在tuxedo中时候存在
查看方式为：
tmadmin
psc -s +服务名
如果是刚注册的xxx服务，请重现发布所在的WTC服务。如果没有重新发布，也会报这个错误。
如果tuxedo 日志显示plicate server，表示有另外一个weblogic domain 配置相同的wtc配置。也就是说 一个Tuxedo domain 对应两个相同的Weblogic domain，这种情况，也会出现这个错误，
请修改另外weblogic domain的wtc配置。（配置相同是指 远程tuxedo访问点与本地tuxedo相同）。
如果跨防火墙，请修改连接策略 都改为ON_STARTUP
2、TPESYSTEM(12):0:0:TPED_MINVAL(0):QMNONE(0):0
tuxedo服务有问题或输入参数不正确。
3、TPESYSTEM(13):0:0:TPED_MINVAL(0):QMNONE(0):0
tuxedo服务返回超过了设置的时间。优化tuxedo服务或修改时间门限。
4、TPESYSTEM(10):0:0:TPED_MINVAL(0):QMNONE(0):0
tuxedo系统问题。报10看下服务，应该有core文件生成。
④ tuxedo 支持java语言开发服务端吗
tuxedo12c的官方文档上介绍时可以使用java开发服务的，具体如何开发可以看Programming an Oracle Tuxedo Application Using Java 这一章节。
⑤ C#编写的tuxedo客户端能不能访问java编写的tuxedo服务端服务
有没有尝试打开到服务器的端口，telnet 192.168.123.84 6677，看看是不是网络问题
⑥ Jolt调用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 通过单个物理连接多路传输请求。
配置更改可按照如下方式实现：