BizTalkServer事务机制.docx

BizTalk Server 事务机制 概述原子事务DTC 事务非序列化对象使用原子事务的方案方案 1具有 COM ServicedComponent 的原子事务方案 2将事务性适配器与原子事务一起使用长期事务嵌套补偿容错使用长期事务的方案方案 1将长期事务用于超时方案 2将长期事务用于自定义补偿业务流程中的持久化概述BizTalk Server 业务流程引擎可管理复杂流程和/或事务集的状态，对其应用业务逻辑，并调用其支持应用程序。 业务流程可由使用原子事务的若干分立工作组成，这些原子事务在发生错误或长时间运行时自动回滚所有更改，业务流程可包含嵌套事务，并可使用自定义异常处理从错误中恢复。这些事务性语义通常由业务流程设计器中的“作用域”构造管理。 长期流程可持续数天、数周，甚至更长的时间。长期流程通常利用相关将收到的消息和要发送的消息关联起来。业务流程引擎通常会冻结这些实例以节省系统资源，并在收到相关消息后解除冻结。业务流程引擎会在已知检查点处将业务流程状态持久化到 MessageBox 数据库，以便为从任何应用程序异常或系统异常中恢复做好准备。提供给 BizTalk 业务流程引擎的事务性编程模型不仅支持异常处理，还支持从失败的事务、在错误发生时自动回滚其操作的原子事务或包含其他事务的长期事务及自定义异常处理中恢复。原子事务BizTalk 业务流程可设计为按照事务的传统“ACID”概念，执行不同部分的工作。在执行时，这些离散的或原子的工作单位会将业务流程从一个一致的状态转移到独立于其他工作单位的一致且持久的新状态。这通常是使用“作用域”构造实现的，作用域构造使用事务性语义封装这些工作单位。也可以将整个业务流程定义为一个原子事务，而不使用作用域。但是，这些作用域不能标记为事务性的，除非业务流程本身标记为长期或原子事务类型。原子事务保证在事务性更新期间发生故障时可自动回滚任何部分更新，并且消除事务的影响（事务中进行的任何 .NET 调用的影响除外）。BizTalk 业务流程中的原子事务与分布式事务处理协调器 (DTC) 事务大体相似，只是前者通常存活时间较短并且具有四个“ACID”属性（原子性、一致性、隔离性和持久性）：原子性一个事务就表示一个原子的工作单位。要么在事务内执行所有修改，要么不执行任何修改。一致性在提交时，事务必须在系统内保持数据的整体性。如果某一事务在该事务开始前对已在内部保持了一致的数据库执行数据修改，则在提交该事务时，数据库仍必须在内部保持一致。确保此属性的工作主要由应用程序开发人员负责。隔离性并行事务进行的修改必须与其他并行事务进行的修改隔离。并行运行的隔离事务所执行的修改将保持内部数据库一致性，与顺序运行事务完全一样。持久性在提交某一事务后，默认情况下所有修改都永久存在于系统中。即使系统发生故障，这些修改也存在。在 BizTalk 业务流程中使用的原子事务支持以下隔离级别：提交读在正在读取数据时保持共享锁，以避免脏读，但是在事务结束之前可以更改数据，从而导致不可重复的读取或幻像数据。可重复读在查询中使用的所有数据上放置锁，以防止其他用户更新这些数据。这防止了不可重复的读取，但仍有可能产生幻像行。 可序列化放置一个范围锁，防止在事务完成前其他用户更新行或将行插入数据库中。BizTalk Server 确保原子事务内的状态变化（例如对变量、消息和对象的修改）只在事务提交后在原子事务的作用域外可见。中间状态的变化将与业务流程的其他部分隔离开来。如果要求对数据具有完全的 ACID 属性（例如，数据必须独立于其他事务），则必须只使用原子事务。在原子事务失败时，所有状态都将重置，就像业务流程实例从来没有进入该作用域。BizTalk 针对原子事务的规则是：所有变量（而不只是作用域的本地变量）都参与该事务。在原子事务中使用的所有非序列化变量和消息都应声明为对作用域而言是本地的；否则，编译器将显示“变量…未标记为可序列化”错误。所有原子作用域都将认为是“同步的”，并且如果实际上将同步的关键字用于原子作用域，则业务流程编译器将对冗余的使用发出警告。共享数据的同步将从作用域开始一直扩展到作用域成功完成（包括在作用域结束时的状态持久化），或者扩展到异常处理程序完成时（如果出现错误）。同步域并不扩展到补偿处理程序。原子事务可与超时值（此时，业务流程将停止事务并且实例将挂起）相关联。如果某一原子事务包含接收形状、发送形状或启动业务流程形状，则相应操作将不会在提交该事务前发生。 如果用户故意引发 RetryTransactionException，或者在原子事务尝试提交时引发 PersistenceException，原子事务将重试。例如，如果原子事务是分布式 DTC 事务的一部分，而该事务中的其他参与者停止了该事务，则可能会引发 Pe