涵盖主存数据库、实时数据库、长事务、嵌套事务、事务处理监控器、事务工作流、电子商务中的事务处理和多数据库事务。

事务处理监控器

事务处理监控器(TP)提供对分布式事务处理的核心支持。

TP监控器体系结构

大规模事务处理系统建立在客户-服务器体系结构上。有如下体系：

• 每客户进程模型：为每个远程客户请求建立一个进程，提供访问支持。缺点：每个进程的内存需要量大，在进程间切换对CPU负载高。
• 单服务器模型：远程客户请求发送到服务器进程，然后由服务器进程执行请求，服务器进程是多线程的，对每个客户有一个线程控制，线程间切换比进程间切换代价小得多。缺点：所有应用作为单一的一个进程运行，它们之间没有保护，一个应用系统的错误会影响到所有应用系统。不适合于并行数据库或分布式数据库，因为一个服务器进程不能在多台计算机执行。
• 多服务器单路由器模型：这种模型服务于多个应用的独立的服务器进程，每一个应用可以有一个服务器进程池，进程池的任何一个可以处理客户会话。请求可以路由的进程池中负载最轻的服务器上，并且每一个服务器进程本身是多线程的，可以并发处理多个客户。应用服务器可以在并行数据库或分布式数据库的不同站点运行，通信进程可以在这些进程间协同。在Web服务器中广泛使用。
• 多服务器多路由器模型：一个控制器进程启动其他的进程，并监控它们的工作。一般超高性能Web服务器采用这种结构。路由进程通常是网络路由，它们根据通信量的来源将到达同一互联网地址的通信量分流到不同的服务器地址。

TP监控器不仅将消息传送给应用服务器，当消息到达时，还有一个队伍管理器管理到达的消息。队伍可以是一个持久队列，在系统故障时仍然保存。TP监控器还提供持久消息发送的支持。

使用TP监控器进行应用协调

对于应用程序与多个数据库如遗产系统，建立在文件系统上的专用数据存储系统和远程站点的其他应用系统通信的系统，TP监控器提供构造和管理这种由多个子系统(例如数据库、遗产系统和通信系统)构成的大型应用的支持。TP监控器将每个子系统作为一个资源管理器，资源管理器提供对某些资源的事务性访问和数据。资源管理器接口由X/Open分布式事务处理标准定义。

TP监控器提供持久队列和持久消息发送等服务，担当这些服务和数据库系统的事务的两阶段提交协调者。管理包括多个服务器和大量客户端的复杂的客户-服务器系统。对系统检查点和系统关闭进行协调，提供安全性和客户端的授权，管理服务器缓冲池，控制故障的范围。

在复制的系统中，用TP监控器来隐藏数据库故障。远程备份系统就是一个例子。事务请求到达TP监控器后，TP监控器将消息传播给某个军思考系统（如果在远程备份系统中，就是主站点）。如果某一个站点故障，TP监控器可以透明地将消息路由到一个备份站点，隐藏第一个站点的故障。

在客户-服务器系统中，客户通常通过远程过程调用（RPC）机制与服务器交互。RPC是由客户启动一个实际在服务器端的过程调用，结果返回给客户。从启动RPC的客户代码来看，该调用好像启动本地过程调用一样，TP监控器可以为系统服务提供一个事务RPC接口，在接口中，RPC机制提供一些调用，可用来将一系列的RPC调用包括在一个事务中，由一个RPC执行的所有更新都是在该事务的范围内执行，从而发生故障时可以回滚。

事务工作流

工作流是一个活动，其中多个任务以不同的处理实体相互协同的方式执行。任务定义了要做的某项工作，并且可以用多种不同的方式来说明，包括文件中的文本描述、电子邮件消息、表单、消息或计算机程序。执行任务的处理实体可以是人或软件系统。

工作流有时称为任务流和多系统应用，工作流任务有时称为步骤。

工作流在机构中以及机构间起着越来越重要的作用，许多组织拥有多种软件系统，它们必须能够协同工作。为使工作流自动化，需要强调两个活动。

• 工作流说明：描述必须执行的任务，并定义执行需求。
• 工作流执行：在执行工作流时必须通过传统的数据库系统提供的有关计算正确性以及数据完整性和持久性的安全性保证。

两个活动都很复杂，因为许多组织机构使用多个独立管理的信息处理系统，这些系统是分开开发、对不同功能进行自动化的，工作流活动可能需要几个这样的系统的交互，每个系统执行一个任务，并且与人交互。

工作流说明

任务内部构件无需为工作流的说明和管理建模。任务可以使用放在它的输入变量中的参数，可以检索和更新本地系统中的数据，将它的结果存放到输出变量中，可以查询任务的执行状态。在执行过程的任何时间，工作流状态包括该该工作流各个任务的状态的集合和工作流说明中所有的变量的状态。

任务之间的协调可以静态地说明，也可以动态说明。在静态说明下，任务以及任务之间的依赖关系在工作流开始执行之前定义。对于工作流的每一个任务的执行都有一个前提条件。前提条件可以用以下结果来定义：

• 其他任务的执行状态
• 其他任务的输出值
• 外部事件修改的外部变量

工作流的故障原子性需求

对工作流来说，许多情况下，当其中的一个任务发生故障时工作流不一定失败。应该允许工作流设计人员定义工作流的故障原子性需求。系统应该保证工作流的每一次执行都满足设计人员定义的故障原子性需求的状态终止。我们将这些状态称为工作流的可接受终止状态，工作流的所有其他的执行状态构成一个不可接受终止状态集合，这些状态可能违背故障原子性需求。

提交的可接受终止状态是工作流的目标全部达到的执行状态。中止的可接受终止状态时一个合法的终止状态，此时工作流未能达到它的目标，那么工作流的部分执行产生的不合要求的影响应该按照该工作流的故障原子性需求撤销。

在工作流达到终止状态前，一个任务可以提交并释放资源，如果这个多任务事务中止了，它的故障原子性可能要求执行补偿任务来撤销已完成的任务所造成的影响。

工作流的执行

多个任务的执行可以由一个协调人来控制，或者由一个工作流管理系统的软件系统控制。工作流管理系统包括一个调度程序、多个任务代理和一个查询工作流系统的状态的机制。任务代理通过处理实体控制任务的执行。调度程序是一个对工作流进行处理的程序，它将不同的任务交付执行，监控各种事件，计算与任务间依赖有关的条件。调度程序可以将一个任务交付执行，也可以要求中止一个先前交付执行的任务。调度程序根据工作流说明，按任务间的依赖关系进行调度，保证任务的执行到达可接受终止状态。

开发工作流管理系统的体系结构：

• 集中式体系结构：单独的调度程序对所有并发执行的工作流任务调度。适合于数据存储在集中式数据库中的工作流系统。调度程序通知各种代理有任务需要执行，跟踪工作流的执行状态比完全分布式方式下容易。
• 部分分布式体系结构：对每一个工作流实例化一个调度程序。
• 完全分布式体系结构：没有调度程序，由各个任务代理通过相互之间的通信来协调执行，以满足任务间依赖关系和其他工作流执行需求。最简单的方式可以基于消息发送，由持久消息发送机制实现，提供有保证的传递。有些使用电子邮件，提供持久发送的许多特点，但不保证消息发送和事务提交的原子性。每个站点有一个任务代理，执行通过消息接收到的任务。执行中可能会将消息交给人，由人去执行某些动作。在断开连接的网络中很有用。

调度程序必须保证工作流终止与一个指定的可接受终止状态。理想情况是，在打算执行一个工作流之前，调度程序检查工作流，看它能否终止于一个可接受状态，如果不能，应该拒绝这样的工作流说明。保证工作流的安全性是设计工作流说明的人员的责任。

工作流的回复

保证工作流的故障原子性。保证在工作流处理构件（包括调度程序）的任何一个发送故障时，工作流都能达到一个可接受终止状态。假设工作流涉及的处理实体有自身本地的恢复系统，能处理本地的故障。为了恢复执行环境上下文，故障恢复例程序要恢复调度程序在发送故障时的状态信息。必须将适当的状态信息作为日志记录存储到稳定存储器上。

还要考虑消息队列的内容，保证只交接一次，持久的消息发送体制提供了这样的特性。

工作流管理系统

工作流通常是手工编码，用于帮助协调整个企业内部的活动，工作流管理系统的目标是简化工作流构造，使得它们更加可靠，这些通过支持工作流以及高层形式和按照相应的说明执行来实现。有大量商业工作流系统是通用工作流管理系统。

工作流管理联盟开发了用于工作流系统之间协同工作的标准，现在的标准力图使用XML作为工作流之间沟通信息的底层语言。

电子商务

活动类型：

• 预售活动
• 销售过程
• 市场
• 销售付款
• 交付产品和服务的相关活动
• 客户支持和售后服务

电子目录

任何电子商务站点提供用户一个站点供应的产品和服务的列表。最低限度，电子目录必须提供浏览和搜索功能，简单的比较不同选择的手段，为特定客户定制目录，存储客户信息。

市场

市场用于协商产品的销售价格，存在不同类型的市场：

• 反向拍卖
• 拍卖
• 交易

在处理市场中遇到的数据库的问题：

• 投标者需要授权
• 出价需要安全地记录在数据库中
• 广播出价的延迟
• 某特定时间交易数量巨大

订单结算

提供安全协议保护信用卡，防止中间人攻击。

手段：

• 数字证书
• 安全电子交易（SET）
• 提供更高的匿名性

主存数据库

为了获得很高的事务处理速率，必须使用高性能硬件，必须开发并行性。但是磁盘I/O会成为瓶颈。我们通常采用增大数据库缓冲区减小数据库系统受磁盘限制的程度。

对于某些应用，如实时控制应用，必须将数据存在主存内来满足性能要求。

大的主存能使数据驻留在内存中，从而使事务处理更快。然而，仍然存在于磁盘有关的限制：

• 在事务提交前必须将日志记录写到稳定存储器中。可以采用组提交技术输出写满的块，减少写到磁盘开销，但可能造成更新事务提交的轻微延迟。
• 为了减小在恢复的时候必须重新执行的日志数量，仍然有必要写出已提交事务做了修改标记的缓冲块。
• 如果系统崩溃了，所有的主存数据都会丢失。

另一方面，主存数据库为优化提供了机会：

• 主存数据库的内部数据结构设计必须注意减小空间需求量，然而，数据结构可以有跨不同页的指针。
• 数据存取前没有必要钉住内存中的缓冲区页，因为缓冲区页从来不会被替换。
• 查询处理技术应该设计成尽量减小空间开销，从而在执行查询时不会超出主存的界限。
• 一旦消除了磁盘I/O瓶颈，封锁等操作可能会变成瓶颈。
• 可以对恢复算法进行优化，因为很少需要将页写出以给其他页腾出空间。

实时事务系统

某些应用系统中，约束条件包括任务必须完成的截止时间。

特性：

• 硬截止时间：如果任务不能在截止时间内完成，可能出现严重问题。
• 严格截止时间：如果任务在截止时间后完成，它的价值为零。
• 软截止时间：如果任务在截止时间之后完成，它的价值减少了，随着延误时间的增加其价值趋近于零。

实时系统的事务管理必须将截止时间考虑在内。对于锁冲突时，让事务等待还是抢占锁通常很难确定。并且事务执行时间估算差异较大。

在实时系统中，最重要的问题不是绝对速度，而是截止时间。设计一个实时系统需要保证在不要求过多的硬件资源的前提下，有足够能力来满足截止时间的要求。

长事务

当事务涉及到人机交互的数据库系统时，这些事务具有重要特性：

• 持续时间长：需要人来响应
• 暴露未提交数据：由于事务可能中止，长事务需要人来响应导致事务迟迟无法提交，那么其他事务被迫去读未提交数据。
• 子任务：用户可能希望中止某个子任务，而不必中止整个事务。
• 可恢复性：活动的事务必须恢复到系统崩溃前不久的状态，以便丢失掉的人的工作较少。
• 性能：在交互式事务中，价格最高的资源是用户，要提供用户的工作效率和满意程度，响应时间需要快。在一个任务持续很长时间去看下，响应时间应该是可预知的。

不可串行化的执行

以上特性使只允许可串行化的调度不切实际。下面每一种并发控制协议对于长事务都有负面影响。

• 两阶段封锁：当一个事务请求锁而不得时，它必须等待。如果这是一个长事务，那么等待时间将极长。很容易导致死锁。
• 基于图的协议：锁的释放比两阶段封锁协议早，并且能避免死锁。然而它对数据项强加了一个排序，使得事务封锁的数据比它实际需要的多，很容易发生长时间的锁等待。
• 基于时间戳的协议：时间戳协议不需要事务等待，然而，它需要事务中止，如果长事务被中止，会丢失大量工作。
• 有效性检查协议：与基于时间戳的协议的缺点一样。

强制要求可串行化导致长时间的等待或长事务的中止，或者两者同时发生。并且一个事务的中止可能导致其他事务的中止，尤其是长事务的级联中止是不可接受的。如果采用封锁机制又想避免级联回滚，就必须保持排他锁到事务结束，这样就增加了事务等待时间。

由此看来，强制要求事务的原子性必然导致长时间等待的可能性增大，或者发生级联回滚的可能性。

并发控制

数据库并发控制是为了保证事务的并发执行不会导致数据库一致性的丢失。通过上面的结论，我们可以采用不同的方式保存数据库一致性而不是可串行化。不是所有保持数据库一致性的调度都是可串行化的。

无串行化条件下正确性概念的观点：

• 正确性依赖于特定数据库的一致性约束
• 正确性依赖于每个事务执行的操作的特性

嵌套事务和多级事务

将长事务分解为一组相关的子事务。如果允许事务T的子任务在完成的时候释放锁，那么T称为多级事务。当一个多级事务代表一个长时间的活动时，该事务有时称为一个传奇。另一种情况，如果T的子事务Ti所持有的锁在Ti完成时自动赋予T，那么T是嵌套事务。

补偿事务

为减少长时间等待的发生频率，我们安排未提交的更新暴露给其他并发执行的事务。事实上，多级事务可能允许这种曝光。然而，未提交事务的曝光产生了级联回滚的可能性。

令事务T分为几个子事务t1,t2,……,tn，在一个子事务ti提交后，它释放了锁，现在如果必须中止外层事务T，那么子事务的影响需要撤销，但是我们不能撤销已提交的子事务。我们执行一个新的子事务称为补偿事务cti来撤销子事务ti的影响，每个子事务ti都需要有一个补偿事务cti。

实现问题

减少保证大数据项可恢复性的开销：

• 操作日志（逻辑日志）。只将对数据项执行的操作和数据项的名字存放在日志中。对每个操作，必须存在一个逆向操作，用逆向操作执行undo，用操作本身执行redo。但redo和undo不是幂等的，对于更新多个页的redo操作使用逻辑日志是复杂的，因为更新过的有些页可能已经写到磁盘上。那么可以使用物理重做日志和逻辑撤销日志，可以提供逻辑日志的并行性优点。
• 日志和影子分页：日志用于小数据项的更大数据项恢复通过影子页复制技术实现。

由于长事务和大数据项导致的复杂性仍然使恢复过程复杂，我们希望对于某些非关键数据不记日志，而依赖于脱机的备份和人的干预。

多数据库的事务管理

多数据库支持两类事务：

• 局部事务
• 全局事务

多数据库系统没有对局部事务的执行进行控制，每个本地系统必须使用并发控制机制保证进度的串行化，并且防止局部死锁的可能。

保证局部串行化对于确保全局串行化是不够的，但全局事务无法控制局部子事务的精确封锁行为。我们可以通过两级串行化来保证全局串行化。

多数据库的另一个问题是全局原子提交，如果所有的局部系统遵循两阶段提交，那么可获得全局原子性，如果作为分布式系统的一部分无法参与这个协议，那么也会出现问题。

两级串行化

两级串行化(2LSR)在系统的两个级别保证串行化：

• 每个本地数据库系统在局部事务中保证串行化（包括全局事务中的局部事务）。
• 多数据库系统只在全局事务中保证串行化—忽略由局部事务引起的排序。

但这不足以保证全局可串行化，还需要采用弱于串行化的需求，称为强正确性：

1. 保持一组一致性约束指定的一致性
2. 保证每个事务读取的数据项集合时一致的

一些协议：

• 全局读协议
• 局部读协议
• 全局读写/局部读协议

保证全局串行化

在更新事务时只读事务的执行环境中，有许多机制保证用于全局串行化。这些机制有几个是基于票的思想。每个本地数据库系统创建一个特殊数据项，叫做票。每个访问该站点数据的全局事务必须在该站点上写这个票，这个要求保证了全局事务在它们访问的每一个站点直接发生冲突，全局事务管理器可以通过控制票的顺序来控制全局事务可串行化顺序。