dotNET和COM+中的事務（2）

 
首頁
新事務之一： dotNET和COM+中的事務（2）
新事務之一： dotNET和COM+中的事務

 

--------------------------------------------------------------------------------

小氣的神

2002-4-16

 

Article Type: In-Depth 

難度等級：6/9       

版本：2.32

CLR中和事務相關的屬性類

屬性類
 作用
 
AutoCompleteAttribute
 函數內自動完成聲明的事務
 
ConstructionEnabledAttribute
 添加construct 字串
 
JustInTimeActivationAttribute
 即時啟用
 
ObjectPoolingAttribute
 對象池
 
TransactionAttribute
 聲明事務
 

 

CLR中和事務有關的方法和屬性

屬性和方法
 介面和方法
 
DisableCommit
 IObjectControl::DisableCommit
 
EnableCommit
 IObjectControl::EnableCommit
 
SetAbort
 IObjectControl::SetAbort
 
SetComplete
 IObjectControl::SetComplete
 
IsInTransaction
 IObjectContextInfo::IsInTransaction
 
MyTransactionVote
 IContextState::Get/SetMyTransactionVote
 
DeactivateOnReturn
 IContextState::Get/StateDeactivateOnReturn
 
Transaction
 IObjectContextInfo::GetTransaction
 
TransactionId
 IObjectContextInfo::GetTransactionId
 
ContextId
 IObjectContextInfo::GetContextId
 

 

當然在上面的類中我們也可以不加任何的屬性控制，只是簡單從ServicedComponent繼承一個類，那麼當我們用Regsvcs向COM+註冊我們的組件成功後，COM+設定中依然有一些預設的值，或是我們使用了屬性但沒有明確的指明屬性的值。這些是由System.EnterpriseServices.RegistrationHelper來完成的，事實上Regsvcs在調用完Regasm和Tlbexp之後就調用了它完成在COM+ Catalogs的註冊。

 

下表是CLR中類編譯之後的屬性（配置和沒有配置）

屬性
 適用範圍
 沒有配置屬性時在COM+中的值
 使用屬性配置但沒有顯示指明屬性在COM+中的值
 
ApplicationActivation
 Assembly
 Library
 No default
 
ApplicationID
 Assembly
 Generated GUID
 No default
 
ApplicationName
 Assembly
 Assembly name
 No default
 
AutoComplete
 Method
 False
 True
 
ConstructionEnabled
 Class
 False
 True
 
JustInTimeActivation
 Class
 False
 True
 
MustRunInClientContext
 Class
 False
 True
 
ObjectPooling
 Class
 False
 True
 
Synchronization
 Class
 False
 SynchronizationOption.Required
 
Transaction
 Class
 False
 TransactionOption.Required

TransactionIsolationLevel.Serializable

Timeout = infinite
 

 

從上面看得出屬性編程給我們帶來的方便和簡捷的感覺，比起以前COM方式下的COM+編程方便了許多，不用太多的引用、不用考慮線程的同步、甚至登記到COM+環境中也相當容易。但只能說，如果以前你在COM下工作得不錯，現在你這CLR下也可以工作的很好或更好，COM+以及事務編程模型仍然沒有改變，從實際需要和應用中分析和構造出事務模型依然還是每個開發人員主要的任務，不過現在你可以有更多的時間和精力來應對這個問題了。

 

 

Windows XP和Windows.NET中的可配置事務隔離層（Configurable Transaction Isolation Level）

 

Windows XP 和Widnows.NET的COM+環境下允許我們指定事務隔離等級.

 

這的確是一個盼望已久的新特性，COM+ 1.0中我們只能使用預設的也是最嚴格的事務隔離等級：Serializable。在Windows XP和Windows.NET中的COM+允許我們指定組件的事務隔離等級，可以由開發人員和實際應用決定使用何種隔離等級。不是所有的RM（resource managers）都支援目前的定義的四個隔離等級，可能的一個策略是當RM不支援當前的隔離設定那麼使用一個更高的隔離等級，Serializable是最嚴格的隔離等級，同時也是最普通的一個隔離等級，那麼也就是說幾乎所有的RM都支援這個隔離等級設定（目前COM+支援的四個隔離等級也是MS SQL Server都支援和實現的也是SQL－92定義的四個）。同樣也不是所有的開發人員都明白這些選項的作用和含義。下面會給出一些通常的解釋和資訊以便在未來的開發過程中作出選擇。

 

多個使用者對資料庫操作就可能產生資料不一致的情況了，隔離等級就是說事務可以接受不一致資料的程度，是一個事務與其他事務隔離的程度。較低的隔離等級可以增加並發，但代價是降低資料的正確性。相反，較高的隔離等級可以確保資料的正確性，但可能對並發產生負面影響。我們在COM+中要求的隔離等級確定了RM使用鎖的行為。不同的隔離等級可能會帶來不同的問題，比如：

問題
 描述
 執行個體
 
髒讀

Dirty read
 也叫未提交讀或未確認讀。一個事務修改了資料庫但未提交或確認，此時另一個事務讀取這個值，並且拿去操作。
 原來小明的帳戶有1元，A負責存入，B負責劃帳，那麼A先存入20元但未提交，此時B讀取這20元，然後划去5元，A失敗復原事務，B則將15元存入資料庫，完成事務。而小明就開心壞了。
 
不可重讀

Nonrepeatable read
 也叫不一致讀或不可再讀。一個事務讀取了某個值，當它下次再讀時這個值變化了，而修改不是它主導的，顯然是其他事務操作了
 這次B學聰明了，在第一次獲得20元的資訊之後先減去自己的5元，然後沒有立即更新資料庫，又去查了一次資料庫，而原先的20現在變成了50，三秒之後B發現已經是10了，所以B很納悶：不是我負責劃帳的嗎？
 
幻影

Phantom
 是指對同一資料庫的兩次讀操作中發現出現一組新的資料。與不可重讀的區別是，不可重讀是對現有資料的修改或覆蓋，沒有增加或減少資料，幻影則是插入了先前沒有的資料或刪除了原先已有的資料。
 B有時也負責向小明報告他最新的存款情況，雖然昨天沒睡好，但是B仍然進行了統計，他發現第一次統計時A有5筆記錄自己有10筆，第二次查詢確認時發現A增加了3筆共有8筆自己少了月初的一筆成了9筆，B想自己應該休息一會再統計一次，儘管少了月初的一筆有些奇怪，但如果結果是A的總數大於自己的，那小明對他的存款還是會有信心的
 

下面的表是設定不同的隔離選項對並發發生的問題接受程度，看得出Serializable 最嚴格，三種可能的錯誤都不會發生。COM+按其順序依次認為它們從低到高隔離值從小到大，Read uncommitted最小，Serializable最大。

Isolation level
 發生髒讀
 發生不可重讀
 發生幻影
 
Read uncommitted
 Yes
 Yes
 Yes
 
Read committed
 No
 Yes
 Yes
 
Repeatable read
 No
 No
 Yes
 
Serializable
 No
 No
 No
 

 

（未完） 

--------------------------------------------------------------------------------

特別：

本文CSDN署名首發，轉載或改編請註明作者和出處。如果有問題，請發電子郵件給new2001@msn.com

以上文字和圖片涉及其他人的隱私和個人權利，所有文字和圖片只用於內部交流，不作任何新聞發表和商業用途。

 

--------------------------------------------------------------------------------
Copyright ?2005 china.udotnet.COM