事务的模型

版权声明:本文为博主原创文章,未经博主允许可随意转载。 https://blog.csdn.net/fly2nn/article/details/61924869


    事务的实现,在不同的数据库系统中是不同的,这是因为事务有着不同的模型,在Jim Gray的《事务处理概念与技术》一书的第四章事务模型中,把事务分为:

q  平板事务(Flat Transactions):事务块中的所有SQL语句,构成一个逻辑单元,要么都成功,要么因之一失败都回滚。PostgreSQL的事务管理如果不考虑保存点(Savepoint)机制,可以认为就是一个平板类型的事务,事务块内的一个SQL失败,导致整个事务必须回滚,之前执行成功的操作也必须回滚掉。

q  带有保存点的平板事务Flat Transactions With Savepoints):在平板事务的基础上,实现了保存点技术,这样使得一个事务块,可以划分出不同的层次,每个层次之间为一个逻辑单元,后面失败的SQL不影响之前保存点前发生的操作,即回滚发生在局部。PostgreSQLInnoDBInformix在平板事务的基础上,支持了保存点技术。

q  链式事务(Chained Transactions):与平板事务不同的是,链式事务在提交一个事务后,释放一些资源如锁等资源,但是,一些上下文环境如事务的载体(存放事务信息的结构体或类等对象)不被释放,会留给下一个事务使用。用户感觉自己的逻辑上的处理单元与之前的事务似乎没有COMMIT之类命令执行的明显分割。如InnoDB的事务模型,就是链式事务的代表(这句话不是说InnoDB不支持平板事务,实际上InnoDB支持平板事务、支持带有保存点的平板事务、支持链式事务,并通过XA技术支持下面谈到的分布式事务)。

q  嵌套事务(Nested Transactions):嵌套事务如同一棵树,树有子叉,每个子叉可以是嵌套的子事务也可以是平板的子事务。但叶子节点的事务是平板事务。根节点事务提交,整个事务的数据修改才生效,否则只是事务内局部有效。PostgreSQLMySQL(不是InnoDBInnoDB是被Oracle收购之后才逐渐并入MySQL的)没有对嵌套事务通过支持。原本MySQL打算在5.0版本之后提供对嵌套事务的支持,但是一直没有兑现。

q  分布式事务(Nested Transactions):在分布式环境下的平板事务或以上其他类型的事务。

q  多层次事务(Multi-Level Transactions):多层事务也如同一棵树,树根是事务的总节点,下层是对象操作(Object Operation)作为子事务存在,对象操作还可以带有子对象操作节点,或带有一个或多个的叶子节点(Page operation)。这样的事务模型可以有自己独特的并发控制处理技术[1],现实中有工程实现的不多见,而且与之前的事务分类角度不同。如图1-5,一个简化的两层事务,从叶子节点起为level 0,逐层向上编号。

1-5 多层事务的一个简化版本(两层事务)

    这些不同的模型,在不同数据库中的实现方式是不相同的。尽管每个数据库都遵循相同的原理,但实现各有不同,这点能体现出理论和工程的差异性(有的时候这些差异是有很大鸿沟的),掌握这些差异性,对于数据库内核开发的工程实践人员尤为重要。尤其对于数据库内核的架构设计者,体悟、领会、掌握不同数据库引擎在相同模块的处理方式上的差异,对于指导自身进行设计就更有实战意义。



[1]更多详细信息参见论文《Multi-Node Multi-Level Transactions》。

展开阅读全文

没有更多推荐了,返回首页