总体来看，如果所有数据的修改仅依靠单个数据源就能完成，则这个事务就相当简单了。然而，随着商业需求的日益增加，应用程序变得越来越复杂，经常需要访问多个数据库，这些数据库通常分布在不同的地方，这就是分布式事务。分布式事务修改的数据存储在多个或多种类型的数据源中，这些数据源分布在多台机器上，甚至更复杂的情况。
    设想有一个事务，要求数据变化发生在两个分离的数据库中，仍然要求所有的ACID特性测试能够满足。基本的事务处理不能满足要求，因为如果其中一个数据库服务器失败，无法确保另外一个数据库的数据还没有提交并成为永久的。换句话说，无法协调发生在不同地方的多个事务处理就没有办法保证事务的原子性。
    例如，运行在机器A上的一个组件是单个事务的组成部分之一，组件能够利用机器B上的SQL Server执行数据库事务。组成事务的另一组件用运行在机器C上的Oracle服务器执行数据库事务。这三台机器运行着四块不同的代码，它们全都要参与到这个事务中。
    即使通过COM+隐藏分布式事务中的细节，也必要研究和了解分布式事务的“幕后”结构。请记住这些ACID特性适用于所有类型的事务，不论事务涉及的数据库是什么类型或数量有多少。
使用MS DTC进行两阶段提交
    让我们再看一下上述分布式事务的例子。如果Oracle服务器停机了，如何保证事务的原子性。答案是使用两阶段提交(two-phase commit，2PC)和通过Microsoft分布式事务协调器(MS DTC)协调。
    MSDTC是最先集成在SQL Server中，现在已成为COM+必不可少的部分，通过在事务处理中加入其他的因子，MS DTC确认所有的过程完成并提交他们。
    让我们进一步研究MS DTC，了解其工作方式。为了能用两阶段提交协议进行协调，事务中的每个数据源必须装有MS DTC。在这些安装中，主要的协调器总是在事务的起源之处。这个主要的协调器称为提交协调器，它负责确保事务的提交或终止。不管事务是成功地提交还
是回滚，提交协调器都负责向客户应用程序返回一个报告。
    在两阶段提交中第一阶段是准备阶段，每个服务器执行它接收的指令，但所有应写到磁盘的内容都被缓冲，如图1 9 - 1所示。

    一旦服务器已执行了指令，就通知提交协调器关于事务的状况，如图1 9 - 2所示。

    第二阶段称为提交阶段。如果提交协调器接收到来自每个数据源的“准备提交”通知，就提交事务，如图1 9 - 3。

    然而，如果从某一受影响的数据源接收到失败信息，提交协调器将执行回滚，并且通知客户应用程序，见图1 9 - 4。