数据库中事务处理的设计

1、 本科毕业（设计）论文（二五）届题目：数据库事务处理的设计分院系部 计算机与信息科学系 专 业 计算机科学与技术 学生姓名 导师姓名 导师职称 讲 师 副 教 授 二五年六月一日数据库事务处理的设计 摘要：本文主要介绍了关系数据库系统事务处理的基本设计思想，并介绍事务处理系统中各组件的基本功能和核心服务。以此为基础设计了一个简单的事务处理系统模型，对部分细节进行了详细设计。关键字：事务；事务处理；事务模型The Design of Transaction Processing in Database Abstract This article mainly introduced relatio

2、nal database system transaction processes the basic design thought, and introduction transaction processes in the system various modules basic function and the core service. Designed a simple transaction take this as the foundation to process the system model, has carried on the detailed design to t

3、he partial details.Keywords Transaction; Transaction Processing; Transaction Processing Model目 录前言11数据库中的事务处理11.1研究的意义11.2研究的背景及目的12事务22.1事务的概念与其特性22.2事务的必要性22.3事务的模型32.3.1扁平事务32.3.2带保存点的扁平事务32.3.3链事务32.3.4嵌套事务32.3.5分布事务42.3.6长事务42.3.7多级别事务42.4事务处理系统的定义53事务处理系统的各模块的核心服务和功能63.1一个事务的执行过程63.2事务处理系统重要组件

4、必要功能的说明73.2.1事务处理监控器的服务73.2.2日志管理器的功能说明93.2.3锁管理器的功能说明93.2.4事务管理器的功能说明104设计与实现104.1事务处理的简单模型104.2具体的设计与细节124.2.1事务标识符的设计124.2.2事务处理监控器的设计134.2.3日志管理器的设计134.2.4锁管理器的设计164.2.5事务管理器的设计165结论21前言事务处理的发展已经有了上千年的历史了。从5000年前的殷人开始使用乌龟的外壳记事以来，已经经过了几千年的历史了。20世纪后半叶在事务处理方面出现了两个主要的发展：基于磁性存储介质（磁带和磁盘）的成批事务处理以及基于电子存

5、储和计算机网络的联机事务处理。在数据库管理系统中附加上事务处理子系统会使系统有更好的可靠性。1数据库中的事务处理1.1研究的意义在修改数据库中的数据时，要使它里面的数据正确一致的被更新，这是事务处理的工作。当数据库系统出现更新故障时，为了将损失减少到最低，一般来使用事务处理来恢复数据。事务处理的发展已经很久了，其理论和技术相对来说是比较成熟的。1.2研究的背景及目的国外的数据库经过几十年的发展，现在几乎垄断了整个市场。数据库技术是整个信息产业的核心。即使数据库的存储介质发生了改变，数据库的概念并不会有所变化。中国已经有四家企业开发了自己的数据库（不包括台湾省）。这些数据库基本能够胜任中等强度与

6、规模的数据库系统应用。对于那些核心业务应用，国产数据库的应用案例十分有限。同时在对图形工具的支持方面，国际主流数据库管理系统提供好的图形管理工具，而且还提供丰富的应用构件和套件，比如应用服务器、系统调优与分析工具、企业应用套件等。国产数据库的要赶上国外的数据库，还要很长时间。研究的目的是：通过对事务处理的研究设计出数据库所需要的事务处理系统。2事务2.1事务的概念与其特性事务是对物理和抽象的应用状态上的操作集合。事务作为单个逻辑工作单元执行一系列操作。一个逻辑工作单元必须有四个属性，称为ACID（原子性、一致性、隔离性和持久性）属性，只有这样才能成为一个事务。保证数据一致性的关键是要明确数据访

7、问和更新的序列。这一序列称为事务。它是并发和恢复的基本单位。下面分别对事务的四个特性进行叙述:原子性：一个事务对状态的改变是原子的。要么都发生，要么都不发生。原子性是从操作调用者的角度来定义，因为几乎没有任何原子操作（包括机器指令）在所有的实现层次上保持真正的原子性。一致性：一个事务是对状态的一个正确改变。作为一组操作没有违反任何与状态相关的完整性约束。这要求事务是一个正确的程序。隔离性：尽管事务是并发执行的，但看起来是单个执行的，即对于一个事务T，任何其他事务要么在T之前执行，要么在T之后执行，但不会既在T之前，又在T之后执行。持久性：一旦一个事务成功完成（提交），它对状态的改变不会受到其他

8、失败事务的影响。2.2事务的必要性事务是为了实现软件容错的。现在没有一直都能运行而不出错的软件，当一个产品化的计算机系统由于软件问题崩溃，它的使用者并不会等到软件开发者来将此问题更正之后，才使用它，而是重启系统，希望这它下一次能运行起来，原因是因为它毕竟昨天被使用过。而系统通过用事务，系统恢复到最近的一个状态。软件故障是系统失败的主要来源，因为其他硬件上的故障都是被软件屏蔽掉的。软件故障是一个没有解决的问题。软件容错主要有两种方法：N版本程序设计和事务。两种方法一般可结合起来使用。数据库是用来管理大量数据的，它肯定会存在软件上的故障，此时只能是通过事务来使它内部的数据不会因为软件故障而被全部破

9、坏掉。用N版本程序设计，它的实现和维护是昂贵的。这是因为要得到占大多数的结果，N至少是3。2.3事务的模型2.3.1扁平事务该模型是所有事务类型中最简单的一种。扁平事务中的所有操作是处于同一平面的，由一个Begin_Work()来标志开始，Commit_Work结束。这个原因使这种事务在执行之后的结果只有两种，除此之外没有其它的结果。一是全做，二是全不做。对于后者来说，原因有两个：一是事务放弃，一是外界的事件使其不能完成。因此它具有“要么全做，要么全不做”的特性。2.3.2带保存点的扁平事务系统在执行过程出错了，但是在一些情况下并不是所有的操作都无效的，如果使用前面的扁平事务，所有的操作都将回

10、滚，这样做带来的结果是，一些不需要回滚的操作也被回滚了，代价也较大。如果是回到同一事务里面的较早状态，就能较好的支持了这类应用。所以在这种模型中设置保存点。2.3.3链事务链事务是保存点模式的一种变种。由前一个事务来触发后一个事务发生。2.3.4嵌套事务嵌套事务的定义有五点：1)嵌套事务是若干事务组成的一棵树，子树既可以是嵌套的，也可以是扁平事务。2)处在叶节点的事务是扁平事务。从根节点到叶节点通过的路径不同所经过的距离也是不同的。3)位于要节点的事务称为顶层事务，其他的事务称为子事务。事务的前驱被称为父（事务），事务的后继被称为子（事务）。4)子事务既可以提交，也可以回滚。直到父事务提交后，

11、子事务的提交才会生效。所以，任何子事务只有在根事务提交后才能最终提交。5)树中的任意一个事务的回滚会引起它的所有子事务一同回滚。正是因为这一点，子事务仅保留了A、C、I特性，而不具有D特性。2.3.5分布事务分布事务一般是扁平事务，它应用于分布环境下，因此必须根据数据的位置来访问网络中的节点。2.3.6长事务以上所有介绍的事务模型都存在一个问题，一个比较大的批事务在前面几个事务模型里不能完美的解决掉。解决这个典型问题的方法一般是由执行一系列更新少量数据的事务构成，整个事务的原子性通过在数据库中的事务上下文数据来维持。上下文是空集的程序被称为上下文无关，其他的被称为上下文相关。影响了数据库的上下

12、文的原因是因为其他的事务更新了数据库。2.3.7多级别事务Tselectinsertupdateselect插入元组插入B树项更新页插入地址表项定位插入项图1一个多级别事务的模型图多级别事务是嵌套事务的一般化和更自由化的版本。它们允许了子事务先提交，这使单独回滚子事务的修改是可能的。然而为了保证事务的四个特性。最终会假设存在一个补偿事务，如果父事务决定（或被迫）回滚，补偿事务就可以取消子事务已经完成的。的补偿事务可以是另外的嵌套事务和多级事务。因为这些补偿事务可以在所有嵌套层次被执行，这样就保证了所有的更新都可以被撤消，即使是在根节点失败之前所有子事务已经提交了的操作。因为这种模型使层次化对象

13、实现模式允许通过隔离高层对象来保护较低层次上的修改，所以它具有所有的ACID特性。这样实现了对根事务的隔离，因此使原子地执行根事务成为可能。在数据库系统限制的情况下，这种多级别事务足够用了。虽然回滚时，执行补偿操作的代价要比仅仅存储旧值昂贵，但是回滚并不是一个频繁的操作，拥有更小的提交控制单元的好处就会远远超过补偿的代价。2.4事务处理系统的定义从不同的角度来认识事务处理系统，因为每一个角度看到的系统都是很不同的，很难对事务处理系统做一个定义。给出一个综合的定义是：事务处理系统提供工具使广泛应用的编程、执行和管理更加容易或者自动化。事务处理应用一般都支持多个设备组成的网络，这些设备可以把查询和

14、更新请求提交给应用。在这些输入的基础上，应用维护着一些表示现实世界特定状态的数据库。应用研究的响应和输出总是驱使着现实世界的传动器和转换器，而它们改变和控制着这些状态。3事务处理系统的各模块的核心服务和功能首先来看一下，一个事务的执行过程:3.1一个事务的执行过程 图2事务执行过程中的核心服务当一个事务发出了Begin_Work()命令时，将在事务管理器中注册该事务并产生一个唯一的事务标识符。一个应用一旦开始了一个事务，它就可以开始调用数据库，并且把请求发送给本地和远程服务。当一个资源管理器得到该事务的第一个请求时，它就加入到事务中，告知本地的事务管理器它想参与此事务的提交和回滚。参与一个事务

15、的资源管理器通常有多个。由于这些资源管理器代表着事务执行操作，所以它们把自已对对象所做的改变都记下来。作为一个规则，资源管理器记录新旧对象值。事务处理系统提供了一个日志服务记录这些改变。日志管理器有效地实施了一个顺序文件，里面记录了事务对对象的所有更新。当然，其他的资源管理器要告诉日志管理器这些更新是什么。为了提供隔离，资源管理器将封锁事务存取的对象；这防止了其他事务看到本事务没有提交的更新，也防止它们更改该未提交的事务所读写的数据。事务处理系统提供了一个封锁管理器供其他资源管理器使用。当事务发出Commit_Work()命令时，事务管理器将执行两阶段提交协议。首先它查询所有参与该事务的资源管

16、理器，问它们是否认为该事务是一个一致的和完整的转变。当任一个资源管理器加以否决时，提交就失败了。但是如果所有的资源管理器都赞同，事务管理器将在日志中记录下这个事实，通知每一个资源管理器事务是完整的。这时，资源管理器才可以放锁，执行一些其他的完成该事务所需的操作。如果事务在执行中出错了，或者有一个资源管理器在两阶段提交的第一个阶段否决，那么事务管理器就要指挥这个事务回滚。这种情况下，事务管理器读事务日志，对每一个日志记录调用写该记录的资源管理理，让其撤消操作。一旦所有撤消都完成以后，事务管理器调用每一个参与该事务的资源管理器，告知它们事务被终止了。远程调用事务的过程是本地先要对调用处理，找到调用

17、的种类和调用的目的。如果调用 的不是本地的，通过通信管理器向另一端发送消息。接收到另外一个节点的TPRC（远程事务处理）到达的时候，就将它传送给一个本地进程。在正确的处理完毕之后返回结果。3.2事务处理系统重要组件必要功能的说明由前面的图1可以知道一个典型的事务处理系统至少应该具有四个部分：事务处理监控器、事务管理器、日志管理器、锁管理器。下面是各个部分的核心的服务和功能：。3.2.1事务处理监控器的服务事务处理监控器是为了引入事务型完程过程调用（TPRC）。事务处理监控器其实是一个管理其他资源管理器和处理器资源（比如，进程、线程、访问权限、程序、上下文等）的资源管理器。TP监控器在这个意义上

18、说很像一个操作系统，但是还好跟操作系统有很大不同，通常来说操作系统根据一个长期的基准给请求分配资源，而TP监控器必须根据每个请求的分配资源。其次在每创建一个会话时，操作系统所带的所有管理任务必须在每个请求上由TP监控器执行。最后TP监控器在崩溃之后进行重启时，必须支持所有的应用程序和所有的资源管理器，操作系统通常只要关心自己的系统文件。它的基本功能为：1)调度 从客户端来的请求必须放到实现应用服务的服务器程序中。并且正确的执行完毕，回滚也是属于正确的执行完毕。因为回滚并没有破坏系统的一致性。它首先确定处理请求的服务。若服务是远程的，那么请求将通RPC发送到那儿。若服务位于本地，检查是否有一个为

19、其服务的服务器已启动。苦没有，调用负载平衡的组件来决定是为其建立一个新的服务器，还是请求应该等到下一个服务器可用。最终，调度器将请法度发给服务器。2)服务器类管理 TP监控器负责启动服务器类，负责负载平等和所有相关的任务。在这里它负责的是启动数据库的服务器及其它重要的事务资源管理器。要确保对于每个应用程序，有一个服务器类被建立和处于激活状态。3)认证和授权 在执行请求服务前，TP监控器必须了解请求。用户并没有登录到了操作系统，只是注册到了TP监控器。但是，因为操作系统并不经常执行授权动作，因而TP监控器不得不对每个请求进行授权，它主要是基于如事务程序名、远程主机名、时间等一系列参数的原则。所有

20、这些都在请求时根据用户配置文件进行检查。4)资源管理 TP监控器负责管理终端、数据库、用户和所有事务处理系统中的其他组件。它们的信息被保存在系统中心库中，然而应用访问中心库的唯一方式是通过TP监控器的管理接口来进行。定义了应用程序和其要交互的设备间的接口。现实的做法是，有一组资源管理器实现各种表示对象，通过事务RPC向TP监控器提供接口来表示服务。5)系统操作 TP监控器必须向操作者提供足够的信息来调整系统，在普通操作过程中产生问题（终端断开、服务器类的问题和其他很多的情况）时通知他们。6)恢复 系统崩溃后，TP监控器负责重建进程配置。7)队列管理 支持队列事务处理。队列的主要功能是接受请求并

21、将其传给相应的服务器，接受响应结果并将其发送给相应客户机。当且仅客户事务提交请求时，请求被放在一个请求队列中。一旦一个请求位于请求队列中时，它将很快得到执行。仅当服务器事务提交时结果才放到响应队列中。队列中的每个响应结果将由通过TP监控器被发送给客户端。根据不同的应用和消息的不同内容，要求有不同的发送保证（要和事务的ACID特性一致）。8)上下文管理 是一个TP监控器服务，它能用于所有的事务程序。它包括两个功能：第一个功能是保存处理上下文，第二个功能和正在运行的事务的上下文有关。3.2.2日志管理器的功能说明日志管理器是从资源管理的角度来描述的，而日志管理程序是从程序角度来描述的。在实质上的理

22、解应该是一样的，没有分别的。首先要说明一下为什么需要日志管理程序，日志本身的设计实际上是一个顺序存取类型的SQL表，然而在写日志方面由于具有以下特殊的性质，日志管理器的设置就成为了必要。1)封装性 日志管理器对日志记录头的封装只是为了确保正确地填写这些头字段信息。日志管理器为其他资源管理器提供接口，用以写日志记录体的内容，而日志头是日志管理器私有的。2)启动 系统重启时，日志管理器用于重构那些永久的系统状态。3)谨慎写 日志通常是双工的，并依据某种协议写日志。这是因为，已经提交的事务更新的数据的唯一永久副本是日志。日志管理程序的基本功能：1)日志管理程序为所有其它资源管理器和事务管理器提供对日

23、志表的读写访问。2)日志管理程序为日志表提供面向记录的读接口和插入-刷新接口，资源管理器使用这些接口记载关于持久（可恢复）对象的改变信息。如果某个事务需要被撤消或重做，这个事务管理器使用这些接口读回这些日志记录交给资源管理器去处理。日志表中顺序地存放着日志记录，每个记录都有一个头，头中包含了资源管理程序的名字、对该记录进行写操作的事务的名字和日志管理程序所能理解的日常信息。每个日志记录中的大部分是日志体，它包含了所有的UNDO-REDO信息，这些信息是由写这个日志记录的资源管理器生成的。日志管理程序并不理解日志体的内容，仅仅是将它们看成字符串。日志记录体通常有几百个字节，但也可能是几百兆字节。

24、3.2.3锁管理器的功能说明这部分是为了实现并发，由另一位同学研究和设计的。最后的目的是为了实现事务处理中的隔离。这里就不进行说明。3.2.4事务管理器的功能说明事务管理器除了能够正常的标识、开始、执行一个事务。当有失败的情况出现时，也要由事务管理器来协调恢复，根据不同的情况具体的实现也就不同：1)事务回滚 事务管理器协调事务回滚到一个保存点或干脆取消（中止）该事务，这种回滚和中止可以由任何参与者发起。2)资源管理器重启 如果一个资源管理器失败并重启，则由事务管理器提供给它回到最近提交状态所需要的日志记录。3)系统重启 计算机系统重启时，事务管理器帮助局部资源管理器恢复其永久性状态，同时，也解

25、决在系统崩溃或关机时处于不确定状态的所有分布式事务，这种机制也能实现事务管理器的重启。4)介质恢复 如果一个对象被破坏，通过使用这个对象的归档副本和自从这个对象归档以来的所有对其更改的日志，事务管理器可以帮助资源管理器重建该对象。现在只考虑单一事务管理器的事务和数据。如果是涉及到几个机群的事务可能涉及到几个事务管理器。如果对一个联网的数据库系统来说的话，情况也应该是这样的。4设计与实现4.1事务处理的简单模型因为要设计的事务处理是为数据库服务的，所以用到多级事务模型。首先来看事务监控器对一个远程事务的处理流程：入队队列事务请求判断权限有成功事务计算出队队列发送到客户错误消息图3事务监控器对一个

26、远程事务的处理一个远程事务请求开始，事务监控器判断其权限，然后把事务放到永久队列中，从队列中取出事务进行事务计算。将计算的结果放到另一个队列中，发送到客户端去。事务管理器对事务的控制过程：事务请求分配事务标识符资源分配第一阶段提交第二阶段提交成功失败事务结束事务回滚成功失败图4事务管理器对事务的控制过程发起一个事务请求，事务管理器为该事务分配一个唯一的事务标识符，事务管理器在正常情况下只是维护事务的ACD特性。参与事物的所有资源管理器将进行第一次表决时，这是第一阶段提交，如果第一阶段提交通过，那么进行第二阶段提交，事务管理器强制写日志表。标识事务已经完了。第二阶段提交后，事务管理器向各个资源管

27、理器通知事务已经结束，资源管理器将调用锁管理器，释放锁。如果在第一阶段有资源管理器不同意，事务回滚。进行补偿事务的调用，补偿事务是一定会成功的。（如果失败，表示系统的设计与实现有问题）。如果是远端的，事务监控器将把请求通过通信管理器发送出去。接收到一个远程处理，首先由事务监控器来判断是否有权限，然后把这个事务请求放入一个永久的队列中，从队列中取出进行计算，将结果放到一个永久队列中，由通信管理器将一定策略来发送，这里的策略是向终端连续发生三次。如果事务回滚将回滚的信息通过通信管理器来发送回终端。在一个事务的提交过程中都是要写日志的，后面的回滚和恢复数据根据日志来的。它是很重要的。下一节的内容是各

28、个组件的具体设计。4.2具体的设计与细节4.2.1事务标识符的设计事务标识符是很重要的对于事务处理来说。对于一个事务处理，事务标识符必须始终是唯一的，每一个事务标识符（trid）标识一个具有ACID属性的工作单元。此外trid能方便地表示出创建它的事务管理器，事务管理器也必须要记住有多少事务，有可能会丢失事务，就得由事务本身来标识自己在事务管理器中是第几个事务。所以事务标识符的数据结构由一个三元组组成组成第一个元素birthday是事务产生的时间，第二个元素TMID是事务管理器的标识符，对于在网络上的事务处理是很有用处的，对于本地机的事务处理这个编号是没有作用的。第三个元素counter是事务

29、在事务管理器中建立的序号。一般来说事务标识是由一个可变的整型数组来表示。对于多级事务的标识来说，顶层事务，标识事务标识的整型数组由一个元素构成，随着事务层次的逐渐降低，表示事务标识的整型数组的元素个数逐渐，这是因为新的子事务的标识由其父事务标识和一个区别兄弟事务区分的新元素构成。这个策略简单，也能满足事务的大部分需求，但是空间开销大。所以在具体的设计与编码时是考虑用位段来存其标识的。下面是一个事务标识的结构Typedef structTIMESTAMP birthday; /TM能记忆的最前的时间 TMID tmid; /事务管理器标识符，在网络中唯一 unsigned a:8TRID4.2.

30、2事务处理监控器的设计当一个事务从终端发送过来，并没有直接发送给服务器。事务处理监控器获得这一信息，对其权限进行检查之后。通过一定的策略启动服务，有时并不是马上启动服务。判断请求的类型，如果请求是一个立即的，马上执行，结果迅速返回，如果请求不是一个立即的，一般就要将它放到一个持久的队列中，如果在执行立即事务时，服务器为请求服务时出现了一个峰值一般的解决方法是建立一个临时的队列，峰值消失的时候该队列也就消失了。用异步方式高度事务处理请求需要使用队列。原因是有以下两个方面：在直接的联机事务处理中，暂时性的系统过载会导致对某一资源管理的请求在相应的服务器类前等待。这时构造的队列是挥发的。TP监控器把

31、它们作为临时控制块在自己共享数据结构池中维护。第二类型的队列是用于队列事务处理的，这种事务处理的特点就是异步。请求被发送到永久的请求队列中去，而不是通过TRPC从请求的一方直接发送到服务器上的。4.2.3日志管理器的设计日志管理程序把日志作为SQL表来实现，因此通过SQL查询可以读日志表。日志管理程序用一组操作来封装日志的写操作。对日志表的设计，在日志表中，每个记录都有唯一的码，称做日志序号。下面是用SQL语言表示的日志表定义：create domain LSN unsigned interger(64);-日志序号（文件号，rba）create domain RMID unsigned in

32、terger(64);-资源管理程序标识符create domain TRID unsigned interger(64);-事务标识符create table log_table(lsn LSN, -记录的日志序号prev_lsn LSN, -日志中前一个记录的lsntimestamp TIMESTAMP, -日志记录的创建时间resource_manager RMID, -写这个日志记录的资源管理器trid TRID, -写这个记录的事务tran_prev_lsn LSN, -该事务的前一个日志记录（或0）body varchar, -日志数据。primary key (lsn) -lsn

33、为主码foreign key(prev_lsn) -前一个日志记录在这个表中 references log_table(lsn), -foreign key(tran_prev_lsn) -该事务的前一个日志记录也在这表中 refernces log_table(lsn), -)entry sequenced; -在文件尾进行插入日志文件通常是双工的，以免单个日志文件的存储失败造成日志破坏。而且这两个物理文件序列通常被分别存放在不同的目录空间中，这主要是为了降低日志被破坏的风险。系统初始化后，首先为日志分配两个物理文件，随着日志的增长，这些文件被写满之后，系统会再分配另外的两个物理文件来登记下

34、个日志记录。这个过程是可一直持续下去的。双工的两个日志文件将使用标准的文件名，并分别以LOGA和LOGB格式结尾，这里的0用该文件在日志目录中的文件索引来填写。由于可用算法计算出第n个日志文件的名字，所以日志管理程序只要维护一个记录就可以描述每个日志（这个记录只需要存储日志文件名的公共前缀和当前日志文件的索引）：如下伪代码所示：struct log_files filename a_prefix;/”a”日志文件的目录 filename b_prefix;/“b”日志文件的目录 long index;/当前文件的索引这个信息构成日志锚点这种数据结构的核心内容，日志锚点在主存中缓存，且至少被记录

35、到持久存储器的两个不同的地方，通常是在两个文件中，这样是考虑到系统重新启动时可以找到日志锚点。日志序号如前所述，每个记录都有一个唯一的标识符，将这个标识符称为日志序号（LSN）。LSN是由记录的文件号和这个记录在文件中的相对字节偏移量组成的。LSN的定义如下：typedef structlong file; /在日志目录中日志文件号 long rba; /记录（第1个字节）在文件中的相对字节地址 LSN；/日志序号定义日志读写的细节设计:读日志问题相对比较简单。除了最后一个日志记录外，不用加锁就可读取所有日志记录，但是最后一个日志记录正在被更新时，它是不能被读取时。日志管理程序对大多数日志页采

36、用乐观读取方式：只读双工日志的一个副本。当然有一定危险性的。可以通过维护一个标志来检测这种情况：在每个日志页上设置一个标志量，标志量的什用来指示这个页是否已满。因为日志是顺序写入的，所以除了最后一页外所有的页都是满期的，标志量值都置为真。由于最后一页大多数都江堰市缓冲在内存中，因而其存取不需要I/O操作。这样便可以进行安全的乐观读。在写日志时，要谨慎写：串行写和乒乓写，双工日志表可以屏蔽绝大多数介质故障，但是有一种情况则不行。最后一个日志页的信息未满期，下一个日志记录将被加到这个日志页上。如果在写的过程中断电，或处理器错误，这种简单的写操作会损坏原来页中已有的信息。处理这个问题的办法有两个，一

37、个是串行写，先写一份日志（副本），当这个日志写完后，再写另一个日志（副本）。串行写花费的时间是原来的两倍。另一个办法是乒乓写算法。假设日志的最后一页称为pagej，pagej非空，并且打算用新增的数据覆盖pagej。这种情况下，先将新增加的数据写入pagej+1，而后在pagej+1和pagej之间乒乓式来回重写。当从磁盘读入的时候，必须读最后两页（j和j+1）并且接受时间戳较大的那页。4.2.4锁管理器的设计锁管理器的设计由另一位同学设计。此处不再提出。在这里事务管理器只是负责了事务特性的A（原子性）、C（一致性）、D（永久性），I（隔离性）由锁管理器去负责。4.2.5事务管理器的设计在正常

38、处理中，资源管理器和系统都不会失败。应用程序通过Begin_Wrok()、Save_Work()、Prepare_Work()、Commit_Work()、Rollback_Work()及Read_Context()调用事务管理器，此外资源管理器通过ldentify()和Join_Work()调用事务管理器。事务管理器数据结构是这样的：事务管理器连同TP监控器一起保存了一个数据结构，用以描述已调用ldentify()的每个资源管理器。同时，事务管理器为每一个活的事务也保存一个数据结构，这个结构包括该事务的状态、日志记录、参与这个事务的资源管理器以有分配给该事务的会话。作为应用接口，所设计事务管

39、理器提供了如下的命令以供调用：TRID Begin_Work(context *);/开始一个事务Bool Commit_Work(context *);/提交该事务void Abord_Work(void);/回滚到保存点0savepoint Save_Work(context *);/建立一个保存点savepoint Rollback_Work(savepoint);/返回到保存点（返回到保存点0即中止）Bool Prepare_Work(savepoint);/将事务置为准备就绪状态context Read_Context(void);/返回到当前保存点上下文TRID Chain_Wor

40、k(context *);/结束当前事务，开始下一事务TRID My_Trid(void);/返回当前事务标识符TRID Leave_Transaction(void);/设置进程TRID为空，返回当前标识符Bool Resume_Transaction(TRID);/设置进程TRID为期望TRIDenum tran_statusACTIVE,PREPARED,ABORTING,COMMITTING,ABORTED,COMMITTED;tran_status Status_Transaction(TRID);/返回一个事务标识符状态关于Begin_Work()它的逻辑是：分配一个新的事务标识符

41、，在事务表中加一个入口项（entry），对该入口项进行格式化以反映保存点1。然后，事务管理器写一条开始事务日志记录，这会引起日志管理程序对那个日志记录在该事务入口项中设置min LSN和max LSN指针，日志管理程序维护该LSN字段，锁管理器维护translock_list。事务可以建立一个持久的保存点（意思是重启时仍然存在），则Begin_Work()请求把日志记录强制写入持久性存储器。最后，设置该里程事务标识符为该trid，从这类保存点直到进程提交、中止或离开该事务，该进程的一切工作和它发出的所有RPC都用这个trid来标识。下面是有关这个处理的伪代码：TRID Begin_Work(c

42、ontext * it,Bool soft)TransCB * trans;/事务描述符TRID him;/新的tridTM_savepoint save;/被写入的保存点记录if(MyTrid()!=NULLTrid) return (NULLTrid);/保持其为空Him=TM_anchor.next_trid;/赋值给它的下一个tridTM_anchor.next_trid.sequence+;/使下一个trid加1(MyProccess()-trid=him;/令其为该进程的trid/分配，格式化事务控制块Trans=malloc(sizeof(TransCB);/分配一个事务入口Tr

43、ans-next=TM_anchor.tran_list;/将事务加入到事务列表中TM_anchor.tran_list=trans;trans-trid=him;/设置它的tridtrans-status=ACTIVE;/设置它的状态为“活动的”trans-save_pt=1;trans-next_save_pt=2;/当前保存点为1，下个保存点为2trans-RM_list=trans-lock_list=trans-ses_list=NULL;/还有会话、锁及资源/格式化，写开始事务（保存点1）日志记录save.record_type=begin;/设置日志记录体类型save.save_

44、pt_num=1;save.soft=soft;/格式化保存点记录save.num_RM=save.sessions=0;/仅仅是现在参与的事务管理器copy(save.it,it,it.length);/加入它的上下文trans-save_pt_lsn=log_insert(save,sizeof(save);/写开始事务日志记录/给出log_insert()如何更新min lsn和max lsnif(!soft)log_flush(trans-max_lsn,FALSE);/如果是持久化的开始，强制写入日志return (him);/返回trid给him;提交事务很简单。通过调用 资源管理

45、器的Prepare()回调请求，资源管理器投票，；通过发送Prepare()TRPC，进行投票表决，然后，可以投赞同票也可以投反对票。若都为赞成票那么事务准备提交。此时，提交调用 写一条提交记录（保存点记录），并强制其写入持久存储器。然后，提交操作向局部资源管理器及通过Commit() TRPC向远程会话广播这个提交决定。当它们都做出响应时，事务管理器就在日志中写一条完成记录，释放事务控制块。整个Commit_Work()逻辑大致如下：Bool Commit_Work(context *it ,Bool lazy)if Prepare_Work()/尝试准备事务commit();/如果准备成功

46、，那么做第2阶段工作elseRollback_Work(0);一般来说问题都出在提交的阶段1，如果在提交的阶段2出现了错误，事务管理器最终必须发送该消息并从资源管理器或远程事务管理器处得到响应。下面是这种情况下的大致代码：void session_failure(SECB* session)/向远程TM持久发送Commit()TRPCTransCB* trans=MyTransP();/指向进程的事务描述符的指针Bool timeout=TRUE;/表明TRPC超时的标志TM_savepoint save;/被格式化的完成记录RMID TM=session-him;/接受commit()回调的

47、远程TM的名字while(timeout)/重复TRPC直到有确认TM.Commit();/通知远程事务管理器提交free session;/如果有确认，则从事务中释放会话if(trans-RM_list=NULL & trans-ses_list=NULL)/如果所有的资源管理器都完成（被释放）而且如果所有的联出会话已提交trans_status=COMMITTED;/进入committed状态save.record_type=commit_complete;/设置日志记录类型为已完成log_insert(save,sizeof(save);/惰性写完成记录dequeue and free

48、frans structure;/释放事务控制块，已完成exit();/进程完成，结束进程;事务的回滚逻辑：UNDO扫描程序反向扫描日志，回滚能返回到以前的任一个保存点。当UNDO扫描程序到达要求的保存点时，事务管理器轮询每个资源管理器，请它重新实例化该保存点。最终，UNDO扫描程序找到一个所有资源管理器都同意的保存点，或到保存点0（事务全部撤消），资源管理器无论如何是不允许否决保存点0。代码如下：long Rollback_Work(long target_savepoint)TransCB * trans=MyTransP();/指向进程事务描述符的指针TM_savepoint save;

49、/被格式化的保存点记录LSN lsn;/用于撤消扫描的lsnRMID rmid;/从日志记录中抽取出的rmidlog_record_header header;/保存日志记录头的缓冲区bool abort=FALSE;/表明UNDO失败，以便中止该事务if(MyTrid()=NULLTrid)return (0);/事务已经中止lsn=trans-max_lsn;/得到最后一条日志记录的lsn/UNDO扫描程序反向扫描日志while(lsn!=NULLLSN)/在日志中进行撤消扫描log_read(lsn,&header,save,sizeof(save);/读日志记录头rmid=header.rmid;/提取资源管理器标识符rmid.undo(lsn);/调用它撤消日志记录if(timeout