内存引擎的并发控制机制采用OCC，在操作数据冲突少的场景下，并发性能很好。
内存引擎的事务周期以及并发管控组件结构，如图9-42所示。
图9-42 内存引擎的事务周期以及并发管控组件结构
这里需要解释一下，内存引擎的数据组织为什么整体是一个接近无锁化的设计。
除去以上提到的Masstree本身的无锁化机制外，内存引擎的流程机制也进一步最小化了并发冲突的存在。
每个工作线程会将事务处理过程中所有需要读取的记录，复制一份至本地内存，保存在read-set（读数据集）中，并在事务全程基于这些本地数据进行相应计算。相应的运算结果保存在工作线程本地的write set（写数据集）中。直至事务运行完毕，工作线程会进入尝试提交流程，对read set（读数据集）和write set进行validate（检查验证）操作并在允许的情况下对write set中数据对应的全局版本进行更新。
这样的流程，会把事务流程中对于全局版本的影响，缩小到validation的过程，而在事务进行其他任何操作的过程中都不会影响到其他的并发事务。并且，在仅有的validation（检查验证）过程中，所需要的也并不是传统意义上的锁，而仅是记录头部信息中的代表锁的数位（lock bit）。相应的这些考虑，都是为了最小化并发中可能出现的资源争抢以及冲突，并更有效地使用CPU缓存。
同时read set（读数据集）和write set（写数据集）的存在，可以良好地支持各个隔离级别，不同隔离级别可以通过在validation（检查验证）阶段对read set（读数据集）和write set（写数据集）进行不同的审查机制来获得。通过检查两个set（数据集）中行记录在全局版本中对应的lock bit（锁定位）以及行头中的TID结构，可以判断自己的读、写与其他事务的冲突情况，进而判断自己在不同隔离级别下是否可以commit（提交）、或是需要abort（终止）。同时由于Masstree中Trie node中存在版本记录，Masstree的结构性改动（insert/delete，插入/删除）会更改相关Trie node（节点）上面的版本号。因此维护一个Range query（范围查询）涉及的node set（节点集），并在validation（检查验证）阶段对其进行对比校验，可以比较容易地在事务提交阶段检查此Range query所涉及的子集是否有过变化，从而能够检测到Phantom（幻读）的存在，是一个时间复杂度很低的操作。
