Minitest测试中子线程与主线程复用ActiveRecord连接的原因排查

• 日常在Rails控制台执行以下代码时，会得到两个完全不同的数据库连接对象ID，符合ActiveRecord连接池的多线程分配预期：

  User.count
  Thread.new { User.count; puts ActiveRecord::Base.connection_pool.connection.object_id }.join
  puts ActiveRecord::Base.connection.object_id
  

  典型输出结果如下：

  46981836802520
  46981834013480
  

• 但将完全相同的代码移入Minitest测试用例运行时，两个位置输出的连接对象ID完全一致，无法触发独立线程分配独立连接的预期行为。

出现这个现象确实和Minitest的配套测试配置直接相关，根源是Rails为测试环境设计的全局连接共享机制：

• Rails在测试环境下，为了保证测试事务回滚逻辑正常工作，默认会在每个测试用例运行阶段开启ActiveRecord::Base.shared_connection设置。该设置会直接绕过连接池的常规线程维度分配逻辑，无论代码运行在哪个线程中，调用connection方法时都会直接返回主线程持有的共享连接对象，不会给子线程从连接池申请独立连接。
• 常规Rails控制台运行在开发环境下，不会开启这个全局连接共享配置，连接池会按照默认逻辑为每个首次访问数据库的独立线程分配专属连接，因此会输出不同的对象ID。
• 这套共享机制的设计初衷是避免测试数据脏写：Minitest默认通过包裹数据库事务的方式实现测试结束后自动回滚数据，如果子线程拿到了独立连接，将无法感知主线程开启的事务上下文，既会导致数据可见性问题，也会让事务回滚逻辑失效。

如果需要在测试环境复现控制台的连接分配行为，可以在测试方法中临时关闭全局连接共享后再运行原代码：

def test_thread_connection_id
  # 临时关闭全局连接共享
  ActiveRecord::Base.shared_connection = nil

  User.count
  Thread.new { User.count; puts ActiveRecord::Base.connection_pool.connection.object_id }.join
  puts ActiveRecord::Base.connection.object_id
end

此时就能观察到和控制台一致的、两个不同连接对象ID的输出结果。

• 不建议全局关闭测试环境的连接共享机制，否则会导致Minitest默认的事务回滚功能失效，测试产生的脏数据会残留到后续测试流程中，引发随机的测试失败问题。
• 如果测试场景中确实需要在独立线程中操作数据库，需要手动保障子线程操作处于和主线程一致的事务上下文中，不能完全依赖连接池的默认分配逻辑。

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