有一篇论文介绍了MVOCC（MVCC +优化的并发控制）
3.2乐观并发控制（MVOCC）
下一个协议基于乐观并发控制 （OCC）方案于1981年提出[26]。 OCC背后的动机 DBMS假设事务不太可能发生冲突， 因此，在以下情况下，事务不必获取元组的锁： 它读取或更新它们。这样可以减少 交易持有锁。原始OCC有所更改 协议以使其适应多版本[27]。最重要的是 DBMS不会为事务维护私有工作空间，因为 元组的版本信息已阻止交易 从阅读或更新对他们不可见的版本。
MVOCC协议将事务分为三个阶段。 事务开始时，它处于读取阶段。这是 事务调用对数据库的读取和更新操作。喜欢 MVTO，要对元组A执行读取操作，首先是DBMS 根据begin-ts和end-ts搜索可见版本的Ax 领域。如果未获取T的写锁，则允许T更新Ax版本。 在多版本设置中，如果交易更新了版本 Bx，然后DBMS创建版本Bx + 1，其txn-id设置为Tid。
当事务指示DBMS想要提交时， 然后进入验证阶段。首先，DBMS分配 交易另一个时间戳（Tcommit）来确定序列化 交易顺序。然后，DBMS确定元组是否 交易的读取集中的交易已由已经进行交易的交易更新 承诺。如果交易通过了这些检查，则它将输入 写入阶段，DBMS将安装所有新版本和新版本 他们的开头是Tcommit，结尾是INF。
事务只能更新元组的最新版本。但是一个 事务在另一个事务之前不能读取新版本 创建它提交。读取过时版本的交易将 只发现它应该在验证阶段中止。
所以我的问题是为什么要分配第二个时间戳作为提交时间戳，而不是使用第一个时间戳？ 分配第二个有什么好处？