什么是JTA Transaction？它有怎樣的特點(diǎn)呢？JTA Transaction是指由J2EE Transaction manager去管理的事務(wù)。其最大的
特點(diǎn)是調(diào)用UserTransaction接口的begin，commit和rollback方法來完成事務(wù)范圍的界定，事務(wù)的提交和回滾。JTA
Transaction可以實(shí)現(xiàn)同一事務(wù)對應(yīng)不同的數(shù)據(jù)庫，但是它仍然無法實(shí)現(xiàn)事務(wù)的嵌套。
分布式事務(wù)的規(guī)范由OMG的OTS所描述。
JTA是只是一組java接口用于描述，J2ee框架中事務(wù)管理器與應(yīng)用程序，資源管理器，以及應(yīng)用服務(wù)器之間的事務(wù)通訊。
它主要包括高層接口即面向應(yīng)用程序的接口；XAResource接口即面向資源的接口；以及事務(wù)管理器的接口。值得注意的是JTA
只提供了接口，沒有具體的實(shí)現(xiàn)。
JTS是服務(wù)OTS的JTA的實(shí)現(xiàn)。簡單的說JTS實(shí)現(xiàn)了JTA接口，并且符合OTS的規(guī)范。
資源管理器只要其提供給事務(wù)管理器的接口符合XA接口規(guī)范，就可以被事務(wù)管理器處理。
所以，JTA可以處理任何提供符合XA接口的資源。包括：數(shù)據(jù)庫，JMS，商業(yè)對象等等
“Java 事務(wù) API”（JTA）啟用兩階段提交功能。當(dāng)配置 WebSphere Application Server 以訪問數(shù)據(jù)庫時，可選擇具有
JTA 能力的驅(qū)動程序。如果需要兩階段提交功能，則必須使用啟用 JTA 的驅(qū)動程序。
只要您在事務(wù)中調(diào)用了多個數(shù)據(jù)庫連接，就需要 JTA。只要您在事務(wù)中調(diào)用了多個數(shù)據(jù)庫服務(wù)器，就需要兩階段提交。這些
連接可以是相同的物理數(shù)據(jù)庫服務(wù)器或多個數(shù)據(jù)庫服務(wù)器。例如：
* 實(shí)體企業(yè) Bean Entity1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。
* 實(shí)體企業(yè) Bean Entity2 在應(yīng)用程序服務(wù)器 AppServer1 中部署。
* 會話企業(yè) Bean Session1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。
如果 Session1 對同一事務(wù)內(nèi)的 Entity1 和 Entity2 調(diào)用了方法而這兩個企業(yè) Bean 正在使用不同的物理數(shù)據(jù)庫連接，則
必須對 Entity1 和 Entity2 使用的數(shù)據(jù)源啟用 JTA。當(dāng)從相同的數(shù)據(jù)源對象獲取那些連接時，這也是成立的。這需要具有
JTA 能力的驅(qū)動程序以提交事務(wù)。
當(dāng)事務(wù)涉及到多個進(jìn)程時，JTA 也是必需的。例如，一個事務(wù)可能會涉及在多個應(yīng)用程序服務(wù)器中部署的企業(yè) Bean。
* 實(shí)體企業(yè) Bean Entity1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。
* 實(shí)體企業(yè) Bean Entity2 在應(yīng)用程序服務(wù)器 AppServer2 中部署。
* 會話企業(yè) Bean Session1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。
如果 Session1 對同一事務(wù)（此事務(wù)構(gòu)成一個分布式事務(wù)）內(nèi)的 Entity1 和 Entity2 調(diào)用了方法，則必須對 Entity1 和
Entity2 使用的數(shù)據(jù)源啟用 JTA。
性能實(shí)現(xiàn)JTA 啟用的連接與非 JTA 啟用的連接執(zhí)行情況不同。基于此原因，如果您的應(yīng)用程序不需要 JTA，則最好使用非
JTA 啟用的驅(qū)動程序。
]]>
了9.2 個百分點(diǎn)。
J2EE 集群就是一種能夠提供高可用性、可擴(kuò)展性以及容錯性的流行技術(shù)。但是由于在J2EE 規(guī)范中沒有對集群做出規(guī)范，各個J2EE 廠商就使用不同的方式來實(shí)現(xiàn)集群，這樣就給系統(tǒng)架構(gòu)師和開發(fā)人員帶來了很多麻煩。下面就是常見的一些問題：
• 為什么帶有集群支持的商業(yè)J2EE 服務(wù)器產(chǎn)品如此昂貴？（是無集群支持產(chǎn)品的10 倍）
• 為什么在單機(jī)環(huán)境下創(chuàng)建的應(yīng)用在集群環(huán)境中無法正常運(yùn)行？
• 為什么我的應(yīng)用在集群環(huán)境下運(yùn)行的非常慢，但是在單機(jī)模式下卻沒有這個問題？
• 為什么我的集群應(yīng)用在向其他廠商的服務(wù)器遷移時會失敗？
要理解為什么會有這些限制，最好的方法就是研究它的實(shí)現(xiàn)，以揭開J2EE 集群的面紗。
基本術(shù)語
在我們開始討論對于集群不同的實(shí)現(xiàn)之前，我想，了解一下集群技術(shù)的一些基本概念還是很有意義的。希望本章不單單是告訴你這些概念和設(shè)計問題，也同時能夠?yàn)槟愎蠢找幌虏煌?/span>J2EE集群實(shí)現(xiàn)的框架以便于理解。
可擴(kuò)展性
在一些大型系統(tǒng)中，很難提前預(yù)知最終用戶的數(shù)量以及他們的使用行為，所以，可擴(kuò)展性就是指一個系統(tǒng)能夠快速適應(yīng)用戶數(shù)量的增加。提高服務(wù)器處理能力的最直 接的方法就是增加硬件資源，例如CPU、內(nèi)存或者硬盤等。集群是解決這個問題的另外一種方式，它使得一組服務(wù)器共同分擔(dān)繁重的任務(wù)，但對于最終用戶來說就 像一臺服務(wù)器。
高可用性
通過向單機(jī)添加硬件來擴(kuò)展系統(tǒng)能力的方案并不可靠，因?yàn)閱我坏姆?wù)器存在一個單點(diǎn)故障。像銀行系統(tǒng)、帳單系統(tǒng)這樣的關(guān)鍵應(yīng)用甚至連一分鐘的停機(jī)都不能容 許，它們需要在任何時間都是可用的，并且要能夠保證響應(yīng)速度。集群技術(shù)就可以滿足這個要求，它通過加入冗余服務(wù)器使得在一個服務(wù)器出錯而停止服務(wù)的時候， 這些冗余的服務(wù)器可以繼續(xù)服務(wù)。
負(fù)載均衡
負(fù)載均衡是集群的另外一個關(guān)鍵技術(shù)，它通過將請求分發(fā)到不同的服務(wù)器來達(dá)到高可用性和高效的處理能力。負(fù)載均衡器可以是一個servlet，也可以是一個 插件（例如Linux 上的ipchains），甚至還可以是一個比較昂貴的內(nèi)嵌了SSL 支持的硬件產(chǎn)品。為了能夠分發(fā)請求，負(fù)載均衡器還需要做一些重要的工作，例如使用“會話粘滯”技術(shù)以確保來自同一個用戶的請求會被轉(zhuǎn)發(fā)到同一個服務(wù)器；使 用“健康檢查”（或者“心跳監(jiān)聽”）技術(shù)來防止將請求轉(zhuǎn)發(fā)到一個失敗的服務(wù)器；有時候負(fù)載均衡器還將參與“失敗轉(zhuǎn)移”的工作。
容錯
高可用的數(shù)據(jù)并不必是嚴(yán)格正確的數(shù)據(jù)。在J2EE 集群中，當(dāng)一個服務(wù)器實(shí)例失敗了，在集群中冗余的服務(wù)器就可以處理新到的請求，這樣就保證了服務(wù)依然可用。但是在服務(wù)器失敗的那一刻，正在被處理的請求就 可能無法得到正確的數(shù)據(jù)。那么，帶有容錯功能的集群就可以確保請求所得到的數(shù)據(jù)是正確的，哪怕是服務(wù)器端出現(xiàn)了錯誤。
這個是怎么實(shí)現(xiàn)的呢？確實(shí)需要我們?nèi)ミM(jìn)行思考！
失敗轉(zhuǎn)移
在集群中，失敗轉(zhuǎn)移是實(shí)現(xiàn)容錯的一個關(guān)鍵技術(shù)。當(dāng)最初的節(jié)點(diǎn)失敗之后，在集群中選擇另外一個節(jié)點(diǎn)來完成處理。失敗轉(zhuǎn)移到其他節(jié)點(diǎn)可以通過編碼實(shí)現(xiàn)，也可以由平臺自動實(shí)現(xiàn)。
冪等方法
如果一個方法使用同樣的參數(shù)進(jìn)行多次調(diào)用所得到的結(jié)果都一樣，也就是說對于該方法的調(diào)用次數(shù)不影響系統(tǒng)，那么這個方法就叫做“冪等方法”。例如 “getUsername()”就是一個冪等方法，而“deleteFile()”就不是冪等的。在討論 HTTP 會話失敗轉(zhuǎn)移和EJB 的失敗轉(zhuǎn)移時，冪等方法是一個很重要的概念
]]>
重/輕量：其實(shí)是使用難易程度，從根本上說，重/輕量應(yīng)該和可伸縮性不矛盾的，特別是EJB 3.0推出以后，這個問題應(yīng)該得到比較好的解決。
但是，在目前情況下，編寫一個JavaBeans要比編寫一個EJB容易多，那么，是重/輕量還是可伸縮性應(yīng)該成為系統(tǒng)架構(gòu)的主要依據(jù)呢？
在這個問題背后，還隱藏了目前在開源領(lǐng)域兩個架構(gòu)技術(shù)選擇：
1. 重量：基于JBoss/EJB的完整J2EE系統(tǒng)架構(gòu)
（具有可伸縮性，目前不易于學(xué)習(xí)）
2. 輕量：基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前無太大可伸縮性，但是易于學(xué)習(xí)使用）
因?yàn)檩p量解決方案易于學(xué)習(xí)新技術(shù)，容易使用，選中率比較高。但是讓人產(chǎn)生對系統(tǒng)的可伸縮性擔(dān)憂。鑒于這種情況，我認(rèn)為有必要強(qiáng)調(diào)一下可伸縮性的重要性，切不能因?yàn)橐M(jìn)新的設(shè)計思想和技術(shù)，而盲目地采用一個無可伸縮性的設(shè)計方案。
其實(shí)，"輕量"應(yīng)該是一個中性詞，但是因?yàn)榇罅啃碌脑O(shè)計思想比較容易通過輕量方案獲得成型軟件，如（Spring/Naning/Hibernate）等，逐漸的"輕量"好像變成了一個褒義詞。 如果從可伸縮性的標(biāo)準(zhǔn)看，輕量還可能是一個貶義詞，輕量意味著喪失重量系統(tǒng)中的分布式網(wǎng)絡(luò)計算的設(shè)計考量，那么可伸縮性就要打問號。
從這次JavaOne大會以及從長遠(yuǎn)來看，隨著EJB 3.0中間件輕量化、SOA架構(gòu)理念普及，輕量/重量的區(qū)別已經(jīng)模糊，如果還是以輕量/重量作為架構(gòu)選擇的標(biāo)準(zhǔn)，甚至標(biāo)榜自己的系統(tǒng)，無疑是不明智的。
可伸縮性應(yīng)該依然是實(shí)用企業(yè)系統(tǒng)架構(gòu)的主選，可伸縮性是站在軟件公司的客戶企業(yè)立場，為這些客戶企業(yè)考慮的，但是他們經(jīng)常因?yàn)楸徽J(rèn)為是外行，擋在了軟件系統(tǒng)架構(gòu)選擇的門外。]]>
可伸縮性:所謂可伸縮性，是指在小型規(guī)模單臺服務(wù)器情況下，應(yīng)用系統(tǒng)可以良好運(yùn)轉(zhuǎn)，系統(tǒng)的訪問量或功能增加后，整個系統(tǒng)只需通過增加服務(wù)器硬件就可以實(shí)現(xiàn)性能擴(kuò)展，無需修改太多軟件。對于可伸縮性平臺（如JBoss）來說，理論上，沒有最大負(fù)載或最多在線人數(shù)這樣的概念。
]]>