1package test;
 2
 3import org.slf4j.Logger;
 4import org.slf4j.LoggerFactory;
 5
 6public class Test {
 7    final static Logger logger = LoggerFactory.getLogger(Test.class);
 8    
 9    public static void main(String[] args) {
10        logger.error("test");
11    }
12
13}
14

slf4j-log4j12-1.5.8.jar
slf4j-api-1.5.8.jar
log4j-1.2.15.jar

 1package test;
 2
 3import java.sql.Connection;
 4import java.sql.DriverManager;
 5import java.sql.ResultSet;
 6import java.sql.Statement;
 7
 8public class jdbcsample {
 9    static public void main(String[] argc) throws Exception {
10        String connectionURL = "jdbc:log4jdbc:mysql://127.0.0.1:3306/sampledb";
11
12        Class.forName("net.sf.log4jdbc.DriverSpy").newInstance();
13        Connection connection = DriverManager.getConnection(connectionURL,
14                "root", "1234");
15
16        Statement statement = connection.createStatement();
17        ResultSet rs = statement.executeQuery("SELECT * FROM customers");
18
19        while (rs.next()) {
20            System.out.println(rs.getString(1));
21        }
22        rs.close();
23
24    }
25}
26

add the jar file:
log4jdbc3-1.2beta1.jar
mysql-connector-java-5.1.12-bin.jar

hibernate.dialect=net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.driver_class=net.sf.log4jdbc.DriverSpy
hibernate.connection.url=jdbc:log4jdbc:mysql://localhost:3306/SAMPLEDB
hibernate.connection.username=root
hibernate.connection.password=1234
hibernate.show_sql=false

静态化是解决减轻网站压力,提高网站访问速度的常用方案,但在强调交互的We2.0 时代,对静态化提出了更高的要求,静态不仅要能静,还要能动,下面我通过一个项目,谈谈网站静态化后的架构设计方案,同时和大家探讨一下,在开源产品大行其道,言架构必称MemberCache, Nginx,的时代,微软技术在网站架构设计中的运用.

静态化的设计原则和步骤

静态化是解决减轻网站压力,但是静态化也会带来一系列的问题,包括开发上复杂度的增加,维护难度的增加,运用不的当,更可能适得其反,而许多替代方案,比如页面缓存,如果运用得当,也能起到很好的效果,所以在开始之前,必须进行详细的考察,确定是否适合静态化,并制定适合的静态化方式,下面先介绍一下

l         考查读写比:

读写比,准确的说是读写负荷比,是否值得静态化的最终考虑,由于一般写入的压力明显大于读出的压力,如果写入太频繁,或者每次写入消耗的资源太多,都不能达到效果,我觉得读写比例10:1应该是个上限.具体情况需要根据自己的业务逻辑判断

l         确定页面呈现的内容是否适合静态化:

在设计方案时,必须详细考虑每个原型页面,找到页面上展示的信息,和他的更新方式,更新时机,更新频率,一定要注意那些不起眼的信息,他们可能左右你的设计,

比如:我们以CSDN的论坛的任意一篇帖子为例,进行分析

上面的帖子中呈现的内容主要是这样几块,帖子内容,回复内容,发帖人回复人的用户信息

n         帖子内容和回复内容在发帖时更新,发帖后用户可以修改其内容,更新频率高

n         用户信息,用户修改个人信息时可能会发生更改,用户等级增加时也可能发生更改,比如加星,更新频率低

n         回复数将每次回复后都要更改,更新频率高

n         设计时要注意细节,如上图中圈出来的部分,这些部分是怎么修改的,频率有多大,一个都不能放过.

l         确定生成方式:

在上面帖子一例中.每次更改都重新生成页面是不可取的,一篇比回复数多的帖子,需要的数据量是巨大的(每层楼的用户信息,回复内容),任何修改,都需要重新取出数据进行生成是不能允许的.一般除非你的页面基本不用更新,或者更新开销极小,(比如一段嵌入的广告代码)才能采用整体更新的方式,不然就需要我们找到合适的更新页面局部区域的方法:

一般有下面两个方法:

1)      正则修改法:

        比如,如果帖子中的回复数,html代码是这样

        <label>回复数<var id="replyCount">34</var></label>

        我们可以通过用下面正则来查找并替换计数

         (?<=id="replyCount">)"d{1,}

2)      页面区域分块:

把页面分成很多小块,在显示时组装起来,比如DotText就采用这个方法

这是一篇典型的Dottext blog页面,其中红色标定部分是一个独立的文件,而黄色框内的是脚本动态加载,这些部分在最终显示的时候组合起来,最终构成了一篇Blog,具体的组合方法也有多种,可以使用Include,也可以自己来实现.DotText就自己实现了一套加载机制

上面的两种方法并不孤立,并可以根据需要,配合使用

l         确定需要动态加载的信息:

页面上总有一些内容看起来不太适合静态化,最典型的是一些统计结果,比如如果你在做一个图书介绍页面,可能就会需要展示图书的当天综合评分,或者书籍排名,这些内容需要用脚本进行动态加载

既然做了静态化,就是希望减少服务器负载,动态加载的数据总是不得已而为之,有的时候在需求允许的情况下,我们在数据在实时性和性能方面做一些妥协,比如上面帖子中的用户星级和昵称,从数据实时性上说,当用户的星级增长,他发言的所有帖子都应该发生变化,所以应该用动态加载.然而其实上这些信息如果不发生变化,也无伤大雅,用户反而能够看到自己在多年前发帖时的级别和昵称.

现实中的项目

X网站是大型的电影资讯,电影社区,向外提供电影相关信息服务,以及用户社区,其中信息服务部分, 其中大部分页面属于信息呈现页,读取量比较大,百万级别pv,信息主要由编辑在后台发布,更新较少,但其页面上有大量的交互性的内容,比如评论,收藏列表,同时许多内容允许用户创造,比如上传图片,添加注释.交互内容的数量和交互的频繁程度,都超过了普通的咨询页面,这次调整,准备将其中访问量最大的几块:电影资料页,影人资料页,进行静态化,如果成功,还将运用到更多的频道,基本实现全站静态化

通过对页面设计和前一版本的分析,下面是具有挑战性的地方.这些特点基本使用于大多数web2.0的站点,很具有典型意义

l         页面生成的触发条件复杂

一般论坛中的帖子或者blog,更新方式比较单一:主要是由回复进行触发还有少数的修改动作,然而该网站一个页面上需要根据不同触发条件就有20多个, 比如光二级菜单:用户发布图片,删除图片,发布或者删除影片信息,发布或者修改视频,后台修改电影信息,都有可能触发

l         一个动作触发生成的页面可能很多而且相互交叠

每一个动作都会触发一系列的生成,并且不同动作可能都会涉及同一个页面或者区域的生成.

比如:用户给一步电影评分,需要生成评分更多页,评分统计更多页,首页右侧谁还关注此影片小区域,等等.用户收藏一个影片,也需要更新首页右侧谁还关注此影片小区域

l         触发频繁:

虽然不及某些更大规模的网站,但是由于涉及众多用户参与的内容,评论,收藏等等,触发点多,发生频度相当频繁

l         页面多,结构复杂,空间占用大:

通常,需要生成的页面规模是这样粗略估算的,Rn*P,Rn为资源数,P为每个资源的页面数,所谓资源,可以看做一个生成单位,其页面数可以简单看做发布一个资源,就需要生成其所有相关页面数量,比如:发布一个blog,就需要生成一个Blog页,同时还需要生成或者更新个人主页的blog列表,算上个人主页右侧的分类文章数的小块,也就是最多10来个页面或者区域,但是发布一个电影,其相关的页面至少有50个以上,而且有的页面还带有分页,一个信息比较丰富的电影,其页面竟可以达到千个以上,空间10~20M,而且资源总数也不少,电影80000左右,电影人虽然P值较少,但是总量确有几十万之巨,估计静态页面磁盘占用量几百个G

l         向下兼容

这是一个已有系统,旧系统的框框需要突破,但又没有时间,或者不能完全突破,比如Url,已经被收录到搜索引擎,就不能随便调整,还有一些地方,原本没有为静态生成考虑,另一些地方又需要兼容旧的设计.

l         多台前端Web

这种结构要求生成的文件可能需要分布到多个服务器(另一个方案是放在几台专用的机器上,等前端来取)

l         任务紧迫

架构讨论结束仪式六月初,离奥运开幕上线只有两月,也就是说所有底层框架实现,页面模板开发,调试测试,动作的整理,必须在7月底全部完成,按我原来估计,光实现这几块的上百个页面模板和填充方法,也需要那么长的时间

综合考虑上述因素,架构必须要有以下几个方面的特点

l         动作可以灵活扩展配置,某个动作对应哪些生成,应该可以配置,并且可以分组

l         文件必须有分发机制

l         分发和生成必须独立出来,并且支持分布式

l         各种的动作,必须转化为消息,发送到生成和分发服务器进行处理

l         针对同意资源频繁动作,在变量相同的情况下能够具有合并的能力

l         动作必须有记录

l         尽量考虑使用已有成熟技术,节省开发时间

下面是设计的第一个架构

用户的动作经过MSMQ[1]传入到生成分发中心(途中绿色箭头)进行处理,,处理中心接受到消息后,负责生成对应的页面或者页面区域,并将页面分发到各个服务器,负载均衡沿用以前的架构,采用微软的NLB[2]

之所以用MSMQ,就是看上了他提供的完整的消息存储恢复机制,这样我们能确保即使服务器down掉重启后,消息依然能正常处理,碰巧我们cms组的同事MSMQ非常熟悉,并且真准备在另外一个项目中使用类似的架构—于是一拍即合

页面采用分块存储,这样能保证生成时目标小,开销小,也能重用性,然后再藉由SSI[3](shtml include)进行整合,之所以采取这样的方案,而不采用Dottext的整合方式,是因为如果采用Dottext的方式,就必须走IIS和.Net的管道[4],而据测试,经过管道和直接返回html性能有非常大的差异,而使用ssi,在性能上是一个折中,并且可以Light HTTPd等高性能web服务器

模板生成方式,采用了XSLT和另外一种自定义的模板(我的同事开发的机制,很有趣, 理论上能把传统模板替换的性能开销全部消除),生成的最终产物是shtml,之所以生成shtml是为了使用其ssi(Server Side Include)的特性,保证一定的灵活性,并实现热点数据的分离:某些页面上的部分可能会频繁更新和生成,而其它地方不变,或者某个部分是所有页面通用的(比如页头和页脚),较之php下常常使用smarty,生成php文件,虽然灵活性不如php,但是性能上不相上下,还略高.

但是这个设计的问题是动态内容和静态内容没有分开,生成的html页面,和动态页面都放在前端服务器上,通过负载均衡访问,也造成了分发服务器需要分发到多台服务器,网络IO效率较低,而且静态内容需要的磁盘空间很大,且小文件非常多,和动态页面混在一起不便于优化,所以第二个方案对生成的静态内容与动态内容使用不同的服务器

方案二:

我们把生成的静态文件单独放置,可以看到,前端增加Nginx,作为跳转,把电影,影人资料库的页面转向静态服务器,其他的调用转向动态服务器,这样我们就可以单独为静态服务器进行优化,比如采用更高效的服务器等等.

同时减少了文件分发的次数(甚至可以只分发到本机),提高生成分发的处理能力

更进一步,可以把图片服务分到另外一组机器上,使用独立的域名,比如img.xxx.com,这样可以有效的减少带宽

最终完整架构:

文件生成分发中心

下图是文件生成分发中心的工作流程图

生成服务对外只有一个输入,就是消息,一个输出:静态文件,内部根据消息,从配置文件中找到对应的生成方法,取出相应的模板,进行数据填充

分发服务主要吧生成服务产生的文件进行分发,分发到前端的N台服务器上,开始考虑得比较复杂,希望分发服务可以跨越协议(本地文件系统,局域网,http协议),跨越多种存储介质(文件系统,数据库),实际最后定下来基本是本地文件系统或者局域网传输

注:上图中文件分发的部分也可以通过定制MogileFS,来实现分布式文件系统

马后炮:

总结起来,静态化除了对架构方面的影响,对开发和测试流程也有影响

对测试提出更高的要求:

因为一旦上线后,某个页面发现问题,即使是文字的修改,也需要重新生成许多页面,所以测试人员必须非常仔细,测试周期也需要延长

开发人员需要掌握模板语言

需要掌握一种模板预言,无论是Xslt还是自己开发的模板语言,都需要花一定的时间掌握

需要给第一次生成腾出足够时间:

如果不是新系统,那么数据迁移和生成的过程就比较痛苦,由于页面众多,第一次生成的过程可能需要以天来计算,在制定上线方案是就需要考虑到这个方面

Nginx作为前端的跳转,根据其他网站的经验,应该可以达到2-3万并发连接,但是使用之后,常常有卡壳的情况发生,具体症状为在浏览器中访问页面时,连接超时,或者一直不响应,此时Nginx连接数并不高,好在还有第一套方案可以备用,让我们有时间去解决这个问题,如果大家对这个问题有什么心得,欢迎交流

Web2.0网站性能调优实践

                                           文/王宗义

当前web2.0革命风起云涌，web2.0强调服务，而服务最基本的要求是速度快和稳定，离开这两个谈功能强大和易用性都没有任何意义。本文介绍一些关于笔者运营一个web2.0网站的优化心得和经验，希望能够和大家共同探讨。

Web2.0网站不同于以往以静态信息为主的网站架构，以往的结构大体分为2层，一个是客户端浏览器，一个就是web服务器；而web2.0以动态和交互为主，一般是3层或者4层，在静态信息网站的结构上的web服务器后端会增加应用服务器和数据库。一般会把浏览器和web服务器归为最上一层即为web层，应用服务器为中间一层，数据库为最底层。从优化角度来讲，越上层优化获得益处越大，优化也是从上自下而来。

Web层优化

DNS的解析时间

这个时间就是在用户第一次访问网站的时候产生，解析时间会影响用户的访问感受，因此想要网站响应速度快，第一就是不要在DNS解析上产生问题。另外DNS的TTL时间也要考量，IE的DNS过期时间是30分钟，TTL设置的比这个长一点就可以。另外在web服务器上使用keep-live也会减少DNS查询次数。

降低浏览器发起请求的数量

尽量降低浏览器发起请求的数量，就是说尽量能够让浏览器缓存任何可以缓存的东西。这样当用户访问过一次后，第二次访问可能会使得发起的请求数趋近1或者等于1，如果是静态的页面则可能是0。方法包括：

把所有的样式表文件并为1个

把所有的js文件并成1个

图片尽量能够合成1张，这个跟以前不一样，现在大多数是adsl上网，反而是大量的零碎图片能够影响速度

页面布局与样式

页面采用xhtml，采用div+css布局，而把样式表和xhtml文件分开，一则能够降低xhtml文件大小，二则能够对样式表文件进行其他缓存处理。这里还有个ui设计的原则，ui跟系统结构一样，越简洁越好，这样整体页面代码会比较少，速度也会比较不错。

JavaScript文件

JavaScript文件也最好放到html文件外，原因同上。

静态文件的优化方法

a)目前大多数的浏览器都支持gzip压缩文件，因此为文本、静态页面、样式表、JavaScript文件等可以压缩处理的文件进行压缩处理能够减少内容获取时间，一般压缩完的大小为原大小的10-30%。这个在apache等web服务器上进行设置，笔者使用lighttpd的设置为：

server.modules = (

      ….

      "mod_compress",

      …

)

compress.cache-dir="/usr/local/lighttpd/cache"

compress.filetype = ("text/plain", "text/html", "text/css", "text/javascript")

b)还可以在静态文件服务器前面增加缓存服务器比如squid，进一步增强客户端的访问性能。如果有好的财力，还可以使用一些商业的CDN加速服务。

应用Cookie的注意事项

Cookie的应用要注意，要限制cookie的应用域和应用的目录以及过期时间。不然如果用户是第一次访问的话，可能连一个小小的静态图片都要发送cookie到服务器，这样增加了通信负载。另外要限制cookie的大小，一个3k的cookie能够增加延迟达到80ms。

提高页面速度

页面由2-4个不同域名的服务器提供服务能够提高速度，这个国外也有研究证明。比如主html文件由app.domain.com提供，样式表由style.domain.com提供，图片等由img.domain.com提供，这样浏览器可以同时从多个服务器下载文件，速度就能够上去。但是最好不要超过4个。

样式表文件位置

把样式表文件放在页面的<head>，这样能够先读取。因为在ie中有个样式表的问题，样式表如果没有加载完会影响后面的html内容的页面显示，因此虽然html文件都已经在浏览器了，但是页面还是显示不出来。

把JavaScript移到html文件末尾

把JavaScript移到html文件末尾。为什么这么做呢，因为JavaScript处理的过程中会阻塞后面的页面显示，并且也会使得http请求也被阻止。笔者的网站就有过这样的例子，网站上放了一个合作方的JavaScript，结果每次访问时候感觉页面都停滞，用户体验特别差，后来让同事处理了一下，放到末尾等页面加载完了再显示在原有位置，一下子就好了。

尽量避免跳转

尽量避免跳转比如301和302。如果必须的话，对301和302的页面添加过期头。笔者原来的单点登录就需要进行跳转，后来改进了不需要跳转，整体的速度效果就出来了。

移除重复的脚本

要移除重复的脚本，ie会对重复的脚本发起重复的http请求，大多数网站在运营一段时间都有可能出现这个情况，笔者的网站中就经常有市场人员添加的重复的广告脚本。

AJAX内容

AJAX内容也是可以进行缓存的，同样可以压缩和缓存异步调用的xml、json等数据。

对爬虫进行限制

对爬虫进行限制，国内的一些爬虫非常厉害，并且不遵守robots规矩，经常有反应某某厉害爬虫把网站搞瘫的事件。怎么对爬虫进行限制呢，只能在web服务器上下功夫了，apache等服务器都能够进行限制，笔者的lighttpd限制10个并发的配置如下： 

 evasive.max-conns-per-ip = 10

web层的优化目的就是极大的利用了浏览器的缓存特性，从而达到几乎是本地访问的速度，下图是笔者访问douban.com首页的效果图对比：

前一列数据是空的缓存所需要下载的文件大小和http请求数量，后面是真实访问的带cache的情况，效果特别明显。http请求减少了95%，内容cache了82%。

应用程序层优化

应用服务器的优化

Php的可以采用一些优化手段比如Zend Optimizer、eAccelerator、MMCache、Zend Performance Suite等

Java的可以采用一些性能强的jdk、应用服务器，对jdk参数进行优化等等

使用ETag

ETag就像版本控制服务器中的版本号一样，每次更新后的ETag是不一样的，而浏览器处理就类似版本服务器的客户端一样，先把版本号发到服务器请求。ETag的处理过程，先是Web服务器在响应的http头中发送ETag，比如这样：

ETag: "1111-2222-3333"

Last-Modified: Thu, 07 Oct 2007 15:20:18 GMT

而浏览器如果再次请求该页面就会发送类似如下的头：

If-None-Match: "1111-2222-3333"

If-Modified-Since: Thu, 07 Oct 2007 15:20:18 GMT

此时，如果该页面没有任何变更，则web服务器会响应一个304的头，并且不需要附带页面内容给浏览器（即不需要再动态生成页面内容），这样就大大减少了服务器的处理和网路通信负载。

同步变异步

同步变异步，在web2.0网站中经常有很复杂的处理，比如一个用户的注册还需要发邮件等操作，有时候可能还有其他的处理，这样用户的等待时间比较长，并且容易出现错误。此种情况下，把其他处理变成异步的，从而直接把页面尽快响应给用户。笔者的一个数据上传的程序也是如此处理，一大堆数据，上传时间可能就1-2秒，而处理时间可能长的需要接近10秒（需要在数据库中进行上千次的插入操作），而在应用服务器容器内处理耗时则更长，笔者后来改成异步处理以后，用户满意度则大幅上升。

使用缓存

还是缓存，可能的情况下尽量使用缓存，毕竟现在内存非常便宜，用空间换取时间效率应该是非常划算的。尤其是对耗时比较长的、需要建立网络链接的，方法：采用memcached进行数据库或者常用数据的缓存；应用数据库缓冲池减少建立数据库连接的时间

采用gzip压缩动态页面

可能情况下，也可以采用gzip压缩动态页面。如果服务器较多，cpu负载不高，则可以考虑对动态页面增加gzip压缩功能

集群处理

访问压力大的时候，对应用服务器采用集群处理。

应用服务器的优化主要是减少程序处理的时间，提高运行效率。

数据库优化

这个议题跟具体数据库关系比较大，议题也比较广泛，笔者就只简要列举一下：

设置专门的DBA，专门负责数据库的安装、优化；对sql进行优化采用数据库集群和复制功能分担数据库压力。

其他优化措施

网站的优化涉及的方面比较多，其他方面涉及的还包括网站架构、操作系统、服务器硬件、网络设备、isp机房网络等等的调优。

工具

笔者用到的工具，都是firefox插件，所以firefox是必备的了：

1、LiveHTTPHeaders (http://livehttpheaders.mozdev.org/)

2、Firebug (http://getfirebug.com)

3、YSlow (http://developer.yahoo.com/yslow/)，要先装Firebug

4、Web Developer (http://chrispederick.com/work/web-developer/)

除了这些免费的工具外，还可以采用一些商业的网站性能监测服务。一般网站性能监测服务商都会在不同的isp设置数据采集点，然后会定期模拟浏览器的访问对网站进行访问获取各种数据，比如dsn查询时间、第一个包获取时间、整个页面加载时间等等，然后汇总到数据中心。数据中心则可以产生性能报表、不同时间的可访问率、哪个isp容易出问题、发出警报等等。如果预算足够的话，可以采用这个服务。国外的有keynote、ip-label等，功能比较齐全，但是服务费用比较贵而且国内的点比较少。国内近些年也开始涌现出一些厂商，比如基调网络。笔者使用的监测系统的图例：

笔者网站3年不同阶段的优化过程

优化的原则是尽量不去优化，在未发生性能问题的时候，没有必要去专门考虑细节的性能问题，当然大的结构应该是能够适应网站不断发展变化的。笔者的网站近3年的优化过程如下：

1、开发完成，刚上线的时候，不做优化，用户量少，用了3台服务器。

2、10万用户的时候，主要对sql进行了优化，还是3台服务器。

3、10万用户到100万的过程中，采用了AJAX等，因此开始关注JavaScript的优化手段，访问量也快速上去，因此对静态文件进行分离并优化。服务器也进行了扩展，扩展到5台服务器。

4、100万-200万用户，业务系统增加了很多，因此数据库采用了复制，程序方面应用了各种缓存处理，在数据库和程序之间增加了memcached进行数据缓存。

5、在200万用户以上，主要在程序架构上做文章，对某些服务使用了集群。另外为了监测国内不同城市、isp的网络状况，使用了商业化的网站性能监测服务。

1. 一個新的 Connection 進來，用 fork() 產生一個 Process 處理。
2. 一個新的 Connection 進來，用 pthread_create() 產生一個 Thread 處理。
3. 一個新的 Connection 進來，丟入 Event-based Array，由 Main Process 以 Nonblocking 的方式處理所有的 I/O。
   

1. 用 fork() 的問題在於每一個 Connection 進來時的成本太高。
2. 用 Multi-thread 的問題在於 Thread-safe 與 Deadlock 問題難以解決，另外有 Memory-leak 的問題要處理。
3. 用 Event-based 的方式在於實做上不好寫，尤其是要注意到事件產生時必須 Nonblocking，於是會需要實做 Buffering 的問題，而 Multi-thread 所會遇到的 Memory-leak 問題在這邊會更嚴重。而在多 CPU 的系統上沒有辦法使用到所有的 CPU resource。
   

1. 以 Poll 的方式解決：當一個 Process 處理完一個 Connection 後，不直接死掉，而繼續回到 accept() 的狀態繼續處理，但這樣會遇到 Memory-leak 的問題，於是採用這種方式的人通常會再加上「處理過 N 個 Connection 後死掉，由 Parent Process 再 fork() 一隻新的」。最有名的例子是 Apache 1.3。
2. Thread-safe 的問題可以透過自己撰寫，或是尋找其他 Thread-safe Library 直接使用。Memory-leak 的問題可以試著透過 Garbage Collection Library 分析出來。Apache 2.0 的 Thread MPM 就是使用這個模式。
   

1. select() 與 poll() 的效率過慢，造成每次要判斷「有哪些 Event 發生」這件事情的成本很高，這在 BSD 支援 kqueue()、Linux 支援 epoll()、Solaris 支援 /dev/poll 後就解決了，但這兩組 Function 都不是 Standard，於是在不同的平台上就必須再改一次。
   
2. 因為 Nonblocking，所以在 write() 或是 send() 時滿了需要自己 Buffering。
3. 因為 Nonblocking，所以不能使用 fgets() 或是其他類似的 function，於是需要自己刻一個 Nonblocking 的 fgets()。但是使用者所丟過來的資料又不能保證在一次 read() 或 recv() 就有一行，於是要自己做 Buffering。

#include <netinet/in.h>

#include <sys/socket.h>

#include <sys/types.h>

#include <event.h>

#include <stdio.h>

#include <time.h>



void connection_time(int fd, short event, struct event *arg)

{

char buf[32];

struct tm t;

time_t now;



time(&now);

localtime_r(&now, &t);

asctime_r(&t, buf);



write(fd, buf, strlen(buf));

shutdown(fd, SHUT_RDWR);



free(arg);

}



void connection_accept(int fd, short event, void *arg)

{

/* for debugging */

fprintf(stderr, "%s(): fd = %d, event = %d.\n", __func__, fd, event);



/* Accept a new connection. */

struct sockaddr_in s_in;

socklen_t len = sizeof(s_in);

int ns = accept(fd, (struct sockaddr *) &s_in, &len);

if (ns < 0) {

perror("accept");

return;

}



/* Install time server. */

struct event *ev = malloc(sizeof(struct event));

event_set(ev, ns, EV_WRITE, (void *) connection_time, ev);

event_add(ev, NULL);

}



int main(void)

{

/* Request socket. */

int s = socket(PF_INET, SOCK_STREAM, 0);

if (s < 0) {

perror("socket");

exit(1);

}



/* bind() */

struct sockaddr_in s_in;

bzero(&s_in, sizeof(s_in));

s_in.sin_family = AF_INET;

s_in.sin_port = htons(7000);

s_in.sin_addr.s_addr = INADDR_ANY;

if (bind(s, (struct sockaddr *) &s_in, sizeof(s_in)) < 0) {

perror("bind");

exit(1);

}



/* listen() */

if (listen(s, 5) < 0) {

perror("listen");

exit(1);

}



/* Initial libevent. */

event_init();



/* Create event. */

struct event ev;

event_set(&ev, s, EV_READ | EV_PERSIST, connection_accept, &ev);



/* Add event. */

event_add(&ev, NULL);



event_dispatch();



return 0;

}

#include <sys/time.h>

#include <event.h>

#include <stdio.h>



void printbuf(struct evbuffer *evbuf)

{

for (;;) {

char *buf = evbuffer_readline(evbuf);

printf("* buf = %p, the string = \"\e[1;33m%s\e[m\"\n", buf, buf);

if (buf == NULL)

break;

free(buf);

}

}



int main(void)

{

struct evbuffer *evbuf;



evbuf = evbuffer_new();

if (evbuf == NULL) {

fprintf(stderr, "%s(): evbuffer_new() failed.\n", __func__);

exit(1);

}



/* Add "gslin" into buffer. */

u_char *buf1 = "gslin";

printf("* Add \"\e[1;33m%s\e[m\".\n", buf1);

evbuffer_add(evbuf, buf1, strlen(buf1));

printbuf(evbuf);



u_char *buf2 = " is reading.\nAnd he is at home.\nLast.";

printf("* Add \"\e[1;33m%s\e[m\".\n", buf2);

evbuffer_add(evbuf, buf2, strlen(buf2));

printbuf(evbuf);



evbuffer_free(evbuf);

}

http://park3.wakwak.com/~ozashin/sw_tips/webapp_tips/sjis_charset.html

文字コードについて（シフトJISの問題）

文字コードをシフトJISで開発し、Windowsのサーバで動かす場合の文字コード問題について示します。

厳密にいうとWindowsが扱う文字コードは、シフトＪＩＳでは、ありません。MS932です。または、コードページ CP932ともいいます。MS932は、マ社がシフトＪＩＳを拡張して定義したコード体系です。

で、ここで何が問題になるかというと、クライアントへの出力をcharset="Shift_JIS"とか定義して、アプリケーションサーバーなど が一生懸命シフトＪＩＳで出力しようとすると、ある文字列が文字化けするのです。ようは、MS932にある文字コードはシフトＪＩＳには、ないので、'? 'で出力されるということです。なお、OC4JやJBuilderで利用するtomcatは、MS932で出力しようとするので、あんまり文字化けしませ ん。

Java内部で扱う文字コードは、Unicodeです。ここでシフトＪＩＳとUnicodeのマッピングとMS932とUnicodeのマッピング の違いによって、思わぬ、文字化けが発生するのです。ちなみに、JSPファイルにじか書きしてあるもじは、そのまま出力されるので問題はありません。
Javaプログラムを通して、Unicodeからcharsetで定義された文字が出力されるとき文字化けの対象となります。

具体的には、'～'、'∥'、'－'、'￠'、'￡'、'￢'などの一部の記号類です。
日本語のUnicodeベンダ依存文字表 http://www.ingrid.org/java/i18n/unicode.html を参照してください。

というわけで、Windowsで動かすのであれば、charsetを"Windows-31J"にしましょう！そうすれば、一部の文字コードを除い て解決です。
JSPの場合は、<%@ page contentType="text/html; charset=Windows-31J" %>と定義します。
Servletでは、

	private static final String CONTENT_TYPE = "text/html; charset=Windows-31J";
....
response.setContentType(CONTENT_TYPE);

のように実装します。charset="MS932"でもＯＫですが、http://www.ingrid.org/java/i18n/encoding/shift_jis.htmlに あるとおり、これからは、Windows-31Jでいくようです。

シフトＪＩＳがらみでもうひとつWAVE DASH問題（TILDE問題）というのがあります。これは、JDBCがらみというか、データベースの文字セットの問題というか、誰が根本的な原因かわか らないところがあります。Unicodeの実装が厳密に定義されていないので、ベンダごとで実装の仕方が違っているそうです。

Oracleを例にとって文字の流れを以下に示します。テスト環境は以下のとおり。

OS	Windows2000
データベースサーバ	Oracle8i R8.1.7
ＤＢ内部コード	JA16SJIS

ある入力フィールドに '～' を含んだ文字列を設定し、それをデータベースへ格納し、参照する場合、文字変換の流れは以下のようになります。

1. ブラウザ上では、Windows-31J(MS932)なので、'～'=0x8160
2. Javaプログラム内部では、Unicodeなので、JisAutoDetectなどで変換して、'～'=0xFF5E (FULL WIDTH TILDE)
3. データベースに格納された結果は、JA16SJISなので、'～'=0x8160
4. Javaプログラムがデータベースから文字をGETしたとき、'～'=0x301C (WAVE DASH)
5. 0x301Cを応答として出力すると、0x8160にマッピングできないので '?'となる。

この問題は、上記のようにcharsetをWindows31Jにしても回避できません。

ちなみに、Unicodeでいうところの '～' は、0x301C (WAVE DASH)になるのが、Unicodeコンソーシアムでは正しい実装方法だそうです。

(4)で、0x301Cに変換されているんだからＯＫじゃん、と思いますが、0x8160を0xFF5Eに変換するんだから、0x8160にするに は、0xFF5Eにしてあげなければならないのです。

この問題を回避するには、２通りあります。

1. (4)で0x301Cで変換された文字を0xFF5Eに再変換する。
2. Oracle9i R9.2以降でMS932がサポートされたデータベース内部コード "JA16SJISTILDE"を利用する。

しかし、(1)では、データベースをアクセスするたび、毎回再変換するので、パフォーマンスが落ちます。(2)では、いまさらOracle9に移行 できる予算がないし、検証しているひまもないという問題があります。
したがって、第３の回避方法として、運用で逃げる（'～'は、システム上扱えないコードとしてユーザに我慢してもらう）という手もあります。

ちなみに、私は、多少パフォーマンスが落ちてもＯＫということで、(1)で再変換の道を選びました。

まぁ、最初からOracle9iR9.2を選んでいれば、ＯＫですけどね。また、検証はしていませんが、EUC-JPでも同様の問題があって、 Oracle9iR9.2からJA16EUCTILDEがサポートされているようです。

Windowsで動かし、JISAutoで変換した場合のデフォルトコンバータは、誰の都合か知りませんが、以下のように変化しました。
まぁ、Windowsで動かす限り、Windows-31Jをcharsetにしておけば、JDK1.4.1以降でもＯＫのようです。

• Database, operating system, or hardware upgrades.
• Database, operating system, or hardware configuration changes.
• Database initialization parameter changes.
• Schema changes, such as adding indexes or materialized views.
• Refreshing optimizer statistics.
• Creating or changing SQL profiles.

• Setting Up the Test
• Creating SQL Tuning Sets using the DBMS_SQLTUNE Package
• Running the SQL Performance Analyzer using the DBMS_SQLPA Package
• Creating SQL Tuning Sets using Enterprise Manager
• Running the SQL Performance Analyzer using Enterprise Manager
• Optimizer Upgrade Simulation
• Parameter Change
• Transferring SQL Tuning Sets

Setting Up the Test

CONN sys/password@prod AS SYSDBA
CREATE USER spa_test_user IDENTIFIED BY spa_test_user
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO spa_test_user;

CONN spa_test_user/spa_test_user@prod
CREATE TABLE my_objects AS
SELECT * FROM all_objects;
EXEC DBMS_STATS.gather_table_stats(USER, 'MY_OBJECTS', cascade => TRUE);

SELECT COUNT(*) FROM my_objects WHERE object_id <= 100;
SELECT object_name FROM my_objects WHERE object_id = 100;
SELECT COUNT(*) FROM my_objects WHERE object_id <= 1000;
SELECT object_name FROM my_objects WHERE object_id = 1000;
SELECT COUNT(*) FROM my_objects WHERE object_id BETWEEN 100 AND 1000;

Creating SQL Tuning Sets using the DBMS_SQLTUNE Package

CONN sys/password@prod AS SYSDBA
EXEC DBMS_SQLTUNE.create_sqlset(sqlset_name => 'spa_test_sqlset');

DECLARE
l_cursor  DBMS_SQLTUNE.sqlset_cursor;
BEGIN
OPEN l_cursor FOR
SELECT VALUE(a)
FROM   TABLE(
DBMS_SQLTUNE.select_cursor_cache(
basic_filter   => 'sql_text LIKE ''%my_objects%'' and parsing_schema_name = ''SPA_TEST_USER''',
attribute_list => 'ALL')
) a;
DBMS_SQLTUNE.load_sqlset(sqlset_name     => 'spa_test_sqlset',
populate_cursor => l_cursor);
END;
/

SELECT sql_text
FROM   dba_sqlset_statements
WHERE  sqlset_name = 'spa_test_sqlset';
SQL_TEXT
--------------------------------------------------------------------------------
SELECT object_name FROM my_objects WHERE object_id = 100
SELECT COUNT(*) FROM my_objects WHERE object_id <= 100
SELECT COUNT(*) FROM my_objects WHERE object_id BETWEEN 100 AND 1000
SELECT COUNT(*) FROM my_objects WHERE object_id <= 1000
SELECT object_name FROM my_objects WHERE object_id = 1000
5 rows selected.
SQL>

Running the SQL Performance Analyzer using the DBMS_SQLPA Package

CONN sys/password@prod AS SYSDBA
VARIABLE v_task VARCHAR2(64);
EXEC :v_task :=  DBMS_SQLPA.create_analysis_task(sqlset_name => 'spa_test_sqlset');
PL/SQL procedure successfully completed.
SQL> PRINT :v_task
V_TASK
--------------------------------------------------------------------------------
TASK_122
SQL>

BEGIN
DBMS_SQLPA.execute_analysis_task(
task_name       => :v_task,
execution_type  => 'test execute',
execution_name  => 'before_change');
END;
/

CONN spa_test_user/spa_test_user@prod
CREATE INDEX my_objects_index_01 ON my_objects(object_id);
EXEC DBMS_STATS.gather_table_stats(USER, 'MY_OBJECTS', cascade => TRUE);

BEGIN
DBMS_SQLPA.execute_analysis_task(
task_name       => :v_task,
execution_type  => 'test execute',
execution_name  => 'after_change');
END;
/

BEGIN
DBMS_SQLPA.execute_analysis_task(
task_name        => :v_task,
execution_type   => 'compare performance',
execution_params => dbms_advisor.arglist(
'execution_name1',
'before_change',
'execution_name2',
'after_change')
);
END;
/

SET LONG 1000000
SET PAGESIZE 0
SET LINESIZE 200
SET LONGCHUNKSIZE 200
SET TRIMSPOOL ON
SPOOL /tmp/execute_comparison_report.txt
SELECT DBMS_SQLPA.report_analysis_task(:v_task)
FROM   dual;
SPOOL OFF

Creating SQL Tuning Sets using Enterprise Manager

Running the SQL Performance Analyzer using Enterprise Manager

CONN spa_test_user/spa_test_user@prod
CREATE INDEX my_objects_index_01 ON my_objects(object_id);
EXEC DBMS_STATS.gather_table_stats(USER, 'MY_OBJECTS', cascade => TRUE);

Optimizer Upgrade Simulation

Parameter Change

Transferring SQL Tuning Sets

CONN sys/password@prod AS SYSDBA
BEGIN
DBMS_SQLTUNE.create_stgtab_sqlset(table_name      => 'SQLSET_TAB',
schema_name     => 'SPA_TEST_USER',
tablespace_name => 'USERS');
END;
/

BEGIN
DBMS_SQLTUNE.pack_stgtab_sqlset(sqlset_name          => 'SPA_TEST_SQLSET',
sqlset_owner         => 'SYS',
staging_table_name   => 'SQLSET_TAB',
staging_schema_owner => 'SPA_TEST_USER');
END;
/

BEGIN
DBMS_SQLTUNE.unpack_stgtab_sqlset(sqlset_name          => '%',
sqlset_owner         => 'SYS',
replace              => TRUE,
staging_table_name   => 'SQLSET_TAB',
staging_schema_owner => 'SPA_TEST_USER');
END;
/

• SQL Performance Analyzer
• DBMS_SQLPA
• DBMS_SQLTUNE

摘要：
　　本《功略》集中了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

http://support.microsoft.com/kb/306126/zh-cn

通过上面的方法， 在家里就可以让自己的虚拟机使用DHCP的方式上网。
当然，这是针对VMWARE里面使用Bridge的网卡，分配IP。

为了让自己的机器到任何地方，1）虚拟机都可以使用网络，2）主机和虚拟机可以互相访问，
就给各个虚拟机配置了三个网卡，分别是Bridge，NAT，HostOnly的方式。

配置完之后，RHEL重启， 就可以立即找到新的网卡，并且DHCP配置完成，主机可以通过NAT
网卡Telnet虚拟机。

可Ubuntu就没这么幸运了。
ifconfig命令，只看到eth0可以用。
ifconfig -a命令，可以看到三块网卡都在。
看来得手工在/etc/network/interface中，手工添加DHCP的相关配置。参考如下：
auto eth0
iface eth0 inet dhcp

iface eth1 inet dhcp
auto eth1
iface eth2 inet dhcp
auto eth2

重启网络，好不容易三块网卡都爬上来了。

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.

解决办法：

rm /etc/udev/rules.d/70-persistent-net.rules

通过 vi /etc/network/interfaces 修改ip地址
然后 /etc/init.d/networking restart

<Location /svn>DAV svn
SVNPath /home/svn 

AuthType Basic
AuthName "myproject subversion repository"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>

   b)restart apache :   /etc/init.d/apache2 restart

   c)create the pass file, and add the user:

      touch  /etc/subversion/passwd 

htpasswd -c /etc/subversion/passwd user_name

6) now you can use your client browser/tool to access your svn server ： http://localhost/svn/myproject

深入理解软件包的配置、编译与安装

作者：金步国

版权声明

本文作者是一位自由软件爱好者，所以本文虽然不是软件，但是本着 GPL 的精神发布。任何人都可以自由使用、转载、复制和再分发，但必须保留作者署名，亦不得对声明中的任何条款作任何形式的修改，也不得附加任何其它条件。您可以自由链接、下载、传播此文档，但前提是必须保证全文完整转载，包括完整的版权信息和作译者声明。

其他作品

本文作者十分愿意与他人共享劳动成果，如果你对我的其他翻译作品或者技术文章有兴趣，可以在如下位置查看现有作品的列表：

• 金步国作品列表

BUG报告，切磋与探讨

由于作者水平有限，因此不能保证作品内容准确无误，请在阅读中自行鉴别。如果你发现了作品中的错误，请您来信指出，哪怕是错别字也好，任何提高作品质量的建议我都将虚心接纳。如果你愿意就作品中的相关内容与我进行进一步切磋与探讨，也欢迎你与我联系。联系方式：MSN: csfrank122@hotmail.com

前言

从源代码安装过软件的朋友一定对 ./configure && make && make install 安装三步曲非常熟悉了。然而究竟这个过程中的每一步幕后都发生了些什么呢？本文将带领你一探究竟。深入理解这个过程将有助于你在LFS的基础上玩出自己的花样来。不过需要说明的是本文对 Makefile 和 make 的讲解是相当近视和粗浅的，但是对于理解安装过程来说足够了。

概述

用一句话来解释这个过程就是：

根据源码包中 Makefile.in 文件的指示，configure 脚本检查当前的系统环境和配置选项，在当前目录中生成 Makefile 文件(还有其它本文无需关心的文件)，然后 make 程序就按照当前目录中的 Makefile 文件的指示将源代码编译为二进制文件，最后将这些二进制文件移动(即安装)到指定的地方(仍然按照 Makefile 文件的指示)。

由此可见 Makefile 文件是幕后的核心。要深入理解安装过程，必须首先对 Makefile 文件有充分的了解。本文将首先讲述 Makefile 与 make ，然后再讲述 configure 脚本。并且在讲述这两部分内容时，提供了尽可能详细的、可以运用于实践的参考资料。

Makefile 与 make

用一句话来概括Makefile 与 make 的关系就是：
Makefile 包含了所有的规则和目标，而 make 则是为了完成目标而去解释 Makefile 规则的工具。

make 语法

首先看看 make 的命令行语法：

make [options] [targets] [VAR=VALUE]...

[options]是命令行选项，可以用 make --help 命令查看全部，[VAR=VALUE]是在命令行上指定环境变量，这两个大家都很熟悉，将在稍后详细讲解。而[targets]是什么呢？字面的意思是"目标"，也就是希望本次 make 命令所完成的任务。凭经验猜测，这个[targets]大概可以用"ckeck","install"之类(也就是常见的测试和安装命令)。但是它到底是个啥玩意儿？不带任何"目标"的 make 命令是什么意思？为什么在安装 LFS 工具链中的 Perl-5.8.8 软件包时会出现"make perl utilities"这样怪异的命令？要回答这些问题必须首先理解 Makefile 文件中的"规则"。

Makefile 规则

Makefile 规则包含了文件之间的依赖关系和更新此规则目标所需要的命令。

一个简单的 Makefile 规则是这样写的：

TARGET : PREREQUISITES
COMMAND

TARGET

规则的目标。也就是可以被 make 使用的"目标"。有些目标可以没有依赖而只有动作(命令行)，比如"clean"，通常仅仅定义一系列删除中间文件的命令。同样，有些目标可以没有动作而只有依赖，比如"all"，通常仅仅用作"终极目标"。

PREREQUISITES

规则的依赖。通常一个目标依赖于一个或者多个文件。

COMMAND

规则的命令行。一个规则可以有零个或多个命令行。

OK! 现在你明白[targets]是什么了，原来它们来自于 Makefile 文件中一条条规则的目标(TARGET)。另外，Makefile文件中第一条规则的目标被称为"终极目标"，也就是你省略[targets]参数时的目标(通常为"all")。

当你查看一个实际的 Makefile 文件时，你会发现有些规则非常复杂，但是它都符合规则的基本格式。此外，Makefile 文件中通常还包含了除规则以外的其它很多东西，不过本文只关心其中的变量。

Makefile 变量

Makefile 中的"变量"更像是 C 语言中的宏，代表一个文本字符串(变量的值)，可以用于规则的任何部分。变量的定义很简单：VAR=VALUE；变量的引用也很简单：$(VAR) 或者 ${VAR}。变量引用的展开过程是严格的文本替换过程，就是说变量值的字符串被精确的展开在变量被引用的地方。比如，若定义：VAR=c，那么，"$(VAR) $(VAR)-$(VAR) VAR.$(VAR)"将被展开为"c c-c VAR.c"。

虽然在 Makefile 中可以直接使用系统的环境变量，但是也可以通过在 Makefile 中定义同名变量来"遮盖"系统的环境变量。另一方面，我们可以在调用 make 时使用 -e 参数强制使系统中的环境变量覆盖 Makefile 中的同名变量，除此之外，在调用 make 的命令行上使用 VAR=VALUE 格式指定的环境变量也可以覆盖 Makefile 中的同名变量。

Makefile 实例

下面看一个简单的、实际的Makefile文件：

CC=gcc
CPPFLAGS=
CFLAGS=-O2 -pipe
LDFLAGS=-s
PREFIX=/usr
all : prog1 prog2
prog1 : prog1.o
$(CC) $(LDFLAGS) -o prog1 prog1.o
prog1.o : prog1.c
$(CC) -c $(CFLAGS) prog1.c
prog2 : prog2.o
$(CC) $(CFLAGS) $(LDFLAGS) -o prog2 prog2.o
prog2.o : prog2.c
$(CC) -c $(CPPFLAGS) $(CFLAGS) prog2.c
clean :
rm -f *.{o,a} prog{1,2}
install : prog1 prog2
if ( test ! -d $(PREFIX)/bin ) ; then mkdir -p $(PREFIX)/bin ; fi
cp -f prog1 $(PREFIX)/bin/prog1
cp -f prog2 $(PREFIX)/bin/prog2
check test : prog1 prog2
prog1 < sample1.ref > sample1.rz
prog1 < sample2.ref > sample3.rz
cmp sample1.ok sample1.rz
cmp sample2.ok sample2.rz

从中可以看出，make 与 make all 以及 make prog1 prog2 三条命令其实是等价的。而常用的 make check 和 make install 也找到了归属。同时我们也看到了 Makefile 中的各种变量是如何影响编译的。针对这个特定的 Makefile ，你甚至可以省略安装三步曲中的 make 命令而直接使用 make install 进行安装。

同样，为了使用自定义的编译参数编译 prog2 ，我们可以使用 make prog2 CFLAGS="-O3 -march=athlon64" 或 CFLAGS="-O3 -march=athlon64" && make -e prog2 命令达到此目的。

Makefile 惯例

下面是Makefile中一些约定俗成的目标名称及其含义：

all

编译整个软件包，但不重建任何文档。一般此目标作为默认的终极目标。此目标一般对所有源程序的编译和连接使用"-g"选项，以使最终的可执行程序中包含调试信息。可使用 strip 程序去掉这些调试符号。

clean

清除当前目录下在 make 过程中产生的文件。它不能删除软件包的配置文件，也不能删除 build 时创建的那些文件。

distclean

类似于"clean"，但增加删除当前目录下的的配置文件、build 过程产生的文件。

info

产生必要的 Info 文档。

check 或 test

完成所有的自检功能。在执行检查之前，应确保所有程序已经被创建(但可以尚未安装)。为了进行测试，需要实现在程序没有安装的情况下被执行的测试命令。

install

完成程序的编译并将最终的可执行程序、库文件等拷贝到指定的目录。此种安装一般不对可执行程序进行 strip 操作。

install-strip

和"install"类似，但是会对复制到安装目录下的可执行文件进行 strip 操作。

uninstall

删除所有由"install"安装的文件。

installcheck

执行安装检查。在执行安装检查之前，需要确保所有程序已经被创建并且被安装。

installdirs

创建安装目录及其子目录。它不能更改软件的编译目录，而仅仅是创建程序的安装目录。

下面是 Makefile 中一些约定俗成的变量名称及其含义：

这些约定俗成的变量分为三类。第一类代表可执行程序的名字，例如 CC 代表编译器这个可执行程序；第二类代表程序使用的参数(多个参数使用空格分开)，例如 CFLAGS 代表编译器执行时使用的参数(一种怪异的做法是直接在 CC 中包含参数)；第三类代表安装目录，例如 prefix 等等，含义简单，下面只列出它们的默认值。

AR   函数库打包程序，可创建静态库.a文档。默认是"ar"。
AS   汇编程序。默认是"as"。
CC   C编译程序。默认是"cc"。
CXX  C++编译程序。默认是"g++"。
CPP  C/C++预处理器。默认是"$(CC) -E"。
FC   Fortran编译器。默认是"f77"。
PC   Pascal语言编译器。默认是"pc"。
YACC Yacc文法分析器。默认是"yacc"。
ARFLAGS     函数库打包程序的命令行参数。默认值是"rv"。
ASFLAGS     汇编程序的命令行参数。
CFLAGS      C编译程序的命令行参数。
CXXFLAGS    C++编译程序的命令行参数。
CPPFLAGS    C/C++预处理器的命令行参数。
FFLAGS      Fortran编译器的命令行参数。
PFLAGS      Pascal编译器的命令行参数。
YFLAGS      Yacc文法分析器的命令行参数。
LDFLAGS     链接器的命令行参数。
prefix      /usr/local
exec_prefix $(prefix)
bindir      $(exec_prefix)/bin
sbindir     $(exec_prefix)/sbin
libexecdir  $(exec_prefix)/libexec
datadir     $(prefix)/share
sysconfdir  $(prefix)/etc
sharedstatedir $(prefix)/com
localstatedir  $(prefix)/var
libdir      $(exec_prefix)/lib
infodir     $(prefix)/info
includedir  $(prefix)/include
oldincludedir  $(prefix)/include
mandir      $(prefix)/man
srcdir      需要编译的源文件所在的目录，无默认值

make 选项

最后说说 make 的命令行选项(以Make-3.81版本为准)：

-B, --always-make

无条件的重建所有规则的目标，而不是根据规则的依赖关系决定是否重建某些目标文件。

-C DIR, --directory=DIR

在做任何动作之前先切换工作目录到 DIR ，然后再执行 make 程序。

-d

在 make 执行过程中打印出所有的调试信息。包括：make 认为那些文件需要重建；那些文件需要比较它们的最后修改时间、比较的结果；重建目标所要执行的命令；使用的隐含规则等。使用该选项我们可以看到 make 构造依赖关系链、重建目标过程的所有信息，它等效于"-debug=a"。

--debug=FLAGS

在 make 执行过程中打印出调试信息。FLAGS 用于控制调试信息级别：

a

输出所有类型的调试信息

b

输出基本调试信息。包括：那些目标过期、是否重建成功过期目标文件。

v

除 b 级别以外还包括：解析的 makefile 文件名，不需要重建文件等。

i

除 b 级别以外还包括：所有使用到的隐含规则描述。

j

输出所有执行命令的子进程，包括命令执行的 PID 等。

m

输出 make 读取、更新、执行 makefile 的信息。

-e, --environment-overrides

使用系统环境变量的定义覆盖 Makefile 中的同名变量定义。

-f FILE, --file=FILE, --makefile=FILE

将 FILE 指定为 Makefile 文件。

-h, --help

打印帮助信息。

-i, --ignore-errors

忽略规则命令执行过程中的错误。

-I DIR, --include-dir=DIR

指定包含 Makefile 文件的搜索目录。使用多个"-I"指定目录时，搜索目录按照指定顺序进行。

-j [N], --jobs[=N]

指定并行执行的命令数目。在没有指定"-j"参数的情况下，执行的命令数目将是系统允许的最大可能数目。

-k, --keep-going

遇见命令执行错误时不终止 make 的执行，也就是尽可能执行所有的命令，直到出现致命错误才终止。

-l [N], --load-average[=N], --max-load[=N]

如果系统负荷超过 LOAD(浮点数)，不再启动新任务。

-L, --check-symlink-times

同时考察符号连接的时间戳和它所指向的目标文件的时间戳，以两者中较晚的时间戳为准。

-n, --just-print, --dry-run, --recon

只打印出所要执行的命令，但并不实际执行命令。

-o FILE, --old-file=FILE, --assume-old=FILE

即使相对于它的依赖已经过期也不重建 FILE 文件；同时也不重建依赖于此文件任何文件。

-p, --print-data-base

命令执行之前，打印出 make 读取的 Makefile 的所有数据（包括规则和变量的值），同时打印出 make 的版本信息。如果只需要打印这些数据信息，可以使用 make -qp 命令。查看 make 执行前的预设规则和变量，可使用命令 make -p -f /dev/null 。

-q, --question

"询问模式"。不运行任何命令，并且无输出，只是返回一个查询状态。返回状态为 0 表示没有目标需要重建，1 表示存在需要重建的目标，2 表示有错误发生。

-r, --no-builtin-rules

取消所有内嵌的隐含规则，不过你可以在 Makefile 中使用模式规则来定义规则。同时还会取消所有支持后追规则的隐含后缀列表，同样我们也可以在 Makefile 中使用".SUFFIXES"定义我们自己的后缀规则。此选项不会取消 make 内嵌的隐含变量。

-R, --no-builtin-variables

取消 make 内嵌的隐含变量，不过我们可以在 Makefile 中明确定义某些变量。注意，此选项同时打开了"-r"选项。因为隐含规则是以内嵌的隐含变量为基础的。

-s, --silent, --quiet

不显示所执行的命令。

-S, --no-keep-going, --stop

取消"-k"选项。在递归的 make 过程中子 make 通过 MAKEFLAGS 变量继承了上层的命令行选项。我们可以在子 make 中使用"-S"选项取消上层传递的"-k"选项，或者取消系统环境变量 MAKEFLAGS 中的"-k"选项。

-t, --touch

更新所有目标文件的时间戳到当前系统时间。防止 make 对所有过时目标文件的重建。

-v, --version

打印版本信息。

-w, --print-directory

在 make 进入一个目录之前打印工作目录。使用"-C"选项时默认打开这个选项。

--no-print-directory

取消"-w"选项。可以是用在递归的 make 调用过程中，取消"-C"参数将默认打开"-w"。

-W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE

设定 FILE 文件的时间戳为当前时间，但不改变文件实际的最后修改时间。此选项主要是为实现了对所有依赖于 FILE 文件的目标的强制重建。

--warn-undefined-variables

在发现 Makefile 中存在对未定义的变量进行引用时给出告警信息。此功能可以帮助我们调试一个存在多级套嵌变量引用的复杂 Makefile 。但是：我们建议在书写 Makefile 时尽量避免超过三级以上的变量套嵌引用。

configure

此阶段的主要目的是生成 Makefile 文件，是最关键的运筹帷幄阶段，基本上所有可以对安装过程进行的个性化调整都集中在这一步。

configure 脚本能够对 Makefile 中的哪些内容产生影响呢？基本上可以这么说：所有内容，包括本文最关心的 Makefile 规则与 Makefile 变量。那么又是哪些因素影响着最终生成的 Makefile 文件呢？答曰：系统环境和配置选项。

配置选项的影响是显而易见的。但是"系统环境"的概念却很宽泛，包含很多方面内容，不过我们这里只关心环境变量，具体说来就是将来会在 Makefile 中使用到的环境变量以及与 Makefile 中的变量同名的环境变量。

通用 configure 语法

在进一步讲述之前，先看看 configure 脚本的语法，一般有两种：

configure [OPTIONS] [VAR=VALUE]...

configure [OPTIONS] [HOST]

不管是哪种语法，我们都可以用 configure --help 查看所有可用的[OPTIONS]，并且通常在结尾部分还能看到这个脚本所关心的环境变量有哪些。在本文中将对这两种语法进行合并，使用下面这种简化的语法：

configure [OPTIONS]

这种语法能够被所有的 configure 脚本所识别，同时也能通过设置环境变量和使用特定的[OPTIONS]完成上述两种语法的一切功能。

通用 configure 选项

虽然每个软件包的 configure 脚本千差万别，但是它们却都有一些共同的选项，也基本上都遵守相同的选项语法。

脚本自身选项

--help

显示帮助信息。

--version

显示版本信息。

--cache-file=FILE

在FILE文件中缓存测试结果(默认禁用)。

--no-create

configure脚本运行结束后不输出结果文件，常用于正式编译前的测试。

--quiet, --silent

不显示脚本工作期间输出的"checking ..."消息。

目录选项

--srcdir=DIR

源代码文件所在目录，默认为configure脚本所在目录或其父目录。

--prefix=PREFIX

体系无关文件的顶级安装目录PREFIX ，默认值一般是 /usr/local 或 /usr/local/pkgName

--exec-prefix=EPREFIX

体系相关文件的顶级安装目录EPREFIX ，默认值一般是 PREFIX

--bindir=DIR

用户可执行文件的存放目录DIR ，默认值一般是 EPREFIX/bin

--sbindir=DIR

系统管理员可执行目录DIR ，默认值一般是 EPREFIX/sbin

--libexecdir=DIR

程序可执行目录DIR ，默认值一般是 EPREFIX/libexec

--datadir=DIR

通用数据文件的安装目录DIR ，默认值一般是 PREFIX/share

--sysconfdir=DIR

只读的单一机器数据目录DIR ，默认值一般是 PREFIX/etc

--sharedstatedir=DIR

可写的体系无关数据目录DIR ，默认值一般是 PREFIX/com

--localstatedir=DIR

可写的单一机器数据目录DIR ，默认值一般是 PREFIX/var

--libdir=DIR

库文件的安装目录DIR ，默认值一般是 EPREFIX/lib

--includedir=DIR

C头文件目录DIR ，默认值一般是 PREFIX/include

--oldincludedir=DIR

非gcc的C头文件目录DIR ，默认值一般是 /usr/include

--infodir=DIR

Info文档的安装目录DIR ，默认值一般是 PREFIX/info

--mandir=DIR

Man文档的安装目录DIR ，默认值一般是 PREFIX/man

体系结构选项

玩交叉编译的朋友对这些选项已经很熟悉了，对于不使用交叉编译的朋友也不必担心，不要理它们就可以了。

--build=BUILD

工具链当前的运行环境，默认是 config.guess 脚本的输出结果。

--host=HOST

编译出的二进制代码将要运行在HOST上，默认值是BUILD。

--target=TARGET

编译出的工具链所将来生成的二进制代码要在TARGET上运行，这个选项仅对工具链(也就是GCC和Binutils两者)有意义。

特性选项

--enable-FEATURE

启用FEATURE特性

--disable-FEATURE

禁用FEATURE特性

--with-PACKAGE[=DIR]

启用附加软件包PACKAGE，亦可同时指定PACKAGE所在目录DIR

--without-PACKAGE

禁用附加软件包PACKAGE

通用环境变量

除了上述通用的选项外，下列环境变量影响着最终生成的 Makefile 文件：

CPP

C预处理器命令

CXXCPP

C++预处理器命令

CPPFLAGS

C/C++预处理器命令行参数

CC

C编译器命令

CFLAGS

C编译器命令行参数

CXX

C++编译器命令

CXXFLAGS

C++编译器命令行参数

LDFLAGS

连接器命令行参数

至于设置这些环境变量的方法，你可以将它们 export 为全局变量在全局范围内使用，也可以在命令行上使用 [VAR=VALUE]... configure [OPTIONS] 的语法局部使用。此处就不详细描述了。

看完上述内容以后，不用多说你应当自然而然的明白该进行如何对自己的软件包进行定制安装了。祝你好运！

补充读物

根据d00m3d的推荐，LinuxSir.Org上的另外两篇帖子：《编译的一点体会》和《关于库的深入思考》，可以作为本文的进一步读物，更加有助于深入理解本文的主题。另外建立在本文基础上的《编译优化指南》专门针对与优化相关的问题进行了探讨。推荐阅读。

CentOS的源有好多，网上大多数人都推荐中科大的源，经测试在青岛网通连接中科大（http://centos.ustc.edu.cn/）的速度也非常好，那就用它吧。

先将RHEL5自带的yum删除，执行

将所有找到的包都删除（有些需要加上--nodeps），然后到中科大的网站下载如下两个包： 

下载后安装：

然后下载中科大专用的配置文件：

因为默认的配置文件中服务器地址用的版本号是变量$releasever，所以需要将其替换为实际的版本号，否则是无法连接到服务器的，当前CentOS最新版是5.3，所以我们修改CentOS-Base.repo

在vi编辑器中进行全文件替换

最后保存退出即可。然后执行

即可进行更新，当然，你也可以选择不更新，只安装你需要的软件，如：

大功告成！

apt-cache search package 搜索包

apt-cache show package 获取包的相关信息，如说明、大小、版本等

sudo apt-get install package 安装包

sudo apt-get install package - - reinstall 重新安装包

sudo apt-get -f install 修复安装"-f = ——fix-missing"

sudo apt-get remove package 删除包

sudo apt-get remove package - - purge 删除包，包括删除配置文件等

sudo apt-get update 更新源

sudo apt-get upgrade 更新已安装的包

sudo apt-get dist-upgrade 升级系统

sudo apt-get dselect-upgrade 使用 dselect 升级

apt-cache depends package 了解使用依赖

apt-cache rdepends package 是查看该包被哪些包依赖

sudo apt-get build-dep package 安装相关的编译环境

apt-get source package 下载该包的源代码

sudo apt-get clean && sudo apt-get autoclean 清理无用的包

sudo apt-get check 检查是否有损坏的依赖