事務性COM+應用程式

來源:互聯網
上載者:User
程式


     在前幾章我們已經看到COM+提供的幾種運行期特性,它們使得分布式組件的開發簡單化,這些組件可用於建立可擴充、可維護的ASP應用程式。MTS最先引進了事務模型,它的設計簡化了基於組件的分散式交易處理系統的開發。作為MTS的繼承者, COM+增強並擴充了MTS的強大的事務模型,給系統提供更多靈活性和簡單化。
    COM+事務模型去掉了複雜的交易處理代碼,這些代碼是通過MS DTC協調分散式交易所必需的。但是更重要的是, COM+事務模型透明地融合了分散式交易與COM+組件。
    通過使用聲明( declarative )屬性實現的COM+事務,有時也稱為聲明事務或自動事務。聲明屬效能從外部指定到組件的實現。為此,必須:
    ? 配置組件的Transaction Support屬性,使用Component Services Explorer或者在組件類型庫中使用一個常數值。
    ? 可選修改組件來表決事務的結果。
    通過代表組件與MS DTC互動,COM+自動地處理其餘的複雜且冗長的事務細節。
    因為COM+依賴於MS DTC協調事務,單個組件能夠在單個COM+事務中對不同類型的資料來源執行操作。當與組件一起使用COM+聲明事務時,能影響ADO或OLE DB資料訪問。在單個事務中能夠操作的資料來源的可能組合是無止境的。例如, COM+對象能夠在SQL Server資料庫中修改資料、發送MSMQ訊息,以及操作來自大型主機系統的資料,所有這一切都在相同的COM+事務中。
    現在我們明白了COM+事務的益處,下面繼續學習如何有效地使用聲明事務模型並瞭解COM+在“幕後”所做的事。
19.3.1 Transaction Support屬性
    正如上面提到的,每個COM+組件的Transaction Support 屬性決定了組件將如何參與COM+事務。啟用COM+對象時,COM+決定了對象的事務支援以及創造者是否已經提供了一個存在的事務。基於這兩方面的資訊, COM+運行期將在一個存在的事務或一個新的事務中提供對象,或者根本不存在事務。不管有沒有事務,都能啟用每一個COM+對象。由於這個原因,利用事務的組件常常被稱為事務性組件,沒有利用事務的組件則稱為非事務性組件。
    使用COM+時有五種可能的Transaction Support屬性選項:
    ? 禁止( Disabled )當組件的Transaction Support屬性設定為Disabled時,COM+將完全地忽略組件的事務要求。COM+首先試圖在建立者的環境內啟用物件。如果建立者的環境是無效的或不相容的, COM+在一個新的環境中啟用物件。由於對象可能繼承或不繼承建立者的環境,則對象也就可能共用或不共用建立者的事務。
    ? 不支援(Not Supported)當組件的Transaction Support屬性設定為Not Supported時,組件的執行個體決不參與事務。這種設定是為不訪問資料來源的COM+組件設計的,其結果是組件沒有事務開銷。然而, Transaction Support屬性為Not Supported的對象總是在一個新的環境中被啟用。這與Disabled相矛盾, Disabled的對象可以共用建立者的環境。NotSupported是預設的Transaction Support屬性值。
    ? 支援(Supported)當組件的Transaction Support屬性設定為Supported時,組件的執行個體參與存在的事務。但是組件對事務並沒有要求,組件在事務不存在的情況下仍能很好地執行。Supported屬性只是表示支援事務,而不是必須要求事務存在。
    ? 需要( Required )當組件的Transaction Support屬性設定為Required時,組件的執行個體總是在事務內執行。在啟用COM+對象前, COM+將使用建立者的事務(如果存在),或者新的事務提供對象。不管哪種情況,組件執行個體總是在事務內執行。
    ? 需要建立(Requires New)當組件的Transaction Support屬性設定為Requires New時,總是在一個新的事務中啟用組件的執行個體,即專為這個對象建立一個事務,而不管是否存在可用的事務。這個設定為必須在事務中完成工作,但又必須把它的工作與所有其他的事務分開的組件而設計的。使用這個設定時, COM+對象永遠不會運行在建立者的事務中。新的事務完全獨立於建立者的事務。
    1. 設定Transaction Support
    組件的Transaction Support屬性可以使用元件服務瀏覽器(Component Services Explorer,CSE)配置,或者在組件的類型庫中指定一個預設的Transaction Support設定。在組件的類型庫中指定一個組件的Transaction Support屬性是有益的,因為當使用CSE從執行這項任務中解除一個管理者時,可以減少不正確地配置組件的危險。然而,記住在組件的類型庫中指定的TransactionSupport屬性是一個預設值,可以使用元件服務瀏覽器覆蓋該值,這一點是很重要的。
    在使用元件服務瀏覽器對一個組件的Transaction Support屬性進行配置時,簡單地開啟一個COM+應用程式的Component Properties對話方塊,從Transactions選項卡中選擇五種可能的Transaction Support屬性設定中的一個,如圖1 9 - 5所示。

    如果使用的是V C++,可以在組件類型庫中為一個組件的Transaction Support屬性設定一個預設值,可簡單地通過在組件的介面定義語言( I D L )的定義中增加相應的一行來實現。當該組件被加到一個COM+的應用程式時,COM+讀取類型庫並且自動地使用儲存於該類型庫中的Transaction Support屬性設定作為預設值。
    Visual Basic 6.0也允許開發人員通過改變類別模組的MTS Transaction Mode屬性,為組件的TransactionSupport屬性設定指定一個預設值。不要讓這個屬性的名稱欺騙了你,MTST ransactionMode屬性不但與MTS一起工作,也和COM+一起工作。當編譯一個項目時,Visual Basic將在組件的類型庫中為Transaction Support屬性的設定放置一個等價的常量值,如圖1 9 - 6所示。

    注意在Visual Basic中MTS Transaction Mode值的技術術語和元件服務瀏覽器中的術語是不完全相同的。然而,不必擔心,除了Disabled (對COM+是新的)外,每一個Transaction Support屬性層級都有一個對應的MTS Transaction Mode設定。表19 - 1中列了所有可能的MTS Transaction Mode屬性和他們的等價的COM+ Transaction Support屬性。

    當組件從Registered Components列表中加入時,因為元件服務瀏覽器不讀取類型庫,因此只要組件用Add File對話方塊加到COM+應用程式中,就應用儲存在組件的類型庫中的Transaction Support屬性設定。相反地,從Registered Components加入的COM+組件,如果不用元件服務瀏覽器修改它們的配置,則組件使用預設的Transaction Support屬性配置,即Not Supported。
19.3.2 活動與同步
    當交易處理系統為許多使用者提供服務時,能從客戶中接收同時發生的調用。因此,交易處理系統必須考慮像多使用者並發、同步和線程管理等問題。COM+能夠處理這些問題,而且允許建立在多使用者分布式環境中執行的組件,其建立過程同建立為單個使用者服務的組件一樣。
    COM+通過使用活動(activity )來完成這個驚人的任務。在MTS中,活動是一個對象組,這些對象都在代表單個客戶運行。在COM+中,活動是一個環境組,這些環境在代表單個客戶運行,環境可能含有一個或多個對象。然而,這僅是一個微小的差別,並且可以認為環境是最內部的對象容器。
    活動確保服務於同一使用者的兩個對象不會同時執行。在一個活動中的對象被同步以阻止在這個活動中並行地執行。活動可以由幾個環境(包含著對象)組成,可以運行在分離的進程中,或者運行在分離的機器上(稍微有一點限制)。由於這些原因,活動有時指的是啟動並執行單個邏輯線程。
    為什麼對象的同步如此重要?考慮一個最糟糕的情況,在完全相同的時刻,代表同一使用者服務的兩個對象試圖訪問相同資源。每一個對象要完成自己的操作,就要阻塞其他對象的運行。這種情況稱為死結。活動能防止發生死結,這是通過每次只允許一個對象代表一個用
戶運行來實現的。另外,活動在協助COM+管理線程緩衝方面起著重要作用。
    在MTS中,活動內對象的同步是通過將活動串連到單個物理線程,或是一個STA實施的。在一個活動中的對象不能並發執行,因為每個活動僅有一個物理線程。另外, COM+使用複雜的鎖定機制來確保活動中的同步。
    每個活動保持著單一的獨佔鎖。當在對象中調用一個方法並且對象的環境存在於一個活動中時,在允許處理方法調用前, COM+首先要試圖獲得活動鎖。如果獲得鎖,就由對象處理調用,直到方法調用完成,才解除鎖。如果不能獲得鎖,就阻塞方法調用,直到獲得鎖才調用方法。雖然鎖定過程更加複雜,但從高層次觀點看, COM+使用邏輯的活動使得多個環境和多個對象同步,基本上就是每一活動用一個單獨的鎖。使用鎖的過程如圖1 9 - 7所示。

    環境能存在於建立者的活動或一個新的活動中或者根本沒有活動。然而,單個環境不能跨越多個活動。為了建立和保持這些關係, COM+為每個活動建立獨特的使用者識別碼,稱為Activity ID,儲存於每個環境中。
    1. 建立活動和Synchronization屬性
    隨著COM和MTS編程模型的整合,建立活動的方法也發生了改變。使用MTS,每個對象屬於一個活動。當VB客戶使用CreateObject函數或New關鍵字(及某些運算式),或者VisualC++客戶使用C o CreateInstance E X函數建立MTS對象時,自動地建立了活動。為了在已存在的活動中建立對象,建立者必須調用ObjectContext對象中的CreateInstance函數。
    正如所想像的,這會導致大量的混亂, MTS的開發人員必須意識到邏輯活動的邊界,並且恰當地使用標準的對象建立技術(CreateObject or CoCreateInstanceEX)或者ObjectContext對象的CreateInstance函數。
    使用COM+,仍然能自動地建立活動,但是活動的建立是通過使用組件的Synchronization屬性來控制的,而不是基於如何執行個體化一個組件。實際上, ObjectContext對象的CreateInstance函數現在的功能與標準的對象建立技術相同,並且它僅支援MTS的向後相容性。另外,COM+提供啟用活動外部的對象的能力。這樣可避免建立活動的額外開銷和可能的調用阻塞,為頻繁使用的非事務性“工具”類型的組件提升效能。如果需要,可以實現它們自己的鎖定技術。
    同Transaction Support 屬性一樣Synchronization屬性在元件服務瀏覽器中的組件Properties對話方塊配置,如圖1 9 - 8所示。

    對Synchronization屬性有五種可能的值:
    ? 禁止(Disabled) 當組件的Synchronization屬性設定為Disabled時,COM+將完全地忽略組件的同步要求。正如當Transaction Support屬性設定為Disabled時, COM+將首先試圖在建立者的環境中啟用物件。如果建立者的環境無效或不相容, COM+將在一個新的環境中啟用物件。如果對象繼承建立者的環境,則對象可以分享建立者的活動,反之不能。應該在非事務性組件中使用這種設定,無論何時,應盡量避免建立環境和活動的額外開銷。
    ? 不支援(Not Supported) 當組件的Synchronization屬性設定為Not Supported時,對象的環境將不存在於活動中。然而,Synchronization屬性為Not Supported的對象總是在一個新的環境中被啟用。
    ? 支援(Supported) 當組件的Synchronization屬性設定為Supported時,對象的環境是否存在於活動中依賴於建立者的環境是否存在於活動中。然而,具有這種設定的組件不需要活動,而且在沒有活動的情況也能很好地執行。
    ? 需要(Required) 當組件的Synchronization屬性設定為Required時,對象的環境將總是存在於活動中。如果建立者環境存在於活動中,則新的對象將在建立者的活動中啟用。否則,COM+將在位於新活動中的新環境裡啟用物件。
    ? 需要建立(Requires New) 當組件的Synchronization屬性設定為Requires New時,對象的環境將總是在新的活動中建立,不管建立者的環境的同步狀態如何。
    正如你所看到的,Synchronization屬性的選項和Transaction Support屬性的選項非常相似。然而,某些Synchronization選項依賴於其他組件屬性的某些值。特別是,支援JIT啟用的組件或Transaction Support屬性為Supported、Required和Requires New的組件必須在活動中被啟用,而且需要Synchronization屬性為Required或Requires New 。只有當JIT啟用被關閉並且Transaction Support屬性設定為Disabled或Not Supported時,Synchronization屬性才能設定為Disabled或Not Supported。我們將在下一節更多地討論事務與活動的關係。
    如果認為所有這些配置選項聽起來有些令人困惑,不必擔心。Microsoft預料到這些互相依賴的配置選項會使開發人員記憶混亂,他們在元件服務瀏覽器中建立驗證功能。如果改變JIT啟用支援或者改變對Synchronization屬性不相容的某些Transaction Support屬性,元件服務瀏覽器器將用警告訊息提示並自動地調整Synchronization屬性來反映任何變化。警告訊息如圖1 9 - 9所示。

    關於活動,最好的優點是它們全部通過COM+在幕後執行,組件不需要做任何附加工作,COM+提供了自動的並行和同步服務。另外,對非事務性組件提供了禁止建立活動的功能。儘管如此,理解Synchronization屬性變化的作用和活動與環境在幕後如何運行是很重要的,這樣才能設計出高效和可擴充的組件。現在我們對事務性COM+組件的可配置屬性有了一定的瞭解,下面討論事務的生存期的每一階段。
19.3.3 事務的生存期
    COM+事務生存期可分為四個階段,分別是:
    ? 事務開始。
    ? 建立並徵募與Resource Manager的串連。
    ? 在事務中執行操作。
    ? 輸出事務結果並結束。
    重要的是記住只有Transaction Support屬性不是Disabled或Not Supported時組件才需要參與事務。COM+組件同樣能可選地表決事務的結果。
    下面詳細看一下在單個和多個對象的COM+事務中,事務生存期的每一階段的具體情況。
    1. 事務開始
    使用COM+事務模型,組件不會顯式地啟動一個COM+事務。相反,COM+在兩種情況下自動地建立一個新的COM+事務:
    ? Transaction Support屬性為Required的組件由非事務性的客戶啟用。
    ? Transaction Support屬性為Requires New的組件由任何客戶啟用。
    一個COM+事務由兩部分組成:
    ? 邏輯事務。
    ? 物理事務。
    邏輯事務也稱為事務流,是共用一個物理事務的對象的一個邏輯集合或邏輯組。另一方面,物理事務是基本的MS DTC事務,使用兩階段交易認可協議,根據資料來源協調事務結果。當物理事務由COM+建立時,它使用最進階別的隔離(可串列的)建立,並且在元件服務瀏覽器中指定事務逾時間隔。COM+從基本的物理事務中完全地抽象對象,而不是讓我們通過邏輯事務流和每個對象的環境管理事務。
    儘管邏輯事務可以由幾個COM+對象組成,但是事務流(邏輯事務)與物理事務始終存在一一對應關係,這一點非常重要。
    在事務流中建立的第一個對象,稱為事務的根。事務的根能夠通過執行個體化組件在同一事務中可選擇地徵募其他的COM+對象,這些被執行個體化的COM+組件的Transaction Support屬性為Required或者Supported。在這同一事務中建立對象時, COM+自動地將根對象的環境事務資訊複製到新的對象環境中,因此COM+能在事務中維持所有對象之間的關聯。事務資訊包含一個稱為Transaction ID的GUID值,COM+用它識別物理(MS DTC)事務。對象之間的關係如圖1 9 - 1 0所示。

    將被徵募到建立者的事務中的新對象必須在相同的活動中建立。利用MTS,這意味著根對象必須使用ObjectContext對象的CreateInstance方法建立子物件。現在COM+已經使MTS和COM編程模型成為一體,不再需要CreateInstame方法,子物件能用Visual Basic 中的CreateObject函數或Visual C++中的C o CreateInstance函數建立。
    COM+事務從不跨越活動,但活動與COM+事務不總是一一對應的關係。單個活動可能會有幾個COM+事務。如果一個COM+對象執行個體化一個Transaction Support屬性為Requires New的COM+組件,這個新的對象將在同一活動中,但是在不同的COM+事務中,這個事務完全獨立於建立者的事務。事務之間的關係如圖1 9 - 11所示。

    通常由COM+運行期自動建立物理和邏輯事務, COM+也允許開發人員在已存在的MSDTC (物理的)事務中建立COM+對象。這個特徵被恰當地稱為“帶著自己的事務” ( BringYour Own Transaction,BYOT )。開發事務性組件時,這個特徵給開發人員提供了更多的靈活性,同時仍然能利用COM+的簡單性和邏輯事務模型。有了BYOT,組件能有效地應用MS DTC和COM+編程模型的組合來虛擬地完成任何事務任務。BYOT的典型用途是建立具有不同屬性的MS DTC 事務,例如低於可序列化的隔離等級,然後在物理事務中建立一個或更多的COM+組件。
    2. 建立與Resource Manager的串連
    建立了邏輯事務和基本的MS DTC(物理的)事務後, COM+必須確保所有由C++對象執行的對資料來源的資料修改操作在MS DTC(物理的)事務中執行。每個資料來源的每個串連必須從徵募到或註冊到MS DTC事務。
    一旦這樣做了,所有的操作都通過此串連執行並由MS DTC監控。雖然對每個串連的整個徵募過程由COM+在幕後完成,但是必須明白在事務的整個生存期中如何完成這一重要步驟的細節。
    Resource Manager(RM)是資料庫伺服器的一部分,它使用COM+管理持久的資料。因此對特定的資料來源的串連事實上僅是對Resource Manager的串連。但是,COM+事務模型在分布式的事務體繫結構中增加一個軟體層,稱為Resource Dispenser (RD)。
    不要把Resource Manager和Resource Dispenser混淆,他們是在COM+事務模型中用於不同目的的兩個不同的軟體組件。
    Resource Manager是一個簡單的系統服務。例如資料庫系統,它在分散式交易中管理著持久性資源。
    MS DTC利用Resource Manager協調事務的提交和復原,這通過使用兩階段交易認可協議實現。Resource Manager的例子包括:SQL Server,Oracle和MSMQ等。
    另一方面, Resource Manager 是一個進程內的動態連結程式庫,它管理存入Resource Manager的記憶體中的非持久的或臨時的資源。例如資料來源串連、網路連接、線程和記憶體資料區塊等。在系統出現故障時不需要保護這些共用資源。
    Resource Manager 能管理可再用資源的緩衝池,在事務中自動地徵募或註冊他們,為COM+對象提供針對這些資源的操作方法和介面。一個由Resource Manager管理的最普通的非持久性資源是與控制非揮發性儲存體的底層Resource Manager的串連。
    不要讓Resource Manager這個術語迷惑了。Resource Manager和用於訪問資源的組件是一樣的。例如, OLE DB服務元件總是駐留在使用ADO或OLE DB的客戶應用程式或者對象與OLE DB提供者及資料來源之間。COM+指定OLE DB服務元件作為Resource Manager,將資料
源作為Resource Manager。其關係如圖1 9 - 1 2所示。

    前面早已提到,作為Resource Manager,這些軟體組件負責管理非持久的資源。但是它們也能可選擇地提供兩個重要的服務:
    ? 資源緩衝資源緩衝是通過給COM+對象提供一個再迴圈的資源而不是建立新的資源,提供了一個有效地分配非持久性資源的方法。COM+對象使用完資源後,將資源放回緩衝池中,這樣它或其他的COM+對象可以立刻再使用這些資源。
    到資料來源(Resource Manager)的串連是所使用的非持久資源中最普通的一個。建立和取消一個到Resource Manager的串連是一個“昂貴”的過程。為了有效地給COM+對象提供資料來源串連,ODBC驅動程式管理器和OLE DB服務元件都提供Resource Manager串連的緩衝,昂貴資源的重用或迴圈對消耗這種資源的COM+對象或應用是完全透明的。
    ? 事務徵募事務徵募(enlistment )是關聯或徵募具有MS DTC(物理的)事務的Resource Dispenser的串連的過程。一旦完成事務徵募,所有的工作由COM+對象通過此串連執行,並且由MS DTC監視並在分布式的事務中得到保護。所有的操作將作為單一的工作單元執行,事務作為一個整體需要確定其ACID屬性。當邏輯事務完成時, MS DTC對所有參與的Resource Manager 執行兩階段交易認可協議。事務徵募是完全可選的, Resource Dispenser決定是否在當前事務中徵募資源。事務徵募通過簡化事務性COM+組件的開發在COM+事務中起著重要作用。
    COM+通過對組件隱藏分散式交易複雜的細節來完成任務。事實上,在事務生命期的此階段中,唯一要做的是建立與資料來源的串連,就像平常使用ADO、OLE DB和ODBC一樣。COM+和Resource Dispenser負責執行資源緩衝和事務徵募。
    3. 執行操作
    一旦建立資料庫連接, COM+對象能依靠Resource Manager開始執行操作。
    當Resource Manager接收和處理這些資料時,能採用相應的方法確保事務滿足ACID要求。許多Resource Manager實現一個日誌機制,提供復原未提交的變化的能力,滿足原子性的要求。通過再應用或恢複未預料問題引起的變化,日誌機制也允許Resource Manager確保事務的持久性。鎖用於隔離事務的變化,使其他針對同一Resource Manager的事務不受這些變化的影響。為確保一致性,Resource Manager通常定義特殊的機制或規則保護資料的完整性。
    4. 表決事務的結果
    前面已提到,事務性COM+對象的環境包含稱為Transaction ID的GUID值,它用於在事務中關聯多個對象,並將邏輯事務連結到底層的物理事務。然而,這僅是儲存在對象環境中的部分資訊。事務對象的環境也包含兩個其他的重要訊息,它們用於完成事務,表決事務是提交還是終止。這兩部分資訊是:
    ? 完成標誌(Done Bit) Done Bit是個布爾值,表明對象是否應該失效, TURE值顯示對象已經完成它的工作,且可以失效, FALSE (預設)值表明對象不能失效。
    在方法調用完成之前, COM+不檢測Done Bit的值。因此,Done Bit值能改變許多次,它的值在方法調用之後才有意義。Done Bit事實上是由J I T啟用提供的,所以,可用與非事務性組件相同的方法支援J I T啟用。
    ? 一致性標誌(Consistency Bit) Consistency Bit有時稱為“ Happy Bit”,它是一個布爾值,它顯示COM+對象決定是提交還是終止事務。TURE值顯示對象試圖提交事務, FALSE值顯示對象要強迫終止事務。
    對象失效(Done Bit 設定為TURE )後, Consistency Bit 才由COM+用於判斷。因此,Consistency Bit值可以重複地修改,甚至在不同的方法調用中也可以修改,因為只有對象失效前的最後值才是事務表決要用的。COM+用TURE值初始化Consistency Bit,即COM+假設事務是想提交的。
    Done Bit和Consistency Bit與事務的關係如圖1 9 - 1 3所示。

    當事務的根失效時(根對象的環境的Done Bit設定為TURE ),COM+在事務流中對每個環境的Consistency Bit賦值,來決定事務結果。試圖提交事務的決定是意見一致的決定。
    如果在事務中所有對象設定它們的環境的Consistency Bit為TURE,表決企圖提交事務,則在事務中執行的所有操作企圖進行永久性的提交。然而,如果事務中任何對象設定它的環境的Consistency Bit為FALSE,表決終止事務,則在事務中完成的所有操作將被復原。當這兩種情形的任一種發生時, COM+調用退出MS DTC,提交或終止這個物理事務。MS DTC然後通過使用兩階段交易認可協議負責與所有徵募的Resource Manager協調分散式交易的提交或終止過程。
    表1 9 - 2概述了Done Bit和Consistency Bit對COM+事務的結果的影響。

    我們瞭解了Done Bit和Consistency Bit取什麼值能夠提交或終止COM+事務。下面介紹如何檢索和修改它們的值。
    Object Context(或I ObjectContext )介面的方法可能是編程式控制制COM+事務結果的最容易的方式,因為這種方式允許調用單個方法同時設定Done Bit和Consistency Bit。由於DoneBit和Consistency Bit之間有四種可能的組合,所以存在由ObjectContext介面定義的四個方法,它們分別是: SetComplete、SetAbort、EnableCommit和DisableCommit。
    如表1 9 - 3所示,每一個對象環境的方法合相對應。與Done Bit和Consistency Bit值的一個獨特組合相對應。

    (1) SetComplete方法
    SetComplete方法告訴COM+,一個特定的工作單元已經成功地完成。通過設定Done Bit和Consistency Bit都為TURE,SetComplete方法強迫對象取消啟用並表決要提交事務。只有在根對象中調用SetComplete方法時,COM+才將在每個對象的環境中檢查Consistency Bit以決定事務結果。下列代碼例子展示了如何調用SetComplete方法:

    (2) SetAbort方法
    SetAbort方法告訴COM+,對象沒有成功地完成它的工作,它想終止事務。如果一個或多個的COM+對象在事務中調用SetAbort方法,由於SetAbort方法設定了Consistency Bit 為FALSE且Done Bit為TURE,整個事務將終止。

    (3) EnableCommit方法
    EnableCommit方法告訴COM+,對象能提交事務,但對象尚未被取消啟用。EnableCommit方法通過設定Consistency Bit為TURE且Done Bit為FALSE完成這一任務。

    (4) DisableCommit方法
    DisableCommit方法正好與EnableCommit方法相反。DisableCommit方法告訴COM+,對象的工作沒有完成,事務不能在當前提交,對象也不想取消啟用。DisableCommit方法設定對象環境的Consistency Bit和Done Bit都為FALSE。由於對象仍然啟用,在方法調用之間將保持其狀態:

    (5) 結束事務的其他方式
    大多數情況下,能通過ObjectContext介面顯式地控制事務結果,但還有另外兩種方式能結束COM+事務:
    ? 事務逾時( Transaction Timeout) 如果在事務中超過事務配置的逾時間隔值仍沒有活動,則結束當前事務。當一個事務逾時時,它將自動地終止。預設逾時間隔值是6 0秒。在元件服務瀏覽器中,這個值能在組件Properties對話方塊的Options選項卡中改變。如果你正調試事務性COM+對象,很明顯需要增加事務逾時間隔,以便有足夠的時間在COM+對象中單步調試方法調用,確保事務沒有自動終止。
    ? 客戶釋放所有對事務根的引用當客戶釋放對根對象的最後一個引用時, COM+隱含地試圖提交該事務。隱含的事務提交過程通常應該被避免,因為這會引起主機出現問題。
    隱含提交的一個問題是事務的結果不會通知給客戶。當根對象調用SetComplete方法時,COM+試圖在把控制返回給調用者之前提交該事務。如果提交事務時出現錯誤, COM+只是簡單地向用戶端發送一個錯誤訊息。這允許客戶應用程式很好地處理問題並且可能再次試著進行交易處理。然而,由於隱含提交時用戶端不再與根對象串連,因此如果不能提交事務,用戶端就不能接收錯誤資訊。客戶完全不知道事務的結果。
    隱含的事務提交過程還使得事務生存期比必要的時間長一些。當事務存在時,它保持著對資源的鎖,以確保ACID特性的隔離要求。一個開啟的、非活動的事務能阻止其他事務在這個資源上執行操作。這能引起效能瓶頸,嚴重限制了應用程式的可擴充性。一個更好的方法是調用ObjectContext的方法,顯式地提交或終止事務。
    5. 事務生存期小結
    事務在它的生存期中經曆的整個過程聽起來很複雜,重要的是記住,對參與事務的COM+組件的唯一要求是給它們配置相應的Transaction Support屬性。有許多不同的技術為提交或終止一個事務提供了靈活性,儘管現在理解它們還有一點困難,但它們使得開發基於組件的事務性系統更容易。
19.3.4 事務訪問自訂資源
    如何對沒有提供Resource Dispenser的資源進行事務性訪問?是否需要開發一個自訂的Resource Dispenser和Resource Manager?如果使用COM+,則什麼都不需要。
    COM+提供了一個新的特性,稱為補償資源管理員(Compensating Resource Manager,CRM),它提供了一個基礎結構來增強COM+對交易處理的支援能力。
    Compensating Resource Manager提供了一個簡單的方法,允許非事務性的資源參與由MS DTC管理的事務。
    在仍然使用MS DTC來協調事務時, CRM是開發一個複雜的COM+ Resource Manager和Resource Dispenser 的一個更簡單的選擇。例如,能開發CRM對諸如檔案系統、記憶體或Windows 2000註冊表等資源提供事務性訪問。事務性的COM+組件能通過CRM的介面訪問這
些資源,並且由CRM執行的所有操作都由一個MS DTC事務進行保護。
    另外,因為使用MS DTC 作為COM+ Resource Manager/Dispenser 和CompensatingResource Manager的事務協調器,所以一個單一的事務可以由一些針對資源的操作組成,這些資源可以是上述的任意結構。這個特性使Compensating Resource Manager成為能提供對資源的事務性訪問的最具有吸引力的解決方案之一。




相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。