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