dotNET和COM+中的事务的详细介绍
新事务之一: dotNET和COM+中的事务
小气的神
2002-4-16
Article Type: In-Depth
难度等级:6/9
版本:2.32
属性类 |
作用 |
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使用锁的行为。不同的隔离等级可能会带来不同的问题,比如:
本文地址:http://www.45fan.com/dnjc/69577.html