xa分布式事務(wù)處理

XA分布式事務(wù)處理2008-12-1116:12在談到XA規(guī)范之前，必須首先了解分布式事務(wù)處理（DistributedTransactionProcessing,DTP）的概念。Transaction，即事務(wù)，又稱之為交易，指一個(gè)程序或程序段，在一個(gè)或多個(gè)資源如數(shù)據(jù)庫(kù)或文件上為完成某些功能的執(zhí)行過程的集合。分布式事務(wù)處理是指一個(gè)事務(wù)可能涉及多個(gè)數(shù)據(jù)庫(kù)操作，分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動(dòng)作，提交或回滾事務(wù)的決定必須產(chǎn)生統(tǒng)一的結(jié)果（全部提交或全部回滾）。X/Open組織（即現(xiàn)在的OpenGroup）定義了分布式事務(wù)處理模型。X/OpenDTP模型（1994）包括應(yīng)用程序（AP）、事務(wù)管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。一般，常見的事務(wù)管理器（TM）是交易中間件，常見的資源管理器（RM）是數(shù)據(jù)庫(kù)，常見的通信資源管理器（CRM）是消息中間件。通常把一個(gè)數(shù)據(jù)庫(kù)內(nèi)部的事務(wù)處理，如對(duì)多個(gè)表的操作，作為本地事務(wù)看待。數(shù)據(jù)庫(kù)的事務(wù)處理對(duì)象是本地事務(wù)，而分布式事務(wù)處理的對(duì)象是全局事務(wù)。所謂全局事務(wù)，是指分布式事務(wù)處理環(huán)境中，多個(gè)數(shù)據(jù)庫(kù)可能需要共同完成一個(gè)工作，這個(gè)工作即是一個(gè)全局事務(wù)，例如，一個(gè)事務(wù)中可能更新幾個(gè)不同的數(shù)據(jù)庫(kù)。對(duì)數(shù)據(jù)庫(kù)的操作發(fā)生在系統(tǒng)的各處但必須全部被提交或回滾。此時(shí)一個(gè)數(shù)據(jù)庫(kù)對(duì)自己內(nèi)部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務(wù)相關(guān)的其它數(shù)據(jù)庫(kù)的操作是否成功，如果任一數(shù)據(jù)庫(kù)的任一操作失敗，則參與此事務(wù)的所有數(shù)據(jù)庫(kù)所做的所有操作都必須回滾。一般情況下，某一數(shù)據(jù)庫(kù)無法知道其它數(shù)據(jù)庫(kù)在做什么，因此，在一個(gè)DTP環(huán)境中，交易中間件是必需的，由它通知和協(xié)調(diào)相關(guān)數(shù)據(jù)庫(kù)的提交或回滾。而一個(gè)數(shù)據(jù)庫(kù)只將其自己所做的操作（可恢復(fù)）影射到全局事務(wù)中。XA就是X/OpenDTP定義的交易中間件與數(shù)據(jù)庫(kù)之間的接口規(guī)范（即接口函數(shù)），交易中間件用它來通知數(shù)據(jù)庫(kù)事務(wù)的開始、結(jié)束以及提交、回滾等。XA接口函數(shù)由數(shù)據(jù)庫(kù)廠商提供。XA與兩階段提交協(xié)議通常情況下，交易中間件與數(shù)據(jù)庫(kù)通過XA接口規(guī)范，使用兩階段提交來完成一個(gè)全局事務(wù)，XA規(guī)范的基礎(chǔ)是兩階段提交協(xié)議。在第一階段，交易中間件請(qǐng)求所有相關(guān)數(shù)據(jù)庫(kù)準(zhǔn)備提交（預(yù)提交）各自的事務(wù)分支，以確認(rèn)是否所有相關(guān)數(shù)據(jù)庫(kù)都可以提交各自的事務(wù)分支。當(dāng)某一數(shù)據(jù)庫(kù)收到預(yù)提交后，如果可以提交屬于自己的事務(wù)分支，則將自己在該事務(wù)分支中所做的操作固定記錄下來，并給交易中間件一個(gè)同意提交的應(yīng)答，此時(shí)數(shù)據(jù)庫(kù)將不能再在該事務(wù)分支中加入任何操作，但此時(shí)數(shù)據(jù)庫(kù)并沒有真正提交該事務(wù)，數(shù)據(jù)庫(kù)對(duì)共享資源的操作還未釋放（處于上鎖狀態(tài)）。如果由于某種原因數(shù)據(jù)庫(kù)無法提交屬于自己的事務(wù)分支，它將回滾自己的所有操作，釋放對(duì)共享資源上的鎖，并返回給交易中間件失敗應(yīng)答。在第二階段，交易中間件審查所有數(shù)據(jù)庫(kù)返回的預(yù)提交結(jié)果，如所有數(shù)據(jù)庫(kù)都可以提交，交易中間件將要求所有數(shù)據(jù)庫(kù)做正式提交，這樣該全局事務(wù)被提交。而如果有任一數(shù)據(jù)庫(kù)預(yù)提交返回失敗，交易中間件將要求所有其它數(shù)據(jù)庫(kù)回滾其操作，這樣該全局事務(wù)被回滾。以一個(gè)全局事務(wù)為例，AP首先通知交易中間件開始一個(gè)全局事務(wù)，交易中間件通過XA接口函數(shù)通知數(shù)據(jù)庫(kù)開始事務(wù)，然后AP可以對(duì)數(shù)據(jù)庫(kù)管理的資源進(jìn)行操作，數(shù)據(jù)庫(kù)系統(tǒng)記錄事務(wù)對(duì)本地資源的所有操作。操作完成后交易中間件通過XA接口函數(shù)通知數(shù)據(jù)庫(kù)操作完成。交易中間件負(fù)責(zé)記錄AP操作過哪些數(shù)據(jù)庫(kù)（事務(wù)分支）。AP根據(jù)情況通知交易中間件提交該全局事務(wù)，交易中間件會(huì)通過XA接口函數(shù)要求各個(gè)數(shù)據(jù)庫(kù)做預(yù)提交，所有數(shù)據(jù)庫(kù)返回成功后要求各個(gè)數(shù)據(jù)庫(kù)做正式提交，此時(shí)一筆全局事務(wù)結(jié)束。XA規(guī)范對(duì)應(yīng)用來說，最大好處在于事務(wù)的完整性由交易中間件和數(shù)據(jù)庫(kù)通過XA接口控制，AP只需要關(guān)注與數(shù)據(jù)庫(kù)的應(yīng)用邏輯的處理，而無需過多關(guān)心事務(wù)的完整性，應(yīng)用設(shè)計(jì)開發(fā)會(huì)簡(jiǎn)化很多。具體來說，如果沒有交易中間件，應(yīng)用系統(tǒng)需要在程序內(nèi)部直接通知數(shù)據(jù)庫(kù)開始、結(jié)束和提交事務(wù)，當(dāng)出現(xiàn)異常情況時(shí)必須由專門的程序?qū)?shù)據(jù)庫(kù)進(jìn)行反向操作才能完成回滾。如果是有很多事務(wù)分支的全局事務(wù)，回滾時(shí)情況將變得異常復(fù)雜。而使用XA接口，則全局事務(wù)的提交是由交易中間件控制，應(yīng)用程序只需通知交易中間件提交或回滾事務(wù)，就可以控制整個(gè)事務(wù)（可能涉及多個(gè)異地的數(shù)據(jù)庫(kù)）的全部提交或回滾，應(yīng)用程序完全不用考慮沖正邏輯。在一個(gè)涉及多個(gè)數(shù)據(jù)庫(kù)的全局事務(wù)中，為保證全局事務(wù)的完整性，由交易中間件控制數(shù)據(jù)庫(kù)做兩階段提交是必要的。但典型的兩階段提交，對(duì)數(shù)據(jù)庫(kù)來說事務(wù)從開始到結(jié)束（提交或回滾）時(shí)間相對(duì)較長(zhǎng)，在事務(wù)處理期間數(shù)據(jù)庫(kù)使用的資源（如邏輯日志、各種鎖），直到事務(wù)結(jié)束時(shí)才會(huì)釋放。因此，使用典型的兩階段提交相對(duì)來說會(huì)占用更多的資源，在網(wǎng)絡(luò)條件不是很好，如低速網(wǎng)、網(wǎng)絡(luò)顛簸頻繁，情況會(huì)更為嚴(yán)重。當(dāng)一個(gè)全局事務(wù)只涉及一個(gè)數(shù)據(jù)庫(kù)時(shí)，有一種優(yōu)化方式，即一階段提交。當(dāng)AP通知交易中間件提交事務(wù)時(shí)，交易中間件直接要求數(shù)據(jù)庫(kù)提交事務(wù)，省去兩階段提交中的第一階段，可以縮短處理一個(gè)事務(wù)的時(shí)間，以提高事務(wù)處理的效率。作為兩階段提交的一種特例，與兩階段一樣，一階段提交也是標(biāo)準(zhǔn)的。XA分布式事務(wù)處理在談到XA規(guī)范之前，必須首先了解分布式事務(wù)處理（DistributedTransactionProcessing，DTP）的概念。Transaction，即事務(wù)，又稱之為交易，指一個(gè)程序或程序段，在一個(gè)或多個(gè)資源如數(shù)據(jù)庫(kù)或文件上為完成某些功能的執(zhí)行過程的集合。分布式事務(wù)處理是指一個(gè)事務(wù)可能涉及多個(gè)數(shù)據(jù)庫(kù)操作，分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動(dòng)作，提交或回滾事務(wù)的決定必須產(chǎn)生統(tǒng)一的結(jié)果（全部提交或全部回滾）。X/Open組織（即現(xiàn)在的OpenGroup）定義了分布式事務(wù)處理模型。X/OpenDTP模型（1994）包括應(yīng)用程序（AP）、事務(wù)管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。一般，常見的事務(wù)管理器（TM）是交易中間件，常見的資源管理器（RM）是數(shù)據(jù)庫(kù)，常見的通信資源管理器（CRM）是消息中間件。通常把一個(gè)數(shù)據(jù)庫(kù)內(nèi)部的事務(wù)處理，如對(duì)多個(gè)表的操作，作為本地事務(wù)看待。數(shù)據(jù)庫(kù)的事務(wù)處理對(duì)象是本地事務(wù)，而分布式事務(wù)處理的對(duì)象是全局事務(wù)。所謂全局事務(wù)，是指分布式事務(wù)處理環(huán)境中，多個(gè)數(shù)據(jù)庫(kù)可能需要共同完成一個(gè)工作，這個(gè)工作即是一個(gè)全局事務(wù)，例如，一個(gè)事務(wù)中可能更新幾個(gè)不同的數(shù)據(jù)庫(kù)。對(duì)數(shù)據(jù)庫(kù)的操作發(fā)生在系統(tǒng)的各處但必須全部被提交或回滾。此時(shí)一個(gè)數(shù)據(jù)庫(kù)對(duì)自己內(nèi)部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務(wù)相關(guān)的其它數(shù)據(jù)庫(kù)的操作是否成功，如果任一數(shù)據(jù)庫(kù)的任一操作失敗，則參與此事務(wù)的所有數(shù)據(jù)庫(kù)所做的所有操作都必須回滾。一般情況下，某一數(shù)據(jù)庫(kù)無法知道其它數(shù)據(jù)庫(kù)在做什么，因此，在一個(gè)DTP環(huán)境中，交易中間件是必需的，由它通知和協(xié)調(diào)相關(guān)數(shù)據(jù)庫(kù)的提交或回滾。而一個(gè)數(shù)據(jù)庫(kù)只將其自己所做的操作（可恢復(fù)）影射到全局事務(wù)中。XA就是X/OpenDTP定義的交易中間件與數(shù)據(jù)庫(kù)之間的接口規(guī)范（即接口函數(shù)），交易中間件用它來通知數(shù)據(jù)庫(kù)事務(wù)的開始、結(jié)束以及提交、回滾等。XA接口函數(shù)由數(shù)據(jù)庫(kù)廠商提供。XA與兩階段提交協(xié)議通常情況下，交易中間件與數(shù)據(jù)庫(kù)通過XA接口規(guī)范，使用兩階段提交來完成一個(gè)全局事務(wù)，XA規(guī)范的基礎(chǔ)是兩階段提交協(xié)議。在第一階段，交易中間件請(qǐng)求所有相關(guān)數(shù)據(jù)庫(kù)準(zhǔn)備提交（預(yù)提交）各自的事務(wù)分支，以確認(rèn)是否所有相關(guān)數(shù)據(jù)庫(kù)都可以提交各自的事務(wù)分支。當(dāng)某一數(shù)據(jù)庫(kù)收到預(yù)提交后，如果可以提交屬于自己的事務(wù)分支，則將自己在該事務(wù)分支中所做的操作固定記錄下來，并給交易中間件一個(gè)同意提交的應(yīng)答，此時(shí)數(shù)據(jù)庫(kù)將不能再在該事務(wù)分支中加入任何操作，但此時(shí)數(shù)據(jù)庫(kù)并沒有真正提交該事務(wù)，數(shù)據(jù)庫(kù)對(duì)共享資源的操作還未釋放（處于上鎖狀態(tài)）。如果由于某種原因數(shù)據(jù)庫(kù)無法提交屬于自己的事務(wù)分支，它將回滾自己的所有操作，釋放對(duì)共享資源上的鎖，并返回給交易中間件失敗應(yīng)答。在第二階段，交易中間件審查所有數(shù)據(jù)庫(kù)返回的預(yù)提交結(jié)果，如所有數(shù)據(jù)庫(kù)都可以提交，交易中間件將要求所有數(shù)據(jù)庫(kù)做正式提交，這樣該全局事務(wù)被提交。而如果有任一數(shù)據(jù)庫(kù)預(yù)提交返回失敗，交易中間件將要求所有其它數(shù)據(jù)庫(kù)回滾其操作，這樣該全局事務(wù)被回滾。以一個(gè)全局事務(wù)為例，AP首先通知交易中間件開始一個(gè)全局事務(wù)，交易中間件通過XA接口函數(shù)通知數(shù)據(jù)庫(kù)開始事務(wù)，然后AP可以對(duì)數(shù)據(jù)庫(kù)管理的資源進(jìn)行操作，數(shù)據(jù)庫(kù)系統(tǒng)記錄事務(wù)對(duì)本地資源的所有操作。操作完成后交易中間件通過XA接口函數(shù)通知數(shù)據(jù)庫(kù)操作完成。交易中間件負(fù)責(zé)記錄AP操作過哪些數(shù)據(jù)庫(kù)（事務(wù)分支）。AP根據(jù)情況通知交易中間件提交該全局事務(wù)，交易中間件會(huì)通過XA接口函數(shù)要求各個(gè)數(shù)據(jù)庫(kù)做預(yù)提交，所有數(shù)據(jù)庫(kù)返回成功后要求各個(gè)數(shù)據(jù)庫(kù)做正式提交，此時(shí)一筆全局事務(wù)結(jié)束。XA規(guī)范對(duì)應(yīng)用來說，最大好處在于事務(wù)的完整性由交易中間件和數(shù)據(jù)庫(kù)通過XA接口控制，AP只需要關(guān)注與數(shù)據(jù)庫(kù)的應(yīng)用邏輯的處理，而無需過多關(guān)心事務(wù)的完整性，應(yīng)用設(shè)計(jì)開發(fā)會(huì)簡(jiǎn)化很多。具體來說，如果沒有交易中間件，應(yīng)用系統(tǒng)需要在程序內(nèi)部直接通知數(shù)據(jù)庫(kù)開始、結(jié)束和提交事務(wù)，當(dāng)出現(xiàn)異常情況時(shí)必須由專門的程序?qū)?shù)據(jù)庫(kù)進(jìn)行反向操作才能完成回滾。如果是有很多事務(wù)分支的全局事務(wù)，回滾時(shí)情況將變得異常復(fù)雜。而使用XA接口，則全局事務(wù)的提交是由交易中間件控制，應(yīng)用程序只需通知交易中間件提交或回滾事務(wù)，就可以控制整個(gè)事務(wù)（可能涉及多個(gè)異地的數(shù)據(jù)庫(kù)）的全部提交或回滾，應(yīng)用程序完全不用考慮沖正邏輯。在一個(gè)涉及多個(gè)數(shù)據(jù)庫(kù)的全局事務(wù)中，為保證全局事務(wù)的完整性，由交易中間件控制數(shù)據(jù)庫(kù)做兩階段提交是必要的。但典型的兩階段提交，對(duì)數(shù)據(jù)庫(kù)來說事務(wù)從開始到結(jié)束（提交或回滾）時(shí)間相對(duì)較長(zhǎng)，在事務(wù)處理期間數(shù)據(jù)庫(kù)使用的資源（如邏輯日志、各種鎖），直到事務(wù)結(jié)束時(shí)才會(huì)釋放。因此，使用典型的兩階段提交相對(duì)來說會(huì)占用更多的資源，在網(wǎng)絡(luò)條件不是很好，如低速網(wǎng)、網(wǎng)絡(luò)顛簸頻繁，情況會(huì)更為嚴(yán)重。當(dāng)一個(gè)全局事務(wù)只涉及一個(gè)數(shù)據(jù)庫(kù)時(shí)，有一種優(yōu)化方式，即一階段提交。當(dāng)AP通知交易中間件提交事務(wù)時(shí)，交易中間件直接要求數(shù)據(jù)庫(kù)提交事務(wù)，省去兩階段提交中的第一階段，可以縮短處理一個(gè)事務(wù)的時(shí)間，以提高事務(wù)處理的效率。作為兩階段提交的一種特例，與兩階段一樣，一階段提交也是標(biāo)準(zhǔn)的。動(dòng)態(tài)編譯JAVA程序|BEATuxedo2009-04-02oracle分布式事務(wù)總結(jié)oracle分布式事務(wù)總結(jié)（轉(zhuǎn)）2008-09-1817:47基本概念LocalCoordinator：在分布事務(wù)中，必須參考其它節(jié)點(diǎn)上的數(shù)據(jù)才能完成自己這部分操作的站點(diǎn)。GlobalCoordinator：分布事務(wù)的發(fā)起者，負(fù)責(zé)協(xié)調(diào)這個(gè)分布事務(wù)。CommitPointSite:在分布事務(wù)中，首先執(zhí)行COMMIT或ROLLBACK操作的站點(diǎn)。一般情況下，應(yīng)該把存儲(chǔ)關(guān)鍵數(shù)據(jù)的站點(diǎn)作為CommitPointSite0因?yàn)镃ommitPointSite和其它站點(diǎn)不一樣，從來不會(huì)進(jìn)入prepared狀態(tài)，所以不會(huì)存在IN-DOUBT事務(wù)?？梢栽O(shè)置初始化參數(shù)COMMIT_POINT_STRENGTH,在分布式事務(wù)中，會(huì)根據(jù)這個(gè)值的大小來確定CommitPointSite，分布事物的狀態(tài)信息也存在該數(shù)據(jù)庫(kù)中。一般將關(guān)鍵的數(shù)據(jù)庫(kù)作為commitpointsite，commit_point_strength值較高的數(shù)據(jù)庫(kù)為commitpointsite，在分布事物中最先提交分布式提交的3個(gè)階段分布事物的兩階段提交分三個(gè)過程：準(zhǔn)備階段(PREPAREPHASE)?本地?cái)?shù)據(jù)庫(kù)GlobalCoordinator向其它數(shù)據(jù)庫(kù)發(fā)出COMMIT通知?比較所有數(shù)據(jù)庫(kù)的SCN號(hào)，將最高的SCN號(hào)作為分布事物的全局SCN號(hào)?所有數(shù)據(jù)庫(kù)寫在線日志?對(duì)分布事物修改的表加分布鎖，防止被讀寫?各數(shù)據(jù)庫(kù)向GlobalCoordinator發(fā)出已經(jīng)準(zhǔn)備好的通知所有參與分布事物的數(shù)據(jù)庫(kù)必須經(jīng)過上述準(zhǔn)備，才能進(jìn)入下一階段。提交階段(COMMITPHASE)?本地?cái)?shù)據(jù)庫(kù)GlobalCoordinator通知commitpointsite首先提交。commitpointsite提交后，釋放其占有的資源，通知GlobalCoordinator完成提交?本地?cái)?shù)據(jù)庫(kù)GlobalCoordinator通知其它數(shù)據(jù)庫(kù)提交?提交節(jié)點(diǎn)在日志中追加一條信息，表示分布事物已經(jīng)完成提交，并通知GlobalCoordinator。此時(shí)所有數(shù)據(jù)庫(kù)的數(shù)據(jù)保持了一致性。注銷階段(FORGETPHASE)?本地?cái)?shù)據(jù)庫(kù)GlobalCoordinator通知commitpointsite所有數(shù)據(jù)庫(kù)已經(jīng)完成提交commitpointsite清除分布事物的記錄和狀態(tài)信息，并通知GlobalCoordinatorGlobalCoordinator清除本地分布事物的記錄和狀態(tài)信息此時(shí)分布事物的兩階段提交全部完成。如果兩階段提交完成之前，數(shù)據(jù)庫(kù)或網(wǎng)絡(luò)出現(xiàn)異常，應(yīng)用就會(huì)報(bào)錯(cuò)，分布事物處于IN_DOUBT狀態(tài)。一旦數(shù)據(jù)庫(kù)或網(wǎng)絡(luò)恢復(fù)正常，系統(tǒng)(RECOPROCESS)會(huì)自動(dòng)處理IN_DOUBT狀態(tài)的分布事物。有些情況需要管理員手工處理IN_DOUBT狀態(tài)的分布事物：-IN_DOUBT狀態(tài)的分布事物,將關(guān)鍵表鎖住，造成應(yīng)用不能正常工作兩個(gè)重要的視圖DBA_2PC_PENDING:列出所有的懸而未決的事務(wù)，此視圖在末填入懸而未決的事務(wù)之前是空的，解決這后也被清空。LOCAL_TRAN_ID本地事務(wù)標(biāo)識(shí)，格式為eger.ingege。當(dāng)一個(gè)連接的local_tran_id和global_tran_id相同時(shí)，那么該節(jié)點(diǎn)是該事務(wù)的全局協(xié)調(diào)器。GLOBAL_TRAN_ID全局事務(wù)標(biāo)識(shí)，格式為：global_db_name.db_hex_id.local_tran_id其中db_hex_id是用來標(biāo)識(shí)數(shù)據(jù)庫(kù)八字符的十六進(jìn)制數(shù)，公共事各id在分布式事務(wù)的每個(gè)節(jié)點(diǎn)都是相同的?！癥ES”意味著一部分事務(wù)已經(jīng)在一個(gè)節(jié)點(diǎn)上提交，而在另一個(gè)節(jié)點(diǎn)上被回滾。TRAN_COMMENT事務(wù)的注釋，或者如果使用了事務(wù)命名，當(dāng)事各被提交時(shí)，事務(wù)的名字就會(huì)出現(xiàn)在此處已提交的事務(wù)的全局提交數(shù)DBA_2PC_PENDING的STATE列的說明Connecting通常情況下，只有全局協(xié)調(diào)器和本地協(xié)調(diào)器才使用這個(gè)條目，節(jié)點(diǎn)在能夠決定它是否能夠準(zhǔn)備好之前，要收集來自于其它數(shù)據(jù)庫(kù)服務(wù)的信息。節(jié)點(diǎn)已準(zhǔn)好，可能或者也可能沒有將已準(zhǔn)備好的消息通知本地協(xié)調(diào)器，但此時(shí)，該節(jié)點(diǎn)還沒有接收到提交的請(qǐng)求，仍保持著準(zhǔn)許備好的狀態(tài)，控制著提交事務(wù)所必需的任何本地資源。節(jié)點(diǎn)（任何類型）已經(jīng)提交了事務(wù)，但該事務(wù)所包含的其它節(jié)點(diǎn)可能并沒有提交，也就是該事務(wù)在一個(gè)個(gè)或多個(gè)其它節(jié)點(diǎn)上仍然是懸而未決。ForcedcommitDBA進(jìn)行判斷后，可以強(qiáng)行提交未決的事務(wù)，如果一個(gè)事務(wù)由DBA在本地節(jié)點(diǎn)進(jìn)行手動(dòng)提交時(shí)，產(chǎn)生此項(xiàng)目Forcedabor（rollback）DBA進(jìn)行判斷后，可以強(qiáng)行回滾未決的事務(wù)，如果一個(gè)事務(wù)由DBA在本地節(jié)點(diǎn)進(jìn)行手動(dòng)回滾時(shí)，產(chǎn)生此項(xiàng)目DBA_2PC_NEIGHBORS:列出所有獲得的（從遠(yuǎn)程客戶）和送出的（給遠(yuǎn)程服務(wù)器）懸而未決的事務(wù)，也表示該本地節(jié)點(diǎn)是不是事務(wù)的提交點(diǎn)站點(diǎn)。LOCAL_TRAN_ID對(duì)獲得事務(wù)來說指本地節(jié)點(diǎn)信息的客戶數(shù)據(jù)庫(kù)的名稱；對(duì)送出的事務(wù)來說指用于訪問遠(yuǎn)程服務(wù)器上信息的數(shù)據(jù)庫(kù)鏈接的名稱DBuser_owner對(duì)獲得事務(wù)來說指遠(yuǎn)程數(shù)據(jù)庫(kù)鏈接用于連接的本地賬戶；對(duì)于送出事務(wù)來說指該數(shù)據(jù)庫(kù)鏈接的擁有者。INTERFACE'C'代表提交信息，’N’表示已準(zhǔn)備好狀態(tài)的一條消息或是一條請(qǐng)求只讀提交的請(qǐng)求。當(dāng)'IN_OUT'為OUT時(shí)，'C'表示該連接的遠(yuǎn)程的站點(diǎn)是提交點(diǎn)站點(diǎn),并且知道是提交還是中斷。'N'表示本地節(jié)點(diǎn)正在通知遠(yuǎn)程節(jié)點(diǎn)，說它已準(zhǔn)備好。當(dāng)'IN_OUT'為IN時(shí)，'C'表示本地節(jié)點(diǎn)或送出的遠(yuǎn)程的一個(gè)數(shù)據(jù)庫(kù)是提交點(diǎn)站點(diǎn)，'N'表示本地節(jié)點(diǎn)正在通知遠(yuǎn)程節(jié)點(diǎn)，說它已準(zhǔn)備好。處理懸掛事務(wù)的一般步驟1、檢查alert文件，發(fā)現(xiàn)類似下面error：ORA-1591"lockheldbyin-doubtdistributedtransaction%s"ORA-2062"distributedrecoveryreceiveddbidx,expectedy"ORA-2068"followingsevereerrorfrom%s%s"2、確認(rèn)網(wǎng)絡(luò)是否正常、dblink是否valid、v$dblink和gv$dblink中查詢當(dāng)前是否在使用分布式事務(wù)。3、查詢視圖dba_2pc_pending，查詢懸掛事務(wù)信息：SELECTLOCAL_TRAN_ID,GLOBAL_TRAN_ID,STATE,MIXED,HOST,COMMIT#FROMDBA_2PC_PENDINGWHERELOCAL_TRAN_ID='??.';如果沒有記錄，說明RECO進(jìn)程已經(jīng)自動(dòng)處理了該事務(wù)。4、在所有節(jié)點(diǎn)上查詢視圖dba_2pc_neighbors5、得到所有節(jié)點(diǎn)的COMMIT_POINT_STRENGTH值，值最大的為commitpointsite，即最早提交的點(diǎn)，如果懸掛事務(wù)發(fā)生在commitpointsite，則它的state決定了整個(gè)分布式事務(wù)的狀態(tài)。懸掛事務(wù)是否應(yīng)該commitforce或者是rollbackforce，由此節(jié)點(diǎn)決定。6、檢查dba_2pc_pending的state列，如果是commited，意味著本地?cái)?shù)據(jù)庫(kù)提交已經(jīng)成功。其他節(jié)點(diǎn)需要根據(jù)本地事務(wù)號(hào)和最大的commit#進(jìn)行強(qiáng)制提交。用法如下：SVRMGR>COMMITFORCE'yourlocaltransactionIDonthisnode','highestSCNfromalreadycommittedsite';SVRMGR>COMMITFORCE'1.13.5197','88123887';7、如果commitpointsite的state為commited外的其他狀態(tài)，則表明commitpointsite沒有提交成功，分布式事務(wù)需要強(qiáng)制回滾。這里不再需要所有節(jié)點(diǎn)的最大commit#。用法如下：SVRMGR>ROLLBACKFORCE'yourlocaltransactionIDonthisnode';SVRMGR>ROLLBACKFORCE'1.13.5197';8、清除dba_2pc_pending和dba_2pc_neighbers的相關(guān)記錄。一般分布式事務(wù)自動(dòng)恢復(fù)后，視圖內(nèi)容會(huì)自動(dòng)清除，如果是手工提交的事務(wù)，則需要用dbms_transaction包手工清除，清除規(guī)則如下表所示：確定何時(shí)能使用DBMS_TRANSACTIONCollectingPurge_lost_db_entry（只有當(dāng)自動(dòng)回復(fù)不能解決事務(wù)時(shí)）CommittedCommittedCommittedPurge_lost_db_entry（只有當(dāng)自動(dòng)回復(fù)不能解決事務(wù)時(shí)）ForcedCommitCommittedPurge_lost_db_entry（只有當(dāng)自動(dòng)回復(fù)不能解決事務(wù)時(shí)）ForcedrollbackPurge_lost_db_entry（只有當(dāng)自動(dòng)回復(fù)不能解決事務(wù)時(shí)）ForcedcommitCommitted手動(dòng)刪除不一致性，然后使用purge_mixedForcedrollback手動(dòng)刪除不一致性，然后使用purge_mixed測(cè)試記錄i設(shè)置db1的commit_point_strength為1，db2的commit_point_strength為2,

db2為commitpointsite。idbl、db2上執(zhí)行100次insert循環(huán)，每次循環(huán)用分布式事務(wù)插入db1和db2中的測(cè)試表。中間rebootdb2服務(wù)器。此時(shí)dbl對(duì)測(cè)試表的查詢出現(xiàn)以下錯(cuò)誤：SQL>selectcount(l)fromtemp.my_table;selectcount(1)fromtemp.my_table*ERRORatline1:ORA-01591:lockheldbyin-doubtdistributedtransaction7.30.7415[oracle@db2bdump]$tail-falert_ntespay.logTueMar414:14:282008TRANDISTRIB1234.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000TRANislocaltran7.30.7415(hex=07.1e.1cf7)insertpendingpreparedtran,scn=934346533(hex=0.37b0ff25)db1中分布式事務(wù)相關(guān)的2個(gè)視圖內(nèi)容如下：selecta.*fromdba_2pc_pendingawhereLOCAL_TRAN_ID='7.30.7415';LOCAL_TRAN_IDTRAN_COMMENTFAIL_TIMEOS_TERMINALHOSTGLOBAL_TRAN_IDSTATEMIXEDADVICEFORCE_TIMELOCAL_TRAN_IDTRAN_COMMENTFAIL_TIMEOS_TERMINALHOST17.30.74154660.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000preparedno2008-3-414:14:282008-3-414:22:56zhenxingzhaiZHAIZHENXINGNETEASE\ZHAIZHENXING934346533其中，state有以下幾種狀態(tài)：Collecting,prepared,committed,forcedcommit,orforcedrollbackmixed表示是否部分提交，部分回滾advice：Cforcommit,Rforrollback,elseNULLselecta.*fromdba_2pc_neighborsawhereLOCAL_TRAN_ID='7.30.7415';LOCAL_TRAN_IDIN_OUTDATABASEDBUSER_OWNERINTERFACEDBIDSESS#BRANCH17.30.7415inNULLTEMPNjavaxa_orcl101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000此視圖說明了數(shù)據(jù)源1的輸入連接信息。因?yàn)閿?shù)據(jù)源2不是通過dblink連接的，以此沒有出現(xiàn)它的記錄。idb2重啟后查詢my_tab：SQL>selectcount(1)frommy_tab;COUNT(1)75i因?yàn)閐b2中dba_2pc_pending和dba_2pc_neighbers中沒有記錄，并且db2為commitpointsite,沒有記錄意味著沒有進(jìn)行任何操作，所以db1應(yīng)該和db2一樣，進(jìn)行強(qiáng)制rollbackoSQL>conn/assysdbaConnected.SQL>rollbackforce'7.30.7415';Rollbackcomplete.SQL>selectcount(12)fromtemp.my_table;COUNT(12)75db1的alert日志中顯示了可疑事務(wù)的回滾過程：TueMar415:14:312008DISTRIBTRAN1234.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000islocaltran7.30.7415(hex=07.1e.1cf7)changependingpreparedtran,scn=934346533(hex=0.37b0ff25)topendingforcedrollbacktran,scn=934346533(hex=0.37b0ff25)i回滾后，兩個(gè)視圖中的狀態(tài)更改為如下：selecta.*fromdba_2pc_pendingawhereLOCAL_TRAN_ID='9.33.5992';LOCAL_TRAN_IDGLOBAL_TRAN_IDSTATEMIXEDADVICETRAN_COMMENTFAIL_TIMEFORCE_TIMERETRY_TIMEOS_USEROS_TERMINALHOSTDB_USERCOMMIT#17.30.74154660.4F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000forcedrollbackno2008-3-414:14:282008-3-415:14:312008-3-415:20:07zhenxingzhaiZHAIZHENXINGNETEASE\ZHAIZHENXING934346533selecta.*fromdba_2pc_neighborsawhereLOCAL_TRAN_ID='9.33.5992';LOCAL_TRAN_IDIN_OUTDATABASEDBUSER_OWNERINTERFACEDBIDSESS#BRANCH17.30.7415inNULLTEMPNjavaxa_orcl101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000i去除dba_2pc_pending和dba_2pc_neighbors中的記錄：Disable分布式恢復(fù)SQL>ALTERSYSTEMDISABLEDISTRIBUTEDRECOVERY;Systemaltered.Puege(清空)in-doubttransactionentry：SQL>execDBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('7.30.7415');PL/SQLmit;然后enable分布式恢復(fù)：SQL>ALTERSYSTEMENABLEDISTRIBUTEDRECOVERY;分布式事務(wù)相關(guān)資料Note:1012842.102Note:100664.1Note:274321.1Note:126069.1事務(wù)處理的nuts和boltsDr.SubrahmanyamAllamaraju?SubrahmanyamAllamaraju1999.Allrightsreserved.Thisdocumentisprotectedbycopyright.Nopartofthisdocumentmaybereproducedinanyformwithoutpriorwrittenconsentoftheauthor.Thisdocumentisforelectronicdistributiononly.Alltrademarksacknowledged.翻譯：寒蟬退士譯者的聲明版權(quán)聲明中聲明了“未經(jīng)版權(quán)持有者的書面允許不得以任何形式復(fù)制本文內(nèi)容，本文檔只以電子版的形式發(fā)布”，很顯然，版權(quán)聲明沒有限制對(duì)電子版的翻譯和在網(wǎng)絡(luò)上傳播。譯者對(duì)譯文不做任何形式的擔(dān)保。譯者對(duì)譯文不擁有任何權(quán)利并且不負(fù)擔(dān)任何義務(wù)。任何人在對(duì)譯文進(jìn)行任何處置(包括但不限于復(fù)制、傳播)之前，應(yīng)當(dāng)認(rèn)真閱讀版權(quán)聲明，譯者對(duì)其他人的行為不負(fù)任何責(zé)任。譯序：譯者添加的圖6引自介紹ORBacusOTS的網(wǎng)頁(yè)。譯者乃一介草莽，譯文中難免存在疏失錯(cuò)訛，祈望仁者指正。原文：/articles/transactions/NutsAndBoltsOfTP.html介紹事務(wù)管理是對(duì)企業(yè)應(yīng)用最緊要的要求之一。在貿(mào)易、金融和電子商業(yè)領(lǐng)域中，多數(shù)大的企業(yè)應(yīng)用依賴于遞送它們的商務(wù)的事務(wù)處理功能。鑒于當(dāng)今商務(wù)對(duì)靈活性的要求，在建造、部署和維護(hù)企業(yè)級(jí)別的分布式應(yīng)用中，事務(wù)處理占據(jù)的是其中最復(fù)雜的部分之一。本文把以下內(nèi)容介紹給讀者：?什么是事務(wù)？什么是ACID??建造一個(gè)事務(wù)應(yīng)用的要點(diǎn)是什么？事務(wù)管理中間件為什么很重要？?事務(wù)處理應(yīng)用的典型的體系是怎樣的？體系中的各種構(gòu)件的職責(zé)是什么？?事務(wù)處理系統(tǒng)涉及哪些概念？?事務(wù)管理領(lǐng)域中有哪些標(biāo)準(zhǔn)和技術(shù)？本文不特定于任何產(chǎn)品，力圖在描述各種要點(diǎn)和概念時(shí)保持普遍性。本文不打算比較各種事務(wù)處理的技術(shù)/標(biāo)準(zhǔn)，只是提供對(duì)此的一個(gè)討論。什么是事務(wù)？為了完成對(duì)數(shù)據(jù)的操作，企業(yè)應(yīng)用經(jīng)常要求并發(fā)訪問在多個(gè)構(gòu)件之間共享的數(shù)據(jù)。這些應(yīng)用在下列條件下應(yīng)該維護(hù)數(shù)據(jù)的完整性（由應(yīng)用的商務(wù)規(guī)則來定義）：?分布式訪問一個(gè)單獨(dú)的數(shù)據(jù)資源，以及?從一個(gè)單獨(dú)的應(yīng)用構(gòu)件訪問分布式資源。在這種情況，可能要求在（分布式）資源上的一組操作被當(dāng)作一個(gè)工作單元（unit）。在一個(gè)工作單元中，操作的所有部分一起成功或失敗并恢復(fù)。在下面的情況下這個(gè)問題更加復(fù)雜：?通過一組分布式的、訪問多個(gè)資源的數(shù)據(jù)的構(gòu)件實(shí)現(xiàn)一個(gè)工作單元，和/或?部分操作是被順序執(zhí)行的或在要求協(xié)調(diào)和/或同步的并行線程中。在所有情況下，都要求應(yīng)用維護(hù)一個(gè)工作單元的成功或失敗。在失敗的情況下，所有資源要把數(shù)據(jù)狀態(tài)返回到以前的狀態(tài)（比如說，工作單元開始前的狀態(tài)）。事務(wù)的概念和和事務(wù)管理器（或者一個(gè)事務(wù)處理服務(wù)）在一個(gè)工作單元中的維護(hù)數(shù)據(jù)完整性，這就簡(jiǎn)化了這樣的企業(yè)級(jí)別分布式應(yīng)用的構(gòu)造。一個(gè)事務(wù)是有下列屬性的一個(gè)工作單元：?原子性（ATOMICITY）:一個(gè)事務(wù)要被完全的無二義性的做完或撤消。在任何操作出現(xiàn)一個(gè)錯(cuò)誤的情況下，構(gòu)成事務(wù)的所有操作的效果必須被撤消，數(shù)據(jù)應(yīng)被回滾到以前的狀態(tài)。?一致性(CONSISTENCY):一個(gè)事務(wù)應(yīng)該保護(hù)所有定義在數(shù)據(jù)上的不變的屬性(例如完整性約束)。在完成了一個(gè)成功的事務(wù)時(shí)，數(shù)據(jù)應(yīng)處于一致的狀態(tài)。換句話說，一個(gè)事務(wù)應(yīng)該把系統(tǒng)從一個(gè)一致狀態(tài)轉(zhuǎn)換到另一個(gè)一致狀態(tài)。舉個(gè)例子，在關(guān)系數(shù)據(jù)庫(kù)的情況下，一個(gè)一致的事務(wù)將保護(hù)定義在數(shù)據(jù)上的所有完整性約束。?隔離性(ISOLATION):在同一個(gè)環(huán)境中可能有多個(gè)事務(wù)并發(fā)執(zhí)行，而每個(gè)事務(wù)都應(yīng)表現(xiàn)為獨(dú)立執(zhí)行。串行的執(zhí)行一系列事務(wù)的效果應(yīng)該同于并發(fā)的執(zhí)行它們。這要求兩件事：o在一個(gè)事務(wù)執(zhí)行過程中，數(shù)據(jù)的中間的(可能不一致)狀態(tài)不應(yīng)該被暴露給所有的其他事務(wù)。o兩個(gè)并發(fā)的事務(wù)應(yīng)該不能操作同一項(xiàng)數(shù)據(jù)。數(shù)據(jù)庫(kù)管理系統(tǒng)通常使用鎖來實(shí)現(xiàn)這個(gè)特征。?持久性(DURABILITY):一個(gè)被完成的事務(wù)的效果應(yīng)該是持久的。這些屬性叫做ACID屬性，擔(dān)保一個(gè)事務(wù)是永遠(yuǎn)不會(huì)不完整，數(shù)據(jù)永遠(yuǎn)不會(huì)不一致，并發(fā)事務(wù)是獨(dú)立的，一個(gè)事務(wù)的效果是持久的。關(guān)于在分布式系統(tǒng)什么能出錯(cuò)的簡(jiǎn)要的一個(gè)描述，請(qǐng)參見在事務(wù)處理系統(tǒng)中的容錯(cuò)和恢復(fù)。建造事務(wù)性應(yīng)用的要點(diǎn)為了引出在建造事務(wù)性應(yīng)用中涉及的要點(diǎn)，考慮一個(gè)定單獲得和定單處理應(yīng)用，它的體系在圖1中展示：圖1：定單獲得和定單處理應(yīng)用這個(gè)應(yīng)用由兩個(gè)客戶構(gòu)件組成，分別實(shí)現(xiàn)定單獲得和定單處理操作。這兩個(gè)操作構(gòu)成了一個(gè)工作或事務(wù)單元。分別基于產(chǎn)品，定單，庫(kù)存清單和貨運(yùn)信息。在這個(gè)圖中，點(diǎn)斷尖頭指示的只讀的數(shù)據(jù)訪問，而連續(xù)尖頭指示指示的是修改數(shù)據(jù)的事務(wù)性操作。下面是在這個(gè)應(yīng)用中的事務(wù)性操作：?生成定單，?更新庫(kù)存，?生成貨運(yùn)記錄，并?更新定單狀態(tài)。當(dāng)作為一個(gè)事務(wù)來實(shí)現(xiàn)這些操作時(shí)，應(yīng)致力于下述要點(diǎn):應(yīng)用應(yīng)當(dāng)與事務(wù)性操作和被操作的數(shù)據(jù)庫(kù)保持聯(lián)系。所以應(yīng)用應(yīng)該為所有事務(wù)定義一個(gè)上下文來包含上述四個(gè)操作。因?yàn)槎▎潍@得和定單處理事務(wù)分布于兩個(gè)構(gòu)件之上，事務(wù)上下文應(yīng)該是全局的，并通過協(xié)議的轉(zhuǎn)換、被從第一個(gè)構(gòu)件傳播到第二個(gè)。當(dāng)事務(wù)發(fā)生期間，應(yīng)用應(yīng)當(dāng)監(jiān)控事務(wù)的狀態(tài)。為了維護(hù)事務(wù)的原子性，應(yīng)用構(gòu)件和/或數(shù)據(jù)庫(kù)服務(wù)器、應(yīng)當(dāng)實(shí)現(xiàn)一種機(jī)制，在這種機(jī)制下對(duì)數(shù)據(jù)庫(kù)的更改可以被撤消，而又不失去數(shù)據(jù)的一致性。為了隔離在共享數(shù)據(jù)上的并發(fā)的事務(wù)，數(shù)據(jù)庫(kù)服務(wù)器應(yīng)該跟蹤被操作的數(shù)據(jù)，并在一個(gè)事務(wù)操作期間鎖住數(shù)據(jù)。應(yīng)用還應(yīng)該維護(hù)數(shù)據(jù)庫(kù)連接和事務(wù)之間的關(guān)聯(lián)。為了實(shí)現(xiàn)可靠的鎖定，應(yīng)用構(gòu)件應(yīng)向數(shù)據(jù)庫(kù)通知事務(wù)的終止。事務(wù)處理-體系看到了從頭開始建造一個(gè)事務(wù)性應(yīng)用的要點(diǎn)，考慮在一個(gè)在圖堂中展示的事務(wù)處理體系下建造相同的應(yīng)用。注意，盡管有多種可能的體系，它們將在后面的章節(jié)中討論，圖2中所展示的代表了本質(zhì)的特征。BeainEnd圖2:事務(wù)處理體系

這個(gè)體系介入了一個(gè)事務(wù)管理器和每個(gè)數(shù)據(jù)庫(kù)（資源）一個(gè)的資源管理器。這些構(gòu)件從應(yīng)用構(gòu)件（定單獲得和定單處理）中抽象出了特定于事務(wù)的大多數(shù)要點(diǎn)，并分擔(dān)事務(wù)實(shí)現(xiàn)的職責(zé)。下面討論這個(gè)體系的各種構(gòu)件。應(yīng)用構(gòu)件應(yīng)用構(gòu)件:職責(zé)?建立和界定事務(wù)?傳播事務(wù)上下文?通過資源管理器操作數(shù)據(jù)應(yīng)用構(gòu)件是事務(wù)性資源的客戶。它們是應(yīng)用開發(fā)者用于實(shí)現(xiàn)商務(wù)事務(wù)的程序。在事務(wù)管理器的幫助下，這些構(gòu)件建立全局事務(wù)，如果需要的話傳播事務(wù)上下文，并在這些事務(wù)的范圍內(nèi)操作事務(wù)性資源。這些構(gòu)件不負(fù)責(zé)實(shí)現(xiàn)保護(hù)事務(wù)的ACID屬性。但是作為應(yīng)用邏輯的一部分，這些構(gòu)件通常做是提交還是回滾一個(gè)事務(wù)的決定。資源管理器資源管理器:職責(zé)?向事務(wù)服務(wù)器應(yīng)征資源?參與兩階段提交和恢復(fù)協(xié)議一個(gè)資源管理器是一個(gè)管理持久和穩(wěn)定的數(shù)據(jù)存儲(chǔ)系統(tǒng)的構(gòu)件，并且參與同事務(wù)管理器的兩段提交和恢復(fù)協(xié)議。一個(gè)資源管理器典型的是一個(gè)穩(wěn)定的存儲(chǔ)系統(tǒng)上的一個(gè)驅(qū)動(dòng)器或一個(gè)包裝，有操作數(shù)據(jù)的接口（給應(yīng)用構(gòu)件），并且為了參與由事務(wù)服務(wù)器協(xié)調(diào)的兩階段提交和恢復(fù)協(xié)議。這個(gè)構(gòu)件也可以，直接的或間接的，向事務(wù)管理器注冊(cè)資源，這樣事務(wù)管理器就可以追蹤所有參與事務(wù)的資源。這個(gè)過程叫做資源征集。為了實(shí)現(xiàn)兩階段提交和恢復(fù)協(xié)議，資源管理器應(yīng)該實(shí)現(xiàn)可能被恢復(fù)所使用的附加機(jī)制。資源管理器提供兩套接口：一套給應(yīng)用構(gòu)件用來連接和完成對(duì)數(shù)據(jù)的操作，另套給事務(wù)管理器用來參與兩階段提交和恢復(fù)協(xié)議。事務(wù)管理器事務(wù)管理器:職責(zé)?建立和維護(hù)事務(wù)上下文?維護(hù)一個(gè)事務(wù)和特定的資源間的關(guān)聯(lián)?發(fā)起并指揮兩階段提交和恢復(fù)協(xié)議?在開始兩階段提交和恢復(fù)過程之

前向應(yīng)用構(gòu)件們做同步呼叫事務(wù)管理器是一個(gè)事務(wù)處理環(huán)境的核心構(gòu)件。它的主要職責(zé)是當(dāng)應(yīng)用構(gòu)件要求時(shí)建立事務(wù)，允許資源征集和遣散,并指揮同資源管理器的兩階段提交或恢復(fù)協(xié)議。一個(gè)典型的事務(wù)性應(yīng)用通過向事務(wù)管理器發(fā)出一個(gè)發(fā)起事務(wù)的請(qǐng)求來開始一個(gè)事務(wù)。作為響應(yīng)，事務(wù)管理器開始一個(gè)事務(wù)并把它同一個(gè)呼叫線程聯(lián)系在一起。事務(wù)管理器也建立一個(gè)事務(wù)上下文。在事務(wù)中的所有應(yīng)用構(gòu)件和/或線程共享事務(wù)上下文。初始發(fā)起開始事務(wù)的請(qǐng)求的線程，或者如果事務(wù)管理器允許的話，任何其他線程可以通過發(fā)起提交或回滾請(qǐng)求來最終終止事務(wù)。在一個(gè)事務(wù)被終止之前，在事務(wù)管理器所知道的多個(gè)數(shù)據(jù)上，多個(gè)構(gòu)件和/或線程可以完成事務(wù)性操作。如果事務(wù)管理器允許的話，在事務(wù)最終完成之前，一個(gè)事務(wù)可以被掛起或被繼續(xù)執(zhí)行。一旦應(yīng)用發(fā)起了提交請(qǐng)求，事務(wù)管理器為一個(gè)提交操作準(zhǔn)備所有資源（通過指揮一次投票表決），并基于是否所有的資源都準(zhǔn)備好了（就緒）提交，來發(fā)起對(duì)所有資源的一個(gè)提交或回滾請(qǐng)求。卜面的章節(jié)討論事務(wù)處理相關(guān)的各種概念。事務(wù)處理-概念事務(wù)界定指定一個(gè)事務(wù)叫做事務(wù)界定（demarcation），通過把分布式的構(gòu)件綁定到一個(gè)全局事務(wù)上來完成事務(wù)界定工作，它是標(biāo)記構(gòu)成一個(gè)事務(wù)的一組操作的一種方法。最常用的界定的途徑是為事務(wù)處理標(biāo)記執(zhí)行操作的線程。這叫做編程界定。這樣建立的事務(wù)可以通過去除標(biāo)記而被掛起，并在以后通過從掛起點(diǎn)向恢復(fù)點(diǎn)顯式的傳播事務(wù)上下文來恢復(fù)執(zhí)行。事務(wù)界定在向事務(wù)管理器的一個(gè)提交或一個(gè)回滾請(qǐng)求之后結(jié)束。提交請(qǐng)求指導(dǎo)所有參與的資源管理器永久的記錄事務(wù)中的操作的效果。回滾請(qǐng)求使資源管理器撤消事務(wù)中所有操作的效果。一個(gè)可替代編程界定的是聲明界定?；跇?gòu)件的事務(wù)處理系統(tǒng)如Microsoft事務(wù)服務(wù)器、和基于應(yīng)用服務(wù)器的事務(wù)處理系統(tǒng)如企業(yè)JavaBeans規(guī)范支持聲明界定。在這種技術(shù)中，構(gòu)件在部署時(shí)被標(biāo)記為事務(wù)性的。這暗示了兩件事。首先，界定的職責(zé)從應(yīng)用轉(zhuǎn)移到了容納構(gòu)件的容器（container）。為此，這種技術(shù)也叫做管理容器界定。其次，界定從應(yīng)用建造期間（靜態(tài)）延期到構(gòu)件部署期間（動(dòng)態(tài)）。事務(wù)上下文和傳播因?yàn)槎鄠€(gè)應(yīng)用構(gòu)件和資源參與了一個(gè)事務(wù)，對(duì)于事務(wù)管理器建立和維護(hù)發(fā)生的事務(wù)的狀態(tài)是必須的。這通常以事務(wù)上下文的形式完成。事務(wù)上下文是在資源上的事務(wù)性操作和調(diào)用操作的構(gòu)件之間的一個(gè)關(guān)聯(lián)(association)o在一個(gè)事務(wù)執(zhí)行期間，所有的參與事務(wù)的線程共享事務(wù)上下文。所以事務(wù)上下文在邏輯上封裝(envelop)了在一個(gè)事務(wù)期間在事務(wù)性資源上的完成的所有操作。事務(wù)上下文通常由底層的事務(wù)管理器透明的維護(hù)。資源征集資源征集是資源管理器向事務(wù)管理器報(bào)告它們參與一個(gè)事務(wù)的過程。這個(gè)過程使事務(wù)管理器可以跟蹤參與一個(gè)事務(wù)的所有資源。資源管理器使用這些信息協(xié)調(diào)資源管理器完成的事務(wù)性工作，以及驅(qū)動(dòng)兩階段提交和恢復(fù)協(xié)議。在事務(wù)結(jié)束時(shí)(一個(gè)提交或回滾之后)事務(wù)管理器遣散資源。在此之后，不再保持事務(wù)與資源之間的關(guān)聯(lián)。兩階段提交這個(gè)事務(wù)管理器與所有應(yīng)征一個(gè)事務(wù)的資源之間的協(xié)議確定是所有的資源管理器都提交事務(wù)還是它們都終止(abort)。在這個(gè)協(xié)議中，當(dāng)應(yīng)用要求提交事務(wù)時(shí)，事務(wù)管理器向所有涉及的資源管理器發(fā)起一個(gè)準(zhǔn)備請(qǐng)求。每個(gè)這些資源可以依次發(fā)送一個(gè)回應(yīng)來指示出它是否準(zhǔn)備好(就緒)提交。只有當(dāng)所有的資源管理器都準(zhǔn)備好提交，事務(wù)管理器才向所有的資源管理器發(fā)起一個(gè)提交請(qǐng)求。否則，事務(wù)管理器發(fā)起一個(gè)回滾請(qǐng)求接著事務(wù)被滾回來。事務(wù)處理-標(biāo)準(zhǔn)和技術(shù)X/Open分布式事務(wù)處理模型X/Open分布式事務(wù)處理(DTP)模型是OpenGroup提出的一個(gè)分布式處理模型，OpenGroup是一個(gè)廠商財(cái)團(tuán)。這個(gè)模型是在事務(wù)處理和數(shù)據(jù)庫(kù)領(lǐng)域中多數(shù)商業(yè)廠商間的一個(gè)標(biāo)準(zhǔn)。這個(gè)模型由四個(gè)構(gòu)件組成：應(yīng)用程序：實(shí)現(xiàn)事務(wù)性操作。資源管理器：同于上面的討論。事務(wù)管理器：同于上面的討論。

通信資源管理器：方便在不同的事務(wù)處理領(lǐng)域中的不同的事務(wù)管理器之間的互操作。這個(gè)模型還定義了下列接口：1.TX接口：這是應(yīng)用程序和事務(wù)管理器之間的接口，并由事務(wù)管理器實(shí)現(xiàn)。這個(gè)接口提供事務(wù)界定服務(wù)，允許應(yīng)用程序把事務(wù)性操作綁定到一個(gè)全局事務(wù)中。這個(gè)接口由下列函數(shù)組成：表1:X/Open模型的TX接口函數(shù)功能tx_open打開一個(gè)事務(wù)管理器和相關(guān)聯(lián)的組資源管理器。tx_close關(guān)閉一個(gè)事務(wù)管理器和相關(guān)聯(lián)的一組資源管理器。tx_begin開始個(gè)新事務(wù)。tx_rollback回滾事務(wù)。tx_commit提父事務(wù)。tx_set_commit_return提交事務(wù)。(譯注：原文如是)tx_set_transaction_control在鏈狀和非鏈狀模式間選擇。在鏈狀事務(wù)的情況下，工作被分成片段(piece)，每個(gè)片段在一個(gè)平坦的(flat)事務(wù)控制之下。一旦完成了工作的一個(gè)片段，這個(gè)片段的提交或回滾不依賴于其他的片段的狀態(tài)。tx_set_transaction_timeout設(shè)置一個(gè)事務(wù)超時(shí)間隔。tx_info返回事務(wù)信息，如它的標(biāo)識(shí)符、事務(wù)的狀態(tài)等。2.XA接口：這是一個(gè)資源管理器和事務(wù)管理器之間的雙向接口。這個(gè)接口規(guī)定了兩套函數(shù)。第一套叫xa_*()函數(shù)，由資源管理器實(shí)現(xiàn)，被事務(wù)管理器使用。表2:X/OpenDTP模型中的事務(wù)管理器的XA接口函數(shù)功能xa_start指導(dǎo)一個(gè)資源管理器把應(yīng)用程序的后續(xù)的請(qǐng)求與個(gè)被提供的標(biāo)識(shí)符所標(biāo)識(shí)的事務(wù)關(guān)聯(lián)起來。xa_end結(jié)束一個(gè)資源管理器與一個(gè)事務(wù)的關(guān)聯(lián)。xa_prepare資源管理器為提交操作做準(zhǔn)備。由事務(wù)管理器發(fā)起，是兩階段提交操作的第一階段。xa_commit提交事務(wù)性操作。由事務(wù)管理器發(fā)起，是兩階段提交操作的第二階段。xa_recover檢索一個(gè)就緒的(prepared)列表，啟發(fā)式的(heuristically)提交或啟發(fā)式的回滾事務(wù)。xa_forget忘記同給定事務(wù)標(biāo)識(shí)苻相關(guān)聯(lián)的啟發(fā)式(heuristic)事務(wù)。4.第二套函數(shù)叫ax_*()函數(shù)，由事務(wù)管理器實(shí)現(xiàn)，被資源管理器使用。表3:X/OpenDTP模型中的資源管理器的AX接口函數(shù)功能ax_reg動(dòng)態(tài)的向一個(gè)事務(wù)管理器應(yīng)征。ax_unreg動(dòng)態(tài)的從一個(gè)事務(wù)管理器撤出。5.XA+接口：這個(gè)接口被用于支持通過通信資源管理器來跨越不同的事務(wù)管理器的全局事務(wù)。TXRPC接口：這個(gè)接口提供在一個(gè)全局事務(wù)中的不同的應(yīng)用程序之間通信的可移植性。CRM-OSITP:是一個(gè)通信資源管理器和OSI事務(wù)處理服務(wù)之間的接口。X/OpenDTP模型在產(chǎn)業(yè)界中被確立的。一些商業(yè)事務(wù)管理產(chǎn)品，象TXSeries/Encina(完全附屬于IBM的Tranarc的產(chǎn)品)，Tuxedo和TopEnd(BEASystems的產(chǎn)品)，還有AT&TGIS支持TX接口。盡管Microsoft的TransactionServer不支持TX接口，它還是能夠同象Oracle這樣的遵從XA的數(shù)據(jù)庫(kù)互操作。類似的，多數(shù)商業(yè)數(shù)據(jù)庫(kù)象Oracle,Sybase,Informix和MicrosoftSQLServer,以及消息中間件產(chǎn)品如IBM的MQSeries,和Microsoft的MSMQServer提供了XA接口的一個(gè)實(shí)現(xiàn)。OMG對(duì)象事務(wù)服務(wù)對(duì)象事務(wù)服務(wù)(OTS)是由對(duì)象管理組織(OMG)規(guī)定的分布式事務(wù)處理服務(wù)。這個(gè)規(guī)范擴(kuò)展了CORBA模型并定義了一系列跨越(across)多個(gè)CORBA對(duì)象完成事務(wù)處理的接口。OTS模型基于X/OpenDTP模型之上并提供下列增強(qiáng)：?OTS模型把函數(shù)形式的XA和TX接口替換成了CORBA業(yè)接口。?在這個(gè)模型中的各種對(duì)象通過在IIOP之上的CORBA方法調(diào)用來通信。OTS可以同X/OpenDTP模型互操作。一個(gè)使用了事務(wù)性對(duì)象的應(yīng)用可以使用事務(wù)管理器的TX接口來進(jìn)行事務(wù)界定。OTS體系由下列構(gòu)件組成：?事務(wù)客戶：一個(gè)調(diào)用事務(wù)性對(duì)象上的操作的程序或?qū)ο蟆?事務(wù)性對(duì)象：一個(gè)封裝(encapsulate)或參照(refersto)持久數(shù)據(jù)的CORBA對(duì)象，并且它的行為依賴于在一個(gè)事務(wù)期間是否調(diào)用它的操作。?可恢復(fù)對(duì)象：一個(gè)直接維護(hù)持久數(shù)據(jù)并且參與事務(wù)協(xié)議的事務(wù)性對(duì)象。?事務(wù)性服務(wù)器：一個(gè)或多個(gè)事務(wù)性對(duì)象的集合(collection)。?可恢復(fù)服務(wù)器：一個(gè)對(duì)象的集合，其中至少有一個(gè)是可恢復(fù)的。?資源對(duì)象：一個(gè)資源對(duì)象是為了參與兩階段提交和恢復(fù)協(xié)議而被注冊(cè)的、在事務(wù)服務(wù)中的一個(gè)對(duì)象。除了通常的事務(wù)性語義，CORBAOTS還提供了下面的：?嵌套事務(wù)：這就允許一個(gè)應(yīng)用建立一個(gè)嵌入在一個(gè)現(xiàn)存的事務(wù)中的事務(wù)。在這個(gè)模型中，多個(gè)子事務(wù)(subtransaction)可以遞歸的嵌入一個(gè)事務(wù)中。子事務(wù)可以提交或回滾而不提交或回滾它的父事務(wù)。但是，一個(gè)提交操作的結(jié)果要視事務(wù)的所有祖先的提交(commitment)狀況而定。這個(gè)模型的主要優(yōu)點(diǎn)是可以在一個(gè)精細(xì)的粒度上控制事務(wù)性操作。應(yīng)用有一個(gè)在子事務(wù)層次上對(duì)錯(cuò)誤進(jìn)行改正或補(bǔ)償?shù)臋C(jī)會(huì)，而不用真正的去嘗試提交整個(gè)父事務(wù)。?應(yīng)用同步：使用OTS同步協(xié)議，在兩階段提交過程開始之前和完成之后，特定的對(duì)象可以為了通告而被注冊(cè)在事務(wù)服務(wù)上。這使得應(yīng)用對(duì)象可以同步暫時(shí)的(transient)狀態(tài)和存儲(chǔ)在持久存儲(chǔ)中的數(shù)據(jù)。

圖6:ORBacus?OTS體系（譯者添加）卜面是CORBAOTS規(guī)范的原理上的接口:表4:CORBAOTS接口接口職責(zé)Current事務(wù)界定(begin,commit,rollback,rollback_only,set_time_out)事務(wù)的狀態(tài)(get_status)?事務(wù)的名字(get_transaction_name)事務(wù)上下文(get_control)TransactionFactory顯式的事務(wù)建立Control顯式的事務(wù)上下文管理Terminator提交或回滾一個(gè)事務(wù)Coordinator事務(wù)的狀態(tài)(get_status,get_parent_status,get_top_level_status)事務(wù)的信息(is_same_transaction,is_related_transaction,is_ancestor_transaction,is_descendant_transaction,

is_top_level_transaction,hash_transaciton,hash_top_level_transaction,get_transaction_name,get_txcontext)資源征集(register_resource,register_subtrans_aware)?同步對(duì)象的注冊(cè)(register_synchronization)?為回滾而設(shè)置對(duì)象(rollback_only)建立子事務(wù)(create_subtransaction)RecoveryCoordinator在失敗的情況下協(xié)調(diào)恢復(fù)(replay_completion)Resource參與兩階段提交和恢復(fù)協(xié)議(prepare,rollback,commit,commit_one_phase,forget)Synchronization在兩階段提交開始之前和完成之后的應(yīng)用同步(before_completion,after_completion)SubtransactionAwareResource提交或回滾一個(gè)子事務(wù)，被事務(wù)服務(wù)調(diào)用(commit_subtransaction,rollback_subtransaction)TransactionalObject所有事務(wù)性對(duì)象都實(shí)現(xiàn)的個(gè)指小器(marker)接口下述產(chǎn)品提供OTS的實(shí)現(xiàn)：IntegratedTransactionService(Inprise的產(chǎn)品)，OrbixOTM(Iona的產(chǎn)品)，OTSARjuna(ArjunaSolutionsLimited的產(chǎn)品),和TPBroker(HitachiSoftware的產(chǎn)品).JTS和JTAJava事務(wù)服務(wù)和Java事務(wù)API是分布式計(jì)算領(lǐng)域中最新的競(jìng)爭(zhēng)參加者。作為企業(yè)Java的發(fā)起者，SunMicrosystemsInc.在1999年提出了規(guī)范。(譯注：1999年12月8日推出正式規(guī)范)OMGObjectTransactionService1.1JavaTransactionAPIJavaTransact!onServiceJavaTransactionalApplicdtions廠、￥JwaTransadionaiResourcesqqb5圖3:Java事務(wù)的發(fā)起JTS規(guī)定一個(gè)Java事務(wù)管理器的實(shí)現(xiàn)。這個(gè)事務(wù)管理器支持JTA,應(yīng)用服務(wù)器可以使用它建造支持事務(wù)性Java的應(yīng)用。JTS的內(nèi)部實(shí)現(xiàn)OMGOTS1.1規(guī)范的Java映射。Java映射被規(guī)定在兩個(gè)包中：org.omg.CosTransactions和org.omg.CosTSPortability。盡管JTS是OMGObjectTransactionService1.1JavaTransactionAPIJavaTransact!onServiceJavaTransactionalApplicdtions廠、￥JwaTransadionaiResourcesqqb5圖3:Java事務(wù)的發(fā)起JTA規(guī)定一個(gè)建造事務(wù)性應(yīng)用服務(wù)器的體系，并為這個(gè)體系中各種構(gòu)件定一系列的接口。這些構(gòu)件是：應(yīng)用構(gòu)件，資源管理器，應(yīng)用服務(wù)器，它們?cè)趫D3中展示。JTS為事務(wù)性應(yīng)用服務(wù)器和應(yīng)用提供了一個(gè)新的體系，而在內(nèi)部遵從OMGOTS1.1接口。這就允許遵從JTA的應(yīng)用程序同其他的遵從OTS1.1的應(yīng)用程序通過標(biāo)準(zhǔn)的IIOP來互操作。象在圖3中展示的那樣，在Java事務(wù)模型中，Java應(yīng)用構(gòu)件能通過JTS在遵從JTA的資源上指揮事務(wù)性操作。JTS扮演的是OTS之上的一個(gè)薄層。應(yīng)用可以發(fā)起全局事務(wù)來包含其他OTS事務(wù)管理器，或參與到一個(gè)其他遵從OTS的事務(wù)管理器發(fā)起的全局事務(wù)。關(guān)于JTS和JTA的更詳細(xì)的敘述請(qǐng)參見Java事務(wù)服務(wù)Microsoft事務(wù)服務(wù)器

Microsoft事務(wù)服務(wù)器(MTS)是一個(gè)基于構(gòu)件的事務(wù)服務(wù)器，它的構(gòu)件基于Microsoft的構(gòu)件對(duì)象模型(COM)oMTS編程模型為建造事務(wù)性COM構(gòu)件提供接口，而MTS運(yùn)行環(huán)境提供一個(gè)部署和管理這些構(gòu)件和管理事務(wù)的方法。使用了MTS，由多個(gè)COM構(gòu)件做的工作可被組合在一個(gè)單一的事務(wù)中。不象本章討論的其他技術(shù)，MTS是一個(gè)產(chǎn)品并且不基于開放的規(guī)范。還要注意，盡管MTS環(huán)境提供了一些其他特征，如資源緩沖池(pooling),對(duì)象重復(fù)利用(recycling),訪問控制等，本節(jié)只聚焦于MTS的事務(wù)性的功能，并嘗試把各種事務(wù)管理的概念映射到MTS環(huán)境。MTS體系高層的MTS體系在圖4中展示:ResourceManagerApplication

ComponentApplicationComponentResourceManagerIApplicationResourceManagerApplication

ComponentApplicationComponentResourceManagerIApplicationComnonentnn-DistributedTransactionCoordinartorResourceDispenser■圖4:Microsoft事務(wù)服務(wù)器MTS運(yùn)行時(shí)環(huán)境(run-time):它是MTS構(gòu)件的實(shí)例執(zhí)行和被管理的環(huán)境。MTS運(yùn)行時(shí)環(huán)境提供了MTS構(gòu)件的部署和管理。它有以下特征：o分布式事務(wù)的管理o過程和線程的原子性管理o對(duì)象的(建立，緩沖(pooling)和重用)管理o控制對(duì)象的建立和使用的分布式安全服務(wù)MTSExplorer:這是一個(gè)圖形用戶界面驅(qū)動(dòng)的工具，用來在MTS運(yùn)行環(huán)境上部署和管理MTS構(gòu)件。MTSExplorer也被用于通過分布式事務(wù)協(xié)調(diào)器來監(jiān)控事務(wù)。分布式事務(wù)協(xié)調(diào)器(DTC):DTC是MTS的事務(wù)管理器。MTSAPI:MTSAPI(在MicrosoftVisualBasic,MicrosoftVisualC++和MicrosoftVisualJ++中)為建造事務(wù)性構(gòu)件提供特定的接口和特定的具體的類。資源分發(fā)器(dispenser):一個(gè)MTS資源分發(fā)器代表MTS應(yīng)用來管理非持久的共享的數(shù)據(jù)。MTS提供兩個(gè)資源分發(fā)器：oODBC資源分發(fā)器：ODBC資源分發(fā)器本質(zhì)上是一個(gè)ODBC驅(qū)動(dòng)器的管理器，并有下列附加功能：?管理到遵從ODBC的數(shù)據(jù)庫(kù)的連接的緩沖池，包括連接的回收和重用。?征集和遣散在MTS上下文對(duì)象上的數(shù)據(jù)庫(kù)連接。o共享的屬性管理器:MTS共享的屬性管理器管理應(yīng)用范圍的特定于進(jìn)程的屬性(一對(duì)名字-值)并提供同步的訪問這個(gè)數(shù)據(jù)。資源管理器：對(duì)于一個(gè)參與MTS事務(wù)的資源管理器，它必須支持下列協(xié)議之一：oOLE事務(wù)：這是一個(gè)基于COM的兩階段提交協(xié)議，資源管理器使用它來參與由DTC協(xié)調(diào)的事務(wù)。oX/OpenDTPXA協(xié)議：對(duì)于這個(gè)協(xié)議，MTS要求一個(gè)OLE事務(wù)到XA的映射器(mapper)。這個(gè)映射器在MTSSDK中提供。MTS對(duì)象和事務(wù)上下文一個(gè)MTS對(duì)象是一個(gè)MTS構(gòu)件的一個(gè)實(shí)例(一個(gè)構(gòu)件在MTS上被部署，并被MTS管理)。對(duì)于每個(gè)MTS對(duì)象，MTS建立和維護(hù)一個(gè)上下文對(duì)象(ObjectContext)，它為一個(gè)MTS對(duì)象提供執(zhí)行上下文。上下文對(duì)象也維護(hù)事務(wù)上下文的信息。資源分發(fā)器和DTC可以為事務(wù)界定，資源征集，遣散，兩階段提交等，訪問這個(gè)事務(wù)上下文信息。注意，在MTS中，為每個(gè)MTS對(duì)象都維護(hù)事務(wù)上下文信息，而不是為所有參與一個(gè)事務(wù)的對(duì)象維護(hù)一個(gè)單一的事務(wù)上下文對(duì)象。事務(wù)結(jié)果每個(gè)MTS對(duì)象可以通過調(diào)用ObjectContext對(duì)象的一個(gè)方法，來參與決定一個(gè)事務(wù)的結(jié)果(outcome):SetComplete:通知MTS，對(duì)象已經(jīng)成功的完成了它的工作，它的工作可以被提交了。SetAbort:通知MTS，對(duì)象的工作不能被提交。EnableCommit:對(duì)象的工作不是必須做完，但它的事務(wù)性工作可以用當(dāng)前的形式被提交。DisableCommit:通知MTS，對(duì)象的工作不能用當(dāng)前的形式被提交。事務(wù)界定MTS同時(shí)允許事務(wù)的編程界定和聲明界定。對(duì)于在MTS上部署構(gòu)件，聲明界定是強(qiáng)制的。除此之外，MTS客戶也可以通過編程發(fā)起和結(jié)束事務(wù)。?聲明界定：依靠一個(gè)MTS構(gòu)件的事務(wù)屬性（property）,MTS代表應(yīng)用自動(dòng)的開始一個(gè)事務(wù)。可能以有下列的事務(wù)屬性（可以在部署期間設(shè)置）：要求事務(wù)：構(gòu)件的實(shí)例總是在一個(gè)事務(wù)的上下文中執(zhí)行。希望調(diào)用（調(diào)用）對(duì)象在一個(gè)事務(wù)的上下文中被執(zhí)行。要求新事務(wù)：構(gòu)件的實(shí)例必須在它們自己的事務(wù)中執(zhí)行，而不考慮調(diào)用對(duì)象是否已經(jīng)開始了一個(gè)事務(wù)。支持事務(wù)：構(gòu)件的實(shí)例可以在調(diào)用對(duì)象的事務(wù)（如果有的話）范圍內(nèi)執(zhí)行。這暗示構(gòu)件是事務(wù)安全的。不支持事務(wù)：構(gòu)件的實(shí)例不在任何事務(wù)的范圍內(nèi)執(zhí)行°MTS不把這樣的構(gòu)件做的工作同任何事務(wù)關(guān)聯(lián)在一起。?編程界定：MTS客戶可以使用TransactionContext對(duì)象用程序界定事務(wù)。一個(gè)客戶可以通過建立TransactionContext對(duì)象的一個(gè)實(shí)例來開始一個(gè)事務(wù)，并通過調(diào)用這個(gè)對(duì)象的Commit或Abort方法來結(jié)束事務(wù)。所有在這些使用TransactionContext對(duì)象的邊界內(nèi)建立的MTS對(duì)象將在同一個(gè)事務(wù)上下文下執(zhí)行。（除非構(gòu)件設(shè)置為要求一個(gè)新事務(wù)或不支持事務(wù)）。MTS隱含的維護(hù)TransactionContext對(duì)象和事務(wù)的關(guān)聯(lián)。資源征集MTS進(jìn)行自動(dòng)的資源征集。當(dāng)一個(gè)MTS對(duì)象向資源分發(fā)器要求到一個(gè)資源的連接時(shí)，資源分發(fā)器獲取調(diào)用對(duì)象的事務(wù)上下文，并用來它注冊(cè)連接。經(jīng)管MTS只能在MicrosoftWindows平臺(tái)上獲得，MTS可以同遵循XA協(xié)議的資源管理器互操作，并且在非Windows平臺(tái)上操作的這樣的資源管理器可以參與由DTC協(xié)調(diào)的事務(wù)。關(guān)于MTS的更多的信息請(qǐng)參閱MSDNlibrary。要得到MTS和其他競(jìng)爭(zhēng)技術(shù)的一個(gè)快速而詳細(xì)的特征匯編請(qǐng)參閱MTSFAQ.企業(yè)JavaBeans企業(yè)JavaBeans（EJB）是來自SunMicrosystemsInc的一個(gè)技術(shù)規(guī)范。它規(guī)定了一個(gè)建造基于構(gòu)件的分布式應(yīng)用的框架。在過去六個(gè)月中，符合這項(xiàng)技術(shù)的應(yīng)用服務(wù)器已經(jīng)從不同的廠商出現(xiàn)，而規(guī)范當(dāng)前由SunMicrosystemsInc來不斷改善。（譯注：1998年3月24日推出正式的規(guī)范1.0）.作為一個(gè)應(yīng)用服務(wù)器框架，EJB服務(wù)器致力于事務(wù)處理，資源緩沖池，安全，線程，持久性，遠(yuǎn)程訪問，生命周期等。但是同于MTS的情況，本節(jié)只聚焦于EJB框架的分布式事務(wù)性模型。EJB框架規(guī)定叫做enterprisebeans的構(gòu)件的構(gòu)造，部署和激發(fā)。EJB規(guī)范把enterprisebeans分成兩類：實(shí)體（entity）beans和任務(wù)（session）beans。實(shí)體beans抽象的是持久域數(shù)據(jù)，任務(wù)beans提供特定的應(yīng)用邏輯的任務(wù)。兩種類型的beans被遵循EJB的服務(wù)器在叫做容器的東西中維護(hù)。一個(gè)容器為enterprisebeans提供運(yùn)行時(shí)環(huán)境。圖5展示了一個(gè)遵循EJB的應(yīng)用服務(wù)器的簡(jiǎn)化了的體系。圖中只展示了體系的各組成部分間的本質(zhì)性的交互。EJBApplicationServer圖5:在EJB應(yīng)用服務(wù)器中的事務(wù)一個(gè)enterprisebean由兩個(gè)接口來指定：home接口和remote接口。home接口指定如何建立和查找一個(gè)bean。通過這個(gè)接口，一個(gè)客戶或其他bean可以獲得駐留在一個(gè)EJB服務(wù)器上某個(gè)容器中的某個(gè)bean的一個(gè)引用。remote指定特定于應(yīng)用的與實(shí)體或任務(wù)bean相關(guān)的方法。客戶可以通過Java命名和目錄接口(JavaNamingandDirectoryInterface:JNDI)機(jī)制獲得enterprisebean的home接口的引用。一個(gè)EJB服務(wù)器應(yīng)當(dāng)為任何命名和目錄服務(wù)器提供一個(gè)JNDI實(shí)現(xiàn)。通過使用這