在这一点上,下面引用的摘录似乎是矛盾的.
(我认为它们都很老了,第二个是从2004年开始,第一个提到Borland所以一定也要老了,所以也许它们已经过时了.)
第一个似乎表明提交保留使事务处于活动状态,因此将坚持OIT.
第二,如果我理解它意味着通过提交保留,现有的TID被标记为已提交,并且事务保持活动但具有新的TID,因此不会粘贴OIT.这第二个摘录与Interbase有关,我不知道这是否解释了看似矛盾的问题.
Firebird文档提取:
使用Firebird(和InterBase),Commit Retaining会使事务无限期地保持有趣.垃圾收集有效地停止在"标准"Borland RAD工具数据库应用程序和任何其他使用Commit Retaining的应用程序上.
Embarcadero Blog post extract
读取已提交,读写:
如果您不时保留提交,此事务可以永久运行而不会对性能产生负面影响.
当您在 Firebird 中使用提交保留（使用 API 或 with COMMIT RETAIN）时，启动的事务并没有真正结束，它只是与内部启动的新事务中的一组可见事务相关联，同时还保留旧事务(s) 活跃。
这意味着最旧的有趣事务和最旧的活动事务不会移动，并且后面的版本会累积，直到事务真正提交为止，无法进行垃圾收集。这意味着最终查询将需要扫描更长的记录版本链，这可能会对性能产生影响。
我假设有一些可能的优化，例如，如果在事务中没有打开游标，则原始事务可能会被标记为已提交（提交保留的功能之一是游标在事务提交时不会关闭，如果我没有记错的话，这需要旧的事务上下文保持可用）。这可能是 InterBase 为读取已提交事务所做的事情。
这可以通过启动 isql 会话并结合提交保留进行一些插入来看到：如果您结合检查gstat -h，您会注意到最旧的有趣和最旧的活动事务在您真正提交之前不会移动。