事务的模型

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

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

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

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

q  嵌套事务（Nested Transactions）：嵌套事务如同一棵树，树有子叉，每个子叉可以是嵌套的子事务也可以是平板的子事务。但叶子节点的事务是平板事务。根节点事务提交，整个事务的数据修改才生效，否则只是事务内局部有效。PostgreSQL、MySQL（不是InnoDB，InnoDB是被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》。