562 SP3高级编程 Chinapub.com 下载 第二阶段称为提交阶段。如果提交协调器接收到来自每个数据源的“准备提交”通知, 就提交事务,如图19-3。 然而,如果从某一受影响的数据源接收到失败信息,提交协调器将执行回滚,并且通知 客户应用程序,见图19-4。 19.3事务性COM+应用程序 在前几章我们已经看到COM+提供的几种运行期特性,它们使得分布式组件的开发简单 化,这些组件可用于创建可扩展、可维护的ASP应用程序。MTS最先引进了事务模型,它的 设计简化了基于组件的分布式事务处理系统的开发。作为MTS的继承者,COM+增强并扩充 了MTS的强大的事务模型,给系统提供更多灵活性和简单化。 COM+事务模型去掉了复杂的事务处理代码,这些代码是通过 MS DTO协调分布式事务所 必需的。但是更重要的是,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+组件设计的,其结果是组件没第二阶段称为提交阶段。如果提交协调器接收到来自每个数据源的“准备提交”通知， 就提交事务，如图1 9 - 3。 然而，如果从某一受影响的数据源接收到失败信息，提交协调器将执行回滚，并且通知 客户应用程序，见图1 9 - 4。 19.3 事务性C O M +应用程序 在前几章我们已经看到 C O M +提供的几种运行期特性，它们使得分布式组件的开发简单 化，这些组件可用于创建可扩展、可维护的 A S P应用程序。M T S最先引进了事务模型，它的 设计简化了基于组件的分布式事务处理系统的开发。作为 M T S的继承者，C O M +增强并扩充 了M T S的强大的事务模型，给系统提供更多灵活性和简单化。 C O M +事务模型去掉了复杂的事务处理代码，这些代码是通过 MS DTC协调分布式事务所 必需的。但是更重要的是， C O M +事务模型透明地融合了分布式事务与 C O M +组件。 通过使用声明( d e c l a r a t i v e )属性实现的C O M +事务，有时也称为声明事务或自动事务。声 明属性能从外部指定到组件的实现。为此，必须： • 配置组件的Transaction Support属性，使用Component Services Explorer或者在组件类型 库中使用一个常数值。 • 可选修改组件来表决事务的结果。 通过代表组件与MS DTC交互，C O M +自动地处理其余的复杂且冗长的事务细节。 因为C O M +依赖于MS DTC协调事务，单个组件能够在单个 C O M +事务中对不同类型的数 据源执行操作。当与组件一起使用 C O M +声明事务时，能影响A D O或OLE DB数据访问。在单 个事务中能够操作的数据源的可能组合是无止境的。例如， C O M +对象能够在SQL Server数据 库中修改数据、发送 M S M Q消息，以及操作来自大型机系统的数据，所有这一切都在相同的 C O M +事务中。 现在我们明白了 C O M +事务的益处，下面继续学习如何有效地使用声明事务模型并了解 C O M +在“幕后”所做的事。 19.3.1 Transaction Support属性 正如上面提到的，每个 C O M +组件的 Transaction Support属性决定了组件将如何参与 C O M +事务。激活C O M +对象时，C O M +决定了对象的事务支持以及创造者是否已经提供了一 个存在的事务。基于这两方面的信息， C O M +运行期将在一个存在的事务或一个新的事务中 提供对象，或者根本不存在事务。不管有没有事务，都能激活每一个 C O M +对象。由于这个 原因，利用事务的组件常常被称为事务性组件，没有利用事务的组件则称为非事务性组件。 使用C O M +时有五种可能的Transaction Support属性选项： • 禁止( D i s a b l e d )当组件的Transaction Support属性设置为D i s a b l e d时，C O M +将完全地忽 略组件的事务要求。 C O M +首先试图在创建者的环境内激活对象。如果创建者的环境是 无效的或不兼容的， C O M +在一个新的环境中激活对象。由于对象可能继承或不继承创 建者的环境，则对象也就可能共享或不共享创建者的事务。 • 不支持(Not Supported)当组件的Transaction Support属性设置为Not Supported时，组件的 实例决不参与事务。这种设置是为不访问数据源的 C O M +组件设计的，其结果是组件没 562计计ASP 3 高级编程 下载