下载 第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 高级编程 下载
有事务开销。然而, 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+对象永远不会运行在创建者的事务中 新的事务完全独立于创建者的事务 设置 Transaction Support 组件的 Transaction Support属性可以使用组件服务浏览器 Component Services Explorer,CSE) 配置,或者在组件的类型库中指定一个缺省的 Transaction Support设置。在组件的类型库中指定 个组件的 Transaction Support属性是有益的,因为当使用CSE从执行这项任务中解除一个管理 者时,可以减少不正确地配置组件的危险。然而,记住在组件的类型库中指定的 Transaction Support属性是一个缺省值,可以使用组件服务浏览器覆盖该值,这一点是很重要的 在使用组件服务浏览器对一个组件的 Transaction Support属性进行配置时,简单地打开一 个COM+应用程序的 Component Properties对话框,从 Transactions选项卡中选择五种可能的 Transaction Support.属性设置中的一个,如图19-5所示 Genera Transactions I secuity Activ I Concurency Advan on suppot x Supported imported Regared r Overide global transaction timeou value Tranaction 图19-5设置 Transaction Support的界面
有事务开销。然而， Transaction Support属性为Not Supported的对象总是在一个新的环 境中被激活。这与 D i s a b l e d相矛盾， D i s a b l e d的对象可以共享创建者的环境。 N o t S u p p o r t e d是缺省的Transaction Support属性值。 • 支持( S u p p o r t e d )当组件的Transaction Support属性设置为S u p p o r t e d时，组件的实例参与 存在的事务。但是组件对事务并没有要求，组件在事务不存在的情况下仍能很好地执行。 S u p p o r t e d属性只是表示支持事务，而不是必须要求事务存在。 • 需要( R e q u i r e d )当组件的Transaction Support属性设置为R e q u i r e d时，组件的实例总是在 事务内执行。在激活 C O M +对象前，C O M +将使用创建者的事务 (如果存在)，或者新的 事务提供对象。不管哪种情况，组件实例总是在事务内执行。 • 需要新建(Requires New)当组件的Transaction Support属性设置为Requires New时，总是 在一个新的事务中激活组件的实例，即专为这个对象创建一个事务，而不管是否存在可 用的事务。这个设置为必须在事务中完成工作，但又必须把它的工作与所有其他的事务 分开的组件而设计的。使用这个设置时， C O M +对象永远不会运行在创建者的事务中。 新的事务完全独立于创建者的事务。 1. 设置Transaction Support 组件的Transaction Support属性可以使用组件服务浏览器(Component Services Explorer，CSE) 配置，或者在组件的类型库中指定一个缺省的Transaction Support设置。在组件的类型库中指定 一个组件的Transaction Support属性是有益的，因为当使用C S E从执行这项任务中解除一个管理 者时，可以减少不正确地配置组件的危险。然而，记住在组件的类型库中指定的 Tr a n s a c t i o n Support属性是一个缺省值，可以使用组件服务浏览器覆盖该值，这一点是很重要的。 在使用组件服务浏览器对一个组件的 Transaction Support属性进行配置时，简单地打开一 个C O M +应用程序的Component Properties对话框，从 Tr a n s a c t i o n s选项卡中选择五种可能的 Transaction Support属性设置中的一个，如图1 9 - 5所示。 图19-5 设置Transaction Support 的界面 第1 9章 A S P和事务性We b应用程序计计563 下载
564Asp高程 下载 如果使用的是C++,可以在组件类型库中为一个组件的 Transaction Support属性设置 个缺省值,可简单地通过在组件的接口定义语言(DL)的定义中增加相应的一行来实现。当该 组件被加到一个COM+的应用程序时,COM+读取类型库并且自动地使用存储于该类型库中的 Transaction Support,属性设置作为缺省值 Ⅴ isual basic6.0也允许开发者通过改变类模块的d MTSTransactionMode属性,为组件的 Transaction|ge Support属性设置指定一个缺省值。不要让这个属性的 名称欺骗了你, MTST ransaction Mode属性不但与MTS 一起工作,也和COM+一起工作。当编译一个项目时 isual basic将在组件的类型库中为 Transaction Suppor 属性的设置放置一个等价的常量值,如图196所示。 注意在 Visual basic中 MTSTransaction Mode值的技 术术语和组件服务浏览器中的术语是不完全相同的。图19.6设置 MTSTransaction mode 然而,不必担心,除了 Disabled(对COM+是新的)外, 属性的界面 每一个 Transaction Support属性级别都有一个对应的 MTSTransaction mode设置。表19-1中列了 所有可能的 MTSTransaction mode属性和他们的等价的COM+ Transaction Support属性 表19-1 MTSTransaction Mode属性与等价的cOM+ Transaction Support,属性的关系 MTSTransaction Mode属性 COM+ Transaction Support属性 0-NotAnMTSObject Not Suppored I-NoTransactions Not Suppored 3-Use Transaction Suppored 4-RequiresNewTransactions 当组件从 Registered Components列表中加入时,因为组件服务浏览器不读取 类型库,因此只要组件用 Add File对话框加到COM+应用程序中,就应用储存在组件 的类型库中的 Transaction Support属性设置。相反地,从 Registered Components 加入的COM+组件,如果不用组件服务浏览器修改它们的配置,则组件使用缺省的 Transaction Support属性配置,即 Not Supported 1932活动与同步 当事务处理系统为许多用户提供服务时,能从客户中接收同时发生的调用。因此,事务 处理系统必须考虑像多用户并发、同步和线程管理等问题。COM+能够处理这些问题,而且 允许创建在多用户分布式环境中执行的组件,其创建过程同创建为单个用户服务的组件一样 COM+通过使用活动( activity)来完成这个惊人的任务。在MTS中,活动是一个对象组,这 对象都在代表单个客户运行。在COM+中,活动是一个环境组,这些环境在代表单个客户 运行,环境可能含有一个或多个对象。然而,这仅是一个微小的差别,并且可以认为环境是 最内部的对象容器 活动确保服务于同一用户的两个对象不会同时执行。在一个活动中的对象被同步以阻止在这 个活动中并行地执行。活动可以由几个环境(包含着对象)组成,可以运行在分离的进程中,或者
如果使用的是V C + +，可以在组件类型库中为一个组件的 Transaction Support属性设置一 个缺省值，可简单地通过在组件的接口定义语言 ( I D L )的定义中增加相应的一行来实现。当该 组件被加到一个C O M +的应用程序时，C O M +读取类型库并且自动地使用存储于该类型库中的 Transaction Support属性设置作为缺省值。 Visual Basic 6.0也允许开发者通过改变类模块的 M T S Tr a n s a c t i o n M o d e属性，为组件的 Tr a n s a c t i o n S u p p o r t属性设置指定一个缺省值。不要让这个属性的 名称欺骗了你，MTST ransactionMode属性不但与M T S 一起工作，也和C O M +一起工作。当编译一个项目时， Visual Basic将在组件的类型库中为Transaction Support 属性的设置放置一个等价的常量值，如图1 9 - 6所示。 注意在Visual Basic中M T S Tr a n s a c t i o n M o d e值的技 术术语和组件服务浏览器中的术语是不完全相同的。 然而，不必担心，除了 D i s a b l e d (对C O M +是新的)外， 每一个Transaction Support属性级别都有一个对应的M T S Tr a n s a c t i o n M o d e设置。表1 9 - 1中列了 所有可能的M T S Tr a n s a c t i o n M o d e属性和他们的等价的C O M + Transaction Support属性。 表19-1 MTSTr a n s a c t i o n M o d e属性与等价的COM+ Transaction Support属性的关系 M T S Transaction Mode属性 COM+ Transaction Support属性 0－N o t A n M T S O b j e c t Not Suppored 1－N o Tr a n s a c t i o n s Not Suppored 2－R e q u i r e s Tr a n s a c t i o n R e q u i r e d 3－U s e Tr a n s a c t i o n S u p p o r e d 4－R e q u i r e s N e w Tr a n s a c t i o n s Requires New 当组件从Registered Components列表中加入时，因为组件服务浏览器不读取 类型库，因此只要组件用 Add File对话框加到C O M +应用程序中，就应用储存在组件 的类型库中的Transaction Support属性设置。相反地，从 Registered Components 加入的C O M +组件，如果不用组件服务浏览器修改它们的配置，则组件使用缺省的 Transaction Support属性配置，即Not Supported。 19.3.2 活动与同步 当事务处理系统为许多用户提供服务时，能从客户中接收同时发生的调用。因此，事务 处理系统必须考虑像多用户并发、同步和线程管理等问题。 C O M +能够处理这些问题，而且 允许创建在多用户分布式环境中执行的组件，其创建过程同创建为单个用户服务的组件一样。 C O M +通过使用活动( a c t i v i t y )来完成这个惊人的任务。在 M T S中，活动是一个对象组，这 些对象都在代表单个客户运行。在 C O M +中，活动是一个环境组，这些环境在代表单个客户 运行，环境可能含有一个或多个对象。然而，这仅是一个微小的差别，并且可以认为环境是 最内部的对象容器。 活动确保服务于同一用户的两个对象不会同时执行。在一个活动中的对象被同步以阻止在这 个活动中并行地执行。活动可以由几个环境(包含着对象)组成，可以运行在分离的进程中，或者 564计计ASP 3 高级编程 图19-6 设置M T S Tr a n s a c t i o n M o d e 属性的界面 下载
inapub.commi9sASRsstwrebsmeym565 运行在分离的机器上(稍微有一点限制)。由于这些原因,活动有时指的是运行的单个逻辑线程 为什么对象的同步如此重要?考虑一个最糟糕的情况,在完全相同的时刻,代表同一用 户服务的两个对象试图访问相同资源。每一个对象要完成自己的操作,就要阻塞其他对象的 运行。这种情况称为死锁。活动能防止发生死锁,这是通过每次只允许一个对象代表一个用 户运行来实现的。另外,活动在帮助COM+管理线程缓冲方面起着重要作用。 在MTS中,活动内对象的同步是通过将活动连接到单个物理线程,或是一个STA实施的 在一个活动中的对象不能并发执行,因为每个活动仅有一个物理线程。另外,COM+使用复 杂的锁定机制来确保活动中的同步。 每个活动保持着单一的独占锁。当在对象中调用一个方法并且对象的环境存在于一个活 动中时,在允许处理方法调用前,COM+首先要试图获得活动锁。如果获得锁,就由对象处 理调用,直到方法调用完成,才解除锁。如果不能获得锁,就阻塞方法调用,直到获得锁才 调用方法。虽然锁定过程更加复杂,但从高层次观点看,COM+使用逻辑的活动使得多个环 境和多个对象同步,基本上就是每一活动用一个单独的锁。使用锁的过程如图197所示。 COM+活动 ActivitylD=(JMC1150-514 Locked=True ActivityID=(JMCI150-514 环境 ActivityID=IJMC1150-514 图19-7使用锁的过程 环境能存在于创建者的活动或一个新的活动中或者根本没有活动。然而,单个环境不能 跨越多个活动。为了建立和保持这些关系,COM+为每个活动创建独特的用户标识符,称为 ActivityID,存储于每个环境中。 创建活动和 Synchronization属性 随着COM和MTS编程模型的集成,创建活动的方法也发生了改变。使用MTS,每个对象 属于一个活动。当ⅤB客户使用 CreateObject函数或New关键字(及某些表达式),或者 Visual C++客户使用 CoCreatelnstanceeX函数创建MTS对象时,自动地创建了活动。为了在已存在的 活动中创建对象,创建者必须调用 ObjectContext对象中的 Createlnstance函数 正如所想像的,这会导致大量的混乱,MTS的开发者必须意识到逻辑活动的边界,并且 恰当地使用标准的对象创建技术 Create Object or CocreatelnstanceEX)或者 ObjectContext对象 的 Createlnstance函数。 使用COM+,仍然能自动地创建活动,但是活动的创建是通过使用组件的 Synchronization 属性来控制的,而不是基于如何实例化一个组件。实际上, ObjectContext对象的 Createlnstance
运行在分离的机器上(稍微有一点限制)。由于这些原因，活动有时指的是运行的单个逻辑线程。 为什么对象的同步如此重要？考虑一个最糟糕的情况，在完全相同的时刻，代表同一用 户服务的两个对象试图访问相同资源。每一个对象要完成自己的操作，就要阻塞其他对象的 运行。这种情况称为死锁。活动能防止发生死锁，这是通过每次只允许一个对象代表一个用 户运行来实现的。另外，活动在帮助 C O M +管理线程缓冲方面起着重要作用。 在M T S中，活动内对象的同步是通过将活动连接到单个物理线程，或是一个 S TA实施的。 在一个活动中的对象不能并发执行，因为每个活动仅有一个物理线程。另外， C O M +使用复 杂的锁定机制来确保活动中的同步。 每个活动保持着单一的独占锁。当在对象中调用一个方法并且对象的环境存在于一个活 动中时，在允许处理方法调用前， C O M +首先要试图获得活动锁。如果获得锁，就由对象处 理调用，直到方法调用完成，才解除锁。如果不能获得锁，就阻塞方法调用，直到获得锁才 调用方法。虽然锁定过程更加复杂，但从高层次观点看， C O M +使用逻辑的活动使得多个环 境和多个对象同步，基本上就是每一活动用一个单独的锁。使用锁的过程如图 1 9 - 7所示。 图19-7 使用锁的过程 环境能存在于创建者的活动或一个新的活动中或者根本没有活动。然而，单个环境不能 跨越多个活动。为了建立和保持这些关系， C O M +为每个活动创建独特的用户标识符，称为 A c t i v i t y I D，存储于每个环境中。 1. 创建活动和S y n c h r o n i z a t i o n属性 随着C O M和M T S编程模型的集成，创建活动的方法也发生了改变。使用 M T S，每个对象 属于一个活动。当 V B客户使用 C r e a t e O b j e c t函数或 N e w关键字(及某些表达式 )，或者 Vi s u a l C + +客户使用C o C r e a t e I n s t a n c e E X函数创建M T S对象时，自动地创建了活动。为了在已存在的 活动中创建对象，创建者必须调用 O b j e c t C o n t e x t对象中的C r e a t e I n s t a n c e函数。 正如所想像的，这会导致大量的混乱， M T S的开发者必须意识到逻辑活动的边界，并且 恰当地使用标准的对象创建技术 (CreateObject or CoCreateInstanceEX)或者O b j e c t C o n t e x t对象 的C r e a t e I n s t a n c e函数。 使用C O M +，仍然能自动地创建活动，但是活动的创建是通过使用组件的 S y n c h r o n i z a t i o n 属性来控制的，而不是基于如何实例化一个组件。实际上， O b j e c t C o n t e x t对象的C r e a t e I n s t a n c e 第1 9章 A S P和事务性We b应用程序计计565 下载 COM+活动 ActivityID={JMC1150-514... Locked=True 环境 ActivityID={JMC1150-514... 环境 ActivityID={JMC1150-514... 环境 ActivityID={JMC1150-514... ASP
566Asp高程 Chinaopub coM 下载 函数现在的功能与标准的对象创建技术相同,并且它仅支持MTS的向后兼容性。另外,COM+ 提供激活活动外部的对象的能力。这样可避免mm 创建活动的额外开销和可能的调用阻塞,为频 繁使用的非事务性“工具”类型的组件提升性 能。如果需要,可以实现它们自己的锁定技 术。 同 Transaction Support属性一样 Synchronization属性在组件服务浏览器中的组 件 Properties对话框配置,如图198所示 对 Synchronization属性有五种可能的值 ·禁止( Disabled)当组件的 Synchronization 属性设置为 Disabled时,COM+将完全地 忽略组件的同步要求。正如当 Transaction Support,属性设置为 Disabled 时,COM+将首先试图在创建者的环境 图19-8配置 Synchronization属性的界面 中激活对象。如果创建者的环境无效或不相容,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。只有当JⅠT激活被关闭并且 Transaction Support属性设置为 Disabled或 Not Supported时, Synchronization属性才能设置为 Disabled或 Not Supported。我们将在下一节更多地讨论事务与活动的关系 如果认为所有这些配置选项听起来有些令人困惑,不必担心。 Microsoft预料到这些互相依 赖的配置选项会使开发者记忆混乱,他们在组件服务浏览器中建立验证功能。如果改变JT激活 支持或者改变对 Synchronization,属性不相容的某些 Transaction Support.属性,组件服务浏览器器 将用警告消息提示并自动地调整 Synchronization属性来反映任何变化。警告消息如图19-9所
函数现在的功能与标准的对象创建技术相同，并且它仅支持 M T S的向后兼容性。另外，C O M + 提供激活活动外部的对象的能力。这样可避免 创建活动的额外开销和可能的调用阻塞，为频 繁使用的非事务性“工具”类型的组件提升性 能。如果需要，可以实现它们自己的锁定技 术。 同 Transaction Support 属 性 一 样 S y n c h r o n i z a t i o n属性在组件服务浏览器中的组 件P r o p e r t i e s对话框配置，如图1 9 - 8所示。 对S y n c h r o n i z a t i o n属性有五种可能的值： • 禁止(Disabled) 当组件的S y n c h r o n i z a t i o n 属性设置为D i s a b l e d时，C O M +将完全地 忽 略 组 件 的 同 步 要 求 。 正 如 当 Transaction Support属性设置为D i s a b l e d 时，C O M +将首先试图在创建者的环境 中激活对象。如果创建者的环境无效或不相容， C O M +将在一个新的环境中激活对象。 如果对象继承创建者的环境，则对象可以分享创建者的活动，反之不能。应该在非事务 性组件中使用这种设置，无论何时，应尽量避免创建环境和活动的额外开销。 • 不支持(Not Supported) 当组件的S y n c h r o n i z a t i o n属性设置为Not Supported时，对象的 环境将不存在于活动中。然而， S y n c h r o n i z a t i o n属性为Not Supported的对象总是在一个 新的环境中被激活。 • 支持(Supported) 当组件的S y n c h r o n i z a t i o n属性设置为S u p p o r t e d时，对象的环境是否存 在于活动中依赖于创建者的环境是否存在于活动中。然而，具有这种设置的组件不需要 活动，而且在没有活动的情况也能很好地执行。 • 需要(Required) 当组件的S y n c h r o n i z a t i o n属性设置为R e q u i r e d时，对象的环境将总是存 在于活动中。如果创建者环境存在于活动中，则新的对象将在创建者的活动中激活。否 则，C O M +将在位于新活动中的新环境里激活对象。 • 需要新建(Requires New) 当组件的S y n c h r o n i z a t i o n属性设置为Requires New时，对象的 环境将总是在新的活动中创建，不管创建者的环境的同步状态如何。 正如你所看到的，S y n c h r o n i z a t i o n属性的选项和Transaction Support属性的选项非常相似。 然而，某些S y n c h r o n i z a t i o n选项依赖于其他组件属性的某些值。特别是，支持 J I T激活的组件 或Transaction Support属性为S u p p o r t e d、R e q u i r e d和Requires New的组件必须在活动中被激活， 而且需要 S y n c h r o n i z a t i o n属性为 R e q u i r e d或Requires New 。只有当 J I T激活被关闭并且 Transaction Support属性设置为D i s a b l e d或Not Supported时，S y n c h r o n i z a t i o n属性才能设置为 D i s a b l e d或Not Supported。我们将在下一节更多地讨论事务与活动的关系。 如果认为所有这些配置选项听起来有些令人困惑，不必担心。 M i c r o s o f t预料到这些互相依 赖的配置选项会使开发者记忆混乱，他们在组件服务浏览器中建立验证功能。如果改变 J I T激活 支持或者改变对S y n c h r o n i z a t i o n属性不相容的某些Transaction Support属性，组件服务浏览器器 将用警告消息提示并自动地调整S y n c h r o n i z a t i o n属性来反映任何变化。警告消息如图1 9 - 9所示。 566计计ASP 3 高级编程 下载 图19-8 配置S y n c h r o n i z a t i o n属性的界面
China pub.coM mIng AS RI S#tws /B EIr 567 The transaction level or just in time activation setting that was just selected is not compatible with the currently selected synchronization level, The synchronization level wil be changed to a compatible level 图19-9警告消息 关于活动,最好的优点是它们全部通过COM+在幕后执行,组件不需要做任何附加工作 COM+提供了自动的并行和同步服务。另外,对非事务性组件提供了禁止创建活动的功能 尽管如此,理解 Synchronization属性变化的作用和活动与环境在幕后如何运行是很重要的,这 样才能设计出高效和可扩展的组件。现在我们对事务性COM+组件的可配置属性有了一定的 了解,下面讨论事务的生存期的每一阶段。 19.33事务的生存期 COM+事务生存期可分为四个阶段,分别是: 事务开始。 ·建立并征募与 Resource manager的连接 在事务中执行操作 输出事务结果并结束。 重要的是记住只有 Transaction Support属性不是 Disabled或 Not Supported时组件才需要参 与事务。COM+组件同样能可选地表决事务的结果 下面详细看一下在单个和多个对象的COM+事务中,事务生存期的每一阶段的具体情况。 事务开始 使用COM+事务模型,组件不会显式地启动一个COM+事务。相反,COM+在两种情况下 自动地创建一个新的COM+事务 Transaction Support属性为 Required的组件由非事务性的客户激活 Transaction Support属性为 Requires New的组件由任何客户激活。 个COM+事务由两部分组成 逻辑事务。 物理事务。 逻辑事务也称为事务流,是共享一个物理事务的对象的一个逻辑集合或逻辑组。另一方 面,物理事务是基本的 MS DTC事务,使用两阶段提交协议,根据数据源协调事务结果。当物 理事务由COM+创建时,它使用最高级别的隔离(可串行的)创建,并且在组件服务浏览器中指 定事务超时间隔。COM+从基本的物理事务中完全地抽象对象,而不是让我们通过逻辑事务 流和每个对象的环境管理事务 尽管逻辑事务可以由几个COM对象组成,但是事务流(逻辑事务)与物理事务始终存在ˉ 对应关系,这一点非常重要 在事务流中创建的第一个对象,称为事务的根。事务的根能够通过实例化组件在同一事 务中可选择地征募其他的COM+对象,这些被实例化的COM+组件的 Transaction Support属性 为 Required或者 Supported。在这同一事务中创建对象时,COM+自动地将根对象的环境事务
图19-9 警告消息 关于活动，最好的优点是它们全部通过 C O M +在幕后执行，组件不需要做任何附加工作， C O M +提供了自动的并行和同步服务。另外，对非事务性组件提供了禁止创建活动的功能。 尽管如此，理解S y n c h r o n i z a t i o n属性变化的作用和活动与环境在幕后如何运行是很重要的，这 样才能设计出高效和可扩展的组件。现在我们对事务性 C O M +组件的可配置属性有了一定的 了解，下面讨论事务的生存期的每一阶段。 19.3.3 事务的生存期 C O M +事务生存期可分为四个阶段，分别是： • 事务开始。 • 建立并征募与Resource Manager的连接。 • 在事务中执行操作。 • 输出事务结果并结束。 重要的是记住只有 Transaction Support属性不是D i s a b l e d或Not Supported时组件才需要参 与事务。C O M +组件同样能可选地表决事务的结果。 下面详细看一下在单个和多个对象的 C O M +事务中，事务生存期的每一阶段的具体情况。 1. 事务开始 使用C O M +事务模型，组件不会显式地启动一个 C O M +事务。相反，C O M +在两种情况下 自动地创建一个新的C O M +事务： • Transaction Support属性为R e q u i r e d的组件由非事务性的客户激活。 • Transaction Support属性为Requires New的组件由任何客户激活。 一个C O M +事务由两部分组成： • 逻辑事务。 • 物理事务。 逻辑事务也称为事务流，是共享一个物理事务的对象的一个逻辑集合或逻辑组。另一方 面，物理事务是基本的MS DTC事务，使用两阶段提交协议，根据数据源协调事务结果。当物 理事务由C O M +创建时，它使用最高级别的隔离 (可串行的)创建，并且在组件服务浏览器中指 定事务超时间隔。 C O M +从基本的物理事务中完全地抽象对象，而不是让我们通过逻辑事务 流和每个对象的环境管理事务。 尽管逻辑事务可以由几个 C O M +对象组成，但是事务流 (逻辑事务)与物理事务始终存在一 一对应关系，这一点非常重要。 在事务流中创建的第一个对象，称为事务的根。事务的根能够通过实例化组件在同一事 务中可选择地征募其他的 C O M +对象，这些被实例化的 C O M +组件的Transaction Support属性 为R e q u i r e d或者S u p p o r t e d。在这同一事务中创建对象时， C O M +自动地将根对象的环境事务 第1 9章 A S P和事务性We b应用程序计计567 下载