Active Record嵌套SQL事务的风险及相关疑问

嵌套事务的风险程度 #

Rails的嵌套事务并非数据库原生的嵌套事务，而是通过**保存点（savepoint）**模拟实现的。只要你不主动使用ActiveRecord::Rollback，风险处于可控范围，但需留意以下几点：

• 数据库级错误触发全局回滚：子事务中若出现约束校验失败、SQL执行错误等数据库异常，会直接向上传播，最终触发最外层事务的全局回滚，这和你测试的结果一致。
• 人为引入的逻辑风险：如果后续代码中加入主动raise ActiveRecord::Rollback的操作，会破坏预期的回滚逻辑。例如：

  User.transaction do
    User.create(username: 'Kotori')
    User.transaction do
      User.create(username: 'Nemu')
      raise ActiveRecord::Rollback
    end
  end
  

  这段代码中，内层的ActiveRecord::Rollback只会回滚当前保存点（即取消Nemu的创建），外层事务仍会正常提交，最终Kotori会被保留在数据库中。
• 性能损耗：每个嵌套事务都会创建一个保存点，大量嵌套会增加数据库的额外开销，但只要不是极端层级，影响可以忽略。

非主动抛出ActiveRecord::Rollback时的回滚保证 #

是的，只要你的代码中不主动触发ActiveRecord::Rollback，所有因数据库操作失败抛出的异常，都会传播到最外层事务，确保整个操作回滚至初始状态。

原因在于：

• 子事务中出现数据库异常时，Rails会先回滚到当前保存点，然后将异常向上抛出。
• 外层事务捕获到异常后，会执行全局回滚，不会提交任何未完成的操作。

Rails服务器超时的异常与事务处理 #

Rails服务器（如Puma、Unicorn）超时通常会抛出对应服务器的超时异常：

• Puma：Puma::TimeoutError
• Unicorn：Timeout::Error

对于未提交的事务：

• 只要超时发生时事务尚未提交，数据库会自动回滚该事务。因为数据库事务与连接绑定，当连接因超时而中断，数据库会检测到未提交的事务并执行回滚。
• 极端情况下，若超时恰好发生在事务提交瞬间，可能出现部分提交的情况，但这种概率极低，无需过度担忧。

内容的提问来源于stack exchange，提问作者Adriano di Lauro