mnesia之transaction

整理下对mnesia事务执行的流程，如有不对，欢迎拍砖指正。

事务通常是由应用程序进程发起，其大致流程为：

（1）向mnesia_tm进程获取一个全局唯一的事务ID和临时存储空间(ets)

（2）执行事务函数

在事务函数中一般会调用mnesia:read()，mnesia:write()完成数据的读写操作。mnesia提供的read，write接口中包含了获取锁的操作，需要注意的是：read，write操作的结果和事务的中间状态都存储前面申请的临时存储空间中。

（3） 分析临时存储空间中的信息

通过分析临时存储空间中记录的信息，得出本次事务涉及到的节点，以及需要使用的提交协议。

（4） 执行提交动作

提交动作会完成对实际数据的读写，即将临时存储空间中的数据写入实际存储区域。另外，提交动作还会触发日志的记录，以及可能的索引更新，检查点更新等操作。提交完成后，释放相关的资源。至此，一个完整的事务流程结束。

mnesia内部有多种提交类型，常用的有

1. sym_trans

当事务涉及的表在所有副本节点为对称复制时会使用这种提交方式，该提交方式的流程可分为两个阶段，第一阶段为表决阶段，事务发起者向所有副本节点发送提交请求，其目的是形成统一的决定（提交或者放弃），第二阶段为在所有副本节点上执行具体的提交动作。

log操作会将事务ID对应的操作，数据以及事务的结果（committed）保存到latest_log文件中，同时在transient_decision表中记录事务的状态。

如果在表决阶段远端节点不同意提交，或者出现远端节点挂掉，网络异常断开等情况，事务发起者将终止本次事务的提交并通知所有副本节点，并将事务结果（aborted）保存到transient_decision表中。

当事务发起者广播执行提交的指令后，如果某个远端节点挂掉，事务将继续执行，挂掉的节点在启动时，由加载算法保证数据的一致性。

如果事务发起者本身挂掉了，远端节点间会相互询问事务的最终执行结果，如果有节点成功提交，那么其他节点也会得到通知并执行提交动作，相反如果没有节点成功提交，那么所有节点都会终止该事务的提交。

2. syn_sym_trans

这种方式和sym_trans的流程基本一致，唯一不同的是，日志记录会立即写入磁盘。

3.  asym_trans

当事务涉及的表在所有副本节点为非对称复制时（例如，事务要写a,b两张表，但是a,b两张表及其副本在不同的节点上）会使用该提交类型，另外schema transaction（涉及schema的操作的事务）也都使用该提交类型。该提交方式的流程可分为三个阶段：第一阶段为表决阶段，第二阶段为预提交阶段，第三阶段为提交阶段。

第一次log是将事务的实际操作，数据以及事务的结果（presume_abort）保存到latest_log文件中

第二次log是将事务的结果（unclear）保存的latest_transient_decision（ets）表或者是mnesia_decision（ets）表中。

第三次log将合并前一次的事务结果，并将最终结果（committed）保存到latest_transient_decision或者mnesia_decision表中，同时还会保存到latest_log文件中。

这里需要注意的时，与sym_trans和syn_sym_trans提交不同的是，在表决阶段，远端节点的mnesia_tm进程会新创建一个进程用来处理该事务的后续提交流程。对于schema transaction来说，不是由应用程序进程来执行，而是新创建一个进程出来处理事务的整个流程，以防止应用程序进程挂掉；除此外，prepare_commit是schema transaction的commit操作的先决条件，比如创建disc_copies类型的表时，prepare_commit会创建对应的ets表和对应的文件（Tab.DCD）。每一个prepare_commit都对应有一个undo_prepare_commit，在终止事务提交时执行对应的undo_prepare_commit操作。

如果在表决阶段或者在预提交阶段有远端节点挂掉，或者网络异常断开等情况，事务发起者将终止本次事务的提交并通知所有副本节点；如果是事务发起者节点挂掉，远端节点将查看当前记录的事务状态，如果事务结果为presume_abort则终止事务的提交，如果事务结果为unclear则向其他节点询问事务的最终结果决定是提交事务还是终止事务的提交。