REPEATABLE READ隔离级别是否有适合通用应用默认的常见场景？

我在开发应用时（观察多基于Rails框架，但不限于该框架）发现一个问题：MySQL默认的REPEATABLE READ事务隔离级别，相比PostgreSQL、Oracle等默认的READ COMMITTED，更容易引发并发处理异常。

以常见的读写逻辑为例：

if order.pending?
  order.process
end

这类代码在事务中运行时，隔离级别会影响并发Worker重复处理同一order的概率。即便应用本身存在重复处理的潜在隐患，降低错误发生概率仍十分关键。

使用REPEATABLE READ时，若两个Worker几乎同时启动事务处理同一订单，第二个事务在第一个提交变更后仍无法感知，会导致重复处理；而READ COMMITTED下，第一个事务提交后第二个事务能立即看到变更，从而缩小重复处理的时间窗口。

我观察到，尽管REPEATABLE READ提供更高的隔离保证，但对通用应用而言，其危害更大且会降低数据库引擎性能，不如READ COMMITTED实用。因此想询问：

• 是否遗漏了REPEATABLE READ更安全的常见应用场景？
• 是否存在常见应用类型，将REPEATABLE READ设为默认比READ COMMITTED更合理？

注：这里指的是通用场景，而非仅应用中个别需单独设置隔离级别的模块。

内容的提问来源于stack exchange，提问作者akostadinov