import bea.jolt.JoltRemoteService;
import bea.jolt.JoltSession;
import bea.jolt.JoltSessionAttributes;

public class SimpleApp {
    public static void main(String[] args) {

        JoltSession session;
        JoltSessionAttributes sattr;
        JoltRemoteService joltService;
        String userName = "";
        String userPassword = "";
        String appPassword = "";
        String userRole = "";
        sattr = new JoltSessionAttributes();
        sattr.setString(JoltSessionAttributes.APPADDRESS,
                "//XX.XX.X:8307");
        sattr.setInt(JoltSessionAttributes.IDLETIMEOUT, 300);
        session = new JoltSession(sattr, userName, userRole, userPassword,
                appPassword);
        joltService = new JoltRemoteService("testServiceName", session);
        joltService.setString("sw01_1", "<Hello>");
        joltService.setString("sw01_2", "<Hello>");
        joltService.setString("sw01_3", "<Hello>");
        joltService.setString("sw01_4", "<Hello>");
        joltService.setString("sw01_5", "<Hello>");
        joltService.setString("sw01_6", "<Hello>");
        joltService.setString("sw01_7", "<Hello>");
        joltService.setString("sw01_8", "<Hello>");

        joltService.call(null);

    }

}

摘要：
　　本《功略》集中了TUXEDO应用中，可能涉及到的所有时间参数，并分别对其进行详细描述，不但对其出处、取值等基本属性进行查证，而且，通过分析其内在的控制机制，给出设置建议，以期能够达到透彻理解、方便查阅、准确使用的目的。

1 前言
　　金融、电信等众多行业的综合营业系统中，广泛使用了TUXEDO交易中间件，用来处理大量并发的联机事务处理（OLTP）业务。典型的OLTP业务，每笔业务的信息量较小，而且，具有一定的实时性，对时间的要求非常严格。

　　TUXEDO，联系着DATABASE和客户端软件，凭借其多层次的超时控制机制，达到客户端快速响应，服务器端稳定可靠的效果。

　　TUXEDO的多层次的超时控制机制中，涉及到的时间参数不少于10个，再加上与之紧密联系的DATABASE中的几个超时参数，确实比较复杂。遗憾的是，目前还没有的专门的文档对它们进行详细说明，而是分散在不同的专题中分别说明，而且，不同的专题中，解释的详细程度也不一样，在查阅过程中，多有不便。

　　本文试图将这些参数集中起来，对每一个都加以详细说明，并试图解释每个参数存在的原因。大部分参数时间长短的设置，除个别外，基本没有固定的模式，只要了解它们的具体含义，并结合具体应用系统的实际要求，相信大家都能够作出合理的配置。

2 全功略解读
2.1 SCANUNIT
2.1.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> SCANUNIT 。

2.1.2 时间单位
　　秒,且必须为5的倍数。

2.1.3 取值范围
　　大于0小于等于60中5的倍数，即｛5，10，15，20，25，30，35，40，45，50，55，60｝。

2.1.4 默认取值
　　10 。

2.1.5 用途解释 ⑴
　　这个参数大家都会用，比较好理解，TUXEDO中，BBL是用来对Bulletin Board进行管理和监控的系统进程，它基于时间片的轮询方式，时间片的大小就是SCANUNIT的值，SCANUNIT是Tuxedo对系统进行管理的最基本时间单位。每隔SCANUNIT，BBL对Bulletin Board进行一次检查，看看有没有超时的事务或阻塞的服务请求。后面讲到的很多时间参数都是以SCANUNIT为单位。

2.1.6 超时后果
　　仅仅是个轮询时间单位而已，到时间就轮询，如此而已。

2.1.7 设置考虑
　　作为一个涉及到整个TUXDO系统的基本单位时间，如果业务需要，对时间参数控制比较严格，设置为5也不算小。如果系统业务对时间要求不严格，那就大点儿，60也没什么不可以；毕竟频繁轮询是要耗费更多系统资源的，而任何对资源的不必要的消耗都是浪费。

2.2 SANITYSCAN
2.2.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> SANITYSCAN 。

2.2.2 时间单位
　　SCANUNIT 。

2.2.3 取值范围
　　1 ～32767 。

2.2.4 默认取值
　　大约120/SCANUNIT。

2.2.5 用途解释 ⑵
　　进行系统健全性检查，主要包括Server进程状态和Bulletin Board数据结构，检查Server进程是否存活，如果已经不存在，会清理Bulletin Board中相应的数据项及IPC资源，并根据参数配置决定是否重新启动，如果设了RESTART=Y，所占的Message Queue不会被清除，Queue中的Request得到保留，仍会被处理。如果是MP模式，BBL还会给DBBL发状态消息。

2.2.6 超时后果
　　仅仅是个系统健康检查的间隔时间而已，到时间就检查，如此而已。

2.2.7 设置考虑
　　作为一个涉及到整个TUXDO系统健康检查的间隔时间，如果系统处在一个稳定的运行环境中，网络、数据库、应用都很稳定，那这个参数可以大一些；如果运行环境不稳定，系统繁忙，而且Server进程经常因异常（如超时）而死掉，那就设置小一些。设置的原则和SCANUNIT一样：不要随意浪费系统资源。

2.3 BBLQUERY
2.3.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> BBLQUERY。

2.3.2 时间单位
　　SCANUNIT

2.3.3 取值范围 ⑶
　　BBLQUERY必须大于等于SANITYSCAN，tmloadcf 时会强制检查，如果设的值小于SANITYSCAN，tmloadcf会自动调整为SANITYSCAN。

2.3.4 默认取值
　　大约300/SCANUNIT。

2.3.5 用途解释 ⑷
　　BBL检查，在MP模式下，BBL会每隔一段时间都发送了" I am ok "心跳信息给DBBL，这个间隔就是BBLQUERY。

2.3.6 超时后果 ⑸
　　如果DBBL在规定时间间隔内没有收到某个BBL的信息，DBBL它会主动发送Request给那个BBL，判断其是否正常。（如果等了DBBLWAIT后仍然没有回复，DBBL会认为那台机器有问题，然后，将其隔离。）

2.3.7 设置考虑
　　此设置仅仅在MP模式下才起作用。

　　在MP模式下，如果TUXEDO系统需要对不稳定的运行环境可能发生的故障作出快速的反应，那么BBLQUERY要设置小一些，让系统快速的自我检查。考虑网络传输时间、系统反应速度等因素，网络速度越慢，系统负载越重，取值越大；反之亦然。

　　如果系统运行环境很稳定，利用其默认值即可，甚至可以更大数值。

2.4 DBBLWAIT
2.4.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> DBBLWAIT。

2.4.2 时间单位
　　SCANUNIT。

2.4.3 取值范围
　　大于0。

2.4.4 默认取值
　　1和20/SCANUNIT中的较大者 。

2.4.5 用途解释 ⑹
　　如果DBBL在规定时间间隔BBLQUERY内没有收到某个BBL的"I AM OK"信息，它会发Request给那个BBL，其等待回复的时间就是DBBLWAIT。

2.4.6 超时后果 ⑺
　　DBBL等了DBBLWAIT后仍然没有回复，DBBL会认为相关BBL的机器有问题，然后，将其隔离（partation）。

2.4.7 设置考虑
　　此设置仅仅在MP模式下才起作用。

　　在MP模式下，考虑网络传输时间、系统反应速度等因素，网络速率越大，系统负载越轻，此数值越小；反之亦然。

2.5 BLOCKTIME
2.5.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> BLOCKTIME。

2.5.2 时间单位
　　SCANUNIT。

2.5.3 取值范围
　　大于0。

2.5.4 默认取值
　　大约60/SCANUNIT。

2.5.5 用途解释
　　Client端阻塞请求（Blocking call）服务的超时值，BBL发现有超时的Request时，会给相应的Client端发超时信息。

　　此参数仅仅在"阻塞请求"的情况下起作用，因此，理解它，关键要理解什么是阻塞请求（Blocking call）？习惯上，我们将"阻塞请求"理解为"同步请求"，将"异步请求"理解为"非阻塞请求"，是源于将"<发送请求－得到结果>"这一过程看成为一个整体。如果是整体的同步操作，就认为是"阻塞请求"；如果是分开异步的操作，就认为是"非阻塞请求"。

　　其实，异步操作中，同样存在"阻塞请求"，tuxedo中，tpacall和tpgetrply这两个异步操作各自本身就是"阻塞请求"，tpacall是将请求发送到请求队列，tpgetrply是将从结果队列中取出结果，如果没有特殊的设置，这两个操作本身都是阻塞的，BLOCKTIME将起作用。

　　以Request/Reply方式为例，将成功发送请求的时长设置为T1，将请求处理的时长(含排队等待)设置为T2,将成功取得结果的时长设置为T3，那么在下面不同的情况下，将触发BLOCKTIME，引起超时：

　　（1） tpcall（）不在transaction中，flag为0，当T1+T2+T3 > BLOCKTIME时，发生超时 ;

　　（2） tpcall（）不在transaction中，flag为TPNOBLOCK，只有当一次调用即成功完成T1阶段发送请求的任务后，T2+T3 > BLOCKTIME时，发生超时 ;

　　（3） tpacall（）不在transaction中，flag为0，当T1 > BLOCKTIME时，发生超时 ;

　　（4） tpgetrply（）不在transaction中，flag为0，当T2+T3 > BLOCKTIME时，发生超时 ;

　　（5） tpcall，tpacall,tpgetrply,在其他任何情况，BLOCKTIME都将不起作用。

　　（6） 如果请求处于事务交易（transaction）中，此参数不起作用，取代它的是 TransactionTimeOut。

2.5.6 超时后果
　　在上面描述的四种情况下，Server端 BBL返回Client端超时错误：tperrno ＝ 13 （TPETIME）。同时，client端和Server端已经建立的联接不受任何影响，继续保持联接。

2.5.7 设置考虑
　　此参数涉及整个TUXEDO系统，不能够直接适应业务系统中不同场合的不同时间等待要求，而且在应用过程中，存在误差，不适合进行精确到秒的时间控制。

　　准确有效的使用这个参数，需要考虑好以下几个问题：

　　（1） 应用中是否完全依赖这个参数进行时间控制？

　　（2） 有哪些业务依赖这个参数进行时间控制？

　　（3） 平衡各种业务，此参数设置为多少？

　　（4） 除此参数外，是否需要利用其他的超时控制机制？

2.6 WSL CLOPT [-T Client_timeout]
2.6.1 参数出处
　　UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-T"。

2.*** 默认取值
　　0 ，意味着无限等待时间。

2.6.5 用途解释 ⑻
　　系统允许的Client静默时长，即Client和WSH建立联接后，如果在此指定的时间内客户端没有发送任何请求，WSH会自动回收与此Client端相关的资源。

2.6.6 超时后果 ⑼
　　WSH会自动释放和这个Client端的联接，并将此Client在Bulletin Board中的数据项清空，RollBack它未完成的事务 。

2.6.7 设置考虑
　　此参数的设置目的，主要是从Server的角度进行考虑，防止在Client端意外失效的情况下仍然耗费Server端的资源。

　　如果设置太小，那么频繁的检测同样要消耗Server端一定的资源，而且，在使用长联接的系统中，系统空闲时，容易造成已经建立的长联接频繁的释放，影响正常业务的提供。

　　如果设置为0，不管发生什么状况，哪怕是Client端系统真的崩溃了，也不会触发此超时，这将造成Server端资源的无谓浪费。

　　建议：在业务负载不均衡的长联接业务系统中，根据业务实际空闲时间，适当加大此数值。

2.7 WSL CLOPT [-t timeout]
2.7.1 参数出处
　　UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-t"。

2.7.2 时间单位
　　SCANUNIT。

2.7.3 取值范围
　　大于0。

2.7.4 默认取值
　　非安全应用为3，安全应用为6 。

2.7.5 用途解释
　　建立联接时长，指workstation Client建立与server端WSH建立联接允许的最长时间，因为非安全应用建立联接时不需要进行用户校验等步骤，因此，建立联接需要的时间较短。同理，安全应用需要的时间较长。

2.7.6 超时后果
　　建立联接失败。

2.7.7 设置考虑
　　设置此参数，要分析业务系统中，网络带宽因素、用户验证的复杂程度等。

2.8 WSL CLOPT [-I init_timeout]
2.8.1 参数出处
　　UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-I"。

2.8.2 时间单位
　　秒。

2.8.3 取值范围
　　大于0。

2.8.4 默认取值
　　60 。

2.8.5 用途解释 ⑽
　　WorkStation Client端和后台建立联接的超时参数值。

　　（注：感觉上此参数和 WSL CLOPT [-t timeout]功能类似）

2.8.6 超时后果
　　不确定，现有的文档没有一点儿解释。按照字面解释，应该是tpinit的超时时间，但是，在tpinit所有的错误中，只有TPESYSTEM可能承担这个超时后果，而且仅仅是可能。

2.8.7 设置考虑
　　在使用过程中，没有感觉到这个参数的存在，也从来没有专门设置过。

2.9 WSL CLOPT [-N network_timeout]
2.9.1 参数出处
　　UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-N"。

2.9.2 时间单位
　　秒。

2.9.3 取值范围
　　大于等于0。

2.9.4 默认取值
　　0 。

2.9.5 用途解释
　　网络超时，指Workstation client利用网络接收数据（receive data）的等待时间。

　　我们同样需要分析触发Network Timeout的不同条件。

　　以Request/Reply方式中的tpcall为例，将成功发送请求的时长设置为T1，将请求处理的时长(含排队等待)设置为T2,将成功取得结果的时长设置为T3，那么在如下情况下，将触发Network Timeout，引起超时：

　　（1） tpcall（）不在transaction中，flag为0，当 BLOCKTIME> T1+T2+T3 > NetworkTimeout时，触发此超时 ;

　　（2） tpcall（） 在transaction中，flag为0，当TranactionTimeout> TI+T2+T3 > NetworkTimeout时，触发此超时 ;

　　（3） tpcall（）不在transaction中，flag为TPNOBLOCK，只有当一次调用即成功完成T1阶段发送请求的任务后，当 BLOCKTIME> T2+T3 > NetworkTimeout时，触发此超时 ;

　　（4） tpcall（）在transaction中，flag为TPNOBLOCK，只有当一次调用即成功完成T1阶段发送请求的任务后，当 TranactionTimeout> T2+T3 > NetworkTimeout时，触发此超时 ;

　　（5） tpcall（）不在transaction中，flag为TPNOTIME，当 T1+T2+T3 > NetworkTimeout时，触发此超时 ;

　　（6） tpcall（）在transaction中，flag为TPNOTIME，当 TranactionTimeout> TI+T2+T3 > NetworkTimeout时，触发此超时 ;

　　（7） tpcall在其他任何情况，NetworkTimeout都将不起作用。

　　（8） 同理，可以确定NetworkTimeout在tpacall和tpgetrply中起的作用。

2.9.6 超时后果
　　在上面描述的六种情况下， Client端操作失败，同时，client端断开与Server端已经建立的联接。Server端已经为此Client完成的操作和分配的资源不能立刻回滚和释放，Server端需要等待前面介绍过的Client_timeout时间后，再释放相关的资源。

2.9.7 设置考虑
　　此参数的设置目的，主要是从Client的角度进行考虑，防止在Server端意外失效的情况下，仍然消耗Client端的资源。

　　设置参数，必须避免小于BLOCKTIME或TransactionTimeout的情况，因为在这种情况下，会出现业务正常等待中，联接却中断的现象，这是一定要避免的。

　　同时，由于此超时触发的联接中断，并不能立刻释放Server端的资源，带来业务执行过程中的不确定性，因此，此参数要谨慎使用。

2.10 SVCTIMOUT
2.10.1 参数出处
　　UBBCONFIG配置文件 -> SERVICES -> SVCTIMEOUT 。

2.10.2 时间单位
　　秒

2.10.3 取值范围
　　大于等于0。

2.10.4 默认取值
　　0，表示无限时长 。

2.10.5 用途解释
　　服务处理时长（Service Processing Time），表示系统允许服务处理请求的时间长度。

　　此参数主要是维护Server端系统安全的角度，防止由于系统异常引起的失控服务占据系统资源，阻碍正常的后续业务请求。它起到了一个清道夫的作用，将不能有效提供服务的Services清除出系统，并依靠系统的其他机制，重新产生具有活力的Services。

2.10.6 超时后果
　　超时后，此Service所属的Server将被系统的SIGKILL信号清除；此操作不会影响与此Server相关的其他正在运行的副本Servers。

　　如果系统设置SERVERS->RESTART=Y，那么，被清除的Server将立刻自动重新启动。重新启动的次数受随后介绍的MAXGEN和GRACE两个参数联合限制。

　　如果系统设置SERVERS->RCMD为有效命令文件，那么，在重启此Server时，将同时执行此命令，如向管理员发送通知邮件等。

　　如果SERVER没有RESTART＝Y设置，那么Server将不会自动重新启动。

2.10.7 设置考虑
　　此参数不是系统全局参数，而是涉及到单个Service，可以根据不同的Service的处理时间进行设置。由于其主要起到系统清道夫的角色，因此，建议设置为正常Service处理时长的3倍较合适，以避免清除正常运行的Service，使正常运行的业务受到影响。

　　如果系统运行环境基本稳定，一旦出现底层网络或数据库系统故障，不是在短时间内能够恢复，建议将此参数增大，至少为平均恢复时间，甚至可以利用默认值0，无限等待，避免此自动机制，而用人工介入的方法进行服务恢复。因为系统自动的、频繁的SIGKILL将影响到整个TUXEDO系统的稳定。

2.11 GRACE
2.11.1 参数出处
　　UBBCONFIG配置文件 -> SERVERS -> GRACE 。

2.11.2 时间单位
　　秒。

2.11.3 取值范围
　　0-2147,483,647。

2.11.4 默认取值
　　86400（24小时）。

2.11.5 用途解释
　　此时间参数与其他两个参数紧密相关RESTART, MAXGEN。

　　关联起来解释就是，当Server异常终止时，如果RESTART=Y，那么此SERVER可立即自动重新启动，这个重新启动的次数被限制为在GRACE指定的时间间隔内，重启不超过MAXGEN-1 次。

　　如果RESTART这个参数为N，其他的相关参数将都无效。

2.11.6 超时后果
　　此参数不仅仅是时间的限制，如果在GRACE时间段内，此SERVER重启次数已经达到MAXGEN-1，后续重启将不能执行。

2.11.7 设置考虑
　　此组参数设置的综合目的是避免运行Server无限的重启，重启次数说明了系统目前异常状况的严重程度，如果在一定时间内，Server重启次数达到了一定的数量，说明这个Server相关的资源已经出现较严重的故障，需要人工进行干预了。

　　另外，经过调优的生产系统是不需要自动重启的，因此，RESTART这个参数更多是应用在系统测试版本中，在正常运行的生产系统中，应该有不同参数设置，谨慎使用，因为过多的重启将有可能严重影响Server端的整体稳定性。

2.12 Transaction TimeOut
2.12.1 参数出处
　　tpbegin(timeout,0)。

2.12.2 时间单位
　　秒,且必须为SCANUINT的倍数。

2.12.3 取值范围
　　大于等于0。

2.12.4 默认取值
　　无，使用时必须明确指定。

2.12.5 用途解释
　　交易时长，确定交易（transaction）的持续时间，如果超过此时间，系统将返回超时错误。

　　分析其触发条件，分两种情况：

　　（1） Server端发起交易，

　　对Client而言，因为Client不在交易范围内，即使BLOCKTIME设置小于此参数，起有效作用的仍然将是BLOCKTIME，而不是此参数。

　　（2） Client端发起交易。

　　对Client而言，因为Client在交易范围内，此时，BLOCKTIME将失效，此参数取而代之。只要处理时间超过此参数，将触发此超时，交易处理将随时中断。

2.12.6 超时后果
　　相关交易将被标识为abort only。注意，仅仅是标识为abort only，而不是系统自动执行tpabort进行交易恢复。随后必须主动执行tpabort，恢复交易，保障交易完整性。如果没有执行tpabort，系统将通过其他机制，恢复交易，保障交易完整性。

2.12.7 设置考虑
　　此参数的主要目的是将交易处理过程限制在合理的时间范围内，如果确实是完成交易的条件不具备，系统也能够作出反应，避免系统资源的长时间占用。因此，不管交易由Client还是由Server发起，此参数都要按照业务的实际状况进行设置。如果设置为0，就基本相当于无限时长。（系统unsigned long数据类型的最大值）

2.13 TRANTIME
2.13.1 参数出处
　　UBBCONFIG配置文件 -> SERVICES -> TRANTIME/AUTOTRAN。

2.13.2 时间单位
　　秒,且必须为SCANUNIT的倍数。

2.13.3 取值范围
　　0-2147,483,647。

2.13.4 默认取值
　　30 。

2.13.5 用途解释
　　此参数必须与AUTOTRAN配合使用，表示不需要调用tpbegin，就可自动发起的隐含交易（AUTOTRAN implicitly transactions）处理持续时长。其实，起到与tpbegin（timeout,0）中的timeout相同的作用。

　　其实，AUTOTRAN这个参数更为重要，其默认值为N, 其作用描述如下：

　　（1） 请求发起方不在交易模式，AUTOTRAN＝Y，Service将自动发起一个交易，TRANTIME将起作用；

　　（2） 请求发起方在交易模式，而且，其中的标记参数（flags）不是TPNOTRAN，那么，无论AUTOTRAN如何，Service将自动加入请求方交易中，TRANTIME将不起作用；

　　（3） 请求发起方在交易模式，而且，其中的标记参数（flags）是TPNOTRAN，如果AUTOTRAN＝N，Service将自动加入请求方交易中，TRANTIME将不起作用；

　　（4） 请求发起方在交易模式，而且，其中的标记参数（flags）是TPNOTRAN，如果AUTOTRAN＝Y，Service将不加入请求方交易中，而是产生一个新的交易，TRANTIME将在新交易中起作用；

2.13.6 超时后果
　　与tpbegin(timeout,0)中的timeout相同。

2.13.7 设置考虑
　　与tpbegin(timeout,0)中的timeout相同。

2.14 ORACLE XA OPENINFO参数：SESTM
2.14.1 参数出处
　　UBBCONFIG配置文件 -> GROUPS -> OPENINFO ->SESTM 。

2.14.2 时间单位
　　秒。

2.14.3 取值范围
　　大于等于0，0表示无限时长。

2.14.4 默认取值
　　无，使用时必须明确设置 。

2.14.5 用途解释
　　会话静默等待时长，即全局交易中，作为资源管理器（resource manager）已经参与交易并完成相应的数据操作的数据库，等待全局交易中的其他参与方操作完成的时间长度。

　　举例说明：

　　假设一个全局交易由以下几个部分组成：

　　（1）tpbegin（T,0） ->

　　（2）tpcall(S1) -> DB1 完成耗时 T1;

　　（3）tpcall(S2) -> DB2 完成耗时 T2;

　　（4）其他操作 耗时 T3

　　（5）tpcommit()

　　其中，tpcall(S1)访问数据库DB1, tpcall(S2)访问数据库DB2。

　　对DB1而言，如果T-T1> T2+T3 > SESTM1,则触发超时；

　　对DB2而言，如果T-T1-T2 > T3 > SESTM2,则触发超时；

　　由此可以看出，此参数的主要目的是对数据库进行资源保护，避免在全局交易中，已经完成任务的数据库，为等待其他参与方耗费过多的资源，毕竟ORACLE中并发全局交易的数量是很有限的。

2.14.6 超时后果
　　触发此超时后，数据库将自己主动回滚已经完成的任务，释放全局交易资源。TUXEDO控制的全局交易进行TPCOMMIT时，如果总时间仍没有超过Transaction TimeOut，那么TPCOMMIT将失败，XALOG会记录下ORACLE错误："ORA-24756: Transaction does not exist"。确实如此，拿上面的例子来说，等到最后TPCOMMIT的时候，DB1已经主动回滚了所有的数据，不难理解，对DB1而言，它好像根本没有参加过这个全局交易，自然就会有这样的错误提示。

2.14.7 设置考虑
　　这个参数是从数据库自我保护的角度设计的，对数据库而言，是不得已的办法。最好的措施还是TUXEDO能够控制时间，赶在SESTM之前，进行TPABORT，主动通知数据库进行数据回滚。

　　用一个简单的比方：冬天，客人出门时没有关门，SESTM时间后，客人还没有回来，主人感觉到冷了，只好自己去关门，不管什么理由，这样总是不太好。如果在SESTM时间内，客人能及时回来关门，主人就不会感觉那么差。

　　从前面的超时触发分析，我们也能发现，只要设置SESTM 能够大于 TransactionTimeOut的话，就能够尽量的不触发此超时机制，达到较好的效果。

2.15 ORACLE XA OPENINFO参数：SESWT
2.15.1 参数出处
　　UBBCONFIG配置文件 -> GROUPS -> OPENINFO -> SESWT。

2.15.2 时间单位
　　秒。

2.15.3 取值范围
　　大于0。

2.15.4 默认取值
　　60 。

2.15.5 用途解释
　　会话繁忙等待时长，指全局交易中的一个交易分支（transaction branch）正在一个会话（session）中处理数据过程中，如果第二个会话也要对此交易分支进行操作，那么第二个会话必须等待第一个会话完成，如果在等待SESWT后，第一个会话仍然没有完成，那么第二个分支将触发此超时。

　　举例说明：

　　假设一个全局交易由以下几个部分组成：

　　（1）tpbegin（T,0） ->

　　（2）tpcall(S1) -> DB1 完成数据操作耗时 T1;

　　（3）tpcall(S2) -> DB2 完成数据操作耗时 T2;

　　（4）其他操作 耗时 T3

　　（5）tpcommit()

　　其中，tpcall(S1)访问数据库DB1, tpcall(S2)访问数据库DB2，任何操作失败后，将调用tpabort。

　　假设 T1+T2 > T > T1，也就是说，在成功执行第二步tpcall(S1)后，应用执行到第三步tpcall(S2)，在执行过程中，将触发TransactionTimeout，tpcall（S2）将返回错误，应用将立即调用tpabort进行交易回滚，DB1的数据将立刻回滚；而DB2并不能中断tpcall(S2)引起的数据操作，对于ORACLE DB2而言，tpcall(S2)引起的数据操作属于第一个会话，而tpabort引起的数据库回滚操作是通过XA接口，属于第二个会话，所以，tpabort作用到DB2上，只有等待第一个会话完成，如果等待SESWT后，第一个会话仍然没有完成，即SESTM

2.15.6 超时后果
　　系统将返回XA_RETRY错误，提示TMS此操作不能完成，需再试一次。如果应用程序对此没有再次尝试的话，仍以上例说明，DB2只能利用SESTM2，触发超时，自动回滚。

2.15.7 设置考虑
　　查阅ORACLE相关资源，发现oracal9.2与以前版本效果不同，以前的版本都是第二个会话在等待SESWT后，如果第一个会话操作仍然没有结束，第二个会话能够使第一个会话操作立即进行有效的回滚，使第一个会话返回错误：ORA-24761。

　　不难理解，两者的区别是，打个简单比方说，A正在用杯子喝水时，B要A放下杯子，B等待SESWT后：

　　oracle9.2的做法很民主，A还没有用完，通知B，A还在用杯子，不能放下，还想让A放下杯子，可以，再来一次；也就是说，只要A在用，B就不能让人家放下杯子，某种程度上，A代表了强权。

　　Oracle9.2之前版本的做法很粗暴，通知A不能使用这个杯子了，必须放下，因为B让你放下，而且已经等很久了，某种程度上，B代表了强权。

　　因此，如果是ORACLE9.2后的版本，SESWT适当放长一些，毕竟还是希望能够等到能做事的时候，把想做的事情做了。如果是以前的版本，SESWT适当放短一些，反正一定能等到，为什么不少等一会儿呢？

2.16 ORACLE sqlnet.expire_time
2.16.1 参数出处
　　$ORACLE_HOME/network/admin/sqlnet.ora -> expire_time 。

2.16.2 时间单位
　　分钟。

2.16.3 取值范围
　　大于0。

2.1*** 默认取值
　　无 。

2.16.5 用途解释 ⑾
　　死联接检测DCD(Dead Connection Detection)是 SQL*NetV2.1 和此版本以后的一个新特性, 当它检测到对方 c/s 或者s/s 联接意外终止时, 释放相关占用的资源。

　　DCD 起初是专为客户机没有从会话中断开联接的情况下断电的环境设计的。

　　DCD由服务端开始建立联接。 这时候SQL*Net 从参数文件中读取变量, 设置一个定时器定时产生信号。 这个时间间隔是sqlnet.ora文件中的SQLNET.EXPIRE_TIME提供的。

　　当定时器设定的时间到了之后, 服务器上的SQL*Net 发送一个探测包到客户端。(如果是数据库联接, 目的端的服务器发送探测包到另一端)。 探测包是由空的SQL*Net包组成, 不体现SQL*Net层任何数据, 但会在下一层的网络协议中产生数据流量。

　　如果客户端的联接仍然是活动的, 探测包被丢弃,计时装置复位。 如果客户端异常断掉，服务器将收到由发送探测包的调用发出的错误。

2.16.6 超时后果
　　服务器将收到由发送探测包的调用发出的错误，SQL*Net 将会通知操作系统释放联接占用的资源。

　　需要说明的是, SQL*Net 2.1.x中 一个活动的孤儿进程（active orphan process） ，如单独的查询进程，在查询完成之前不会被杀掉。 在SQL*Net 2.2中，孤儿进程占用的资源将会被无条件释放，不管查询是否结束。

2.16.7 设置考虑
　　ORACLE 在NT操作系统上，此功能表现很差，检测出的无效联接（dead connection）不能被尽快释放，而必须等到数据库重新启动时才释放。SQL*Net v2.3以后版本改善了以上问题。

　　此功能只是服务器的特性，如果不设置此参数，此功能将不启动。按照ORACLE的建议，对大多数应用来说，设置10分钟较合适，其实关键还是分析应用系统的实际情况。

　　同时，不难理解，作为一个数据库自我管理的机制，也是要占用数据库资源和网络资源的，太频繁的探测同样会降低系统和网络的性能。在低速网络上，设置此参数，就需更为慎重。

　　客户端不需要设置此参数。

2.17 ORACLE distributed_lock_timeout
2.17.1 参数出处
　　ORACLE初始参数文件：init.ora -> distributed_lock_timeout。

2.17.2 时间单位
　　秒。

2.17.3 取值范围
　　大于0。

2.17.4 默认取值
　　60 。

2.17.5 用途解释
　　分布式事务锁等待超时（distributed transaction waiting for lock），指第二个事务处理需要的数据库资源，正被第一个分布式事务占用而锁定，那么，第二个事务将等待第一个分布式事务释放此资源，等待distributed_lock_timeout时间后，如果第一分布式事务仍然没有释放此资源，第二个事务触发此超时。

2.17.6 超时后果
　　如果资源被第一个事务正常使用锁定，ORACLE回滚第二个事务，并返回错误："ORA-02049: time-out: distributed transaction waiting for lock "。

　　如果第一个事务处理完成，资源释放后，再尝试第二个事务，就会成功。如果第二个事务不能等待资源自动释放，那么可以采用处理数据库死锁（deadlock）的措施，人工介入，清除第一个事务，但一般不建议采用这种方式，因为第一个事务一般会正常结束的。

　　如果资源被第一个事务因为处于不确定分布事务状态（in-doubt distributed transaction）而锁定，ORACLE回滚第二个事务，并返回错误："ORA-01591: lock held by in-doubt distributed transaction identifier "。

　　这种错误遇到的可能性较小，一般只有在分布事务的关键提交阶段出现网络、系统故障，才可能出现此故障，而且，当网络、系统故障恢复后，ORACLE一般可以自己解决此问题，不需要人工介入。如果一定要人工介入，可以查阅ORACLE专门的手册。

2.17.7 设置考虑
　　出现这样的超时，是因为特定数据库资源的使用碰撞，要分析应用系统的业务特点，确定碰撞可能发生的条件，在此条件下，资源可能被先来者锁定多长时间（T1），后来者又能够等多长时间（T2），再来设置此参数（T）的大小。如果在大多数情况下，T1 < T2, 那么就设置T1 < T < T2；反之，大多数情况下，T1 > T2，那么，就设置T < T2。

　　因此，不分析业务特点，一味的增大和减小是不恰当的。

2.18 ORACLE Max_commit_propagation_delay
2.18.1 参数出处
　　ORACLE初始文件:init.ora -> Max_commit_propagation_delay。

2.18.2 时间单位
　　0.01秒。

2.18.3 取值范围
　　0 ～ 90000。

2.18.4 默认取值
　　700 。

2.18.5 用途解释
　　最大提交传播时延（MAX_COMMIT_PROPAGATION_DELAY，简称MCPD），在ORACLE RAC(或OPS)环境中才使用，表示在RAC系统中，一个instance系统提交产生的最新系统改变码（SCN），能够以多快的速度反应到另一个instance中。

　　举例说明，RAC系统，有A,B两个实例（instance），A、B本地系统改变码为SCN1，A更新数据DATA1提交， LGWR操作完成后，A本地系统改变码为SCN2，经过不大于MAX_COMMIT_PROPAGATION_DELAY时间后，B系统本地改变码才变为SCN2。

2.18.6 超时后果
　　Global Cache Services 将刷新RAC中的SCN。不管SCN是否及时刷新，后续的数据查询都不会因此产生数据库错误。但，在此时间内，有可能查询结果不是最新数据，产生读一致性（read consistency）问题。

2.18.7 设置考虑
　　RAC环境中的所有实例，此参数值必须相同。

　　ORACLE8i后，建议常用的两个值是0和700（默认），其他数值皆不建议。其实，这两个数值就代表了RAC环境中，两种SCN 产生机制：

　　Lamport Scheme和 Broadcast on Commit scheme。

　　设置为默认值700，表示采用Lamport Scheme，SCN改变不会完全同步，同步将在 7秒钟内完成，而不是总等待7秒钟后才完成。如果系统比较空闲，同步可能在0.5秒（甚至更短时间）内完成；不管系统多繁忙，同步时间也不可能超过7秒。不难理解，采用此模式，整个RAC系统的运行效率较高。

　　设置为0，表示采用Broadcast on Commit scheme，SCN改变完全同步。每当commit时（即LGWR 写redo log时）：

　　－ LGWR发送消息更新全局SCN（global SCN），

　　－ LGWR 发送消息给每个活动的实例更新其本地SCN（local SCN）。

　　有资料说，只要MCPD < 700，系统将采用Broadcast on Commit scheme。

　　Lamport Scheme能够适应绝大部分应用的要求，只有个别实时性特别高的业务，才需要Broadcast on Commit scheme。通过分析，不难理解，Broadcast on Commit scheme将需要更多的系统资源。

3 总结
　　以上所有时间参数，都是tuxedo系统或ORACLE数据库系统提供的时间控制机制，更多的是从维护本系统自身安全的角度，建立起相互之间沟通的规则。在Client 端，中间件服务器，数据服务器这相互联系的三者之间，用一个简单的比方，就是先保证自己尽量不给相关人带来麻烦；一旦相关人出了麻烦，自己能够自我保障，不受别人干扰。

　　这些时间参数还有的一个共性的特点就是"不精确"，如果业务需要要精确到1秒，则必须依靠业务程序中更精确的时间编程。

　　总之，要保障整个业务系统的有效性和健壮性，必须了解都有哪些时间参数？都表示什么意思？都起哪些作用？自己的业务应用对时间要求是怎样的？这些参数该如何配置才能满足应用的要求？希望本文能够在以上方面给大家带来一点方便。

4 后记
　　自2002年真正在项目中利用TUXEDO起，就发现已有资料在时间参数解释方面的缺憾，那时，就有写这样一个专题的打算，开始收集这方面的资料。由于后来工作内容的变化，也就没有精力再作整理，但心里一直惦记着这件事情。直到前些天知道了BEA的这个活动，再到网络上搜集资料，发现已经有了一些类似的资料，但感觉仍然不够完整，不够透彻，因此，我认为整理这样一个专题资料，还是有必要的，便下决心借此机会做完这件事情。经过近十天的查阅、整理，终于完成，算是了我多年夙愿。

　　文中的参数，我仅仅使用过其中的12个，其他未用参数，主要是靠查阅资料和逻辑分析，根据我自己的理解进行解释，再加上时间仓促，或遗漏、不妥之处，敬请指正，让我们一起来使此《功略》更准确、更全面，让更多的人从中受益。

5 参考文献
http://e-docs.bea.com BEA TUXEDO RELEASE 7.1 。
http://dev2dev.bea.com.cn/techdoc/tuxedo/20030230.html 《Tuxedo 中关于时间的参数的说明》作者：不详 。
《ORACLE8i Reference》。
《ORACLE9i Reference》。
《ORACLE8i Parallel Server Concepts and Administration》。
《ORACLE8i Application Developers Guide - Fundamentals》。
http://metalink.oracle.com 相关问题解决资料。
http://www.chinaunix.net 《DCD死联接检测》作者：yukaikai
　　注：文章中标注⑴～⑽涉及的内容，引自参考文献-2 ，标注⑾涉及的内容，引自参考文献-8 。

在没有负载均衡的情况下，是由一个server（可能包含一个或多个service）来处理客户端对其中service的请求，所有的请求首先放入这个server的队列里面，然后server逐个取出处理。在UNIX系统上，TUXEDO较多的使用了队列，并且也用到了共享内存和信号量，相关的UNIX系统参数会影响到系统的性能，但这个不在本文讨论范围之内，这里假设已经调到了合适的范围，具体请查阅TUXEDO关于IPC的文档。

现以一个帐单处理的server为例，负载均衡前server的ubb配置为：
billpay SRVGRP=GROUP1 SRVID=1
在单个server不能满足性能要求的情况下，就考虑采用TUXEDO的负载均衡方法。
方法一是直接将相关server启多份，将上面的配置改为：
billpay SRVGRP=GROUP1 SRVID=1 MIN = 5 MAX = 10
这样tmboot的时候，就会有MIN = 5个billpay启动，类似下面的情况：
billpay 00001.00001 GROUP1 1 0 0 ( IDLE )
billpay 00001.00002 GROUP1 2 0 0 ( IDLE )
（依此类推，共5个）

其中第二列是该server的队列名，"."前面是GRPNO,后面是SRVID，每个server有自己的队列。相关的另一个参数就是在ubb的*RESOURCES段的LDBAL，表示是否启动Load Balancing，默认是"N"（不启动），你可以通过设置成"Y"来启动。这里需要注意的是，为"N"的时候并不表示多个server不能分担负载。主要的差别是为"Y"时，TUXEDO在接收到请求时会按照它的负载均衡的算法来找到合适的server来处理，而设置成"N"时，总是由第一个可用的server来处理。通过这种方法可以让多个server来处理大量并发的请求，就达到了改善性能的目的。

方法二是采用MSSQ（Multi Server, Single Queue），顾名思义，就是有多份server，但是只有一个队列（请求队列）。具体的配置是：
billpay SRVGRP=GROUP1 SRVID=1 MIN = 5 MAX = 10
RQADDR=" billpay" REPLYQ=Y

启动后的情况如下：
billpay billpay GROUP1 1 0 0 ( IDLE )
billpay billpay GROUP1 2 0 0 ( IDLE )
（依此类推，共5个）

我们发现几个billpay server都关联相同的名为billpay的队列，这就是所谓的Single Queue。

与直接多server相比，多了两个参数，RQADDR是这多个server共用的队列名，是一种逻辑名，可以自己命名，不和别的冲突就可以，REPLYQ是标示是否设置返回队列，在使用MSSQ的时候是强烈建议设置，因为这样可以将请求和返回分开，避免多个server共用队列时造成混乱。相关的其它参数这里没有详细列出。

到底两种方式和没有负载均衡时有什么不同，后面将提供相关的测试结果。先分析一下两种方法。方法一有多个队列可以容纳请求，但是这些大量的请求怎样放入这些队列必定有一定的策略，而且根据LDBAL的设置会不同，但是这个策略本身的运算也是一种消耗，因为每个请求都面临着这个选择。因为这种情况下每个队列是和server对应的，所以队列的选择就意味着选择了相应的那个server，这样大量的请求就被分流。虽然有选择的消耗，但是额外的好处也是显而易见的，那就是有多个queue可用，有效避免了请求并发量很大时队列的溢出，这种情况在实际的压力测试中发生过。使用方法二时，放入队列时不用做选择，然后每个server的任务就是从队列取出请求去处理，考虑到多个server并发取队列，所以用MSSQ时其server的数目不宜太多，官方文档建议2－12。而且在这种情况下，建议不要设置LDBAL=Y，因为MSSQ本身就是一种基于single queue的负载均衡的方法，这时再使用系统的策略已经没有意义。这种方法也有一个问题，如果相对于请求数来说，处理得不够快，就比第一种方法更容易造成队列溢出。

因为我们无法知道TUXEDO一些具体的算法和策略，那就用一些具体的测试来比较吧。笔者在一个和实际生产系统配置相同的UNIX+ORACLE+TUXEDO8.0系统上做了一下试验，被测服务是一个帐单查询服务，每次根据一批ID从数据库查询出具体的帐单，由于都是实际数据和实际使用的服务，有一定的说明力，但是也不排除一些情况造成的误差。以下是测试的一些结果，每个server的实际运行份数都是10。

一：客户端数目为1，循环调用100次。

1． 方法一，LDBAL = Y or N。结果发现所有的请求都由其中的一个server处理，其它全部空闲。在此基础上再进行两次循环调用，结果还是一样。
2． 用方法二，LDBAL = Y or N。其中两次测试的情况是：
<1>19，19，2，2，1，18，18，1，1，19
<2>23，8，23，23，23，（其它空闲）
以上数据说明了两种方式的调度策略是不一样的，在单客户端循环的情况下方法二更合适。

二：客户端数目50，每个循环80次，统计总的执行时间。
1． 用single server。两次测试的处理时间分别是219s和196s。
2． LDBAL = Y 方法一：三次测试时间为：63s，79s，69s
3． LDBAL = N 方法一：三次测试时间为：74s，79s，85s
4． LDBAL = Y 方法二：三次测试时间为：74s，73s，77s
5． LDBAL = N 方法二：三次测试时间为：78s，76s，75s

通过以上数据可以看出不管用那种方法，使用负载均衡相比单个server都可以在大量请求并发时得到更好的性能。但是同时也发现后四种情况的总时间差别不大，考虑一些实际的误差，很难断定哪种更好。

通过前面的分析，并查阅相关的文档，建议采用的是两种方式：多个server，不用MSSQ,设置LDBAL = Y；用MSSQ，设置LDBAL = N。当然，在使用TUXEDO的应用系统中，不能绝对的说哪一种方式更好，只能是根据具体的情况来分析，并通过实际的压力测试来进行选择，而且这个和具体server的特点也是有关的。

以上是一些个人分析和测试的结果，算是写出来和大家探讨，也希望大家提出自己的看法并讨论。

一、中间件技术在系统设计规划方面的经验总结

1.1、中间件应用架构的选择
这种架构选择的焦点就是业务逻辑到底是放在前台应用中还是放在后台中间件应用中。其实，引入中间件平台的原因之一就是业务逻辑的集中管理，出现这种争论的原因主要是开发商对这种业务逻辑集中的理解不深，在应用设计的过程中仍然没有摆脱以前两层结构的影响，再加上因为业务逻辑集中会增加程序开发量，才出现了这种情况。我们认为，把业务逻辑集中在中间件服务器上不仅对于业务逻辑的集中管理有好处，而且对于系统的后期运行维护、软件的升级管理都有着明显的优势。当然,在开发的工作量方面，业务逻辑集中时工作量大很多。

1.2、中间件服务分布的设计和优化原则
在Tuxedo中，Server可以理解成为Unix的一个进程，Service可以理解成为应用进程Server中的一个函数。用户可以任意划分Server和Service：既可以把所有的Service放在一个单一的Server中，也可以采用“一个Service一个Server”的方式。Tuxedo对此没有任何限制。
中间件应用的性能直接影响到营业前台服务的稳定性和连续性，而影响中间件应用性能的因素除了硬件资源的保证、数据库响应时间、中间件应用软件本身的质量之外，中间件应用服务的分布也起着至关重要的作用。我们有着这样的一个例子，在前台进入收费界面的时候，应用程序需要调用一个SERVICE名字叫A，A分布在一个叫SA的server中，而SA中又包含着很多其他的在线统计的SERVICE B，结果造成了SA响应B调用的时候执行时间比较长，所有的SA都在执行SERVICE B ，前台请求SERVICE A得不到响应，收费的界面怎么都进不去，从而导致前台收费业务中断。这就是个典型的因为服务分布不当造成的系统故障。
我们在系统规划设计过程中遵循的一个最基本原则就是尽量将“类似的Service”捆绑在一个Server之内。所谓“类似的Service”是指这些函数有相似的大小、执行时间、复杂度或者功能。我们来考虑一个极端的例子：假设一个Service A是完成非常简单工作的，它的平均执行时间是100毫秒。另一个Service B进行数据库的查询，它的执行时间可能长达20秒。如果将这两个Service捆绑在一起使用，就会出现非常严重的后果。大家知道，操作系统的基本调度单位是进程。在一个进程中的Service执行是串行的。Tuxedo把发往同一个Server的请求交易包放在同一个消息队列中。当Service B在执行的时候，Service A的请求包必须在队列里面等待20秒以上才可能被执行，虽然它的执行时间仅仅100毫秒。这显然是不能容忍和应该避免的。
实际上，用户在设计和开发应用程序的时候，并不能完全估计出每个Service的执行时间和频度。所以对Server和Service的划分优化是在应用程序开发完毕后进行调整的。调整的依据就是在系统运行的时候记录每个Service的执行时间和频度，然后根据这些数据来进行优化调整。下面就是我们在实际当中获得经验的一些系统总结。
1、 区分Service的不同类型：是业务操作还是简单的数据访问
在中间件应用中的Service可以进一步细分成负责完成业务操作和负责数据访问的两种类型。在设计的时候，最好把这两种不同类型的Service区别出来。所谓完成业务操作的类型其实就是进行数据修改的操作，负责数据访问的类型其实就是进行数据查询的操作。但是在实际的系统运行过程中，凡是涉及到数据修改的操作过程中必然会有数据查询的操作，这种类型的操作也应该规整到第1种类型中去。
2、 请求/响应类型的Service要和会话Service分开在不同的Server中
在Tuxedo中，一个Server要么支持请求/响应类型类型的Service，要么支持会话方式的Service。会话方式和请求/响应方式是两种互斥的通讯方式。请求/响应方式效率比较高，是使用最频繁的通讯类型。Tpcall/tpacall/tpforward都是这种类型的函数。会话方式适合大量的数据传输，但是它的代价是效率的下降。所以这两种类型的Service要分开放在不同的Server里面。
3、 执行时间相似的Service放在同一个Server里面
在Tuxedo应用环境中，可能有成百上千的Service，这些Service的执行时间显然是不同的。对于单线程的Server来说，虽然它可能有多个Service，但是这些Service的执行是串行的。如果某个Server拥有两个Service，A和B。A的执行时间是100ms，B的执行时间是1000ms，也就是说执行一次B的时间可以执行十次A。那么当B在执行的时候，可能会有十个A在队列里面等待。这种情况会急剧降低该Server处理Service的吞吐率。因此很自然的一个原则是把执行时间相似的Service放在同一个Server里面。
4、 具有相同执行频度的Service放在同一个Server里面
在一个典型的Tuxedo应用系统中，并不是所有的Service的执行频率都是相同的。可能一些Service被频繁的执行，而另外一些Service只是偶尔才被执行几次。把这些SERVICE分开可以避免偶尔调用的SERVICE堵塞频繁调用的SERVICE。
5、 避免死锁的情况发生
在Tuxedo中的死锁情况有两种，第一种是一个Server中的Service A去调用同在一个Server中的Service B。这种死锁发生的原因是，对于单线程的Server来说，它其中的Service是串行执行的。Service A去调用Service B的时候，Service A还没有执行完，它等待Service B的返回结果。 但是Service B不能执行，因为该Server还处于执行Service A的状态。最终导致Service A超时而出错。
第二种情况是两个Server中的Service互相调用。例如Server1和Server2，Server1中的Service A去调用Server2中的Service X。同时Server2中的Service Y去调用Server1中的Service B。这种情况发生的死锁和第一种情况非常类似，都是因为进程只能串行实行Service导致的。
这两种死锁情况在应用设计时特别要注意避免。第一种情况是比较容易察觉的，但是第二种情况就不大容易察觉。
1.3、中间件系统应用平台FAILOVER方式的选择在真实的生产运行环境中，运行平台的failover是一个必须考虑的问题。Tuxedo平台上的实现failover机制基本上有两种，一种是利用tuxedo自己的failover机制配合前台配两个WSNADDR地址来实现failover。一种是利用双机软件来实现。
第一种方式是指使两台的中间件服务器处于MP工作模式下，在每一台都启动WSL进程，然后在中间件前台配置两个ip地址。通过自己实验发现利用tuxedo自己的failover机制只有如下好处即不需要额外的操作系统和软件的支持，但是其缺点确很多，主要缺点如下：
1、两台中间件平台的MASTER切换必须要手工完成，无法自动完成。
2、前台配置的两个WSNADDR地址，如果第一个地址失败，要重新连接到第二个地址需要很长的时间，并且在每次服务调用时都要等待同样的时间。
通过双机软件来实现FAILOVER是指两台中间件服务器都配置在SHP模式下，然后利用双机软件的ip切换功能来实现failover。这种方法需要在各自的配置文件中加入另外一台主机的WSL的信息，在另外一台主机故障时，通过双机软件进行IP切换，再通过双机切换脚本将这台主机的备用WSL启动即可。采用这种方式有以下优点
1、机器切换自动完成，不需要人工干预。
2、前台业务不受影响，能保证业务开展的连续性。
缺点主要有
1、在正常情况下，每一台主机的启动中间件时，备用的WSL服务会启动失败，不过这不影响正常使用，备用的WSL只在另外一台主机故障后才起作用。
2、需要额外的双机配置和脚本配置工作。
经过这些比较，我们选定了采用双机软件的方案实现了中间件的failover机制。在以后的运行维护过程中起到了好的效果。
1.4、中间件与数据库的连接方式的选择在TUXEDO中间件应用中连接数据库的方式有两种，一种为通过XA方式连接数据库，另外一种是在应用程序中自己连接数据库。
通过XA方式连接数据库是指利用关系型数据库的XA接口，在tuxedo的配置文件中的OPENINFO段中加入连接信息，然后在server程序的初始化代码的中调用中tp_open（或xa_open），当SERVER启动时进行数据库连接。
通过应用程序直接连接数据库，数据库的连接操作不一定是在SERVER启动时进行的。
这两种方式的连接在BOSS系统中都会用到，其中的区别主要就在于如果业务操作的事务为分布式事务时，则必须要用XA方式。详细比较如下：
1、通过XA连接的方式可以实现分布式事务，即能够保证事务在不同数据库中的一致性。但是正是因为如此，它对中间件系统和数据库系统都有额外的开销，有时候这种开销甚至会影响系统的性能。
2、通过应用程序直连数据库的方法不能够实现分布式事务，但是同时也因此减少了对系统的压力。
综上，选择数据库的连接方式对整个系统的性能影响也是至关重要的，我们有个原则，凡是在不涉及到分布式事务的地方就不用XA连接。过多的依赖了XA接口，会给系统带来了许多额外的负担和压力，也会造成许多额外的故障。

二、中间件技术在系统维护方面的经验总结在中间件的日常维护中，我们了解了一些TUXEDO的基本知识，摸索了一套行之有效的故障排除方法，积累了一些常见故障的排除经验，现在与大家介绍如下：
2.1、LICENSE数的问题tuxedo的license由文本文件lic.txt来控制，位于udataobj目录下，分为SDK/RTK两种，两种LICENSE不能合并使用。它控制的是并发用户数并且有10%的冗余，这里的并发用户数是指在某一时刻前台程序已经发起tpinit还没有作tpterm的连接数，所以在tuxedo中间件的使用中存在着长连接和短连接的问题。长连接是指tpinit后就开始一系列的服务调用，只在系统重启或系统非常空闲的时候才做tpterm，而短连接是指每次服务调用前作tpinit，调用结束后立即作tpterm调用。因为短连接下的服务调用需要额外的连接时间消耗，这对系统响应时间会有影响，而长连接又会占用系统的并发用户数。所以在系统设计时需要针对不同的应用情况做出不同的设计，比如针对接口类型的应用因为服务调用比较频繁，进行连接的时间就会占比较大的比重，这时就需要使用长连接，而对于前台应用类型的应用，连接过程的时间对于业务操作的时间来说是可以忽略的，这时就要用短连接来节约license资源。

2.2、客户端连接的问题当客户端无法连接中间件时，我们需要确认的是
1、 客户端的WSNADDR是否设置或是否设置正确。
2、 系统配置文件中的MAXWSCLIENTS和MAXACCESS是否正确设置。
3、 WSL是否启动，WSH的个数是否足够。
4、 是否有防火墙，如果有防火墙存在，则需要在WSL的配置中作相应的地址映射和端口指定。
5、 操作系统是否有足够的SCOKET资源使用。
解决了这些问题后，一般就可以解决客户端连接不上的问题了。
在TUXEDO中，参数TMTRACE对故障的定位和排除很有作用，它是一个环境境变量。我们一般在系统监控的工作终端上将此参数设置为on，在前台报系统故障的时候，我们直接进入故障模块将故障重现，然后在终端机器的c:\或者tuxedo的安装目录下打开一个ULOG文件，在此文件中会发现tpcall服务的失败信息，根据这个信息查找对应的SERVER和SERVICE的对应表，很快就可以找到问题服务。采用这种方式，维护人员不需要了解程序的具体流程就可以定位错误解决故障。
在TUXEDO的服务端，有几类文件需要关注，这些文件包括ULOG文件、XA接口的trc文件、数据库连接故障的sqlnet.log、标准输出文件stdout（也可以被应用程序自己定义）。在这些文件中包含着丰富的系统运行错误告警信息。ULOG记载关于中间件的启停记录和系统本身的一些配置运行告警信息。XA的trc文件记录的是XA接口方面的一些的错误信息，关于分布式事务的一些错误在这个文件中都有记录。sqlnet.log记录了应用程序和数据库连接故障的信息，只要有当前日期时间的这个文件存在，应用和数据库的连接就会存在问题。标准输出文件stdout记录了应用程序本身的运行信息。这些文件的跟踪检查对于及时主动的发现故障有着重要的意义。

2.3、事务控制的问题1、事务边界的问题：在这里我们要遵循谁发起发起事务，谁就结束的原则，这里的谁主要是指中间件的前台和后台。我们知道在TUXEDO中事务的发起既可以在前台程序中发起，也可以在后台程序中发起。无论放在前台还是放在后台都有其优缺点。事务放在前台增加了网络传输的流量，当时可以保证异常情况下前后台操作的一致性，事务放在后台可以减少网络流量，但是对于异常情况下前后台操作的一致性很难保证。我们采用的是事务放在前台程序中。但是无论放在前台还是后台，都要遵循谁发起，谁结束的原则。
2、XA接口使用的注意事项：首先是XA资源文件的配置，在oracle数据库中一般用到的是libclntsh.a，我们可以先Make sample，提取其中用到的连接库加入到RM文件中即可。其次在oracle8i之前要对XA进行授权，要在oracle的DBA用户下执行grant select on dba_pending_transactions to public。
3、事务挂起的问题：在使用XA的情况下，我们经常会遇到这种情况，SERVER进程还在，可就是不做事。在相关的日志文件中总是报“当前的进程已经在一个本地事务中了”的错误，这时只有重启该SERVER，才能排除故障。其实这是一个事务控制的问题，它产生的根本原因是在开启全局事务前，该SERVER执行了一个本地的事务并且没有提交或回滚。在程序代码上表现为如下三种原因：
（1）、在调用该SERVER的某个带DML语句的service前没有加tpbegin。
（2）、在调用tpbegin后没有判断返回值。
（3）、tpbegin后的tpcall服务调用没有判断返回值，在全局事务超时后没有能够及时的退出后续的调用，导致下一个tpcall产生了一个本地事务。
此外，还会有一类比较特殊的问题，那就是TMS服务挂起的问题，利用tmadmin中的pq命令发现TMS的队列中有很多请求存在，在这种情况下，一般只能等待其执行完成，情况严重时，则需要调整相应的数据库参数，在ORACLE中该参数应该设为max_commit_propagation_delay>=90000。
在实际的运行维护中，我们发现即使把数据库参数调整了，有时还会有TMS挂起的故障发生。针对这件事情我们专门作了研究，TMS之所以挂起是因为TMS在等待数据库中DX独占锁的释放，这种独占锁加锁的对象一般都是ORACLE的系统对象，而这种独占锁的产生一般是在全局事务中执行着DML语句，当这种DML语句执行比较慢时，就会引起TMS的锁等待现象。此外，我们还发现，一般的查询语句是不会产生锁的（OPS的lm_lock锁除外），但是如果将查询放入一个全局事务中时，它就会产生一个共享的DX锁，如果这个在全局事务中的查询的调用是通过ORACLE的工具包DBMS_SQL来进行的话，那就会产生一个DX的排他锁。基于这些结果，我们建议在程序的开发过程中要遵循能不用XA全局事务的情况下就不用，能将查询放到事务之外的就不要放到事务之内，能不用ORACLE工具包进行开发的就不要用。我们也按照这个原则要求我们的开发商，取得了比较好的效果。
4、事务超时设置的问题
中间件应用系统的事务超时控制很重要，不设置超时时间对系统来说简直就是一种灾难。我们曾经就有过因为超时时间的设置没设和设置不当造成了严重的系统故障，最直接的故障就是系统报全局事务数不够的错误，无法开启新的事务，从而导致前台业务的终止。TUXEDO的超时主要有三种，一个是在代码中的tpbegin超时（值为其参数）T1，他控制整个事务的完成时间，第二个为XA连接的超时（配置文件中的open_info中的SesTm ）T2，他控制同一连接中对于分布式事务锁的等待超时时间，还有一个为数据库中等待数据库对象非分布式事务锁释放的超时时间（_dirstributed_lock_timeout）T3。这三个超时共同作用并且有如下的关系 T1

2.4、服务不能正常启动的问题在实际的维护工作中，经常会出现服务不能正常启动的现象。明明所有的服务都已经关闭了，tmboot就是起不来。这种原因一般是因为系统的IPC资源没有释放。IPC资源是操作系统用来进行进程间通讯的系统资源，主要包括信号灯、共享内存、消息队列。在UNIX操作系统下通过IPCS命令可以清楚的看到IPC资源的使用情况。当服务无法启动的时观察IPCS就会发现tuxedo运行环境的用户下的ipc资源没有被释放，这时使用ipcrm命令清除相应的IPC资源，再启动服务就可以了。
 

草木瓜 2006-6-1

------------------------
一、简介
------------------------

外部应用访问Tuxedo服务是很经常的事，一般有两种方法WTC和Jolt,网上很多关于Jolt调用Tuxedo服务
文章，描述的太多笼统，其实通过Jolt并不是很复杂的事情，这里使用Eclipse3.1+Jolt+WebLogic8.1
+Tuxedo9.0环境描述调用服务的全过程。

Jolt是Bea Tuxedo自带的jar组件，在Tuxedo9.0的安装过程中可以看到安装的Jolt组件。

调用服务理论步骤是这样的：

1.先准备Tuxedo服务端代码
2.在Tuxedo中配置Jolt相关文件
3.启动Tuxedo服务
4.配置WebLogic服务与Tuxedo Jolt相关的参数
5.配置Eclipse3.1启动WebLogic服务
6.编写Eclipse Servlet代码，运行调用服务。

本例使用了《Windows Tuxedo的安装配置-数据库补充》一文中的Tuxedo数据服务文件，所以在启动
Tuxedo服务前，必须先启动数据库实例，因为在tpsvinit()里面就配置了数据连接。关于Tuxedo配置
要点需参阅《Tuxedo的安装配置-...》的四篇文章。

------------------------
二、Tuxedo服务文件全代码
------------------------

这里把server.pc服务文件代码再次列出。其中包括三个服务DBREAD（读数据库）和TOUPPER（转换大写）。
本例不使用TOUPPER，所以不用理会那段代码。

其中liwei/liwei@windb连接的表tuxedo_test，结构如下：

CREATE TABLE TUXEDO_TEST(
ID                        NUMBER(2),
NAME                      VARCHAR2(10)
)

ID            NAME
------------------------
1             aaaaaaa
2             bbbbbbb

#include <stdio.h>
#include <ctype.h>
#include <atmi.h> /* TUXEDO Header File */
#include <userlog.h> /* TUXEDO Header File */

EXEC SQL BEGIN DECLARE SECTION;
VARCHAR ora_no[2];
int ora_id;
VARCHAR ora_value[10];
VARCHAR ora_cn[30];
EXEC SQL END DECLARE SECTION;
EXEC SQL INCLUDE sqlca;

tpsvrinit()
{
  strcpy(ora_cn.arr,"liwei/liwei@windb");
  ora_cn.len = strlen(ora_cn.arr);
  ora_cn.arr[ora_cn.len]='\0';

  //EXEC SQL WHENEVER SQLERROR GOTO cnError;
  EXEC SQL CONNECT :ora_cn;
  return(0);
}
tpsrvdone()
{
  EXEC SQL COMMIT WORK RELEASE;
}

DBREAD(TPSVCINFO *rqst)
{
 
 strcpy(ora_no.arr,(char *)rqst->data);
 ora_no.len=strlen(ora_no.arr);
 ora_no.arr[ora_no.len]='\0';

 userlog("ERRSRV: %s",ora_no.arr);
 EXEC SQL select name into :ora_value from tuxedo_test where id=:ora_no;
 if(sqlca.sqlcode!=0)
 {
  userlog("ERRSRV: select name from tuxedo_test where id=, sqlcode=%ld , sqlerr=\n",sqlca.sqlcode);
  strcpy(rqst->data,sqlca.sqlerrm.sqlerrmc);
  tpreturn(TPFAIL, 0, rqst->data, 0L, 0);
 }

 /* Return the transformed buffer to the requestor. */
 strset(rqst->data,"");
 strcpy(rqst->data,ora_value.arr);
 tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);
}

TOUPPER(TPSVCINFO *rqst)
{

 int i;

 for(i = 0; i < rqst->len-1; i++)
  rqst->data[i] = toupper(rqst->data[i]);

 /* Return the transformed buffer to the requestor. */
 tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);
}

------------------------
三、编译服务
------------------------

编译命令的注意事项，以前Tuxedo系列文章都提过。

proc server.pc include=%TUXDIR%\include
buildserver -o server -f server.c -s DBREAD -s TOUPPER -v -l orasql9.lib

------------------------
四、配置Tuxedo服务的config文件
------------------------

完全文件如下：

#Liwei

*RESOURCES
IPCKEY  123456
DOMAINID liweiapp
MASTER  lw
MAXACCESSERS 150
MAXSERVERS 100
MAXSERVICES 100
MODEL  SHM
LDBAL  N

*MACHINES
LWYM
 LMID = lw
 TUXDIR = "E:\bea\tuxedo9.0"
 TUXCONFIG = "G:\Liwei\Tuxedo\dbread\tuxconfig"
 APPDIR = "G:\Liwei\Tuxedo\dbread"
 MAXWSCLIENTS=1
 TLOGDEVICE = "G:\Liwei\Tuxedo\dbread\TLOG"
 TLOGNAME=TLOG
 TLOGSIZE = 100
 
*GROUPS

APPGRP LMID=lw GRPNO = 1

#OPENINFO="Oracle_XA:Oracle_XA+Acc=P/liwei/liwei+SqlNet=linux+SesTm=600+MaxCur=5+LogDir=."
#TMSNAME="TMS_ORA9i" TMSCOUNT=2

JSLGRP  LMID=lw GRPNO = 2             
JREPGRP LMID=lw GRPNO = 3             

*SERVERS
server SRVGRP=APPGRP SRVID=1

#WSL SRVGRP=APPGRP SRVID =300
#CLOPT="-A -- -n //192.168.0.166:8888 -d/dev/tcp -m1 -M5 -x 10"

JSL SRVGRP=JSLGRP SRVID=301
CLOPT="-A -- -n //192.168.0.166:9878 -M 10 -x 10 -m 2"

JREPSVR SRVGRP=JREPGRP SRVID=302
CLOPT="-A -- -W -P E:\bea\tuxedo9.0\udataobj\jolt\repository\jrepository"

*SERVICES
DBREAD
TOUPPER

细心一看，这个config文件比在*GROUPS和*SERVERS各加了两项对应内容：

JSLGRP  LMID=lw GRPNO = 2             
JREPGRP LMID=lw GRPNO = 3    
和
JSL SRVGRP=JSLGRP SRVID=301
CLOPT="-A -- -n //192.168.0.166:9878 -M 10 -x 10 -m 2"
JREPSVR SRVGRP=JREPGRP SRVID=302
CLOPT="-A -- -W -P E:\bea\tuxedo9.0\udataobj\jolt\repository\jrepository"

这两项是用于jolt的访问接口。JSL和JREPSVR必须是独自的GROUP，由于外部调用通过JSL和JREPSVR直接于
Tuxedo服务通信，WSL就没用了。JSL的主机地址是Tuxedo服务器地址，端口是随意指定的，不要与其他重复
即可，一般设置的大一点。在config里面加入这此内容后，config文件就Ok了。

------------------------
五、配置jrepository文件
------------------------

直接打开E:\bea\tuxedo9.0\udataobj\jolt\repository\jrepository文件添加以下内容：

add SVC/DBREAD:vs=1:ex=1:bt=STRING:\
 bp:pn=STRING:pt=string:pf=167772161:pa=rw:ep:
add PKG/SIMPSERV:DBREAD:

这个文件如果没有DBREAD配置，调用会提示DBREAD not avaliable，DBREAD配置错误，会提示DBREAD has
been modifed ...

对这个文件操作还有以下两种方式：

方式一：在IE打开E:\bea\tuxedo9.0\udataobj\jolt\RE.html，是个java applet，里面是图形界面，添加
 完服务，设置好参数即可。具体方法可以查阅网上资料，有图文解说的。
方式二：在命令行键入Java bea.jolt.admin.jbld //192.168.0.166:9878 services.rep，其中//192..要与
JSL的设置一致。services.rep是随意的一个文件，不过文件内容绝对不随意，如下：

service=DBREAD
inbuf=STRING
outbuf=STRING
export=true
param=STRING
type=string
access=inout

要执行这个命令设置jdk环境变量是必不可少的，PATH，CLASSPATH。我的CLASSPATH加入了以下内容，
E:\bea\tuxedo9.0\udataobj\jolt\joltwls.jar;
E:\bea\tuxedo9.0\udataobj\jolt\joltjse.jar;
E:\bea\tuxedo9.0\udataobj\jolt\jolt.jar;
E:\bea\tuxedo9.0\udataobj\jolt\joltadmin.jar
个人认为对于这个java命令joltadmin是必须的，其他三个没用，不过没有亲自尝试。

方式一，二修改后，jrepository文件会显得比较乱，所以我不喜欢！最好是自已手工修改。

------------------------
六、编译启动服务
------------------------

当然，数据库必须要有了，编译config后，启动tuxedo服务。
tmloadcf -y config
tmboot -y

提示如下：

exec BBL -A :
        process id=3520 ... Started.

Booting server processes ...

exec server -A :
        process id=3812 ... Started.
exec JSL -A -- -n //192.168.0.166:9878 -M 10 -x 10 -m 2 :
        process id=252 ... Started.
exec JREPSVR -A -- -W -P E:\bea\tuxedo9.0\udataobj\jolt\repository\jrepository :

        process id=2920 ... Started.
4 processes started.

------------------------
七、配置Eclipse3.1
------------------------

我们要在Eclipse里面启动WebLogic服务，《Eclipse3.1 Web开发配置》一文中已经说明了，如何配置
WebLogic8.1的服务器，这里对WebLogic的服务本身也要做此必要的配置。

打开选用的WebLogic8.1服务路径，编辑config.xml文件，本机位置G:\Liwei\WebLogic\WebServer\config.xml。
加入如下内容：

    <JoltConnectionPool FailoverAddresses="//192.168.0.166:9878"
        MaximumPoolSize="2" MinimumPoolSize="1" Name="JoltPool"
        PrimaryAddresses="//192.168.0.166:9878"
        SecurityContextEnabled="false" Targets="webServer"/>
    <StartupClass
        ClassName="bea.jolt.pool.servlet.weblogic.PoolManagerStartUp"
        LoadBeforeAppActivation="true" Name="MyStartup" Targets="webServer"/>
    <ShutdownClass
        ClassName="bea.jolt.pool.servlet.weblogic.PoolManagerShutDown"
        Name="MyShutdown" Targets="webServer"/>
       
这里要说明一下：PrimaryAddresses，FailoverAddresses地址是前面Tuxedo配置文件指定的JSL地址和端口
SecurityContextEnabled一定要是false!所有name是随意的，StartupClass和ShutdownClass的ClassName
绝对不能错！

除此方法，还可以通过Weblogic服务的控制台进行管理。启动服务后，在http://localhost:7001/console/
登陆后的主页面上选择 连接性->通过 JOLT 的 Tuxedo  ->配置新的Jolt 连接缓冲池...输入参数内容就是
上面config.xml的参数。另外首页中 已部署的资源 ->启动和关闭 需要设置两个Class，参数也同上。

连接性->通过 JOLT 的 Tuxedo  ->配置新的Jolt 连接缓冲池...

①进入选项卡的General(常规),输入参数:
Name:   JoltPool
Minimum Pool Size:  1
Maximum Pool Size:   2
Recv Timeout:  0
点击Apply应用按纽
②进入选项卡的Addresses(地址),输入参数:
Primary Addresses: //192.168.0.166:9878
Failover Addresses: //192.168.0.166:9878
点击Apply应用按纽
③进入Targets栏：
选中myserver
点击Apply应用按纽.

已部署的资源 ->启动和关闭 分别配置StartUp,ShutDown的Class

①进入Configuration(设置)
在ClassName:中输入: bea.jolt.pool.servlet.weblogic.PoolManagerStartUp,
其它采用默认值。
②进入Targets(目标)栏：
选中myserver,点击Apply应用按纽.

①进入Configuration(设置)
在ClassName:中输入: bea.jolt.pool.servlet.weblogic.PoolManagerShutDown,
其它采用默认值。
②进入Targets(目标)：
选中myserver,点击Apply应用按纽.

到这里config.xml文件就设置完了，下面需要编辑startWebLogic.cmd，加入对jolt jar的引用，否则jolt
是启动失败的。在echo CLASSPATH=%CLASSPATH%前加入以下代码，设置CLASSPATH，这里classpath跟外部环境
变量是两码事。

set CLASSPATH=%CLASSPATH%;E:\bea\tuxedo9.0\udataobj\jolt\jolt.jar;E:\bea\tuxedo9.0\udataobj\jolt\joltwls.jar;E:\bea\tuxedo9.0\udataobj\jolt\joltjse.jar

设置完后，重启服务，在Eclipse管理WebLogic服务时如果出现启动关闭不成功，多试几次就可以了。
在启动的console界面里如果出现以下内容，就说明jolt pool启动成功！

<2006-6-1 下午09时12分55秒 CST> <Notice> <WebLogicServer> <BEA-000327> <Starting WebLogic Admin Server "webServer" for domain "WebServer">
Jolt pool deployed for webServer
<2006-6-1 下午09时13分13秒 CST> <Notice> <Security>...

------------------------
八、Eclipse3.1编写Servlet代码
------------------------

首先需要在所建工程->右键->Properties->Java BuildPath ->Library->Add External jars ..添加jolt的jar包
这里需要三个jar包，如下：
E:\bea\tuxedo9.0\udataobj\jolt\jolt.jar
E:\bea\tuxedo9.0\udataobj\jolt\joltjse.jar
E:\bea\tuxedo9.0\udataobj\jolt\joltwls.jar
 
添加jar完后，建立一个主页面index.jsp和一个Servlet。关于Eclipse3.1配置Servlet在《Eclipse3.1 Web开发配置》
一文也有说明。这里Servlet名为liwei.java,具体内容如下：

index.jsp

<body>
<form id=form1 name="form1" action=liwei method=post>
<input type="text" name="STRING" value="1">
<input type=submit value=submit>
</form>
</body>

说明：name要是STRING,用来传递参数，action是liwei.java即Servlet。

liwei.java

 public class liwei extends javax.servlet.http.HttpServlet 
 {
 
 //声明管理连接池的变量
 private bea.jolt.pool.servlet.ServletSessionPoolManager bool_mgr = (bea.jolt.pool.servlet.ServletSessionPoolManager) bea.jolt.pool.SessionPoolManager.poolmgr;

 public void init(javax.servlet.ServletConfig config) throws javax.servlet.ServletException
 {
  //初始化servlet
  super.init(config);
 }
   
 public void destroy() {
  //关闭servlet
  bool_mgr = null;
 } 
 
 protected void doGet(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response)
 throws javax.servlet.ServletException, java.io.IOException
 {
  
  bea.jolt.pool.servlet.ServletResult result;
  
  //设置页面类型，如果没有charset，显示汉字会乱码
  response.setContentType("text/html;charset=UTF-8");
  
  java.io.PrintWriter out =response.getWriter();
  out.println("<html>");
  out.println("<body>");
  
  //System.out.println("TEST________________________1");

   //获取在WebLogic服务定义好的连接池,JoltPool
   bea.jolt.pool.servlet.ServletSessionPool pool_session = (bea.jolt.pool.servlet.ServletSessionPool)
   bool_mgr.getSessionPool("JoltPool");

    if (pool_session == null) {
      out.println("获取Tuxedo服务失败。"+
                  "<br>"+
                  "确认Tuxedo服务已启动且配置正确。"+
                  "</font></body></html>");
      out.close();
      return;
    }
    System.out.println(pool_session);
    
    String sendvalue;
    sendvalue=request.getParameter("STRING");
    System.out.println(sendvalue);
    
    // 调用服务
    try
    {
     System.out.println("OK!");
     
     //调用服务DBREAD
      result = pool_session.call("DBREAD", request);
      out.println("传递的参数 = " + sendvalue);
      out.println("Tuxedo服务成功调用。 ");
     
      //跟据传递的变量STRING值，获取返回值
      out.println("返回值："+result.getValue("STRING", ""));
    }
    catch (bea.jolt.pool.SessionPoolException e)
    {
      // 连接池繁忙
      out.println("此时请求不能被处理。\n"+
                  "错误信息: "+e.getMessage()+"\n"+
                  "可能的原因：1.无效的连接池 2.连接池已关闭");
    }
    catch (bea.jolt.pool.ServiceException e)
    {
    // 服务出错，这里主要是Tuxedo的服务配置，jrepository文件出错
      e.printStackTrace();
      out.println("错误信息："+
                  "Error message:"+e.getMessage()+
                  "Error number:"+e.getErrno());
    }
    catch (bea.jolt.pool.ApplicationException e)
    {
      // 应用程序出错
      result = (bea.jolt.pool.servlet.ServletResult) e.getResult();
      out.println("错误代码："+result.getApplicationCode());
    }
    catch (Exception e)
    {
      out.println("意外错误："+e);
    }
   
    out.println("</body></html>\n");
    out.close();
 } 
 
 protected void doPost(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response)
 throws javax.servlet.ServletException, java.io.IOException
 {
  this.doGet(request,response);
 }          
}

------------------------
九、RUN
------------------------

Run on server ，点击Submit，显示 传递的参数 = 1 Tuxedo服务成功调用。 返回值：aaaaaaa !


=======================

Java通过Jolt访问Tuxedo服务-补充说明

草木瓜

2006-6-2

一、页面参数文件说明以及通过WebLogic调用Tuxedo服务

《Java通过Jolt访问Tuxedo服务》一文是在Eclipse环境下开发调用Tuxedo服务。

其中在index.asp和liwei.java中有这么几句语句：

index.asp

<form id=form1 name="form1" action=liwei method=post>
<input type="text" name="STRING" value="1">
<input type=submit value=submit>

liwei.java

//跟据传递的变量STRING值，获取返回值
out.println("返回值："+result.getValue("STRING", ""));

这两段的STRING是不可以随便替换的，这必须与E:\bea\tuxedo9.0\udataobj\jolt\repository
下jrepository文件描述的服务参数相一致！且必须为大写！即：

add SVC/DBREAD:vs=1:ex=1:bt=STRING:\
 bp:pn=STRING:pt=string:pf=167772161:pa=rw:ep:       //这里面定义的参数就是STRING
add PKG/SIMPSERV:DBREAD:
     
下面用WebLogic对Tuxedo服务调用再详细的举例说明。

WebLogic通过jolt调用Tuxedo服务，有了上文的前提就显得很容易，说白了只是Servlet与Jsp的一点
小转换。除了最后一步在Eclipse3.1编写Servlet代码，其他的前提步骤是必须的。WebLogic要使用
Jolt接口，同样需要jolt,joltjse,joltwls三个jar包，将它们Copy到WEB-INF下的lib文件夹即可。

以下是完整的示例，参数名用大写的TEST。

index.jsp
---------------------------------

<form action="_test/testTuxedo.jsp" method="post">
<p>
<input type="text" value="1" name="TEST" id="text1"><input type="submit" value="tuxedo">
</p>
</form>

testTuxedo.jsp
---------------------------------

<body>
<p>
   
    <%
      bea.jolt.pool.servlet.ServletSessionPoolManager bool_mgr = (bea.jolt.pool.servlet.ServletSessionPoolManager) bea.jolt.pool.SessionPoolManager.poolmgr;
      bea.jolt.pool.servlet.ServletResult result;
     //获取在WebLogic服务定义好的连接池
     bea.jolt.pool.servlet.ServletSessionPool pool_session = (bea.jolt.pool.servlet.ServletSessionPool)
       bool_mgr.getSessionPool("JoltPool");
     if (pool_session == null) {
       out.println("获取Tuxedo服务失败。"+
                   "<br>"+
                   "确认Tuxedo服务已启动且配置正确。");
       out.close();
       return;
     }
     // 调用服务
     try
     {
       result = pool_session.call("DBREAD", request);
       System.out.println("OK!");
       out.println("传递的参数 = " + sendvalue);
       out.println("Tuxedo服务成功调用。 ");
       out.println("返回值："+result.getValue("TEST", ""));
     }
     catch (bea.jolt.pool.SessionPoolException e)
     {
       // 连接池繁忙
       out.println("此时请求不能被处理。\n"+
                   "错误信息: "+e.getMessage()+"\n"+
                   "可能的原因：1.无效的连接池 2.连接池已关闭");
     }
     catch (bea.jolt.pool.ServiceException e)
     {
       // 服务出错
     e.printStackTrace();
       out.println("Error："+
                   "Error message:"+e.getMessage()+
                   "Error number:"+e.getErrno());
     }
     catch (bea.jolt.pool.ApplicationException e)
     {
       // 应用程序出错
       result = (bea.jolt.pool.servlet.ServletResult) e.getResult();
       out.println("错误代码："+result.getApplicationCode());
     }
     catch (Exception e)
     {
       out.println("意外错误："+e);
     }
    
  %>
</p>
</body>

二、典型的服务应用

Oracle服务器   192.168.0.111
Tuxedo服务器   192.168.0.66
Web服务器     

通过Web客户端访问Web服务器，调用Tuxedo服务访问数据库

1.配置Tuxedo服务器的Oracle连接字符串(TNSNAME)。注意Oracle服务器的防火墙

WINDB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.111)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = wincn)
    )
  )
 
2.配置Tuxedo的jrepository文件
3.配置Tuxedo的Config文件,JSR服务的IP与端口要与本地IP一致。

JSL SRVGRP=JSLGRP SRVID=301
CLOPT="-A -- -n //192.168.0.66:9988 -M 10 -x 10 -m 2"

4.配置Web服务器的WebServer，config.xml中ip与端口即为Tuxedo服务器的JSR服务IP与端口
注意Tuxedo服务器的防火墙。

<JoltConnectionPool FailoverAddresses="//192.168.0.66:9988"
    MaximumPoolSize="2" MinimumPoolSize="1" Name="JoltPool"
    PrimaryAddresses="//192.168.0.66:9988"
    SecurityContextEnabled="false" Targets="webServer"/>

Windows下Tuxedo的安装与配置-数据库

草木瓜 2005-5-18

一、准备数据库环境

  这里使用的是Linux+Oracle9的虚拟机数据库环境。本机配置Tuxedo服务器。在上篇无数据库配置
  基础上，配置Tuxedo服务器连接Oracle理解起来就相对简单了。这里采用XA方式连接数据库。

二、准备客户端，服务端的应用程序
 
  这里是自已写的代码。
 
  client.c
 
#include <stdio.h>
#include <atmi.h>  /* TUXEDO  Header File */

main(int argc, char *argv[])
{
 char *sendbuf;
 long sendlen=1024;
 int ret;

 
 if(argc != 2) {
  (void) fprintf(stderr, "args not exist\n");
  exit(1);
 }

 /* 与服务器建立连接 */
 if (tpinit((TPINIT *) NULL) == -1)
 {
  (void) fprintf(stderr, "Tpinit failed\n");
  exit(1);
 }

 /* 分配发送缓冲 */
 sendbuf = (char *) tpalloc("STRING", NULL, sendlen);
 if (sendbuf== (char *)NULL)
 {
  (void) fprintf(stderr,"Error allocating send buffer\n");
  tpterm();
  exit(1);
 }

 (void) strcpy(sendbuf, argv[1]);
 (void) fprintf(stdout, "InputValue: %s\n", argv[1]);

 /* 向服务发送请求 */
 ret = tpcall("DBSERV", (char *)sendbuf, 0L, (char **)&sendbuf, &sendlen, 0L);
 if(ret == -1) {
  (void) fprintf(stderr, "Can't send request to service DBREAD\n");
  (void) fprintf(stderr, "Tperrno = %d\n", tperrno);
  tpfree(sendbuf);
  tpterm();
  exit(1);
 }

 (void) fprintf(stdout, "Returned string is: %s\n", sendbuf);
 
 /* Free Buffers & Detach from System/T */
 tpfree(sendbuf);
 tpterm();
 return(0);
}

  server.pc 这里用到了ProC的一些方法
 
#include <stdio.h>
#include <ctype.h>
#include <atmi.h> /* TUXEDO Header File */
#include <userlog.h> /* TUXEDO Header File */

EXEC SQL INCLUDE sqlca;

EXEC SQL BEGIN DECLARE SECTION;

VARCHAR ora_no[2];
VARCHAR ora_value[10];
EXEC SQL END DECLARE SECTION;

DBREAD(TPSVCINFO *rqst)
{

 strcpy(ora_no.arr,(char *)rqst->data);
 ora_no.len=strlen(ora_no.arr);
 ora_no.arr[ora_no.len]='\0';
 
 userlog("ERRSRV: %s",ora_no.arr);
 EXEC SQL select name into :ora_value from tuxedo_test where id=:ora_no;
 if(sqlca.sqlcode!=0)
 {
  userlog("ERRSRV: select name from tuxedo_test where id=, sqlcode=%ld \n",sqlca.sqlcode);
  tpreturn(TPFAIL, 0, rqst->data, 0L, 0);
 }

 strcpy(rqst->data,ora_value.arr);
 tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);
}

三、编译客户端，服务端代码

  buildclient -o client -f client.c -v
 
  对pc文件，须首先编译为c，然后再编译为服务。在proc编译的过程，会出现link错误，这是因为tuxedo本身
  带的sqlca.h与oracle proc冲突，将C:\bea\tuxedo9.0\include\sqlca.h改名即可。
  proc server.pc include=%TUXDIR%/include
  buildserver -o server -f server.c -r Oracle_XA -s DBREAD -v

 
四、配置Tuxedo的RM文件

  本地Tuxedo9.0安装路径为C:\bea\tuxedo9.0。
  打开C:\bea\tuxedo9.0\udataobj路径下的rm文件。找到Oracle_XA:这句，可以注释掉，然后增加下面内容。
  Oracle_XA;xaosw;E:\oracle\ora92\rdbms\XA\ORAXA9.LIB E:\oracle\ora92\precomp\lib\orasql9.lib
  注：本机如果没有装服务版的Oracle,可能找不到对应库文件，可从服务器端复制过来即可。
 
  这两个lib是用于编译tms文件的，tuxedo通过TMS_ORA9i与Oracle数据库进行XA通讯。
  修改完rm文件，运行命令buildtms -o C:\bea\tuxedo9.0\bin\TMS_ORA9i -r Oracle_XA编译生成TMS_ORA9i。
 
 
五、修改ubbconfig文件

  在*GROUP下添加下面语句。liwei/liwei@linux是连接数据库的tns配置。TMSCOUNT=2表示启动两个TMS服务。
 
  OPENINFO="Oracle_XA:Oracle_XA+Acc=P/liwei/liwei+SqlNet=linux+SesTm=600+MaxCur=5+LogDir=."
  TMSNAME="TMS_ORA9i" TMSCOUNT=2
 
  另外在*MACHINES添加日志的处理，语句如下。
  TLOGDEVICE = "F:\Liwei\Tuxedo\dbread\TLOG"
 TLOGNAME = TLOG
 TLOGSIZE = 100
 
 因为编译的服务文件名是server,*SERVERS下改为server
 因为生成的服务是DBREAD，所以*SERVICES下也要改成DBREAD。
 
 修改后文件如下：
  
#Liwei

*RESOURCES
IPCKEY  123456
DOMAINID liweiapp
MASTER  lw
MAXACCESSERS 5
MAXSERVERS 5
MAXSERVICES 5
MODEL  SHM
LDBAL  N

*MACHINES
LWYM
 LMID = lw
 TUXDIR = "C:\bea\tuxedo9.0"
 TUXCONFIG = "F:\Liwei\Tuxedo\dbread\tuxconfig"
 APPDIR = "F:\Liwei\Tuxedo\dbread"
 
 TLOGDEVICE = "F:\Liwei\Tuxedo\dbread\TLOG"
 TLOGNAME=TLOG
 TLOGSIZE = 100
 #ULOGPFX = "F:\Liwei\Tuxedo\dbread\ULOG"
 
*GROUPS
GROUP1 LMID=lw GRPNO = 1
OPENINFO="Oracle_XA:Oracle_XA+Acc=P/liwei/liwei+SqlNet=linux+SesTm=600+MaxCur=5+LogDir=."
TMSNAME="TMS_ORA9i" TMSCOUNT=2

*SERVERS
DEFAULT:
  CLOPT="-A"
server SRVGRP=GROUP1 SRVID=1
*SERVICES
DBREAD

  编译日志后不能立刻tmboot运行，需要先用tmadmin创建TLOG。方法如下：
 
  C:\>tmadmin
  >crdl -b 500 -z F:\Liwei\Tuxedo\dbread\TLOG
  >crlog -m lw

  注：lw是ubbconfig里面的LMID。
 
六、Oracle的设置
 
  Linux：
 
  sqlplus /nolog
  conn sys/*** as sysdba
 
  执行xaview.sql 创建v$xatrans$和 v$pending_xatrans$两个视图
  @...../rdbms/admin/xaview.sql
 
  并把两个视图的select权限授给连接用户如liwei。
 
  grant select on v$xatrans$ to liwei with grant option;
  grant select on v$pending_xatrans$ to liwei with grant option;
 
  最后
 
  grant select any table to liwei;
 
 
七、运行tmboot

  你会发现有个TMS_ORA9i启动不起来，没关系，将*RESOURCES max系列的设大点，tmshutdown,并且
  结束掉tuxipc，重新编译config然后tmboot就ok了。
 
  client 1
  执行就会返回数据库结果了。

Windows下Tuxedo的安装配置-数据库补充

草木瓜 2006-5-28

一、序

《Windows下Tuxedo的安装配置-数据库》一文中介绍了通过XA方法连接数据库，步骤比较多，当然也可以采
用另一种方法，在服务程序里面直接写入连接数据库的命令。

二、服务端程序

小作修改

EXEC SQL BEGIN DECLARE SECTION;
VARCHAR ora_no[2];
VARCHAR ora_value[10];
VARCHAR ora_cn[30];               //新增
EXEC SQL END DECLARE SECTION;

EXEC SQL INCLUDE sqlca;

//新增以下内容，tpsvinit,tpsrdone是tuxedo默认构造和析构函数。
tpsvrinit()
{
  strcpy(ora_cn.arr,"liwei/liwei@windb");
  ora_cn.len = strlen(ora_cn.arr);
  ora_cn.arr[ora_cn.len]='\0';
  EXEC SQL CONNECT :ora_cn;
  return(0);
}
tpsrvdone()
{
  EXEC SQL COMMIT WORK RELEASE;
}

三、配置文件

注释掉与XA相关项，由于客户端与服务器是同一台机器，WSL要不要无所谓。这里也注释掉。

*GROUPS

GROUP1 LMID=lw GRPNO = 1

#OPENINFO="Oracle_XA:Oracle_XA+Acc=P/liwei/liwei+SqlNet=linux+SesTm=600+MaxCur=5+LogDir=."
#TMSNAME="TMS_ORA9i" TMSCOUNT=2

*SERVERS
server SRVGRP=GROUP1 SRVID=1

#WSL SRVGRP=GROUP1  SRVID =300
#CLOPT="-A -- -n //192.168.98.166:5898 -d/dev/tcp -m1 -M5 -x 10"

*SERVICES
DBREAD

四、编译服务端的命令

修改如下：

proc server.pc include=%TUXDIR%\include
buildserver -o server -f server.c -s DBREAD -v

如果在编译过程中出现error LNK2001: unresolved external symbol _sqlcxt类似的错误，那是因为
找不到orasql9.lib文件。设置环境变量lib,加上e:\oracle\ora92\precomp\lib，修改命令：

buildserver -o server -f server.c -s DBREAD -v -l orasql9.lib

五、编译config文件，运行tmboot

六、补充说明

Tuxedo配置一般如下步骤：

1 设置环境变量。
2 准备服务端客户端程序。
3 服务端客户端编译（buildclient buildserver）。
4 准备tuxedo的config文件。
5 编译config文件（tmload）。
6 如果config文件包含日志，必须通过tmadmin生成日志文件(crdl,crlog)，如出错须将原日志文件删除。
7 启动tuxedo服务（tmboot）。

进入linux系统，在linux系统dos输入页面中输入tmadmin

进入tmadmin的监管环境，输入下面的命令即可

启动tmadmin
tmboot  -y

1查看服务信息psr
(1) 命令: printserver 简写 psr
(2)  psr [-m machine] [-g groupname] [-i srvid] [-q qaddress]
-m machine LMID为 machine的所有服务进程
-g groupname 组名为groupname的所有服务进程
-I srvid SRVID为srvid的服务进程
-q qaddress 消息队列为qaddress的所有SERVERS查看server的信息
(3) 结果示例:
Prog Name     Queue Name   Grp Name      ID   RqDone  Load Done  Current Service
---------    ----------    --------      --    ------  ---------  ---------------
rz_Ecsb        00004.04000   APGP2       4000    0        0       (  IDLE )
BBL            70020         simple         0     1       50       (  IDLE )
IFMTMS         APGP2_TMS    APGP2      30001     1       50       (  IDLE )
ftpserv32      00002.00001  FTPGP          1    60      3000     (  IDLE )
结果说明:
列号  描述
1. 服务的可执行文件名
2. 服务连接的队列名
3. 组名
4. 服务的数字id
5. 服务已经处理的请求数(该SERVER的所有service的负载因子总和)
6. 服务处理的全部请求的参数和，如果当前没有service被调用，则为IDLE
2查看交易信息psc
(1)  命令: printservice  简写: psc
psc [-m machine] [-g groupname] [-I srvid] [-q qaddress]
[-s service] [-a {0|1|2}]
-s service 显示名为sevice的service信息
-a {0|1|2} 显示系统的隐含的service
其他参数与psr命令相同
(2)  结果示例:
Service Name   Routine Name   Prog Name  Grp Name   ID   Machine   # Done   Status
------------   ------------     -------    --------   --   -------   ------   ------
416701         rz_Ecsb         rz_Ecsb     APGP2     4000    simple    0      AVAIL
416601         rz_Ecsb         rz_Ecsb     APGP2     4000    simple    0      AVAIL
416501         rz_Ecsb         rz_Ecsb     APGP2     4000    simple    0      AVAIL
(3)  结果说明:
列号    描述
1. Service Name :服务名
2. Routine Name :函数名(采用TUXEDO服务的别名机制,一个函数可以对应多个服务名)
3. Prog Name :service 所在的SERVER名
4. Grp Name :组名
5. ID ：server的ID号
6. Machine :server所在的LMID
7. # Done ：service被调用的次数
8. Status :service的状态。AVAIL表示可用
3查看队列信息pq
(1) 命令: printqueue 简写:pq [PADRESS]
(2) 结果示例:
pq 00004.05062
Prog Name      Queue Name  # Serve  Wk Queued  # Queued  Ave. Len    Machine
---------    ------------  ------   ---------  --------  --------    -------
CCS_GEDAIPC_50 00004.05062     1         0        0       0.0       simple
(3) 结果说明:
列号    描述
1. Prog Name :队列连接的服务的可执行文件名
2. Queue Name :字符队列名，是RQADDR参数或一个随机值
3. #Serve :连接的服务数
4. Wk Queued :当前队列的所有请求的参数和
5. #Queued :实际请求数
6. Ave.Len :平均队列长度
7. Machine :队列所在机器的LMID
4查看客户端信息pclt
(1) 命令: printclient 简写:pclt
-m machine 显示LMID号为machine上的客户端连接
-u username 显示用户名为username 的客户端连接
-c ctlname 显示用户进程为ctlname的客户端连接
(2) 结果示例:
  LMID        User Name       Client Name    Time    Status  Bgn/Cmmt/Abrt
---------- --------------- --------------- -------- ------- -------------
simple          ccsmis          WSH        17:42:47   IDLE      0/0/0
simple          ccsmis          tmadmin    0:44:28    IDLE      0/0/0
(3) 结果说明:
列号  描述
1. 已经登录的客户端机器的LMID
2. 用户名，由tpinit()提供的
3. 客户端名，由tpinit()提供的
4. 客户端连接后经过的时间
5. 客户端状态
6. IDLE——表示客户端目前没有任何交易在工作
7. IDLET——表示客户端启动了一个交易
8. BUSY——表示客户端在工作中
9. BUSYT——表示客户端正在交易控制下工作
10. 启动/提交/中断的交易数

5查看部分统计信息bbs
(4) 命令: bbstats  简写：bbs
> bbs
Current Bulletin Board Status:
Current number of servers: 335
Current number of services: 2324
Current number of request queues: 27
Current number of server groups: 11
Current number of interfaces: 0

6观察某个节点的进程信息default
(5) 命令：default –m
> default -m SITE13

SITE13> psr
Prog Name      Queue Name  Grp Name      ID RqDone Load Done Current Service
---------      ----------  --------      -- ------ --------- ---------------
BBL            30004.00000 SITE13         0  22827   1141350 ..ADJUNCTBB
BRIDGE         836437      SITE13         1      0         0 (  IDLE )
GWADM          00021.00019 BGWGRP1+      19      0         0 (  IDLE )
GWTDOMAIN      00021.00020 BGWGRP1+      20 123826         0
GWADM          00022.00021 BGWGRP2+      21      0         0 (  IDLE )
GWTDOMAIN      00022.00022 BGWGRP2+      22      0         0 (  IDLE )
GWADM          00025.00027 GWGRP1_+      27      4       200 (  IDLE )

7查看消息发送状态pnw
(6) 命令：printnetwork 简写 pnw
> pnw SITE12

SITE12                         Connected To:  msgs sent    msgs received
                                      SITE14      61904            62319
                                      SITE13      61890            62288
                                      SITE11      15972            13564
8退出管理模式q
(7) 命令: quit  简写：q

C++ constructors are called to initialize class objects when those objects are created, and destructors are invoked when class objects are destroyed. For automatic (that is, local, non-static) variables that contain constructors and destructors, the constructor is called when the variable comes into scope and the destructor is called when the variable goes out of scope. However, when you call the tpreturn() or tpforward() function, the compiler performs a non-local goto (using longjmp(3)) such that destructors for automatic variables are not called. To avoid this problem, write the application so that you call tpreturn() or tpforward() from the service routine directly (instead of from any functions that are called from the service routine). In addition, one of the following should be true:

• The service routine should not have any automatic variables with destructors (they should be declared and used in a function called by the service routine).

   

• Automatic variables should be declared and used in a nested scope (contained within curly brackets {}) in such a way that the scope ends before calling the tpreturn() or tpforward() function.