jinfeng_wang

一、中間件技術(shù)在系統(tǒng)設(shè)計(jì)規(guī)劃方面的經(jīng)驗(yàn)總結(jié)

1.1、中間件應(yīng)用架構(gòu)的選擇
這種架構(gòu)選擇的焦點(diǎn)就是業(yè)務(wù)邏輯到底是放在前臺(tái)應(yīng)用中還是放在后臺(tái)中間件應(yīng)用中。其實(shí)，引入中間件平臺(tái)的原因之一就是業(yè)務(wù)邏輯的集中管理，出現(xiàn)這種爭(zhēng)論的原因主要是開(kāi)發(fā)商對(duì)這種業(yè)務(wù)邏輯集中的理解不深，在應(yīng)用設(shè)計(jì)的過(guò)程中仍然沒(méi)有擺脫以前兩層結(jié)構(gòu)的影響，再加上因?yàn)闃I(yè)務(wù)邏輯集中會(huì)增加程序開(kāi)發(fā)量，才出現(xiàn)了這種情況。我們認(rèn)為，把業(yè)務(wù)邏輯集中在中間件服務(wù)器上不僅對(duì)于業(yè)務(wù)邏輯的集中管理有好處，而且對(duì)于系統(tǒng)的后期運(yùn)行維護(hù)、軟件的升級(jí)管理都有著明顯的優(yōu)勢(shì)。當(dāng)然,在開(kāi)發(fā)的工作量方面，業(yè)務(wù)邏輯集中時(shí)工作量大很多。

1.2、中間件服務(wù)分布的設(shè)計(jì)和優(yōu)化原則
在Tuxedo中，Server可以理解成為Unix的一個(gè)進(jìn)程，Service可以理解成為應(yīng)用進(jìn)程Server中的一個(gè)函數(shù)。用戶可以任意劃分Server和Service：既可以把所有的Service放在一個(gè)單一的Server中，也可以采用“一個(gè)Service一個(gè)Server”的方式。Tuxedo對(duì)此沒(méi)有任何限制。
中間件應(yīng)用的性能直接影響到營(yíng)業(yè)前臺(tái)服務(wù)的穩(wěn)定性和連續(xù)性，而影響中間件應(yīng)用性能的因素除了硬件資源的保證、數(shù)據(jù)庫(kù)響應(yīng)時(shí)間、中間件應(yīng)用軟件本身的質(zhì)量之外，中間件應(yīng)用服務(wù)的分布也起著至關(guān)重要的作用。我們有著這樣的一個(gè)例子，在前臺(tái)進(jìn)入收費(fèi)界面的時(shí)候，應(yīng)用程序需要調(diào)用一個(gè)SERVICE名字叫A，A分布在一個(gè)叫SA的server中，而SA中又包含著很多其他的在線統(tǒng)計(jì)的SERVICE B，結(jié)果造成了SA響應(yīng)B調(diào)用的時(shí)候執(zhí)行時(shí)間比較長(zhǎng)，所有的SA都在執(zhí)行SERVICE B ，前臺(tái)請(qǐng)求SERVICE A得不到響應(yīng)，收費(fèi)的界面怎么都進(jìn)不去，從而導(dǎo)致前臺(tái)收費(fèi)業(yè)務(wù)中斷。這就是個(gè)典型的因?yàn)榉?wù)分布不當(dāng)造成的系統(tǒng)故障。
我們?cè)谙到y(tǒng)規(guī)劃設(shè)計(jì)過(guò)程中遵循的一個(gè)最基本原則就是盡量將“類似的Service”捆綁在一個(gè)Server之內(nèi)。所謂“類似的Service”是指這些函數(shù)有相似的大小、執(zhí)行時(shí)間、復(fù)雜度或者功能。我們來(lái)考慮一個(gè)極端的例子：假設(shè)一個(gè)Service A是完成非常簡(jiǎn)單工作的，它的平均執(zhí)行時(shí)間是100毫秒。另一個(gè)Service B進(jìn)行數(shù)據(jù)庫(kù)的查詢，它的執(zhí)行時(shí)間可能長(zhǎng)達(dá)20秒。如果將這兩個(gè)Service捆綁在一起使用，就會(huì)出現(xiàn)非常嚴(yán)重的后果。大家知道，操作系統(tǒng)的基本調(diào)度單位是進(jìn)程。在一個(gè)進(jìn)程中的Service執(zhí)行是串行的。Tuxedo把發(fā)往同一個(gè)Server的請(qǐng)求交易包放在同一個(gè)消息隊(duì)列中。當(dāng)Service B在執(zhí)行的時(shí)候，Service A的請(qǐng)求包必須在隊(duì)列里面等待20秒以上才可能被執(zhí)行，雖然它的執(zhí)行時(shí)間僅僅100毫秒。這顯然是不能容忍和應(yīng)該避免的。
實(shí)際上，用戶在設(shè)計(jì)和開(kāi)發(fā)應(yīng)用程序的時(shí)候，并不能完全估計(jì)出每個(gè)Service的執(zhí)行時(shí)間和頻度。所以對(duì)Server和Service的劃分優(yōu)化是在應(yīng)用程序開(kāi)發(fā)完畢后進(jìn)行調(diào)整的。調(diào)整的依據(jù)就是在系統(tǒng)運(yùn)行的時(shí)候記錄每個(gè)Service的執(zhí)行時(shí)間和頻度，然后根據(jù)這些數(shù)據(jù)來(lái)進(jìn)行優(yōu)化調(diào)整。下面就是我們?cè)趯?shí)際當(dāng)中獲得經(jīng)驗(yàn)的一些系統(tǒng)總結(jié)。
1、 區(qū)分Service的不同類型：是業(yè)務(wù)操作還是簡(jiǎn)單的數(shù)據(jù)訪問(wèn)
在中間件應(yīng)用中的Service可以進(jìn)一步細(xì)分成負(fù)責(zé)完成業(yè)務(wù)操作和負(fù)責(zé)數(shù)據(jù)訪問(wèn)的兩種類型。在設(shè)計(jì)的時(shí)候，最好把這兩種不同類型的Service區(qū)別出來(lái)。所謂完成業(yè)務(wù)操作的類型其實(shí)就是進(jìn)行數(shù)據(jù)修改的操作，負(fù)責(zé)數(shù)據(jù)訪問(wèn)的類型其實(shí)就是進(jìn)行數(shù)據(jù)查詢的操作。但是在實(shí)際的系統(tǒng)運(yùn)行過(guò)程中，凡是涉及到數(shù)據(jù)修改的操作過(guò)程中必然會(huì)有數(shù)據(jù)查詢的操作，這種類型的操作也應(yīng)該規(guī)整到第1種類型中去。
2、 請(qǐng)求/響應(yīng)類型的Service要和會(huì)話Service分開(kāi)在不同的Server中
在Tuxedo中，一個(gè)Server要么支持請(qǐng)求/響應(yīng)類型類型的Service，要么支持會(huì)話方式的Service。會(huì)話方式和請(qǐng)求/響應(yīng)方式是兩種互斥的通訊方式。請(qǐng)求/響應(yīng)方式效率比較高，是使用最頻繁的通訊類型。Tpcall/tpacall/tpforward都是這種類型的函數(shù)。會(huì)話方式適合大量的數(shù)據(jù)傳輸，但是它的代價(jià)是效率的下降。所以這兩種類型的Service要分開(kāi)放在不同的Server里面。
3、 執(zhí)行時(shí)間相似的Service放在同一個(gè)Server里面
在Tuxedo應(yīng)用環(huán)境中，可能有成百上千的Service，這些Service的執(zhí)行時(shí)間顯然是不同的。對(duì)于單線程的Server來(lái)說(shuō)，雖然它可能有多個(gè)Service，但是這些Service的執(zhí)行是串行的。如果某個(gè)Server擁有兩個(gè)Service，A和B。A的執(zhí)行時(shí)間是100ms，B的執(zhí)行時(shí)間是1000ms，也就是說(shuō)執(zhí)行一次B的時(shí)間可以執(zhí)行十次A。那么當(dāng)B在執(zhí)行的時(shí)候，可能會(huì)有十個(gè)A在隊(duì)列里面等待。這種情況會(huì)急劇降低該Server處理Service的吞吐率。因此很自然的一個(gè)原則是把執(zhí)行時(shí)間相似的Service放在同一個(gè)Server里面。
4、 具有相同執(zhí)行頻度的Service放在同一個(gè)Server里面
在一個(gè)典型的Tuxedo應(yīng)用系統(tǒng)中，并不是所有的Service的執(zhí)行頻率都是相同的。可能一些Service被頻繁的執(zhí)行，而另外一些Service只是偶爾才被執(zhí)行幾次。把這些SERVICE分開(kāi)可以避免偶爾調(diào)用的SERVICE堵塞頻繁調(diào)用的SERVICE。
5、 避免死鎖的情況發(fā)生
在Tuxedo中的死鎖情況有兩種，第一種是一個(gè)Server中的Service A去調(diào)用同在一個(gè)Server中的Service B。這種死鎖發(fā)生的原因是，對(duì)于單線程的Server來(lái)說(shuō)，它其中的Service是串行執(zhí)行的。Service A去調(diào)用Service B的時(shí)候，Service A還沒(méi)有執(zhí)行完，它等待Service B的返回結(jié)果。 但是Service B不能執(zhí)行，因?yàn)樵揝erver還處于執(zhí)行Service A的狀態(tài)。最終導(dǎo)致Service A超時(shí)而出錯(cuò)。
第二種情況是兩個(gè)Server中的Service互相調(diào)用。例如Server1和Server2，Server1中的Service A去調(diào)用Server2中的Service X。同時(shí)Server2中的Service Y去調(diào)用Server1中的Service B。這種情況發(fā)生的死鎖和第一種情況非常類似，都是因?yàn)檫M(jìn)程只能串行實(shí)行Service導(dǎo)致的。
這兩種死鎖情況在應(yīng)用設(shè)計(jì)時(shí)特別要注意避免。第一種情況是比較容易察覺(jué)的，但是第二種情況就不大容易察覺(jué)。
1.3、中間件系統(tǒng)應(yīng)用平臺(tái)FAILOVER方式的選擇在真實(shí)的生產(chǎn)運(yùn)行環(huán)境中，運(yùn)行平臺(tái)的failover是一個(gè)必須考慮的問(wèn)題。Tuxedo平臺(tái)上的實(shí)現(xiàn)failover機(jī)制基本上有兩種，一種是利用tuxedo自己的failover機(jī)制配合前臺(tái)配兩個(gè)WSNADDR地址來(lái)實(shí)現(xiàn)failover。一種是利用雙機(jī)軟件來(lái)實(shí)現(xiàn)。
第一種方式是指使兩臺(tái)的中間件服務(wù)器處于MP工作模式下，在每一臺(tái)都啟動(dòng)WSL進(jìn)程，然后在中間件前臺(tái)配置兩個(gè)ip地址。通過(guò)自己實(shí)驗(yàn)發(fā)現(xiàn)利用tuxedo自己的failover機(jī)制只有如下好處即不需要額外的操作系統(tǒng)和軟件的支持，但是其缺點(diǎn)確很多，主要缺點(diǎn)如下：
1、兩臺(tái)中間件平臺(tái)的MASTER切換必須要手工完成，無(wú)法自動(dòng)完成。
2、前臺(tái)配置的兩個(gè)WSNADDR地址，如果第一個(gè)地址失敗，要重新連接到第二個(gè)地址需要很長(zhǎng)的時(shí)間，并且在每次服務(wù)調(diào)用時(shí)都要等待同樣的時(shí)間。
通過(guò)雙機(jī)軟件來(lái)實(shí)現(xiàn)FAILOVER是指兩臺(tái)中間件服務(wù)器都配置在SHP模式下，然后利用雙機(jī)軟件的ip切換功能來(lái)實(shí)現(xiàn)failover。這種方法需要在各自的配置文件中加入另外一臺(tái)主機(jī)的WSL的信息，在另外一臺(tái)主機(jī)故障時(shí)，通過(guò)雙機(jī)軟件進(jìn)行IP切換，再通過(guò)雙機(jī)切換腳本將這臺(tái)主機(jī)的備用WSL啟動(dòng)即可。采用這種方式有以下優(yōu)點(diǎn)
1、機(jī)器切換自動(dòng)完成，不需要人工干預(yù)。
2、前臺(tái)業(yè)務(wù)不受影響，能保證業(yè)務(wù)開(kāi)展的連續(xù)性。
缺點(diǎn)主要有
1、在正常情況下，每一臺(tái)主機(jī)的啟動(dòng)中間件時(shí)，備用的WSL服務(wù)會(huì)啟動(dòng)失敗，不過(guò)這不影響正常使用，備用的WSL只在另外一臺(tái)主機(jī)故障后才起作用。
2、需要額外的雙機(jī)配置和腳本配置工作。
經(jīng)過(guò)這些比較，我們選定了采用雙機(jī)軟件的方案實(shí)現(xiàn)了中間件的failover機(jī)制。在以后的運(yùn)行維護(hù)過(guò)程中起到了好的效果。
1.4、中間件與數(shù)據(jù)庫(kù)的連接方式的選擇在TUXEDO中間件應(yīng)用中連接數(shù)據(jù)庫(kù)的方式有兩種，一種為通過(guò)XA方式連接數(shù)據(jù)庫(kù)，另外一種是在應(yīng)用程序中自己連接數(shù)據(jù)庫(kù)。
通過(guò)XA方式連接數(shù)據(jù)庫(kù)是指利用關(guān)系型數(shù)據(jù)庫(kù)的XA接口，在tuxedo的配置文件中的OPENINFO段中加入連接信息，然后在server程序的初始化代碼的中調(diào)用中tp_open（或xa_open），當(dāng)SERVER啟動(dòng)時(shí)進(jìn)行數(shù)據(jù)庫(kù)連接。
通過(guò)應(yīng)用程序直接連接數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的連接操作不一定是在SERVER啟動(dòng)時(shí)進(jìn)行的。
這兩種方式的連接在BOSS系統(tǒng)中都會(huì)用到，其中的區(qū)別主要就在于如果業(yè)務(wù)操作的事務(wù)為分布式事務(wù)時(shí)，則必須要用XA方式。詳細(xì)比較如下：
1、通過(guò)XA連接的方式可以實(shí)現(xiàn)分布式事務(wù)，即能夠保證事務(wù)在不同數(shù)據(jù)庫(kù)中的一致性。但是正是因?yàn)槿绱耍鼘?duì)中間件系統(tǒng)和數(shù)據(jù)庫(kù)系統(tǒng)都有額外的開(kāi)銷，有時(shí)候這種開(kāi)銷甚至?xí)绊懴到y(tǒng)的性能。
2、通過(guò)應(yīng)用程序直連數(shù)據(jù)庫(kù)的方法不能夠?qū)崿F(xiàn)分布式事務(wù)，但是同時(shí)也因此減少了對(duì)系統(tǒng)的壓力。
綜上，選擇數(shù)據(jù)庫(kù)的連接方式對(duì)整個(gè)系統(tǒng)的性能影響也是至關(guān)重要的，我們有個(gè)原則，凡是在不涉及到分布式事務(wù)的地方就不用XA連接。過(guò)多的依賴了XA接口，會(huì)給系統(tǒng)帶來(lái)了許多額外的負(fù)擔(dān)和壓力，也會(huì)造成許多額外的故障。

二、中間件技術(shù)在系統(tǒng)維護(hù)方面的經(jīng)驗(yàn)總結(jié)在中間件的日常維護(hù)中，我們了解了一些TUXEDO的基本知識(shí)，摸索了一套行之有效的故障排除方法，積累了一些常見(jiàn)故障的排除經(jīng)驗(yàn)，現(xiàn)在與大家介紹如下：
2.1、LICENSE數(shù)的問(wèn)題tuxedo的license由文本文件lic.txt來(lái)控制，位于udataobj目錄下，分為SDK/RTK兩種，兩種LICENSE不能合并使用。它控制的是并發(fā)用戶數(shù)并且有10%的冗余，這里的并發(fā)用戶數(shù)是指在某一時(shí)刻前臺(tái)程序已經(jīng)發(fā)起tpinit還沒(méi)有作tpterm的連接數(shù)，所以在tuxedo中間件的使用中存在著長(zhǎng)連接和短連接的問(wèn)題。長(zhǎng)連接是指tpinit后就開(kāi)始一系列的服務(wù)調(diào)用，只在系統(tǒng)重啟或系統(tǒng)非常空閑的時(shí)候才做tpterm，而短連接是指每次服務(wù)調(diào)用前作tpinit，調(diào)用結(jié)束后立即作tpterm調(diào)用。因?yàn)槎踢B接下的服務(wù)調(diào)用需要額外的連接時(shí)間消耗，這對(duì)系統(tǒng)響應(yīng)時(shí)間會(huì)有影響，而長(zhǎng)連接又會(huì)占用系統(tǒng)的并發(fā)用戶數(shù)。所以在系統(tǒng)設(shè)計(jì)時(shí)需要針對(duì)不同的應(yīng)用情況做出不同的設(shè)計(jì)，比如針對(duì)接口類型的應(yīng)用因?yàn)榉?wù)調(diào)用比較頻繁，進(jìn)行連接的時(shí)間就會(huì)占比較大的比重，這時(shí)就需要使用長(zhǎng)連接，而對(duì)于前臺(tái)應(yīng)用類型的應(yīng)用，連接過(guò)程的時(shí)間對(duì)于業(yè)務(wù)操作的時(shí)間來(lái)說(shuō)是可以忽略的，這時(shí)就要用短連接來(lái)節(jié)約license資源。

2.2、客戶端連接的問(wèn)題當(dāng)客戶端無(wú)法連接中間件時(shí)，我們需要確認(rèn)的是
1、 客戶端的WSNADDR是否設(shè)置或是否設(shè)置正確。
2、 系統(tǒng)配置文件中的MAXWSCLIENTS和MAXACCESS是否正確設(shè)置。
3、 WSL是否啟動(dòng)，WSH的個(gè)數(shù)是否足夠。
4、 是否有防火墻，如果有防火墻存在，則需要在WSL的配置中作相應(yīng)的地址映射和端口指定。
5、 操作系統(tǒng)是否有足夠的SCOKET資源使用。
解決了這些問(wèn)題后，一般就可以解決客戶端連接不上的問(wèn)題了。
在TUXEDO中，參數(shù)TMTRACE對(duì)故障的定位和排除很有作用，它是一個(gè)環(huán)境境變量。我們一般在系統(tǒng)監(jiān)控的工作終端上將此參數(shù)設(shè)置為on，在前臺(tái)報(bào)系統(tǒng)故障的時(shí)候，我們直接進(jìn)入故障模塊將故障重現(xiàn)，然后在終端機(jī)器的c:\或者tuxedo的安裝目錄下打開(kāi)一個(gè)ULOG文件，在此文件中會(huì)發(fā)現(xiàn)tpcall服務(wù)的失敗信息，根據(jù)這個(gè)信息查找對(duì)應(yīng)的SERVER和SERVICE的對(duì)應(yīng)表，很快就可以找到問(wèn)題服務(wù)。采用這種方式，維護(hù)人員不需要了解程序的具體流程就可以定位錯(cuò)誤解決故障。
在TUXEDO的服務(wù)端，有幾類文件需要關(guān)注，這些文件包括ULOG文件、XA接口的trc文件、數(shù)據(jù)庫(kù)連接故障的sqlnet.log、標(biāo)準(zhǔn)輸出文件stdout（也可以被應(yīng)用程序自己定義）。在這些文件中包含著豐富的系統(tǒng)運(yùn)行錯(cuò)誤告警信息。ULOG記載關(guān)于中間件的啟停記錄和系統(tǒng)本身的一些配置運(yùn)行告警信息。XA的trc文件記錄的是XA接口方面的一些的錯(cuò)誤信息，關(guān)于分布式事務(wù)的一些錯(cuò)誤在這個(gè)文件中都有記錄。sqlnet.log記錄了應(yīng)用程序和數(shù)據(jù)庫(kù)連接故障的信息，只要有當(dāng)前日期時(shí)間的這個(gè)文件存在，應(yīng)用和數(shù)據(jù)庫(kù)的連接就會(huì)存在問(wèn)題。標(biāo)準(zhǔn)輸出文件stdout記錄了應(yīng)用程序本身的運(yùn)行信息。這些文件的跟蹤檢查對(duì)于及時(shí)主動(dòng)的發(fā)現(xiàn)故障有著重要的意義。

2.3、事務(wù)控制的問(wèn)題1、事務(wù)邊界的問(wèn)題：在這里我們要遵循誰(shuí)發(fā)起發(fā)起事務(wù)，誰(shuí)就結(jié)束的原則，這里的誰(shuí)主要是指中間件的前臺(tái)和后臺(tái)。我們知道在TUXEDO中事務(wù)的發(fā)起既可以在前臺(tái)程序中發(fā)起，也可以在后臺(tái)程序中發(fā)起。無(wú)論放在前臺(tái)還是放在后臺(tái)都有其優(yōu)缺點(diǎn)。事務(wù)放在前臺(tái)增加了網(wǎng)絡(luò)傳輸?shù)牧髁浚?dāng)時(shí)可以保證異常情況下前后臺(tái)操作的一致性，事務(wù)放在后臺(tái)可以減少網(wǎng)絡(luò)流量，但是對(duì)于異常情況下前后臺(tái)操作的一致性很難保證。我們采用的是事務(wù)放在前臺(tái)程序中。但是無(wú)論放在前臺(tái)還是后臺(tái)，都要遵循誰(shuí)發(fā)起，誰(shuí)結(jié)束的原則。
2、XA接口使用的注意事項(xiàng)：首先是XA資源文件的配置，在oracle數(shù)據(jù)庫(kù)中一般用到的是libclntsh.a，我們可以先Make sample，提取其中用到的連接庫(kù)加入到RM文件中即可。其次在oracle8i之前要對(duì)XA進(jìn)行授權(quán)，要在oracle的DBA用戶下執(zhí)行g(shù)rant select on dba_pending_transactions to public。
3、事務(wù)掛起的問(wèn)題：在使用XA的情況下，我們經(jīng)常會(huì)遇到這種情況，SERVER進(jìn)程還在，可就是不做事。在相關(guān)的日志文件中總是報(bào)“當(dāng)前的進(jìn)程已經(jīng)在一個(gè)本地事務(wù)中了”的錯(cuò)誤，這時(shí)只有重啟該SERVER，才能排除故障。其實(shí)這是一個(gè)事務(wù)控制的問(wèn)題，它產(chǎn)生的根本原因是在開(kāi)啟全局事務(wù)前，該SERVER執(zhí)行了一個(gè)本地的事務(wù)并且沒(méi)有提交或回滾。在程序代碼上表現(xiàn)為如下三種原因：
（1）、在調(diào)用該SERVER的某個(gè)帶DML語(yǔ)句的service前沒(méi)有加tpbegin。
（2）、在調(diào)用tpbegin后沒(méi)有判斷返回值。
（3）、tpbegin后的tpcall服務(wù)調(diào)用沒(méi)有判斷返回值，在全局事務(wù)超時(shí)后沒(méi)有能夠及時(shí)的退出后續(xù)的調(diào)用，導(dǎo)致下一個(gè)tpcall產(chǎn)生了一個(gè)本地事務(wù)。
此外，還會(huì)有一類比較特殊的問(wèn)題，那就是TMS服務(wù)掛起的問(wèn)題，利用tmadmin中的pq命令發(fā)現(xiàn)TMS的隊(duì)列中有很多請(qǐng)求存在，在這種情況下，一般只能等待其執(zhí)行完成，情況嚴(yán)重時(shí)，則需要調(diào)整相應(yīng)的數(shù)據(jù)庫(kù)參數(shù)，在ORACLE中該參數(shù)應(yīng)該設(shè)為max_commit_propagation_delay>=90000。
在實(shí)際的運(yùn)行維護(hù)中，我們發(fā)現(xiàn)即使把數(shù)據(jù)庫(kù)參數(shù)調(diào)整了，有時(shí)還會(huì)有TMS掛起的故障發(fā)生。針對(duì)這件事情我們專門(mén)作了研究，TMS之所以掛起是因?yàn)門(mén)MS在等待數(shù)據(jù)庫(kù)中DX獨(dú)占鎖的釋放，這種獨(dú)占鎖加鎖的對(duì)象一般都是ORACLE的系統(tǒng)對(duì)象，而這種獨(dú)占鎖的產(chǎn)生一般是在全局事務(wù)中執(zhí)行著DML語(yǔ)句，當(dāng)這種DML語(yǔ)句執(zhí)行比較慢時(shí)，就會(huì)引起TMS的鎖等待現(xiàn)象。此外，我們還發(fā)現(xiàn)，一般的查詢語(yǔ)句是不會(huì)產(chǎn)生鎖的（OPS的lm_lock鎖除外），但是如果將查詢放入一個(gè)全局事務(wù)中時(shí)，它就會(huì)產(chǎn)生一個(gè)共享的DX鎖，如果這個(gè)在全局事務(wù)中的查詢的調(diào)用是通過(guò)ORACLE的工具包DBMS_SQL來(lái)進(jìn)行的話，那就會(huì)產(chǎn)生一個(gè)DX的排他鎖。基于這些結(jié)果，我們建議在程序的開(kāi)發(fā)過(guò)程中要遵循能不用XA全局事務(wù)的情況下就不用，能將查詢放到事務(wù)之外的就不要放到事務(wù)之內(nèi)，能不用ORACLE工具包進(jìn)行開(kāi)發(fā)的就不要用。我們也按照這個(gè)原則要求我們的開(kāi)發(fā)商，取得了比較好的效果。
4、事務(wù)超時(shí)設(shè)置的問(wèn)題
中間件應(yīng)用系統(tǒng)的事務(wù)超時(shí)控制很重要，不設(shè)置超時(shí)時(shí)間對(duì)系統(tǒng)來(lái)說(shuō)簡(jiǎn)直就是一種災(zāi)難。我們?cè)?jīng)就有過(guò)因?yàn)槌瑫r(shí)時(shí)間的設(shè)置沒(méi)設(shè)和設(shè)置不當(dāng)造成了嚴(yán)重的系統(tǒng)故障，最直接的故障就是系統(tǒng)報(bào)全局事務(wù)數(shù)不夠的錯(cuò)誤，無(wú)法開(kāi)啟新的事務(wù)，從而導(dǎo)致前臺(tái)業(yè)務(wù)的終止。TUXEDO的超時(shí)主要有三種，一個(gè)是在代碼中的tpbegin超時(shí)（值為其參數(shù)）T1，他控制整個(gè)事務(wù)的完成時(shí)間，第二個(gè)為XA連接的超時(shí)（配置文件中的open_info中的SesTm ）T2，他控制同一連接中對(duì)于分布式事務(wù)鎖的等待超時(shí)時(shí)間，還有一個(gè)為數(shù)據(jù)庫(kù)中等待數(shù)據(jù)庫(kù)對(duì)象非分布式事務(wù)鎖釋放的超時(shí)時(shí)間（_dirstributed_lock_timeout）T3。這三個(gè)超時(shí)共同作用并且有如下的關(guān)系 T1

2.4、服務(wù)不能正常啟動(dòng)的問(wèn)題在實(shí)際的維護(hù)工作中，經(jīng)常會(huì)出現(xiàn)服務(wù)不能正常啟動(dòng)的現(xiàn)象。明明所有的服務(wù)都已經(jīng)關(guān)閉了，tmboot就是起不來(lái)。這種原因一般是因?yàn)橄到y(tǒng)的IPC資源沒(méi)有釋放。IPC資源是操作系統(tǒng)用來(lái)進(jìn)行進(jìn)程間通訊的系統(tǒng)資源，主要包括信號(hào)燈、共享內(nèi)存、消息隊(duì)列。在UNIX操作系統(tǒng)下通過(guò)IPCS命令可以清楚的看到IPC資源的使用情況。當(dāng)服務(wù)無(wú)法啟動(dòng)的時(shí)觀察IPCS就會(huì)發(fā)現(xiàn)tuxedo運(yùn)行環(huán)境的用戶下的ipc資源沒(méi)有被釋放，這時(shí)使用ipcrm命令清除相應(yīng)的IPC資源，再啟動(dòng)服務(wù)就可以了。