（计算机系统结构专业论文）基于corba的事务处理系统的研究.pdf

、 摘要 摘要 本论文主要讨论了基于c o r b a 的事务处理系统。在讨论基于c o r b a 的事务处理系统 的过程中，着重讨论基于c o r b a 的事务处理系统与传统的事务处理系统的差异。而讨论 基于c o r b a 的事务处理系统，又必须对c o r b a 与数据库的集成进行研究。从数据库集成 的角度看，有两种集成的方案：是数据库本身通过使用c o r b a 接口输出服莠提虿毛幂r c o r b a 的紧密集成；二是集成发生在应用层。本论文主要研究发生在应用层的集成。 在研究基于c o r b a 的事务处理系统前，先总体讨论了事务与事务处理，以及a c i d 属性和两阶段提交协议。最后探讨c o r b a 和对象事务服务( o t s ) 如何与高级事务模型 ( 如s a g a 事务和嵌套事务) 结合以支持复杂企业工作流。 1r 、 关键词：c o r b a 拿醇事务处理数据库集箴 7 t 摘要 a b s t r a c t t h i s p a p e rm o s t l y d i s c u s s e st h et r a n s a c t i o n p r o c e s s i n gs y s t e m b a s e do n c o r b a ( c o m m o n0 b j e c tr e q u e s t b r o k e r a r c h i t e c t u r e ) t h e d i f i e r e n c eb e t w e e nt h e t r a d i t i o n a it r a n s a c t i o np r o c e s s i n gs y s t e ma n dt h et r a n s a c t i o np r o c e s s i n gs y s t e mb a s e do n c o r b ai se m p h a s i z e di nt h ed i s c u s s i n gp r o c e s so nt h et r a n s a c t i o np r o c e s s i n gs y s t e mb a s e d o nc o r b a t h et h ei n t e g r a t i o no fc o r b aa n dd a t a b a s em u s tb er e s e a r c h e db e f o r et h e r e s e a r c ho nt h et r a n s a c t i o np r o c e s s i n gs y s t e mb a s e do nc o r b a t h e r ea r et w oi n t e g r a t i o n p r o j e c t sf r o mt h ea n g l eo f d a t a b a s ei n t e g r a t i o n ：o n ei st h ed a t a b a s ei t s e l fo u t p u t ss e r v i c et o s u p p l y t h e t i g h ti n t e g r a t i o n w i t hc o r b ab yu s i n gc o r b ai n t e r f a c e ；t h eo t h e ri st h e i n t e g r a t i o n o c c u r si na p p l i c a t i o nl a y e r t h i sp a p e rm o s t l ys t u d y st h ei n t e g r a t i o no c c u r r e di n a p p l i c a t i o nl a y e r t h et r a n s a c t i o np r o c e s s i n gs y s t e m ，t h et r a n s a c t i o np r o c e s s i n gc o n t r o l l e r , t h eq u a l i t yo f a c i da n dt w o p h a s e ss u b m i s s i o np r o t o c o la r ed i s c u s s e da saw h o l eb e f o r es t u d y i n gt h e t r a n s a c t i o np r o c e s s i n gs y s t e mb a s e do nc o r b a t h i sp a d e rp r o b e si n t oh o wt oc o m b i n e c o r b aa n do b j e c tt r a n s a c t i o ns e r v i c ew i t ha d v a n c e dt r a n s a c t i o nm o d e l ( e t c s a g at r a n s a c t i o n a n dn e s t i n gm o d e l ) t oh o l do u tc o m p l e x e m e l p r i s et a s kf l o w k e y w o r d ：c o r b a t r a n s a c t i o nt r a n s a c t i o np r o c e s sd a t a b a s e i n t e g r a t i o n 绪论 绪论 近年来，c o r b a 已从一学术研究课题转变为主流技术。c o r b a 结合了计算机工 业中两个重要的趋势：面向对象软件开发和客户机h e 务器计算。本论文主要讨沦了基 于c o r b a 的事务处理系统。这涉及到数据库集成、事务、事务处理等复杂的问题。 传统的事务处理系统是以对象数据库管理系统为基础的，而大多数传统的对象数据 库管理系统是以两层结构来设计的，即数据库客户机和数据库服务器。数掘库客户机通 过数据库管理系统提供的某种机制( 如嵌入式s q l 或者o d b c ) 访问数据库服务器。 这些访问机制通常负责提供些使事务开始的方法，让数据库客户机能在事务上下文中 发出查询和更新命令，并且最后终止事务。 一方面，对象请求代理o r b ( o b j e c tr e q u e s tb r o k e r ) 提供了分布性、互操作性和 技术集成，也提供了面向对象技术；另一方面，数据库提供了数据持久性、数据完整性、 事务、并发数据访问和分布性。很自然地，我们想拥有这两者的优点，而又不愿失去各 自的特性。这就导致了c o r b a 与数据库的集成。从c o r b a 与数据库集成的角度看，有 两种集成的方案：一是数据库本身通过使用c o r b a 接口输出服务，提供和c o r b a 的紧密 集成；二是集成发生在应用层。本论文主要研究发生在应用层的集成。这种应用层集 成自然导致了三层结构的系统，即客户机、应用程序服务器和数据库服务器。客户机通 过应用程序服务器输出的 d l 接口来访问应用程序服务器。应用程序服务器扮演了双重 角色，一方面是c o r b a 服务器，另一方面作为数据库客户机访问数据库服务器以获得持 久状态信息。 o d b m s 使用户能以极其有效的方式在高度复杂的对象图中导航。通常导航逻辑在 第二层，即在某个数据库客户机中实现。大多数o d b m s 还提供机制把查询直接送到数 据库服务器，这样查询就可在第一层进行最有效的评估。c o r b a 关系服务使关系可被 第三层访问：c o r b a 对象间的关系可以表示为c o r b a 对象。它使用户能用标准的 c o r b a 机制来表达和导航关系。实际上，第三层中的导航关系由于简单的性能原因受 到严重的限制：从一个对象到另一个对象的每一步都包括多个远程激发。不同于o d b m s 客户机，c o r b a 客户机没有标准的方法在本地捕捉对象和关系的信息。 本论文所讨论的基于c o r b a 的事务处理系统和c o r b a 核心服务部分是分开的。 因为现在还没有集成化的解决方案。 论文将在以下方面展开讨论： 1 如何使用c o r b a 组件来完成实际的业务需求。 2 如何将c o r b a 和数据库的各自优点结合起来，以形成三层的体系结构。 3 在c o r b a 环境下，事务处理的几种方式的特点及各自的欠缺。 三l 塑坠塑皇箜竺望墨竺塑堑壅 4 最后，鉴于具体商业事务的复杂性以及商业事务很难映射为面向a c i d 系统事 务，所以论文初步地探讨如用高级事务模型何将商业事务用系统事务来实现。 总之，本论文的重点在于在建立基于c o r b a 的事务处理系统以及c o r b a 与数掘 库集成的过程中，探求一种实用、可行的方法，并对出现的问题逐一加以讨论和解决。 稍 t 第一章个基fc o r b a 的例子 第一章一个基于c o r b a 的例子 住讨论c o r b a 的技术特性时，很难把它和现实问题关联起来，为此，本论文引入一个例子，它 演示了一些业务需求，这些需求可驱动用户开发c o r b a 系统，并说明如何使州c o r b a 组件来完成 这些需求。在本论文的其它章节也会用这个例子来阐明c o r b a 设计和开发的特殊方面。这是一个住 金融信息服务和股票交易领域中的例子。这个例子包括两个组件。第一个组什通过提供关丁股票价 格的信息来供应简单的金融信息服务。第二个组件证券管理系统，它使川金融信息服务米提供像计 算特定投资的当前价值等的服务，可以在 n g e r n e g 上提供证券管理。 1 1 s t o c k w a t c h 组件 第一个演示组件称为s t o c k w a t c h 例子，提供对历史股票数据的访问。服务器假设 客户机想选择一特定的股票，然后再访问该股票价格的历史。演示客户机实现简单的 g u i ，它显示可选择股票的代号，并根据所选择的特定代号来显示股票的历史价格。图 1 1 是简单的g u i 客户机的概貌。 ” 图1 1s t o c k w a t c hg u i g u i 客户机和金融信息服务器通信，这个服务器依次访问数据库来获取股票信息。 服务器实现两类c o r b a 对象：s t o c k w a t c h 对象，它允许客户机选择特定的股票；s t o c k 对象，它提供对特定股票信息的访问。在使用g u i 客户机时，系统有一简单的三层体系 结构，如图1 2 所示。 s t o c k w a t c h 和s t o c k 对象的i d l 如下所示： 4 基于c o r b a 的事务处理系统的研究 h i d l ：s t o c k w a t c he x a m p l e | b a s i ct y p ed e f i n i t i o n s i t y p e d e fs t r i n gd a t e ； t y p e d e ff l o a tm o n e y ； t y p e d e fs t r i n gs y m b o l ； t y p e d e fs e q u e n c e s y m b o l s e q ； h e x c e p t i o n s | | e x c e p t i o nr e j e c t e d ( s t r i n gm _ r e a s o n ； l s t r u c t s “ s t r u c ts t r u c t l n f o ( m o n e ym _ p r i c e ； d a t am _ w h e n ； ) ； t y p e d & s e q u e n c e p r i c e i n f o s e q ； | | i n t e r f a c e s i | i n t e r f a c es t o c k ( s y m b o lg e t s y m b o l ( ) ； s t r i n gg e t d e s c r i p t i o n ( ) r a i s e s ( r e j e c t e d ) ； m o n e yg e t c u r r e n t p r i c e ( ) m i s e s ( r e j e c t e d ) ； p r i c e l n f o s e qg e t r e c e n t p r i c e s ( ) r a i s e s ( r e j e c t e d ) ) ： i n t e r f a c es t o c k w a t c h ( s y m b o l s q lg e t s y m b o l s ( ) r a i s e s ( r e j e c t e d ) ； s t o c kg e t s t o c k b y s y m b o l ( i ns y m b o la s y m b 0 1 ) 第一章一个基于c o r b a 的例子 r a i s e s ( r e j e c t e d ) ； ) ： 客户机通过获取s t o c k w a t c h 对象的引用来首次接触金融信息服务器。s t o c k w a t c h 接口包括两个操作： g e t s y m b o l s ( ) 返回所有已知股票代号的列表。 g e t s t o c k b y s y m b 0 1 ( ) 返回和特定代号相关联的s t o c k 对象。 s t o c k w a t c h 对象作为金融信息服务的进入点，允许客户机获取与特定股票相关联 的s t o c k 对象的引用。 当客户机得到s t o c k 对象的引用后，它就可以查询对象来取得相应股票的信息： g e t c u r r e n t p r i c e ( ) 返回股票的当前价格。 g e t r e c e n t p r i c e ( ) 返回近来股票价格的历史。 g e t d e s c r i p t i o n ( ) 返回股票的文字描述。 顾客 金融信息供应者 l jl 图1 2s t o c k w a t c h 框架 为获取股票价格的信息，服务器使用嵌入的s o l 和关系数据库管理系统交互。下面 显示了用来存储股票和股票价格的数据库表： s t o c k 表 s t r i n gs y m b o l s t r i n gd e s c r i p t i o n 表1 1 s t o c k p r i c e 表 s t r i n gs y m b o l n u m b e rp r i c ed a t ed a t e 表l2 s t o c k 表使用股票代号作为主健。s t o c k p r i c e 表使用股票代号和f 1 期的组合。在 s t o c k p r i c e 表中，s y m b o l 列也是- 夕1 - 部关键字，它使股票价格和s t o c k 表中的输入相 关。 这样的数据库中数据量可能是很大的，这是由于股票数量很多，而且还必须存储历 基于c o r b a 的事务处理系统的研究 史数据。另外，表的内容可能很频繁地改变，股票的价格每天都要改变多次，而且这些 改变必须在长时间内捕捉。 1 2 证券管理器组件 在本论文中，描述c o r b a 设计和开发问题时，要参考s t o c k w a t c h 应用程序。为了 描述其中的一些问题，必须扩展这个例子以便对更多问题讨论。所以引入一个客户机应 用程序，称为证券管理器( p o r t f o l i om a n a g e r ) 组件。 证券公司想向其客户提供基于i n t e r n e t 的证券管理系统。公司向其客户提供简单 的g u i ，用于和后台的证券管理器通信。证券管理器是一c o r b a 服务器，它实现一些分 布式对象。证券管理器g u i 如图1 _ 3 所示。 证券管理器的i d l 如下： c o r b ai d l ： # i n c l u d e 图1 3 证券管理器g u l 第章一个基于c o r b a 的例子 i n t e r f a c eh o l d i n g ； i n t e r f a c ep o r t f o l i o ( m o n e yg e t c u r r e n t v a l u e ( ) ； s y r n b o l s e qg e t s y m b o l s ( ) ； h o l d i n gg e t h o l d i n g b y s y m b o l ( i ns y m b o la s y m b 0 1 ) ) ： i n t e r f a c eh o l d i n g ( u n s i g n e dl o n gg e t n u m b e r o t s h a r e s ( ) ； s t o c k g e t s t o c k ( ) ； ) ； 7 基t - c o r b a 的事务处理系统的研究 第二章o o r b a 与数据库集成的讨论 c o r b a 平数据库技术可以集成来支持持久性c o r b a 对象。o r g 提供了一些重要特征，如分布性、 互操作性年技术集成，也提供了面向对象的好处，如抽象和封装。另一方面，数据库提供了数据持 久性和数据完整性、事务、并发数据访问和分布性。本章讨论如何把这两种技术结合起米产生二 层的体系结构。 2 1 对象数据库和对象关系映射 2 1 i o d m g 提出的标准 对象数据库结合了c + + 等面向对象编程语言的语义和传统数据库系统的数据管理查 询工具。当对象数据库管理系统( o d b m s ) 与面向对象编程语言集成时，它应该能够直 接支持此语言的语义。也就是说，如果编程语言支持继承、封装和多态，o d b m s 也应该 支持这些特性。对象数据库不仅为面向对象编程提供了方便的持久性机制，还增加了并 发、事务和查询处理等额外的数据库特征。 o d m g 对象数据管理组( o d m g ) 的定义发展了一系列的所有对象数据库厂商都认可和实现 的标准。在o d i g 之前，缺乏对象数据库标准限制了它们更广泛的使用。关系数据库的 成功不仅是因为比以前有更高层次的数据独立和更简单的数据模型，它们的成功在很大 程度上是来自提出的标准。由于接受s q l 标准，所以允许了定程度的系统间可移植性 和可互操作性，简化了学习新的关系型d b m s ，并代表了关系型方法的广泛认同。o d m g 认 识到这些，并着手定义和精炼对象数据库规范。o d m g 标准的主要组件有：o d m g 对象模 型、对象定义语言( o d l ) 、o d l 的不同语言绑定，以及对象查询语言( o q l ) ： o d m g 对象模型o d m g 对象模型是基于o m g 对象模型的。通过向核心o m g 模型 增加o d b m s 轮廓，o d b m s 模型增加了对关系、查询、事务和持久性的支持。 o d l 对象定义语言可用于o d m g 兼容的数据库的规范语言之一就是o d l ( 对 象定义语言) 。o d l 有点类似基于s q l 的、广泛用于关系数据库的数据定义语 言( d d l ) 。但是，像o m g 的i d l 一样，它不是完整的编程语言，而是接口标 记的一种规范语言。 o d m g 语言映射o d l 提供了映射的声明部分。o d l 映射成多种编程语言，如 c + + 、s m a l l t a l k 和j a v a 。在开发者看来，只有一种语言，而不是两种分别的 语言。对于c + + ，o d l 和c 十+ 之间的映射表示成类库和标准c + + 类定义语法的一 个扩展。 第二章c o r b a 与数据库集成的讨论 o q l ( 对象查询语言)o q l 是类似s q l 的声明语言，为查询数据库对象提供 了丰富的环境，包括对象集合和结构的商层原语。o q l 提供了s q l9 2s e l e c t 语法的超集。这意味着大多数运行在关系型d b m s 的s q ls e l e c t 语句可以用 相同的语法和语义工作于o d m g 集合类上。o q l 还包括了对象扩展，以支持对 象标识、复杂对象、操作调用和继承。o q l 的查询能力包括在o d m g 语言绑定 中调用操作，o q l 也能从o d m g 语言程序内部调用。 2 1 2 对象关系映射的基本映射技术 下面解释用于o r 映射的基本映射技术，包括讨论从基本面向对象概念( 如类、关 系和继承) 到关系型世界的映射。 1 从类映射到表 对象关系映射的基本思想其实很简单：类映射成表，对象实例映射成行，对象属 性映射成关系表中的列。图2 1 显示了基本对象关系映射。 类 表 方法 1 y 属性1 基于c o r b a 的事务处理系统的研究 一s t o c kp r i c e 表有一个外键s y m b o l ，指向s t o c k 表的一行。 不同的连接表关系还可以通过创建一个额外的表( 连接表) 来表示。这 种方法有时增加了灵活性，但也增加了开销，因为显式的连接表在执行查 询时需要额外的连接。通常，连接表只用来表示多对多对象关系。 折叠类最后，可以把类折叠进单个表以合并它们。通常，这只用于一对 一关系和属性。作为折叠类的一个例子，假定要用一个新的、稍微复杂的 类型表示金钱；金钱对象有两个属性：货币和数量。股票价格有一个金钱 类型的属性。出于性能考虑，可以直接向s t o c k p r i c e 表加两列：c u r r e n c y 和a m o u n t ，而不用定义一个新表m o n e y 。 4 继承 关系模型中并不提供继承的概念。因此，把对象模型的继承层次映射到关系框架中 并不容易。对象模型的继承映射到关系模型中有几种可能方式，各有一定的优点和缺点。 例如，可以把每个类映射成相应的表，也可以只把类片断映射成表，或者把所有类映射 成单个的表。每种方式对于继承层次的变化，都有不同的表现特征和不同程度的灵活性。 2 1 3 水平分割 继承图中的每一个具体类映射成一个单独的表，每个表包含这个具体类的所有属性 的列定义，加上它从具体和抽象的基类继承来的所有属性的列定义。抽象类不映射成相 应的表。水平分割能支持多继承，列名可能用属性首次定义所在的类的名称。水平分割 提供的映射支持了简单的“每个类映射成一个表”的概念，并为强类型控制操作提供了 图2 2 水平分割 良好的性能。图2 2 的例子显示了水平分割如何查找有两个特例( 可选股和优先股) 的 基类股票。获取所有优先股的请求只需要单个地返回整个集合的简单查询；本质上发出 一个“s e l e c t f r o mp r e f e r r e d s t o c k ”s q l 调用。如果抽象基类之一或者继承图根 第二章c o r b a 与数据库集成的讨论 部附近的具体类发生改变，比如另外加一个属性，那末从这个类派生出的每个具体类都 必须改变。从查询的角度看，一个弱类型的查询将需要多表查询以及结果的聚集。例如， 为了取得所有股票对象，必须发出三个分别的s q ls e l e c t 查询；一个用来获取所有的 股票实例，第二个用来获取所有可选股实例，第三个用来获取所有的优选股实例。这些 中间结果集合必须合并起来产生一个包含所有股票的统一集合。也可能通过定义一个覆 盖水平分割框架的关系型视图来使这类查询更为有效。 2 1 4 垂直分割 每个派生类映射成一个新的表，只包含此类中显式定义的那些属性。另外，每个表 都包含到其基类对应表的外键。通过在派生类的表中包含多个外键来支持多继承。扩展 和修改也很容易实现，因为只需改变一个表。但是，任何获取派生类表的实例的查询 都需要至少一次连接；当继承层次很深时，还需要多重连接。这影响了操纵数据的所有 操作( 插入、查询、更新和删除) 的性能。垂直分割的一个例子如图2 3 所示。 讣键 图2 3 垂直分割 v 共型描述符 图24 统一 在同一根分支下的各层次所有抽象类和具体类被映射成单个的表。一个增加的列 基于c o r b a 的事务处理系统的研究 叫做类型识别器，用来标识每一行的实际类型。大多数情况下，使用实际类名来表示。 这种映射不遵从关系型设计的规范化规则。因此，表可能非常大，特别是当一个叶子类 定义了大量属性的时候。当用到抽象父类时，这种映射最为有利，即不存在抽象类的实 例，虽然它定义的属性出现在每个派生类中。统一方法的一个例子如图2 4 所示。 2 1 6 自顶而下和自底而上 对象关系映射有两种方式：把对象存储到关系表中，以及通过对象访问关系表。 通常，这两种方法分别被称为自顶而下和自底而上。自顶而下方法的思想是从对象模型 丌始着手，并由此派生出关系型数据框架。自底而上则从关系型数据框架开始，并由此 派生出对象模型。 自顶而下方法注重于事务逻辑，例如用u m l 来描述通用模型。然后可以从对象模型 派生出关系型数据框架。设计派生的关系型数据框架时，要保证性能和数据完整性。在 类和表之间并不总能够用简单的一对一映射。数据框架必须适应关系型世界的特殊性。 关系型数据框架常常被规范化，以避免冗余和更新异常。但是，极端规范化常常可能导 致低性能、高度零碎的数据和急剧增加的复杂性。 在关系型数据框架已存在，并且改变框架很不可取的时候，自底而上方法是最常用 的。在这种情况下，分析关系型框架，并试图派生出既反映业务逻辑又反映关系型框架 的对象模型，假如关系型框架己被规范化，这可能特别困难。这时，通常必须把多个表 映射成一个类，以便一个对象实例能代表数据行的一个集合。这种方法称为封装。 支持遗留系统 如果要建立的应用程序依赖于访问己存在于关系数据库中的数据，那术会发生什末 昵? 首先，充分观察业务领域，包括从业务对象模型到关系型框架的新映射。这种方法 意味着数据要在各种( 所有权) 的数据存储中复制。但这甚至不是一对一复制；相反， 需要对原数据作转换，以把它复制到新应用程序使用的数据库中。如果新应用程序要使 它的一些数据用于已有的任何应用程序，那末可能需要编写特别的数据通路。这种方法 引起的数据管理的复杂性，不可避免的需要采用其它方法，使得新应用程序可以从已有 的框架中访问( 至少一些) 数据。我们不再定义从业务对象模型到持久数据框架的映射， 而是需要一种混合的处理方法，先用逆向工程从关系型框架产生出对象表示，然后建立 封装器来提供自己的业务对象模型和那些类之间的基本映射。这个抽象层在应用程序本 身的对象模型和遗留应用程序的关系框架之间提供了一个缓冲，方便了底层数据的透明 访问，但这种方法有一定的代价。抽象层隐含地理解了两个模型，因而任一个系统的改 变都需要它作相应的改变。不但抽象代码难以维护和易于出现错误，而且会影响性能， 尤其当应用程序业务对象只是代表表示关系数据的数据访问对象时。总的来说，任何额 外的重定向都会降低应用程序的性能和灵活性。 2 1 7 数据一致性 第二章c o r b a 与数据库集成的讨论 保证数据一致性的最自然方法是用事务的概念。几乎所有的数据库管理系统，包括 o d b m s ，都是基于事务概念的。事务是逻辑上组合以形成一个原子行为的一系列操作，它 把系统持久数据从一个一致性状态转换到另一个。这意味着，在事务执行期问，系统状 态可能不。致，所以保持事务彼此隔离是重要的，以便能看到它们内部的不一致状态。 这也称为事务的串行化( s e r i a l i z a t i o n ) ，因为即使事务并发执行，事务机制也必须保 证其效果和串行执行时完全一样。 为保证事务串行化，d b m s 必须提供使并发事务彼此隔离的机制，也叫并发机制。商 用d b m s 上最普通的并发控制技术是加锁。如果事务t 2 要访问特定数据项，在访问前它 必须得到此数据项的锁。如果另一个事务t 1 已经得到了此数据项的锁，并且和t 2 需要 的锁不相容，就出现了加锁冲突，必须作适当处理。两类最普遍的锁是读锁和写锁。但 d b m s 可能提供其他的锁类型。 隔离级别 加锁通常代价很大，所以隔离经常在性能、并发性和数据一致性之间折衷。为能灵 活调整以反映性能、并发性和数据一致性的需求级别，大多数数据库管理系统支持不同 级别的隔离。 a n s i i s o5 q l 9 2 标准定义了四级隔离。几乎所有商用d b m s 都提供至少一种隔离级 别；很多甚至能为不同事务配置使用不同隔离级别。这四种隔离级别中每种都和并发执 行的事务之间出现的三种现象之一有关。这三种现象是： 脏读取事务读取的数据已被另一个没提交的事务更改。 无重复读取事务重读先前己读过的数据，并发现在两次读取之间数据已被 另一个已提交的事务更改或删除。 幽灵读取事务重复执行查询，返回满足特定查找条件的行的集合，并发现 另一个已提交的事务已经插入了满足这种特定条件的额外的行。 基于这三种现象，s q l 9 2 标准定义了四级隔离。根据事务正在运行的隔离级别，可 能不允许这些现象出现，或者允许这些现象的一部分或全部出现： j隔离级别脏读取无重复读取幽灵读取 不提交读取可能可能可能 已提交读取不可能可能可能 重复读取不可能不可能可能 串行不可能不可能不可能 表2 1 必须注意，只有串行隔离级别提供完全的隔离即充分保证数据一致性。所有其 它的隔离级别都为了增加并发性和有利于性能而接受可能的数据不一致。 基于c o r b a 的事务处理系统的研究 2 1 8 数据同步 和数据一致性密切相关的是数据同步。考虑一个场景：用户有一个台式电脑和笔记 本电脑，用来读电子邮件和编辑文档。他如何在这两台计算机之间使数据同步呢? 文档 的标准方法是手工来回的拷贝文件。这常常导致出现有微小差别名字的很多临时文件。 另一个问题是，电子邮件程序可能使用专有的文件格式，可能不支持两台计算机之间的 简单同步。虽然有很多工具可以帮助解决这些特殊问题，但是这个讨论说明了数据同步 的一般问题。 下面从对象持久性的角度探讨数据同步的两个重要部分：缓冲和复制。 1 缓冲 o d b m s 相对于一般r d b m s 的主要优点是它们提供了成熟的、特定于业务领域的缓冲 机制。r d b m s 通常只在数据库服务器提供缓冲，并且这些缓冲是基于表结构而不是基于 业务领域逻辑的。相反，o d b m s 通常在数据库客户机端提供缓冲机制，并且允许在应用 层对缓冲机制进行微调。一个通用技术是定义逻辑上关联的对象簇，它们可以被缓冲机 制成组地管理。这是面向对象方式下结构化数据的一个主要优点，因为它使业务对象之 间的依赖关系可以在缓冲策略中得以反映。这些特定于应用程序的缓冲策略是o d b m s 在 操纵复杂关系图的导航时大大优于r d b m s 的一个主要原因。 缓冲和事务相关的程度的问题。一些缓冲机制只在事务周期内缓冲数据。大多数 o d b m s 只在一次事务上下文内允许访问对象，并在这次事务结束时从本地缓冲区中清除 所有对象。但是，有一些缓冲策略跨事务边界维持缓冲。这时，就必须引入特殊的同步 机制来保证数据一致性。通常，在想修改或从缓冲区写回元素时，可以用时间戳机制来 比较缓冲版本和数据库版本。既然通常不处理单个缓冲区，而是多个缓冲区，就需要考 虑某种缓冲区同步机制。如果数据在数据库中改变了，我们要向相关缓冲区通知这个事 件，以便它们能更新缓冲区入口或者使缓冲区入口无效。这样，就减少了由于缓冲区入 口不一致造成的潜在错误数量。 2 复制 复制的主要目的通常是改善系统可用性和响应时间。无论是持久数据或者活动服务 器进程都可以复制。下面讨论数据复制。一个重要问题是复制的数据应该以怎样的程度 同步。例如在f t p 镜像中，并不期待复制镜像总能和主服务器完全同步通常镜像和 主服务器之间在一天或者一个星期中同步一次就足够了。 另一方面，可能已经复制了要求所有的镜像被实际同步复制的系统。这通常需要分 布式事务处理，细节在第四章讨论。一种方法是主从复制，即在主拷贝上进行更新处 理，并从这罩对从拷贝进行更改。 2 2c o r b a 业务对象 第二章c o r b a 与数据库集成的讨论 2 2 1o d b m s o d b m s 为遍历对象关系提供了高度优化方法，这是由于它实现了成熟的缓冲策略 并且常常通过一些方法，把对象分成簇以使应用程序能优化缓冲工具。 o d b m s 客户机o d s m s 服务器 图2 5o d b m s 对象图导航 图2 5 显示了典型的o d b m s 客户机如何遍历一个对象图，客户机第一次访问对象时， o d b m s 把对象状态取回到由o d b m s 管理的客户机端缓冲区。多数o d b m s 被优化，以减少 从数据库服务器下载数据的次数，下载不仅是下载请求的对象，还下载下次可能访问的 其它对象的状态和关系信息。 在图2 5 中，客户机访问的第一个对象( 1 a ) 导致获取整个一组相关对象进入缓冲 区( 1 b ) 。如果现在客户机想导航关系( 2 ) 以访问相关对象( 3 ) ，因为它已活动于缓冲 区，故无需再次请求数据库服务器。o d b m s 提供的集簇技术越好，对缓冲区的利用就越 好，在导航复杂对象图时，这对于保证高性能是重要的。 2 2 2c o r b a 关系服务 c o r b a 关系服务使用i d l 表示关系：两个c o r b a 对象间的关系由实现接口 r e l a t i o n s h i p 和r o l e 的c o r b a 对象来表示。导航i d l 表示的对象存在的问题是导航 ( 1 3 ) 的每一步都是一次远程访问，并且每次远程访问都附加一定的开销。另外，关 系涉及了太多相对重量级c o r b a 对象。因此，遍历一个由c o r b a 关系服务表示的关系， 将比遍历一个使用具有高度优化的缓冲和集簇机制的o d b m s 慢几个数量级。本规范对这 个问题的解释很模糊。例如，规范称g e t _ o t h e r r e l a t e d _ o b j e c t ( ) 操作能“通过缓冲 其它角色和相关对象的对象引用来实现”。这并没有说明如何为相关对象的簇而管理关 系信息的缓冲。规范模糊地提出了通过选择对象工厂来管理集簇，但是没有说明如何在 单个行为中实际地缓冲集簇的关系信息。最后，即使规范允许实现有效缓冲机制，i d l 编译器生成的标准桩也是不够的：我们需要特定于客户机的方案来实现缓冲管理。 基rc o r b a 的事务处理系统的研究 c o r b a 客户机 c o r b a n 务器d b m s 服务器 图2 6 使用关系服务遍历关系 这样，c o r b a 关系服务看来主要适用于需要独立于数据存储的关系访问和高层抽象 系统，这些系统对性能和可伸缩性没有太高的要求。在性能可伸缩性非常重要时，很难 找到有效方法来用c o r b a 客户机从第三层有效的遍历关系，这一点必须反映在i d l 涉及 上。 查询处理 和关系紧密相关的问题是查询处理。我们先考虑c o r b a 查询服务，然后在讨论不同的折 衷方法前，看看可替换的方法。 22 3c o r b a 查询服务 c o r b a 查询服务实际说明的是一般数据操纵，包括选择、插入、更新和删除，所以 它更像是数据操纵服务，而不是简单的查询服务。查询服务使用谓词来处理查询，并设 计为独立于任何特定的查询语言。但是，需要特别指出的是，实现必须至少支持s q l 9 2 或者o q l 9 3 。提供在集合上操纵数据，并执行于服务器端的操作的查询服务方式看来很 有前途，尤其在远程导航关系问题上。理想的情况是，查询服务的实现应和d b m g 紧密 集成。查询服务还缺乏可用的商用实现。 2 2 4 无状态伺服对象 无状态伺服对象作为暂时的实体，代表了使用s q l 向数据库服务器输入的i o p 请 求，这意味着无状态伺服对象在i d l 接口操作语义和s o l 查询问提供了某种转换。 很多b o a 代的o r b 并不提供对无状态伺服对象的很好支持，因为它们在o i d 和伺服 对象之间实现了一对一映射，即，一个伺服对象只能为一个特定的c o r b a 对象处理请求。 是否值得用对象池模式来减少对象故障数量，取决于伺服对象激活和冻结，那么，把无 状态伺服对象保留在池中以减少对象激活和冻结的频率就可能很有意义。如果o r b 运行 于并不附加很大丌销，那么，可能在预请求的基础上激活和冻结伺服对象更好些，减少 了池管理的开销。 第二章c o r b a 与数据库集成的讨论 对p o a 代的o r b ，管理无状态伺服对象较为容易，例如使用缺省伺服对象能控制所 有输入的请求，而不考虑目标对象标识。缺省伺服对象包含了来自p o a 的目标对象标识， 并用它来为此服务构造合适的查询。 无状态伺服对象是使用c o r b a 来输出那些用底层数据库实现的服务的很普遍方法。 对比一下今天成千上万i n e r n e t 应用程序使用的、结合了h t m l 、h t t p 和c g i 的方法， i n t e r n e t 客户机向h t t p 服务器发送h t t p 请求，激活了c g i 脚本来执行请求。c g i 脚本 是典型无状态的，并用s q l 把h t t p 请求委托给数据库服务器。使用c o r b a 无状态伺服 对象在思想上类似于这种方法，但是还提供了c o r b a 的其他好处，包括面向对象系统提 供的强大的抽象，c o r b a 服务的更高层框架和请求参数的自动打包和解包。 2 2 5 有状态伺服对象 使用有状态伺服对象时，首要问题是伺服对象状态是否绑定于事务边界。如果伺服 对象状态仅在单个事务期间保留于内存，这种方法很少有问题，如果试图在事务外把状 态信息保留在内存，就可能很困难。通常，这种方法需要完成成熟的缓冲同步机制。但 是很少有商用数据库试于支持跨事务的缓冲区同步例如，提供有效的触发机制来同 步缓冲区。 除了事务边界，还必须看看进程边界。在进程级，必须保证缓冲区在应用程序服务 器间同步：很多c o r b a 系统有镜像应用程序服务器。缓冲区同步有很多方法，如用多点 传送技术来公布更改。 通过实现十分简单的缓冲策略，仅缓冲只读的值或不常改变的值，可能获得显著的 性能增益。例如，股票对象实现能在缓冲区内保留股票的符号，因为股票符号很少改变 这时，缓冲区能够被有效的管理，例如，在发生改变时简单地使应用程序的所有缓冲区 无效。 一 对象池模式之所以称为对象池，是因为其目的不是维持对象缓冲区，而是解决资源 管理问题。即使此模式能够用于为持久对象实现特定于应用程序的缓冲策略，这似乎也 是一个复杂的任务，尤其在频繁改变的值需要细粒度的缓冲区同步时。下面简单讨论 o r b 如何与o d b m s 集成，以便不必在应用层处理缓冲，而能依靠o d b m s 缓冲区管理。 2 2 6 数据库适配器 一些o r b 厂商指出：通过提供自己专有的数据库适配器来具体说明对象数据库适配 器的结构，这一点还缺乏c o r b a 标准。例如，i n o at e c h n o l o g i e s 提供建立数据库适配 器的类属框架，可用来集成o r b i xo r b 和o d b m s ( 如v e r s a n t 和o b j e c t s t o r e ) 。这个框 架的关键概念是把c o r b a 对象是实现和持久对象相分离：o r b 向临时伺服对象发送输入 调用。此伺服对象只有一个成员变量，即一个灵巧指针。伺服对象使用这个灵巧指针简 单地把每个调用委托给持久对象。多数o d b m s 支持灵巧指针的思想，它负责保证在访问 缓冲对象前目标对象存在于本地缓冲区，如图2 7 所示。 基于c o r b a 的事务处理系统的研究 。 图2 7o r b o d b m s 集成 。 临时伺服对象和持久对象的完全分离是重要的，这样避免了在持久对象中和临时的 指定o r b 的数据成员有关的问题。这里陈述的解决方法基本能用于任何o r b ，问题只是 如何实现伺服对象。另一个要对象数据库适配器解决的问题是c o r b a 对象标示符转换成 灵巧数据库指针。多数o d b m s 提供了灵巧指针和字符串之间相互转换的工具。这种串形 式的o d b m s 对象i d 能嵌入于c o r b a 对象i d 。最后，对象适配器需要处理事务。通常o d b m s 不允许应用程序在事务外访问对象。因此，适配器必须管理事务。 c o r b a 数据库适配器帮助我们集成了持久对象和c o r b a 对象实现，以建立持久c o r b a 对象。但是，这只是c o r b a 和数据库集成得更大问题中的一小部分。例如，这里讨论的 c o r b a 数据库适配器，并没有解决如何把c o r b ai d l 数据类型映射成可在d b m s 中存储 的数据类型的问题，反之亦然。这是将出现的持久状态服务要解决的问题。 2 3 系统体系结构 从集成的观点看，有两种明显的可能性：或者数据库本身通过使用c o r b a 接口输出 服务，提供和c o r b a 的紧密集成；或者集成发生在应用层次，由于缺乏可用的商业集成 产品，必须在应用层进行集成，这种应用层集成自然导致了三层结构的系统。 2 3 1 三层结构 三层结构的基本元素是客户机、应用程序服务器和数据库服务器。客户机通过应用 程序服务器输出的i d l 接口来