《ASP3高级编程》学习资料（讲稿）第十九章 ASP和事务性Web应用程序

下载 第19章ASP和事务性Web应用程序 在许多大型、关键的应用程序中,计算机每秒钟都在执行大量的任务。更为经常的不是 这些任务本身,而是将这些任务结合在一起完成一个业务要求,称为事务。如果能成功地执 行一个任务,而在第二个或第三个相关的任务中出现错误,将会发生什么?这个错误很可能 使系统处于不一致状态。这时事务变得非常重要,它能使系统摆脱这种不一致的状态。 Microsoft最初使用 Microsoft事务服务器(MTS)来处理事务。随着 Windows2000的发布 Microsoft进一步改进了MTS,使其成为COM+的一部分或组件服务。 本章讲述组件服务的事务性特性。了解它们如何用于支持在ⅡS上开发的应用程序的事务 本章的主要内容包括 事务处理的定义 事务处理的目的 在COM+中的事务处理如何工作 事务性ASP页面 首先,让我们看一看什么是事务处理 91事务处理的定义 本书已经介绍了许多涉及事务处理的概念,但是事务处理到底是什么。在大型机时代, 就有事务处理。用户信息控制系统(CICS)、 Tuxedo和 OpeNd等产品都是事务处理系统的例子, 它们为应用程序提供事务服务。 为了讨论事务处理,必须首先定义事务。 事务是一个最小的工作单元,不论成功与否都作为一个整体进行工作 不会有部分完成的事务。由于事务是由几个任务组成的,因此如果一个事务作为一个整 体是成功的,则事务中的每个任务都必须成功。如果事务中有一部分失败,则整修事务失败。 当事务失败时,系统返回到事务开始前的状态。这个取消所有变化的过程称为“回滚” ( rollback)。例如,如果一个事务成功更新了两个表,在更新第三个表时失败,则系统将两次 更新恢复原状,并返回到原始的状态 19.1.1保持应用程序的完整性 任何应用程序的关键是要确保它所执行的所有操作都是正确的,如果应用程序仅仅是部 分地完成操作,那么应用程序中的数据,甚至整个系统将会处于不一致状态。例如,看一下 银行转账的例子,如果从一个帐户中提出钱,而在钱到达另一个帐户前出错,那么在此应用 程序中的数据是错误的,而且失去了它的完整性,也就是说钱会莫名其妙地消失 克服这种错误有两种方法 在传统的编程模型中,开发者必须防止任何方式的操作失败。对任何失败点,开发者必

下载 第19章 ASP和事务性Web应用程序 在许多大型、关键的应用程序中，计算机每秒钟都在执行大量的任务。更为经常的不是 这些任务本身，而是将这些任务结合在一起完成一个业务要求，称为事务。如果能成功地执 行一个任务，而在第二个或第三个相关的任务中出现错误，将会发生什么？这个错误很可能 使系统处于不一致状态。这时事务变得非常重要，它能使系统摆脱这种不一致的状态。 M i c r o s o f t最初使用M i c r o s o f t事务服务器 ( M T S )来处理事务。随着 Windows 2000的发布， M i c r o s o f t进一步改进了M T S，使其成为C O M +的一部分或组件服务。 本章讲述组件服务的事务性特性。了解它们如何用于支持在 I I S上开发的应用程序的事务。 本章的主要内容包括： • 事务处理的定义。 • 事务处理的目的。 • 在C O M +中的事务处理如何工作。 • 事务性A S P页面。 首先，让我们看一看什么是事务处理。 19.1 事务处理的定义 本书已经介绍了许多涉及事务处理的概念，但是事务处理到底是什么。在大型机时代， 就有事务处理。用户信息控制系统 ( C I C S )、Tu x e d o和To p E n d等产品都是事务处理系统的例子， 它们为应用程序提供事务服务。 为了讨论事务处理，必须首先定义事务。 事务是一个最小的工作单元，不论成功与否都作为一个整体进行工作。 不会有部分完成的事务。由于事务是由几个任务组成的，因此如果一个事务作为一个整 体是成功的，则事务中的每个任务都必须成功。如果事务中有一部分失败，则整修事务失败。 当事务失败时，系统返回到事务开始前的状态。这个取消所有变化的过程称为“回滚” ( r o l l b a c k )。例如，如果一个事务成功更新了两个表，在更新第三个表时失败，则系统将两次 更新恢复原状，并返回到原始的状态。 19.1.1 保持应用程序的完整性 任何应用程序的关键是要确保它所执行的所有操作都是正确的，如果应用程序仅仅是部 分地完成操作，那么应用程序中的数据，甚至整个系统将会处于不一致状态。例如，看一下 银行转账的例子，如果从一个帐户中提出钱，而在钱到达另一个帐户前出错，那么在此应用 程序中的数据是错误的，而且失去了它的完整性，也就是说钱会莫名其妙地消失。 克服这种错误有两种方法： • 在传统的编程模型中，开发者必须防止任何方式的操作失败。对任何失败点，开发者必

Cac0N06559 须加上支持应用程序返回到这一操作开始前的状态的措施。换句话说,开发者必须加入 代码使系统能够在操作岀现错误时恢复原状(撤消)。 ·更为简单的方法是在事务处理系统的环境之内进行操作,事务处理系统的任务就是保证 整个事务或者完全成功,或者什么也不做。如果事务的所有任务都成功地完成,那么在 应用程序中的变化就提交给系统,系统就处理下一个事务或任务。如果操作中某一部分 不能成功地完成,这将使系统处于无效的状态,应回滚系统的变化,并使应用程序返回 到原来的状态。 事务处理系统的能力就是将完成这些操作的知识嵌入到系统本身。开发者不必为将系统 恢复原状编写代码,需要做的只是告诉系统执行任务是否成功,剩下的事情由事务处理系统 自动完成。 在帮助开发人员解决复杂的问题时,事务处理系统的另一好处是其ACID属性 191.2AC|D属性 当事务处理系统创建事务时,将确保事务有某些特性。组件的开发者们假设事务的特性 应该是一些不需要他们亲自管理的特性。这些特性称为ACID特性 ACID就是:原子性( Atomicity)、一致性( Consistency)、隔离性( Isolation)和持久性 (Durabilily) 原子性 原子性属性用于标识事务是否完全地完成,一个事务的任何更新要在系统上完全完成, 如果由于某种原因出错,事务不能完成它的全部任务,系统将返回到事务开始前的状态。 让我们再看一下银行转帐的例子。如果在转帐的过程中出现错误,整个事务将会回滚 只有当事务中的所有部分都成功执行了,才将事务写入磁盘并使变化永久化。 为了提供回滚或者撤消未提交的变化的能力,许多数据源采用日志机制。例如, SQL Server使用一个预写事务日志,在将数据应用于(或提交到)实际数据页面前,先 写在事务日志上。但是,其他一些数据源不是关系型数据库管理系统( RDBMS),它 们管理未提交事务的方式完全不同。只要事务回滚时,数据源可以撤消所有未提交 的改变,那么这种技术应该可用于管理事务。 2.一致性 事务在系统完整性中实施一致性,这通过保证系统的任何事务最后都处于有效状态来实 。如果事务成功地完成,那么系统中所有变化将正确地应用,系统处于有效状态。如果在 事务中出现错误,那么系统中的所有变化将自动地回滚,系统返回到原始状态。因为事务开 始时系统处于一致状态,所以现在系统仍然处于一致状态 再让我们回头看一下银行转帐的例子,在帐户转换和资金转移前,帐户处于有效状态。 如果事务成功地完成,并且提交事务,则帐户处于新的有效的状态。如果事务出错,终止后, 帐户返回到原先的有效状态 记住,事务不负责实施数据完整性,而仅仅负责在事务提交或终止以后确保数据返回到 致状态。理解数据完整性规则并写代码实现完整性的重任通常落在开发者肩上,他们根据 业务要求进行设计

须加上支持应用程序返回到这一操作开始前的状态的措施。换句话说，开发者必须加入 代码使系统能够在操作出现错误时恢复原状 (撤消)。 • 更为简单的方法是在事务处理系统的环境之内进行操作，事务处理系统的任务就是保证 整个事务或者完全成功，或者什么也不做。如果事务的所有任务都成功地完成，那么在 应用程序中的变化就提交给系统，系统就处理下一个事务或任务。如果操作中某一部分 不能成功地完成，这将使系统处于无效的状态，应回滚系统的变化，并使应用程序返回 到原来的状态。 事务处理系统的能力就是将完成这些操作的知识嵌入到系统本身。开发者不必为将系统 恢复原状编写代码，需要做的只是告诉系统执行任务是否成功，剩下的事情由事务处理系统 自动完成。 在帮助开发人员解决复杂的问题时，事务处理系统的另一好处是其 A C I D属性。 19.1.2 ACID属性 当事务处理系统创建事务时，将确保事务有某些特性。组件的开发者们假设事务的特性 应该是一些不需要他们亲自管理的特性。这些特性称为 A C I D特性。 A C I D就是：原子性 ( A t o m i c i t y )、一致性 ( C o n s i s t e n c y )、隔离性 ( I s o l a t i o n )和持久性 ( D u r a b i l i l y )。 1. 原子性 原子性属性用于标识事务是否完全地完成，一个事务的任何更新要在系统上完全完成， 如果由于某种原因出错，事务不能完成它的全部任务，系统将返回到事务开始前的状态。 让我们再看一下银行转帐的例子。如果在转帐的过程中出现错误，整个事务将会回滚。 只有当事务中的所有部分都成功执行了，才将事务写入磁盘并使变化永久化。 为了提供回滚或者撤消未提交的变化的能力，许多数据源采用日志机制。例如， SQL Server使用一个预写事务日志，在将数据应用于 (或提交到)实际数据页面前，先 写在事务日志上。但是，其他一些数据源不是关系型数据库管理系统 ( R D B M S )，它 们管理未提交事务的方式完全不同。只要事务回滚时，数据源可以撤消所有未提交 的改变，那么这种技术应该可用于管理事务。 2. 一致性 事务在系统完整性中实施一致性，这通过保证系统的任何事务最后都处于有效状态来实 现。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在 事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。因为事务开 始时系统处于一致状态，所以现在系统仍然处于一致状态。 再让我们回头看一下银行转帐的例子，在帐户转换和资金转移前，帐户处于有效状态。 如果事务成功地完成，并且提交事务，则帐户处于新的有效的状态。如果事务出错，终止后， 帐户返回到原先的有效状态。 记住，事务不负责实施数据完整性，而仅仅负责在事务提交或终止以后确保数据返回到 一致状态。理解数据完整性规则并写代码实现完整性的重任通常落在开发者肩上，他们根据 业务要求进行设计。 第1 9章 A S P和事务性We b应用程序计计559 下载

560Ap高程 Cha°bub.com 下载 当许多用户同时使用和修改同样的数据时,事务必须保持其数据的完整性和 致性。因此我们进一步研究ACID特性中的下一个特性:隔离性 3.隔离性 在隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事 务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只 有该事务在使用系统 这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化 请求,使得在同一时间仅有一个请求用于同一数据 重要的是,在隔离状态执行事务,系统的状态有可能是不一致的,在结束事务前,应确 保系统处于一致状态。但是在每个单独的事务中,系统的状态可能会发生变化。如果事务不 是在隔离状态运行,它就可能从系统中访问数据,而系统可能处于不一致状态。通过提供事 务隔离,可以阻止这类事件的发生。 在银行的示例中,这意味着在这个系统内,其他过程和事务在我们的事务完成前看不到 我们的事务引起的任何变化,这对于终止的情况非常重要。如果有另一个过程根据帐户余额 进行相应处理,而它在我们的事务完成前就能看到它造成的变化,那么这个过程的决策可能 建立在错误的数据之上,因为我们的事务可能终止。这就是说明了为什么事务产生的变化, 直到事务完成,才对系统的其他部分可见。 隔离性不仅仅保证多个事务不能同时修改相同数据,而且能够保证事务操作产生的变化 直到变化被提交或终止时才能对另一个事务可见,并发的事务彼此之间毫无影响。这就意味 着所有要求修改或读取的数据已经被锁定在事务中,直到事务完成才能释放。大多数数据库, 例如 SQL Server以及其他的 RDBMS,通过使用锁定来实现隔离,事务中涉及的各个数据项或 数据集使用锁定来防止并发访问 4.持久性 持久性意味着一旦事务执行成功,在系统中产生的所有变化将是永久的。应该存在一些 检查点防止在系统失败时丢失信息。甚至硬件本身失败,系统的状态仍能通过在日志中记录 事务完成的任务进行重建。持久性的概念允许开发者认为不管系统以后发生了什么变化,完 成的事务是系统永久的部分。 在银行的例子中,资金的转移是永久的,一直保持在系统中。这听起来似乎简单,但这, 依赖于将数据写入磁盘,特别需要指出的是,在事务完全完成并提交后才写入磁盘的。 所有这些事务特性,不管其内部如何关联,仅仅是保证从事务开始到事务完成,不管事 务成功与否,都能正确地管理事务涉及的数据 192分布式事务 总体来看,如果所有数据的修改仅依靠单个数据源就能完成,则这个事务就相当简单了。 然而,随着商业需求的日益增加,应用程序变得越来越复杂,经常需要访问多个数据库,这 些数据库通常分布在不同的地方,这就是分布式事务。分布式事务修改的数据存储在多个或 多种类型的数据源中,这些数据源分布在多台机器上,甚至更复杂的情况 设想有一个事务,要求数据变化发生在两个分离的数据库中,仍然要求所有的ACID特性

当许多用户同时使用和修改同样的数据时，事务必须保持其数据的完整性和一 致性。因此我们进一步研究A C I D特性中的下一个特性：隔离性。 3. 隔离性 在隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事 务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只 有该事务在使用系统。 这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化 请求，使得在同一时间仅有一个请求用于同一数据。 重要的是，在隔离状态执行事务，系统的状态有可能是不一致的，在结束事务前，应确 保系统处于一致状态。但是在每个单独的事务中，系统的状态可能会发生变化。如果事务不 是在隔离状态运行，它就可能从系统中访问数据，而系统可能处于不一致状态。通过提供事 务隔离，可以阻止这类事件的发生。 在银行的示例中，这意味着在这个系统内，其他过程和事务在我们的事务完成前看不到 我们的事务引起的任何变化，这对于终止的情况非常重要。如果有另一个过程根据帐户余额 进行相应处理，而它在我们的事务完成前就能看到它造成的变化，那么这个过程的决策可能 建立在错误的数据之上，因为我们的事务可能终止。这就是说明了为什么事务产生的变化， 直到事务完成，才对系统的其他部分可见。 隔离性不仅仅保证多个事务不能同时修改相同数据，而且能够保证事务操作产生的变化 直到变化被提交或终止时才能对另一个事务可见，并发的事务彼此之间毫无影响。这就意味 着所有要求修改或读取的数据已经被锁定在事务中，直到事务完成才能释放。大多数数据库， 例如SQL Server以及其他的R D B M S，通过使用锁定来实现隔离，事务中涉及的各个数据项或 数据集使用锁定来防止并发访问。 4. 持久性 持久性意味着一旦事务执行成功，在系统中产生的所有变化将是永久的。应该存在一些 检查点防止在系统失败时丢失信息。甚至硬件本身失败，系统的状态仍能通过在日志中记录 事务完成的任务进行重建。持久性的概念允许开发者认为不管系统以后发生了什么变化，完 成的事务是系统永久的部分。 在银行的例子中，资金的转移是永久的，一直保持在系统中。这听起来似乎简单，但这， 依赖于将数据写入磁盘，特别需要指出的是，在事务完全完成并提交后才写入磁盘的。 所有这些事务特性，不管其内部如何关联，仅仅是保证从事务开始到事务完成，不管事 务成功与否，都能正确地管理事务涉及的数据。 19.2 分布式事务 总体来看，如果所有数据的修改仅依靠单个数据源就能完成，则这个事务就相当简单了。 然而，随着商业需求的日益增加，应用程序变得越来越复杂，经常需要访问多个数据库，这 些数据库通常分布在不同的地方，这就是分布式事务。分布式事务修改的数据存储在多个或 多种类型的数据源中，这些数据源分布在多台机器上，甚至更复杂的情况。 设想有一个事务，要求数据变化发生在两个分离的数据库中，仍然要求所有的 A C I D特性 560计计ASP 3 高级编程 下载

china-pub.com 载 第9章4)和务丝b应用程序561 测试能够满足。基本的事务处理不能满足要求,因为如果其中一个数据库服务器失败,无法 确保另外一个数据库的数据还没有提交并成为永久的。换句话说,无法协调发生在不同地方 的多个事务处理就没有办法保证事务的原子性 例如,运行在机器A上的一个组件是单个事务的组成部分之一,组件能够利用机器B上的 QL Server执行数据库事务。组成事务的另一组件用运行在机器C上的 Oracle服务器执行数据 库事务。这三台机器运行着四块不同的代码,它们全都要参与到这个事务中 即使通过COM+隐藏分布式事务中的细节,也必要研究和了解分布式事务的“幕后”结 构。请记住这些ACID特性适用于所有类型的事务,不论事务涉及的数据库是什么类型或数量 有多少 使用 MS DTC进行两阶段提交 让我们再看一下上述分布式事务的例子。如果 Oracle服务器停机了,如何保证事务的原子 性。答案是使用两阶段提交(two- phase commit.,2PC)和通过 Microsoft分布式事务协调器(MS DTC协调。 MS DTC是最先集成在 SQL Server中,现在已成为COM+必不可少的部分,通过在事务处 理中加入其他的因子, MS DTC确认所有的过程完成并提交他们 让我们进一步研究 MS DTC,了解其工作方式。为了能用两阶段提交协议进行协调,事务 中的每个数据源必须装有 MS DTC。在这些安装中,主要的协调器总是在事务的起源之处。这 个主要的协调器称为提交协调器,它负责确保事务的提交或终止。不管事务是成功地提交还 是回滚,提交协调器都负责向客户应用程序返回一个报告。 在两阶段提交中第一阶段是准备阶段,每个服务器执行它接收的指令,但所有应写到磁 盘的内容都被缓冲,如图19-1所示 旦服务器已执行了指令,就通知提交协调器关于事务的状况,如图192所示。 插入 准备 事务开始 事务执行閤 提交 准备 提交协调器 提交协调器anc 提交 图19-1准备阶段 图19-2通知提交协调器关于事务的状况 提交 提交 更新成功 滚到原始状态 提交 终止 提交协调器 提交协调器 图19-3提交协调器提交事务 图19-4事务回滚

测试能够满足。基本的事务处理不能满足要求，因为如果其中一个数据库服务器失败，无法 确保另外一个数据库的数据还没有提交并成为永久的。换句话说，无法协调发生在不同地方 的多个事务处理就没有办法保证事务的原子性。 例如，运行在机器A上的一个组件是单个事务的组成部分之一，组件能够利用机器 B上的 SQL Server执行数据库事务。组成事务的另一组件用运行在机器 C上的O r a c l e服务器执行数据 库事务。这三台机器运行着四块不同的代码，它们全都要参与到这个事务中。 即使通过C O M +隐藏分布式事务中的细节，也必要研究和了解分布式事务的“幕后”结 构。请记住这些A C I D特性适用于所有类型的事务，不论事务涉及的数据库是什么类型或数量 有多少。 使用MS DTC进行两阶段提交 让我们再看一下上述分布式事务的例子。如果 O r a c l e服务器停机了，如何保证事务的原子 性。答案是使用两阶段提交 (two-phase commit，2 P C )和通过M i c r o s o f t分布式事务协调器 ( M S D T C )协调。 MS DTC是最先集成在SQL Server中，现在已成为C O M +必不可少的部分，通过在事务处 理中加入其他的因子，MS DTC确认所有的过程完成并提交他们。 让我们进一步研究MS DTC，了解其工作方式。为了能用两阶段提交协议进行协调，事务 中的每个数据源必须装有MS DTC。在这些安装中，主要的协调器总是在事务的起源之处。这 个主要的协调器称为提交协调器，它负责确保事务的提交或终止。不管事务是成功地提交还 是回滚，提交协调器都负责向客户应用程序返回一个报告。 在两阶段提交中第一阶段是准备阶段，每个服务器执行它接收的指令，但所有应写到磁 盘的内容都被缓冲，如图1 9 - 1所示。 一旦服务器已执行了指令，就通知提交协调器关于事务的状况，如图 1 9 - 2所示。 第1 9章 A S P和事务性We b应用程序计计561 下载 图19-1 准备阶段 图19-2 通知提交协调器关于事务的状况 图19-3 提交协调器提交事务 图19-4 事务回滚 事务开始 更新成功 提交 提交 终止 回滚到原始状态 提交 事务执行 插入 更新 准备 提交 准备 提交 插入 更新 提交协调器 提交协调器 提交协调器 提交协调器

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 高级编程 下载