中间件在下面几个方面有很大的优势：
中间可以屏蔽数据库的异构性，当选用不同的数据软件时，可以通过选用中间软件，来屏蔽他们之间的不同之处，实现透明访问；
平衡系统负载，提高系统的可靠性、稳定性、可用性；
为实现分布式数据库提供一条简便的途径，采用TUXEDO基于事务的XA数据访问方式，可以很好的实现数据库的一致性，程序员不用为数据库的一致性而分散精力，将精力集中在关键业务的把握上。
Tuxedo 从逻辑上可以将应用分为以下几个层次：Domain、Machine、Group、Server、Service。可以通过两种方式来实现Service 与Service之间的相互调用。通过tpcall进行同步或异步调用；通过tpforword实现交易请求的转发
TUXEO系统的运行需要三类IPC资源：Share Memory，Message Queue，semphone
交易调用过程系统交易的发起过程，需要综合调用各种IPC资源。协调系统的各个管理进程协同工作。在整个交易的调用过程中：
1 首先客户端，跟需要通过TUXEDO的tpinit函数调用建立与TUXEDO服务端的通讯连接。在这一过程中同时完成对客户端的登陆用户的鉴权。在通过鉴权后，TUXEDO的系统进程WSL为其分配一个WSH受理以后发起的请求。在这一过程中，TUXEDO的WSL侦听进程对连接占用的时间进行控制（timeout是WSL的启动参数，可配），当连接超时时，TUXEDOWSL将断开WSH。如果WSH比较繁忙，无暇处理新的连接请求，那么WSL就将请求放入消息队列中，等待受理。当然请求不会无限在消息队列中等待，超时后清除。
2 TUXEDO客户准备前台数据，并发起服务调用请求，通过 tpcall/tpacall将请求的服务命令字，以及请求数据包发送到服务端。TUXEDO服务端将客户端提交的请求交于WSH。WSH代理客户端的请求，将用户的请求放入对应的接收消息队列中。服务处于等待状态，直到有空闲SERVER来受理用户请求。超时时间通过ubbconfig中的 *resource段blocktime进行控制。超时后返回系统交易失败。
TUXEDO通过维护SERVICE和SERVER对应表，来根据SERVICE查找到受理它的对应进程。
3 SERVER 进程自从启动后，一直监视接收消息队列，当空闲且恰有请求位于消息队列时，从接收消息队列中取出请求，交于相应的交易处理函数处理用户请求。从交易的受理到交易的受理结束通过SERVICE段SVCTIMEOUT参数进行控制，当受理超时时，BBL向对应进程发KILLSIG。对于基于XA的应用，当事务处理超过tpbegin的超时参数时，SERVICE处理结束，返回交易失败。
4 SERVER进程将处理结果，返回数据提交到发送消息队列，由系统将返回数据返回客户端，当返回数据失败时，系统在ULOG日志中记录告警信息。
5 前台客户端取出数据，分析交易受理结果。
6 断开与后台服务端的连接，调用TUXEDO tpterm函数释放与TUXEDO服务端的连接。
一、首先设置合理的操作系统核心参数！！
#用tmunloadcf > generated.ubb 可以得出目前配置得UBB文件所有得参数值（没有设置的有缺省值）
#用tmloadcf –c或tmboot –c可以计算出当前UBB配置的Tuxedo启动最少要占用的系统IPC资源。
Ipc sizing (minimum /T s only) ...
Fixed Minimums Per Processor
SHMMIN: 1
SHMALL: 1
SEMMAP: SEMMNI
Variable Minimums Per Processor
SEMUME, A SHMMAX
SEMMNU, * *
Node SEMMNS SEMMSL SEMMSL SEMMNI MSGMNI MSGMAP SHMSEG
------ ------ ------ ------ ------ ------ ------ ------
KF_FENGM 65 8 60 A + 1 37 74 220K
where 1 <= A <= 8.
SEMMNS
Maximum number of semaphores in the system. The minimum requirement for SEMMNS is
MAXACCESSERS - MAXWSCLIENTS + 13
SEMMNI
Maximum number of active semaphore sets
SEMMSL
Maximum number of semaphores per semaphore set. SEMMNI and SEMMSL are commonly chosen so that their product equals SEMMNS. The BEA Tuxedo system does not perform semaphore operations on semaphore sets; however, it attempts to allocate as many semaphores per semaphore set as possible
SEMMAP
Size of the control map used to manage semaphore sets. SEMMAP should be equal to SEMMNI
SEMMNU
Number of undo structures in the system. Because an undo structure is needed for each process that can access the Bulletin Board, SEMMNU must be at least as large as SEMMNS
SEMUME
Maximum number of undo entries per undo structure. The 1 suffices.
二、BEA Tuxedo配置文件UBBCONFIG
UBB配置文件分成*RESOURCES,*GROUP,*SERVER,*SERVICE,*NETWORK等若干节。DEFAULT表示该节中所有对象共有的缺省属性。
*RESOURCES
#RESOUCES节提供整个系统的基本参数。
IPCKEY 55555 （32767-262143）
#进行IPC通讯的key值
DOMAINID unicom
#DOMAIN的ID值
MASTER unicom1,unicom2
#指定DOMAIN中的管理主机为unicom1,运行过程中unicom1若出现问题，管理主机切换至unicom2
MAXACCESSERS 1000
#这里该值表示整个系统中单个机器上可以访问TUXEDO的最多的Client和Server的总数(可以访问 BBL的最大进程数)，应大于license用户数+server数（副本应记入）。该字段会被MACHINE部分的MAXACCESSERS覆盖。
#系统核心参数中SEMAPHORE的数目(SEMMNS)要大于这里的MAXACCESSERS数目，而ipc消息个数（MSGMAX）应大于MAXACCESSERS数+所有带REPLYQ的SERVER的个数。
MAXSERVERS 80
#最大的server数（副本应记入）
MAXSERVICES 200
#最大的service数（多个server重复记入）
MAXGTT 20
#系统最多的并发的全局交易数目
MODEL MP
#表示cluster方式，否则为SHM
OPTIONS LAN,MIGRATE
#多机cluster方式时必须指定为LAN方式，MIGRATE表示可以以组为单位进行机器间SERVER的迁移。
LDBAL Y
#允许负载均衡
SCANUNIT 10
#SCANUNIT 是BBL在所有服务请求中定期扫描以寻找超时的交易和被阻塞德调用和德间隔时间（秒）。这个参数指定BBL扫描间隔时间的基本单位， 它会影响在tpbegin中指定的交易超时时间和用BLOCKTIME指定的请求阻塞超时时间的精确程度。SANITYSCAN, BBLQUERY, DBBLWAIT, BLOCKTIME等参数都是SCANUNIT的倍数，而不是实际秒数。而作为时间单位SCANUNIT必须是5的倍数，并且满足0<SCANUNIT<60。
SANITYSCAN 12
#SANITYSCAN的值指定在每个MACHINE上BBL自动检测所有进程的时间间隔，以SCANUNIT为单元。缺省值满足（SCANUNIT*SANITYSCAN）约为120秒。
DBBLWAIT 2
#DBBLWAIT的值指定DBBL扫描BBL时等待所有BBL应答的最大时间，以SCANUNIT为单元，即超过DBBLWAIT*SCANUNIT（秒）就超时。每一次DBBL将请求转发给它的BBL时，BBL会在请求返回结果之前先回复一个肯定的应答。这样可以定时检测死掉或不正常的BBL。缺省值满足（SCANUNIT*DBBLWAIT）的值等于SCANUNIT和20秒两者之间的最大者。
BBLQUERY 30
#BBLQUERY指定DBBL对所有BBL进行状态检查的时间间隔，它也是以SCANUNIT为计算单位。如果DBBL的状态询问没有回答，该BBL就被‘隔离’了。缺省值满足(SCANUNIT * BBLQUERY) 约为 300秒。
BLOCKTIME 6
#BLOCKTIME指定在阻塞队列中的被阻塞请求的超时时间(包括客户端从tpinit到tpterm的等待时间)，以SCANUNIT为计算单位。缺省值满足(SCANUNIT * BLOCKTIME) 约为60秒。
*MACHINES
DEFAULT:
#该部分对各主机进行描述。
unicom2 LMID=unicom2
APPDIR = "/usr/tuxedo/apps/simpapp"
TUXCONFIG = "/usr/tuxedo/apps/simpapp/tuxconfig"
TUXDIR = "/usr/tuxedo"
UID = 17
GID = 26
MAXACCESSERS = 100
unicom1 LMID = unicom1
APPDIR = "/usr/tuxedo/apps/simpapp"
TUXCONFIG = "/usr/tuxedo/apps/simpapp/tuxconfig"
TUXDIR = "/usr/tuxedo"
UID = 17
GID = 26
MAXWSCLIENTS = 50
#unicom2, unicom1为网络主机名用hostname获得。
#LMID：Logical Machines ID 为tuxedo对主机的内部逻辑命名。
#APPDIR要求放置SERVER的可执行文件。
#TUXCONFIG为全路径的二进制配置文件，要求和环境变量TUXCONFIG相同。对于master机tuxconfig文件是由tmloadcf生成的，而非master机则是由tmboot启动后由tlisten从master机上拷贝获得。
#TUXDIR为tuxedo安装目录，要求和环境变量TUXDIR相同。
#MAXWSCLIENTS表示可连接client的最大个数。
*GROUPS
#GROUP1为组名，LMID表示该组运行的主机，GRPNO为组号，OPENINFO为该组通过XA打开RM(通常指数据库)的初始串。
GROUP1 LMID=unicom2 GRPNO=1 OPENINFO=NONE
GROUP2 LMID=unicom3 GRPNO=2 OPENINFO=NONE
*SERVERS
#这里描述应用服务器。SRVGRP的该SERVER所属组名，SRVID为服务器ID号，MIN表示该服务器CLOPT提供运行的相关参数，要求是”-A -- ….”,可以在应用服务器的srvinit函数中获得这些参数。
DEFAULT:
CLOPT="-A"
BillServer SRVGRP = GROUP1 SRVID = 1 MIN = 2 MAX = 4
RQADDR = QNAME REPLYQ = Y
CLOPT = "-A -o ./out.log –r -e ./err.log --
-p [L][low_water][,[terminate_time]][:[high_water][,create_time]]
如果MAX>1，并且使用了MSSQ（RQADDR， RQPERM）的Server可以配置-p来控制进程的增加和减少。控制算法如下：如果请求队列中的请求个数大于high_water 后超过create_time 秒,就增加该服务的一个新进程； 如果请求队列中的请求个数小于low_water 后超过terminate_time 秒, 就停止该服务的一个进程。low_water 缺省是平均每个服务进程有一个请求消息或者workload 50；high_water 缺省是平均每个服务进程有两个请求消息或者workload 100。create_time 缺省最小是50秒, and terminate_time 缺省最小是60秒。
注意：
使用TUXEDO的服务进程池时，用户自己在程序中如果用alarm（）等系统调用来停止进程是不起作用的，但也不会报错。
[L] 标记意味着增减服务进程基于负载而不是请求队列的长度。仅用于SHM模式下并且LDBAL=Y，否则会报错 (LIBTUX_CAT:1542) ，服务进程也不会增减。
WSL SRVGRP=GROUP2 SRVID=1
CLOPT = "-A -- -n //130.36.0.103:8889 -m 3 -M 10 -x 10 -T 10"
#WSL用于和client端进行连接。-n 表示出接入点为IP:PORT方式，-m –M 表示最小和最大启动多少个WSH和前端通讯，-x则表示一个WSH和几个client端连接。-T 10表示如果client端和server连接后10分钟内没有交易请求则关闭连接。
*SERVICES
#不要求将所有的service在这里描述，当某个service有特别参数时才在SERVICE节中说明。
TOUPPER
LOAD = 60 // 负载，当LDBAL=Y时有用
PRIO = 80 // 服务在请求队列中的优先级
TRANSTIME = 120 // 交易时间
SVCTIMEOUT = 600 // 服务超时时间
*NETWORK
#NETWORK节对多机之间如何进行网络连接进行描述。
#cluster方式下要求先启动tlisten。事实上，对于非master机启动应用服务器是由tlisten完成的。
#tlisten的启动方式为
#unicom1: tlisten –l //130.36.1.101:8891
#unicom2: tlisten –l //130.36.0.102:8891
#NADDR指定网络连接的接入点。
#NLSADDR则指定tlisten的接入点。
#BRIDGE则指TCP连接所用的设备文件。
三、BEA Tuxedo常见配置错误
BEA Tuxedo服务启动时可能遇到的问题：
1、 服务启动时报错“No space in Bulletin Board”
增加ubb文件中的MAXACCESSERS值和MAXSERVERS
2、 Tuxedo应用程序在初始化时失败：”Application server failed or dumped core during initialization”
重新编译连接。
3、 Tuxedo应用程序可执行文件没找到或无法运行: “Application server file not found or not executable”
4、 server group的自动迁移
Automatic migration of server group
5、 缺省的启动顺序可能不是最佳的
Default boot sequence may not be optimal
6、 环境变量没有设置或设置不正确
Environment variable not set or not set properly
7、 IPCKEY以被使用:”IPCKEY is already in use”
将ubb文件中的IPCKEY改成另一个值。
8、 无效NETADDRESSS 。Invalid network address
9、 Met upper bound limits specified in the UBBCONFIG file
10、Network port 被占用 Network port is in use already
11、达到系统资源的限制 Reached limit on system resources
12、Server boot dependency
13、没有建立TLOG文件。TLOG file is not created
四、BEA Tuxedo服务shutdown时可能遇到的问题：
1、Clients still attached 。客户端仍然保持连接
2、Dead servers。应用服务程序Dead
3、Shutdown sequence
五、BEA Tuxedo常用命令
l、buildclient:BEA Tuxedo Client端应用程序编译命令
buildclient [ -C ] [ -v ] [ {-r rmname | -w } ] [ -o name]
[ -f firstfiles] [ -l lastfiles]
说明：
-C specifies COBOL compilation.COBOL语言的编译方式
-v specifies that buildclient should work in verbose mode. In particular, it writes the compilation command to its standard output.
Buildclient 的编译信息详细的输出到标准输出设备
-w specifies that the client is to be built using the workstation libraries.
指出Client程序编译时连接Workstation 相应的动态库
-r rmname specifies the resource manager associated with this client.
-o 输出文件名
-f 输入文件名称，一个或多个，多个以-f 分离
-l specifies one or more user files to be included in the compilation and link edit phases of buildclient last, after the BEA Tuxedo libraries.
需要连接的非BEA Tuxedo的动态库，可以为多个，多个时以-l 分离
buildtms(transaction manager server):
1、buildserver:
* tmboot -- activates the application that is referenced in the specified configuration file. Depending on the options used, the entire application or parts of the application are started.
* tmloadcf -- parses the UBBCONFIG file and loads the binary TUXCONFIG
2、configuration file.
* tmunloadcf -- unloads the TUXCONFIG configuration file.
* tmconfig -- dynamically updates and retrieves information about the
3、configuration for a running system.
* dmadmin -- updates the compiled DMCONFIG (binary domain configuration file) while the system is running.
* tmadmin -- produces information about configuration parameters. Once invoked, you can enter many administrative commands that duplicate the s of other commands. For example, the tmadmin shutdown command is identical to the tmshutdown command.
* tmshutdown -- shuts down a set of specified BEA WebLogic Enterprise or BEA Tuxedo servers, or removes a set of BEA WebLogic Enterprise interfaces or BEA Tuxedo services listed in a configuration file.
单个启动或关闭服务器:
要动态的启动指定的服务器必须先启动BBL服务,JSL服务,JREPSVR服务!具体做法如下:
tmloadcf ubbsimple
tmadmin
>boot -B simple (simple为ubbsimple中指定的MASTER,注意B大写!)
>boot -M (单独启动BBL服务)
>boot -i serApp1 (serApp1为ubbsimpel中定义的JSL的SRVID)
BBL服务和JSL服务均成功启动后,可以启动wlserver。
wlserver启动之后，首先启动JREPSVR服务,如下:
>boot -i serApp2 (serApp2为ubbsimpel中定义的JREPSVR的SRVID)
再启动用户自己定义的服务,如下:
>boot -i serApp3 (serApp3为ubbsimpel中定义的simpserv的SRVID)
关闭指定服务器:
>shutdown -i serApp1 (serApp1为ubbsimpel中定义的simpserv的SRVID)
启动指定的group
>boot -g GROUP1
关闭指定的GROUP
>shutdown -g GROUP1
通过以上方法,可以动态加载服务器,而不需要把整个Tuxedo服务重启!
--转自
当前位置：
论坛首页 »
自由讨论区 »
MQ, Tuxedo及OLTP讨论区
»
发起投票
技术讨论
加好友
发消息
2014-12-26 16:37:26 |
赞(
操作
