事务性COM+应用程序

在前几章我们已经看到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的对象可以共享创建者的环境。not supported是缺省的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从执行这项任务中解除一个管理者时，可以减少不正确地配置组件的危险。然而，记住在组件的类型库中指定的transaction support属性是一个缺省值，可以使用组件服务浏览器覆盖该值，这一点是很重要的。
在使用组件服务浏览器对一个组件的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属性，为组件的transaction support属性设置指定一个缺省值。不要让这个属性的名称欺骗了你，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关键字(及某些表达式)，或者visual c++客户使用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+也允许开发者在已存在的ms dtc (物理的)事务中创建com+对象。这个特征被恰当地称为“带着自己的事务” ( bring your 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 和compensating resource manager的事务协调器，所以一个单一的事务可以由一些针对资源的操作组成，这些资源可以是上述的任意结构。这个特性使compensating resource manager成为能提供对资源的事务性访问的最具有吸引力的解决方案之一。