Ktor/Exposed中newSuspendedTransaction块关闭后TransactionManager.currentOrNull()非空的异常问题（含delay时触发）

这问题确实有点让人摸不着头脑对吧？我之前在项目里也碰到过类似的协程+Exposed事务的坑，结合你给出的代码，我大概能猜到问题出在哪了。

问题核心分析 #

首先看你的两个代码片段，核心差异在于运行环境的Dispatcher不同：

• Ktor路由默认使用的是ApplicationDispatcher（Ktor为HTTP请求优化的自定义调度器）；
• 而你的测试代码里显式指定了Dispatchers.IO。

Exposed的TransactionManager底层默认依赖ThreadLocal存储当前事务，当你在newSuspendedTransaction块里调用delay时，协程会被挂起，恢复时可能切换线程。在Ktor的ApplicationDispatcher环境下，这种线程切换会干扰事务的清理逻辑——简单说就是，事务的ThreadLocal值在块结束后没有被正确清空，所以TransactionManager.currentOrNull()还能读到残留的事务引用。

而测试代码用Dispatchers.IO时，协程挂起恢复的线程管理逻辑更贴合Exposed的事务清理预期，所以块结束后事务能被正常清除。

解决办法 #

你可以通过以下两种方式修复这个问题：

1. 在Ktor路由中显式切换到Dispatchers.IO运行事务代码

把路由中事务相关的逻辑包裹在withContext(Dispatchers.IO)里，让事务在标准IO调度器下执行：

get("/") {
    withContext(Dispatchers.IO) {
        require(TransactionManager.currentOrNull() == null) { "1 - transaction should not exist at the start" }
        
        newSuspendedTransaction {
            require(TransactionManager.currentOrNull() != null) { "2 - transaction should exist now" }
            delay(2000) // 模拟处理时间
        }
        
        // 现在这行校验应该能通过了
        require(TransactionManager.currentOrNull() == null) { "3 - transaction should not exist at the end" }
    }
    call.respondText("OK")
}

2. 给newSuspendedTransaction显式指定Dispatcher

另一种更直接的方式是在调用事务函数时，传入dispatcher = Dispatchers.IO参数，强制事务块在IO调度器下运行：

get("/") {
    require(TransactionManager.currentOrNull() == null) { "1 - transaction should not exist at the start" }
    
    newSuspendedTransaction(dispatcher = Dispatchers.IO) {
        require(TransactionManager.currentOrNull() != null) { "2 - transaction should exist now" }
        delay(2000) // 模拟处理时间
    }
    
    require(TransactionManager.currentOrNull() == null) { "3 - transaction should not exist at the end" }
    call.respondText("OK")
}

补充说明 #

至于你的测试代码能正常运行，就是因为你直接用了Dispatchers.IO，和我们上面的修复思路完全一致，所以事务的清理逻辑能在块结束后正常清空ThreadLocal里的事务引用，自然TransactionManager.currentOrNull()就返回null了。

另外，针对你要检测事务状态来设置行级安全参数的需求，建议后续所有事务相关代码都统一用Dispatchers.IO，避免因上下文不一致引发更隐蔽的事务泄漏问题。

内容来源于stack exchange