主动数据库事务(数据库)

时间：2022-12-09 12:30:01 | 来源：信息时代

时间：2022-12-09 12:30:01 来源：信息时代

    主动数据库事务 : 数据库系统中保持数据一致性的基本控制单位。主动数据库系统中事务可分为两类,一类是为执行应用程序由用户定义的事务,另一类是为执行规则由系统创建的事务,规则事务需要与用户事务同步进行。因用户事务的执行可能发生某个事件而触发相应规则的执行,该规则的执行又可能触发另一个规则的执行,这样的执行是一种嵌套结构,相应事务的执行也是嵌套的,称为嵌套事务。为触发规则创建的事务称为被触发事务,而引起规则被触发的事务称为触发事务。由于规则不同的耦合模式,形成了不同的事务处理模式。
在基本嵌套事务模型中有两类事务: 嵌套事务和顶级事务。一个嵌套事务是包含在另一个事务中的事务,称为嵌套子事务,这另一个事务称为子事务的父事务。顶级事务是不包含在任何事务中的事务。一个顶级事务可以有多个子事务,一个子事务还可以有多个子事务,从而形成一棵事务树。在一个嵌套事务内部,处在同一层上的多个子事务可以串行执行或并行执行,而处在不同层上的子事务自底向上执行。事务的提交也是自下而上的,只有所有的子事务都提交后顶级事务才能提交。如果顶级事务夭折则整个事务树也夭折。
以上事务模型是基本嵌套事务模型,也称封闭的嵌套事务模型。此外,还有多种扩展的嵌套事务模型。如在有的嵌套事务模型中不要求保证顶层事务的原子性,其事务的部分结果对其他事务是可见的,称为开放的嵌套事务模型。
除了基本嵌套子事务外还有两种类型的嵌套(子)事务:
(1)延迟嵌套子事务:是指嵌套子事务要延迟到顶级事务执行后事务提交前才能执行。如果一个嵌套事务中有多个延迟型子事务,则这些延迟子事务在顶级事务执行后并行执行。如果任意延迟型子事务又派生另外的子事务,若该子事务是延迟型的则要在所有上层延迟型子事务完成后再执行,延迟子事务的提交通过顶级事务提交,以保证顶级事务的原子性。
(2)嵌套顶级事务: 是由其他事务执行时引发的,但不是形成子事务而是独立于其他事务的顶级事务。嵌套顶级事务可以有自己的事务树,但对启动它的事务没有任何权力,即不能看到启动事务任何非提交的更新数据,嵌套顶级事务的提交和夭折都是独立的。
在主动数据库中,规则条件的评估和动作的执行是在不同的事务中处理的。当规则被触发后,系统首先创建条件评估事务,评估规则的条件是否成立。如果规则的E-C耦合模式为立即型,则条件评估事务作为触发事务的子事务在触发点创建并立即执行,而触发事务被暂停直到条件子事务执行完后再继续执行; 如果规则的E-C耦合模式为延迟型,则条件评估子事务为延迟嵌套子事务,该子事务在触发点创建但要延迟到触发事务执行完后才能执行; 如果规则的E-C耦合模式为分离型,则系统为条件评估创建一个嵌套顶级事务独立于触发事务执行。如果规则的条件成立,则系统将创建另一个子事务以执行规则的动作。规则动作事务的创建和执行由规则的C-A耦合模式决定。在规则的条件评估或动作执行期间可能会引发事件,该事件又触发了另一个规则。同样地,系统要为触发规则创建相应的条件评估子事务,如果规则条件成立,系统也要为规则的动作执行创建另一个子事务,从而形成了事务的嵌套执行。
在实际应用中,对嵌套顶级事务有不同的处理模式。嵌套顶级事务与触发事务可以串行执行,也可以并行执行。这样处理可能会出现被触发事务提交而触发事务夭折的情况,这对于一些应用是不允许的。例如,在销售管理中,一次销售使库存量低于限额而引发订货的动作,动作的执行不应作为销售事务的一部分,应该以分离方式执行。但负责重订货的事务只有在原触发事务的销售持续下去的情况下其执行才有意义。这类应用,在触发事务与被触发事务间存在因果关系。为满足这类应用,在嵌套顶级事务的基础上,提出了嵌套(causallydependent,CD)顶级事务,即具有因果关系的嵌套顶级事务。嵌套CD顶级事务与启动它的事务间具有因果依赖关系,即事务提交依赖于启动它的事务的提交,如果启动它的事务夭折,则CD顶级事务也跟着夭折。但是,CD顶级事务的夭折不会对启动它的事务有任何影响。如销售管理的例子中,负责重订货的事务就可以采用嵌套CD顶级事务执行,如果销售事务夭折,则重订货的事务也跟着夭折。嵌套CD顶级事务有两个变种,一种是嵌套顶级事务的执行要等到启动它的事务提交后才能执行,即嵌套顶级事务的执行与启动它的事务具有顺序依赖关系。例如,要将传感器的输出在屏幕上显示,一个分离耦合规则用来更新传感器输出的变化,在具有顺序依赖的嵌套顶级事务的执行能够使输出显示正确反映更新次序。还有一种是嵌套顶级事务与启动它的事务的执行是并行的,但只有当启动事务夭折后它才能提交,即嵌套顶级事务作为启动它的事务失败后的一种补偿。如果启动事务成功提交,则嵌套顶级事务将夭折。例如,在工程管理中,工程事务要求在某一关键时刻之前完成,如果此事务执行时发现可能赶不上预定的进度,系统会调度一个起弥补作用的事务,此事务与原触发事务并行执行,如果在预定时间内触发事务完成,被触发事务将中止。
数据库系统中,当事务失败后应将数据库恢复到一致状态。主动数据库系统中的恢复是很复杂的,主要和规则事务有关。其主要原因是: 有些事件是不可恢复的,有些外部动作是不可逆的,还有一些耦合模式允许被触发事务的提交在触发事务之前进行。封闭嵌套事务总是通过顶级事务提交,因而封闭嵌套事务是可恢复的。与数据库操作有关的事件总是可以恢复的。其他事件如暂时事件,有的可以恢复有的是不可以恢复的,因有些事件在恢复过程中不可能再生成。事件日志应清楚地记录与事件相关的所有内容,如事件所触发的规则、是否是复合事件的组成部分等。一般的恢复原则是: 由提交事务引发的事件在事故发生前所执行的动作应该被恢复,在事故发生前未完成的动作如果是可恢复的应由该事件重新引发再执行。以分离模式被触发的规则事务以及嵌套CD顶级事务必须能保证它的执行,即系统应提供相应的机制保证这些规则的执行。因为触发事务已经提交而用户并不知道分离的被触发事务的失败,因而不能采取相应的措施。因分离模式下的事务不依赖于触发事务,因此,分离模式应该用于触发事务能够容忍分离模式事务失败的这样一些应用中,或在这些应用中能定义补偿事务已弥补事务失败的影响。