下面引用的摘录在这一点上似乎是矛盾的。
（我认为它们都很老，第二个是2004年的，第一个提到Borland，所以也必须很老，所以也许它们已经过时了。）
第一个似乎表明，提交保留可以保持事务活动，因此会阻塞OIT。
第二，如果我理解这意味着保留提交，则将现有的TID标记为已提交，并且使事务保持活动状态，但是使用新的TID，因此不会粘在OIT上。第二部分摘录与Interbase有关，我不知道这是否解释了看似矛盾的地方。
Firebird文档摘录：
使用Firebird（和InterBase），“提交保留”会导致事务无限期保持有趣。在“标准” Borland RAD工具数据库应用程序和任何其他使用“提交保留”的应用程序上，垃圾收集实际上停止了。
读已提交，可读写：
如果您不时进行一次提交，则该事务可以永久运行，而不会对性能产生负面影响。
当您将提交保留（通过API或与一起使用COMMIT RETAIN）与Firebird一起使用时，已启动的事务并没有真正结束，它只是与内部已启动的新事务中的一组可见事务相关联，同时还保留了旧事务（s）活跃。
这意味着最老的有趣事务和最老的活动事务不会移动，并且回溯版本会累积，直到真正提交事务后才能进行垃圾回收。这意味着最终查询将需要扫描更长的记录版本链，这可能会对性能产生影响。
我假设可以进行一些优化，例如，如果没有在事务中启动的游标打开，则原始事务可能会被标记为已提交（提交保留的功能之一是在事务提交时不会关闭游标，这-如果我没记错的话-要求旧的交易环境保持可用）。这可能是InterBase为读取已提交的事务所做的事情。
可以通过启动isql会话并结合提交保留进行一些插入来亲自看到：如果gstat -h进行组合检查，您会注意到最有趣的最早事务和最活跃的事务在您真正提交之前不会移动。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句