新事务之一： 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
以上文字和图片涉及其他人的隐私和个人权利，所有文字和图片只用于内部交流，不作任何新闻发表和商业用途。
