ManualTxn_COM+_IP 產生的 COM+ 相互操作非常少,因為此方法不使用任何 COM+ 服務,這也是它和 ManualTxn 具有非常類似的行為的原因,在 ManualTxn 中,根本沒有涉及到 COM+。
如果將 ManualTxn 和 ManualTxn_COM+_IP 與 AutomaticTxn_IP 進行比較,您會發現自動事務處理平均要慢約 30%。這是因為使用分布式事務協調器 (DTC) 設置事務處理的成本要比在事務處理中完成所有工作(11 次插入)的成本大。AutomaticTxn_IP 還涉及到一個上下文方法調用,需要進行上下文轉換,因而產生了額外的成本。
AutomaticTxn_IP 提供的性能比 ManualTxn_COM+_OP 和 AutomaticTxn_OP 要好,因為 AutomaticTxn_IP 中的庫程序包可以使程序集在調用應用程序進程(本例中是 aspnet_wp.exe)內部運行,從而避免了封送處理。因為無需數據封送,AutomaticTxn_IP 中的總體成本(包括 DTC 成本)要比 ManualTxn_COM+_OP 少,這也是 AutomaticTxn_IP 在性能方面比 ManualTxn_COM+_OP 略勝一籌的原因。
可以看到,AutoCompleteTxn_IP 和 AutoCompleteTxn_OP AutoComplete 版本分別與 AutomaticTxn_IP 和 AutomaticTxn_OP 版本的運行狀況類似。使用 AutoComplete 提交的缺點是,它在方法成功返回并確定進行提交時,由于事務處理要釋放服務器資源而延長了時間,因而可能會降低應用程序的性能。另外,當事務處理失敗時,它不允許用戶在需要時發出用戶友好消息。
圖 2:InsertOrder_OpenXml(Order=1, Details=100)
當測試運行 1 個訂單和 100 個詳細信息時,各種方法之間幾乎沒有什么差別。
在吞吐量方面,數據庫事務處理模型仍然比其他方法略占一些優勢。
此測試中各個模型的性能都非常接近,這是因為在此事務處理中完成了大量工作(101 次插入)。這里的成本(例如進程間的 DTC 通信和數據封送)被分攤到整個事務處理過程中,因此變得不是那么明顯。
使用多個 DataAdapter 的 InsertOrder
在第二組測試中,我們為數據庫中的 Order 和 OrderDetails 表分別關聯了 DataAdapter。在 DataAdapter 上,為 InsertCommand 指定了存儲過程。首先調用與 Order 表對應的 DataAdapter 上的 Update 方法,它返回新插入訂單的 OrderId。然后調用與 OrderDetails 表對應的 DataAdapter 上的 Update 方法。因為 Update 方法不是以批處理方式向數據庫發送更改,因此這一技術使用了多次數據庫往返操作,以完成這些插入。
請參閱 Performance Comparison: Data Access Techniques(英文)一文,其中比較了各種數據訪問技術,包括 OPENXML 和多個 DataAdapter 方法。
測試首先運行 1 個訂單和 10 個詳細信息。
圖 3:InsertOrder_DataSet(Order=1, Details=10)
注意
在 ManualTxn 方法中,事務處理控件通過 ADO.NET SQLTransaction 對象來實現。
在 ManualTxn_COM+_IP 和 ManualTxn_COM+_OP 中,都是使用 ADO.NET SQLTransaction 對象來控制事務處理,而程序集則由 COM+ 分別配置為庫和服務器程序包。
包含 AutomaticTxn 和 AutCompleteTxn 實現的 .NET 程序集使用 COM+ 進行注冊。在 AutomaticTxn 中,我們顯式提交或中止事務處理,而在 AutoCompleteTxn 中,則由 .NET 程序集來確定提交或中止當前事務處理。
在 AutomaticTxn_IP 和 AutoCompleteTxn_IP 中,包含程序集的 COM+ 應用程序是一個由庫激活的應用程序,所以該應用程序在創建它的客戶端進程中運行。
在 AutomaticTxn_OP 和 AutoCompleteTxn_OP 中,包含程序集的 COM+ 應用程序是一個由服務器激活的應用程序,所以它在代理進程 (dllhost.exe) 中運行。
ManualTxn 和 ManualTxn_COM+_IP 的性能非常類似,這是因為與 COM+ 相互操作相關的成本很小。
原文轉自:http://www.uml.org.cn/Test/200505245.htm