分布式数据库技术：面向对象数据库系统中的事务

2023-10-28 理论教育版权反馈

【摘要】：可串行化是经典数据库事务并发控制的正确性判据。抽象数据类型集合的前向交换关系兼容和后向交换关系兼容分别如表15.3和表15.4所示。下面从可交换性上来讨论面向对象数据库的事务管理问题。对象系统中，如果使用封锁技术，则封锁颗粒会有变化。这是因为没有把对象的语义考虑在内。ADT上的事务执行需要多级机制。

可串行化是经典数据库事务并发控制的正确性判据。关于可串行化有很多讨论，其中涉及一些重要概念，如交换性、可恢复性等。

1.交换性

交换性（commutativity）强调的是两个操作如果按不同的顺序串行执行，结果会不同，则它们是冲突的（conflict）。反之，它们是可交换的。

我们来考察两个简单操作R（x）和W（x），它们分别表示读操作和写操作。如果不知作用在对象x上的读/写操作的语义，则先执行R（x）再执行W（x）与先执行W（x）再执行R（x）是不一样的，两种情况下R（x）读出的值是不一样的。前面章节里已使用兼容表说明过操作间的冲突与否关系。但是，前面只从语法角度来看读/写操作，故文献上称为语法交换性（syntactic commutativity）。

如果考虑操作的语义，则可获得更有效的冲突意义。特别是在面向对象环境下，有些写-写和读-写的并发执行可以看成是非冲突的。

【例15.10】考虑一个抽象数据型，即集合型，在其上定义三个操作：插入（Insert）和删除（Delete），与关系数据库里的Write对应；成员（Member），测试成员关系，与关系数据库里的Read对应。按照操作的语义，集合型上的两个插入操作与集合型上的两个插入实例操作有时是可交换的。令集合S=｛1，2，3｝，有两个操作是a=Insert（3），b=Insert（3），则a、b是可交换的。

Weikum在其攻读博士学位论文期间讨论了基于交换性的并发控制问题，他和其后来的研究者提出了前向可交换性与后向可交换性的概念。他（们）将冲突关系定义为考虑操作间的二元关系，考查的是操作及其结果。将操作定义为调用和响应的偶对，例如x：［Insert（3），ok］是一个有效的调用，在集合x上实施一个插入操作，返回正确值（这里用ok表示）。

有两种不同的交换性关系，它们可以定义为前向交换性（forward commutativity）和后向交换性（backward commutativity）。

假设有两个操作P和Q，以及一个对象的状态s。前向交换性定义如下：每个状态s上定义的P和Q，P（Q（s））=Q（P（s）），这里P（Q（s））是已定义的（即不是空状态），表示若先在s上施加Q操作，再在其结果上实施P操作，等价于先在s上实施P操作，随后在其结果上实施Q操作。

集合的前向交换关系兼容如表15.3所示。

表15.3　集合的前向交换关系兼容表

pagenumber_ebook=354,pagenumber_book=339

后向交换性定义如下：每个状态s上的P和Q，P（Q（s））是有定义的，即Q（s）已定义，而P（s）不知是否已定义，则P（Q（s））=Q（P（s））。当然，这里的P和Q也可以扩展为操作序列，而非仅是单个操作。

【例15.11】抽象数据类型（ADT）集合的前向交换关系兼容和后向交换关系兼容分别如表15.3和表15.4所示。表中，Member操作定义为成功执行后返回代码（true）和非成功执行后返回代码（false）。

表15.4　集合的后向交换关系兼容表

pagenumber_ebook=354,pagenumber_book=339

【例15.12】如果集合对象的初始状态是｛1，2，3｝，集合对象上的第一个操作是一个调用-响应对［Insert（3），ok］，第二个操作是［Member（3），true］，这两个操作定义在｛1，2，3｝上，则用哪种序给出的结果都是一样的。然而，如果应用操作［Insert（3），ok］后，状态是｛1，2，3｝，则无法说出初始状态究竟是｛1，2｝还是｛1，2，3｝。因此，对于一个集合对象而言，［Insert（x），ok］和［Member（x），true］是前向可交换的，但不是后向可交换的。

2.可恢复性

可恢复性（recoverability）是另一种冲突关系。直观地说，一个操作P是对另一个操作Q可恢复的，如果P返回的值独立于Q，无论Q是在P前执行还是在P后执行。

下面从可交换性上来讨论面向对象数据库的事务管理问题。(www.chuimin.cn)

对象系统中，如果使用封锁技术，则封锁颗粒会有变化。下面考虑一个事务模型。从对象结构考虑，先区分几类不同的对象：简单对象（如files、pages、records）、作为ADT实例的对象、完整对象（full-fledged objects）和增加了复杂性的主动对象。

前面的讨论基本上是简单对象。有些系统虽提供记录级的并发控制，但管理开销很大，记录上的操作不是原子性的，需要进行页面级同步。这是因为没有把对象的语义考虑在内。例如，更新页面被看成是写页面，而不去考虑逻辑记录是否在这个页面。

从事务处理角度看，ADT引入了处理抽象操作的需求。抽象操作产生了对语义的需求。ADT上的事务执行需要多级机制。在这样的系统中，自底向上，一级是另一级的抽象。将事务看成是由操作集合构成的偏序，操作可能不是简单操作，而是一个事务。抽象操作由更低一级的抽象构成，这么分解下去直到最底层的简单读/写操作。正确性判据就变成面向应用了。

值得一提的是，必须考虑下面这些问题。

●运行组合对象上的事务可能会涉及作用在成分对象上的附加事务，从而形成嵌套事务。这种事务需要按多级处理。

●子型/继承性涉及行为和对象状态的共享。因此，必须考虑在某个级别存取一个对象的语义。

●必须区分被动对象和主动对象。主动对象的事务管理需要触发子型或相应的事件-条件-动作（ECA）响应规则的支持。

如上所述，对象DBMS中的事务管理必须处理组合（聚集）图，能显示组合对象结构、型（类）格、表示对象之间的is-a关系。

组合（聚集）图需要处理存取对象的同步，这种对象有其他对象作为成分，形成复杂结构。形成的型（类）格通过事务管理器来考虑其模式演化。

对象DBMS还将方法和数据封装在一起。对对象共享存取的同步必须考虑方法的执行，特别是事务调用方法，该方法会依次调用其他方法。这样，即使事务模型是平面的，这些事务的执行也可以动态嵌套。

典型情况是将冲突定义为存取相同对象上的两个操作是不可交换的。值得注意的是，对象DBMS中，存取两个不同对象的操作也可能产生冲突。原因是存在组合（聚集）图和型（类）格问题。

考虑存取对象x上的一个操作O1，它有一个成分是另一个对象y（即x是一个组合或复杂对象）。还有另外一个操作O2（假设O1和O2属于不同的事务）用于存取y。按照经典的冲突定义，我们不会认为O1和O2是冲突的，因为它们存取的对象不同。然而，O1把y看作x的一部分，在存取x时也要存取y，这样就与O2产生冲突。

方法的嵌套调用导致嵌套2PL算法（nested 2PL）和嵌套时标序（nested timestamp ordering）算法等的开发。处理时，可以采用对象间并行来改进并发度。换句话说，对象的属性可以建模为数据库里的一个数据元素，方法可以建模为事务，可以同时调用一个对象方法，可以同时激活。可以使用特别的对象外同步提供更多的并发性，并在每个对象上维持同步决策的兼容。

对象上的方法（建模为事务）执行由本地步（local steps）和方法步（method steps）组成，前者对应于本地操作（如读取简单属性值）的执行，一起返回结果值，后者是方法调用和返回值。本地操作是一个原子操作（如Read、Write、Increment），它们会对对象变量产生影响。

唯一的要求是它们能“正确”执行，即基于交换性可串行。作为各对象间同步委派的结果，并发控制算法集中在对象内同步。

文献中还提出了多颗粒封锁（multigranularity locking）。多颗粒封锁定义了封锁表数据库颗粒的分层体系。对象DBMS里，各自有类和实例对象的对应关系。

这种分层的好处是强调粗糙颗粒封锁和精细颗粒封锁的折中。粗糙颗粒封锁（在文件中或更高层次）有较少的封锁开销，因为设置的封锁数目少，所以大大减少了并发性。精细颗粒封锁情况则相反。

多颗粒封锁背后的主要思想是，对粗糙颗粒封锁的事务蕴含对所有相应对象的精细颗粒封锁的事务。例如，对文件的封锁蕴含对文件上所有记录的封锁。除传统的共享（S）锁和排外（X）锁外，还可以增加两个新的封锁类型，即意向（intention）（或称隐含（implicit））共享（IS）锁和意向排外（IX）锁。如果事务试图在对象上施加S锁或IS锁，则必须先在其祖先（即粗糙颗粒的相关对象）上施加IS锁或IX锁。同样，事务如果想在对象上设置X锁或IX锁，则必须在其所有祖先上设置IX锁。意向共享锁在其后代封锁期间不能释放。

当事务试图读相同颗粒的对象和在精细颗粒上修改这个对象某些部分时，会产生另外一个复杂问题。此时，在这个对象上必须同时设置S锁和IX锁。例如，事务可能读一个文件，并更新这个文件里的某些记录（这在面向对象数据库系统中是经常发生的，事务可能读类的定义，并更新该类的某些实例对象）。为了处理这种情况，必须引入共享意向排外（SIX）锁，它等价于该对象上拥有的S锁和IX锁。学术界对此有很多研究，有兴趣的读者可以参阅相关文档，这里不再赘述。

分布式数据库技术：面向对象数据库系统中的事务

相关推荐