CIMS环境下基于客户/服务器体系的工程数据库事务管理

摘要：介绍了基于客户/服务器的EDBMS体系结构，分析了工程设计环境的特点，提出了基于该体系的工程事务模型，以及客户/服务器体系下的事务管理子系统的构成与特点。文中主要阐述了长事务的并发控制机制和封锁策略，并采用日志的方法实现事务的恢复机制。

关键词:数据库;数据库管理系统;数据管理;工程数据库;事务管理;客户/服务器

工程数据库管理系统(EDBMS)是计算机集成制造系统(CIMS)实现集成的关键技术之一。工程应用是一个多人、长期、分阶段的过程，其环境较传统的事务管理要复杂得多，传统的集中式数据库体系在许多方面不能很好满足工程应用环境的要求。随着高性能，低价格的工作站被广泛地推广和应用，以及计算机网络的日益成熟，一种适合工程设计环境的数据库管理系统体系结构—客户/服务器体系在工程应用领域逐渐显示出其卓越的性能。客户/服务器体系客户/服务器体系由以下若干模块构成:
(1)若干个用作客户的工作站(或微机)。这些工作站具有较强的运算处理能力，同时可为用户提供良好的图形界面。
(2)一个(或多个)高性能工作站(或主机)作服务器。
(3)一个将若干客户与服务器连接起来的局域网(LAN)。

1客户/服务器(erient/server)体系的三种结构

cllent/server体系根据其内存规模和客户工作站是否有盘可分为三种结构:基本型(SCS)，客户服务器型(cS)，增强型(Ecs)。scs型中的客户工作站是无盘工作站，其内存规模也较小，不能驻留一部分DBMs，DBMs的运行和维护完全由server完成;cs型的客户工作站也无盘，但其内存规模较大，可以驻留一部分DBMs，为serve:分担一部分DBMs的工作;Ecs型采用有盘工作站作客户，其内存规模也较大，可以驻留一部分DBMs。工程应用环境较传统的事务管理环境要复杂的多，因此EDBMs比一般的DBMs要复杂。这样一个复杂的系统如果完全放在server中，由主机运行，当主机为多个客户服务时，必然造成主机工作负荷过重，对主机的性能要求也很高。采用client/server体系，建立EDBMs的目的之一就是为了能充分利用工作站较强的运算处理能力来分担一部分EDBMs工作，减轻server的工作负荷，使其能为更多的client服务，从而提高数据库的共享性。Cs型和ECs型能攀好地达到这一目的。ECs型由于采用有盘工作站作client，用户通过checkln/checkout机制从共享数据库中获得所需的数据后，在client工作站磁盘中为自己建立私有库，从而大大降低了单个用户为完成某项任务对server的访间次数.所以在通常情况下，Ecs型的综合性能(吞吐量，响应时间，携带client数等)最优，cs型次之，SCs型再次之，文中给出了这三种体系结构在不同的工作方式下的仿真性能，但是由于工程设计环境中读数据操作远远多于修改数据操作，且服务器携带的客户数据不是很多，Ecs型的优越性能在这种环境中表现并不明显，因此选用cs型的client/server体系建立EDBMs，无论是成本还是性能都能较好地满足工程设计环境的要求

2基于客户/服务器的EDBMS体系结构

基于客户/服务器的DBMS，根据在服务器与客户之间传输的单元不同，可分为对象一服务器结构。页一服务器结构，文件一服务器结构，对象一服务器结构中服务器能够理解对象的概念，并可改进对象使用方法，其优点在于可大大提高网络利用率，减少不必要的数据在网上传输，但这是以增加服务器工作负荷为代价的。文件一服务器结构的server工作负荷大大减轻，server可为更多的client服务，提高了数据共享性，但网的有效利用率较低。文中通过比较这三种结构的DBMS的仿真性能，指出如果DBMS的簇机制有效且client工作站有足够大的缓冲区，则页一服务器结构的DBMS最为理想。这种结构中的服务器DBMS进程只处理页而不考虑对象的逻辑关系，服务器DBMs管理数据库页的存贮和检索，服务器部分的并发控制机制和恢复机制也是建立在页面基础上的。这种结构是在对象一服务器结构和文件一服务器结构之间作了折衷，它既兼顾了网的利用率的数据共享性，又兼顾了服务器与客户之间工作负荷的平衡。另外由于工程设计环境中，父项目库与子项目库、私有库之间通过Checkin/checkout机制成批的交换数据，因此采用页一服务器结构的EDBMs能较好地实现这一机制，达到较高的效率。其中，报文处理程序接收处理所有发送给EDBMS的报文，对象子系统可以提供高层的数据管理功能，包括查询优化、模式管理、大对象管理，并支持可版本化对象，复杂对象以及多媒体对象等。事务管理子系统管理并发地对象访问及系统恢复。存贮子系统提供数据对象在外存设备中以及缓冲区中的管理，并控制对象在它们之间的流动。Client/server体系不同于传统的集中式数据库管理系统之处在于共享的数据仍由server集中管理，而DBMs的运行由elient和server共同完成。基于该体系的EDBMs的优点在于，因采用高性能工作站作客户，有利于平衡客户和服务器之间的工作负荷，减轻服务器部分的压力，从而使服务器可为更多的客户服务，提高了数据库的共享性。此外高性能的图形工作站可为工程用户提供良好的图形界面，基于该体系的EDBMs也有利于开放式系统的建立。但是基于client/Server体系的EDBMs也有不足之处，主要表现在由于大量的数据在网上传输，容易在Server部分形成阻塞，从而降低了网络的传输效率。此外，基于Client/server体系的EDBMs较传统的DBMs更复杂，实现起来也更困难。
2.1事务管理
.在工程设计中，一个项目往往大而复杂，需要很多设计者紧密协作共同完成。因此设计人员常把一个项目划分为若干个子任务，每个子任务还可以继续划分，子任务之间存在着协作(Cooperation)和提交/子合约两种关系，通过这两种关系，一个设计任务被划分成树状的层次结构。为了支持这样的工程设计环境并提高事务的并发度，系统的事务管理机制应满足:支持长事务、支持协作事务、支持用户控制。支持上述要求的多用户CAD工程事务模型为:
(1)把事务看成一组完成某种特定任务的单位，是数据库一致性的单位，它包括长事务(LT)和短事务(ST)，LT在cAD中，主要是设计人员完成某个设计任务时的交互式设计过程，ST是一组用户定义的数据库操作，事务长短的划分是由具体设计环境决定的。
(2)设计者在开始设计时，在项目库上创建一个LT作为根LT，它在执行过程中可以生成若干个子LT和ST，由它们完成相应的子任务设计，根LT在提交前，必须进行全局一致性检查。
(3)每个子LT在物理上都对应于一个子项目库或私有库。一个LT只有在其所有子LT和sT提交或异常终止后，才能提交，在提交依赖上，子依赖于父，而父不依赖于子。子LT在完成后必须作局部一致性检查。
(4)为了支持协作事务间的交互性，定义了一个check区，一旦某事务的阶段性成果完成后，在该事务提交前，先把它放入check区，供别的和其协作紧密的设计者读取，这一过程可通过调用CoPy命令完成。这样可以不通过项目库就达到交换部分已完成的设计成果的目的。
(5)父LT和子LT通过eheek玩/eheekout机制交互操作。子LT取出它所需的所有数据对象后在父LT库中对这些对象封锁(共享锁或独占锁)，同时生成尸张checkout一list锁表，该锁表记录了子LT对这些对象的操作权限。嵌套事务的锁通过该锁表向下传播.
(6)在工程事务模型中，事务和项目库都是动态生成的。为了保证数据库的一致性，应严格按照二阶段封锁策略进行封锁，保证一组事务的调度是可串行化的。
2.2事务管理子系统
事务管理器所完成的功能包括:事务开始、事务结束、事务终止的管理、项目库局部一致性和整个数据库全局一致性检查、死锁的检测等，死锁管理器采用简单的“时间结束”(timeout)方法来实现。由于采用页一服务器结构的client/server体系建立EDBMs，因此server部分的锁管理器不考虑对象的逻辑关系，只对包含了某事务申请的对象的页面进行封锁，由cllent部分的锁管理器对该事务申请的对象进行逻辑封锁。对于ST，锁表被缓存在client缓冲区中，这样当该cllent中的其它事务申请同一数据对象时，clie尽锁管理器首先对该事务申请的置锁模式与数据对象上已置的锁模式的相容性进行判别。如果相容，则该事务可不经过server同意，直接从client缓冲区中获得所申请的数据对象;如果不相容，则该事务终止或等待。采用这种方法设计锁管理器，可减少客户对服务器的访问，提高了系统的性能，对于LT，由于复杂对象的封锁面很大，且LT经历时间长，所以锁表是建立在文件上。这样可以缓解系统对锁表大小的限制，而且当一个结点发生故障时，不至于由于事务的控制信息丢失而不能恢复，但这是以降低系统性能为代价的。日志管理器存贮了对象变化的记录，在终止一个事务或在事务执行过程中由于存在不一致性状态而需从系统的缓冲区中恢复时，日志被调用。恢复管理器中只包含了一个uNDo记录(前映象)，当一个事务提交时，不仅包含了被修改对象的页被存入磁盘，而且日志也被存入磁盘，采用的策略是:“WriteAheadLos”。在基于client/server体系的EDBMs中，分布事务的提交和终止采用二阶段提交/终止策略。在该协议中存在两类事务:协调器事务，负责协调在不同站点上的参与提交/终止的事务;参与者事务，在不同站点上参与提交/终止的事务。在工程事务模型中，协调器事务可由父LT来担任，而参与者事务可由子LT和sT担任。在第一阶段，协调器向所有参与者询问是否已准备好提交，并等待回答。如果每个参与者都回答准备好，第二阶段开始，协调器通知所有参与者提交。如果在第一阶段，有一个参与者回答失败或时间到，协调器在第二阶段通过所有参与者终止(Abort)。
2.3长事务并发控制
长事务通过checkin/checkout机制成批地存取数据，在c比nt中建立私有库，同时长事务的执行时间一般较长。因此为了提高并发度，并尽量降低锁的开销，作者在client中对长事务根据情况分别采用粒度封锁，复杂对象封锁和类层次封锁等多种封锁策略。如果对对象的查询只是浅度的，即只查询类本身的属性或其组成实例，而无需查询它的子类(即使实例本身是一复杂对象)时，采用粒度封锁策略。粒度封锁策略定义了五种锁模式:Is，Ix，x，s，slx。当一个类中的绝大多数实例都被访问时，在类上封锁，这样隐含了对每个实例都以相同的模式封锁;当一个类上只有少数几个实例被访间时，对被访问的实例封锁，而在类上加意向锁。类层次封锁采用以下这种策略:系统在以一个被访间的类为根的类层次中的所有子类上置显式锁。例如，如果一个类的定义被修改，系统在这个类和它的所有子类上置修改锁。如果以一个特定的类为根的类层次被查询，系统在以该类为根的类层次中的每个类上置读锁，如果被访问的类靠近类层次的叶子层时，这种封锁策略较理想。为了支持复杂对象的封锁，定义了两种引用:独立引用和依赖引用。被独立引用的对象可被共享，被依赖引用的对象不能被共享。为了提高并发度，我们采用只对复杂对象本身及其依赖性组成对象封锁，而对共享对象是否进行封锁根据授予用户的权限，由用户选择的复杂对象封锁策略。由于嵌套事务的锁是向下传播的，即子LT和sT必须继承父LT拥有的锁，因此在执行checkout操作时，对取出的对象封锁，将生成一张checkout一list表。该表随被取出的对象一起送到局部设计库中，以说明事务对取出对象的访问权限。该锁表中的锁有三种:读锁(R)、写锁(w)、拷贝锁(c)。拷贝锁不排斥其它LT的读写。恢复在EDBMs中短事务是恢复的基本单位，对短事务的恢复采用记日志(los)和设置检查点(checkPiont)的方法。日志的内容包括对数据库作修改的事务的Tid，被修改对象的旧值，被修改对象的新值。目前我们的恢复管理器只执行uNDo操作，定义的日志文件是前映象文件。为了有效地解决系统故障，使数据库能恢复到正常状态，EDBMs定期地设置检查点，保存数据库的当前状态。在EDBMs中可人为随时设置检查点或按照日志文件写满一定记录后由系统自动设置检查点。此外，系统还需建立一个记录，该记录包括在检查点上所有正在执行的事务清单以及事务最后一个日志记录的地址。
长事务最终都是由短事务构成，因此长事务可通过短事务的恢复而得到恢复。如果一个长事务所在的库出现系统故障，则可以用Restart消息将长事务的项目库恢复到某个一致状态。由于子LT执行的一些控制信息(锁表、事务控制表)是存贮在文件上的，因此恢复后的LT仍可对它的子IJT进行控制。如果设计者要撤销一个LT，只要对其父事务发出Abort消息，父事务所在结点的事务管理系统收到消息后，就会释放该子LT拥有的锁，在LT控制表中取消LTjd，结束它们之间的联系，并向设计人员报告。由于采用多级设计库，这一过程无需父LT的项目库做任何UNDo工作。

3结束语

client/server体系是一种很有前途的分布式数据库管理系统体系结构，基于该体系的EDBMS虽然较为复杂，但具有优越的性能，能较好地满足工程设计环境的要求。工程数据库系统的事务管理较传统的数据库事务管理有其特点，也更为复杂。本文提出了工程数据库的事务模型和相应的事务子系统，讨论了长事务的并发控制和恢复机制。实现一种既能满足工程应用要求又不至于过分复杂的长事务并发控制策略是作者追求的目标。