http://kimva.blogbus.com/logs/10795776.html
http://kimva.blogbus.com/logs/10795836.html
摘要：
本《功略》集中了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 。