Tcl/SQLite 如何在请求事务提交后安全刷新数据？

2026-11-04数据小许

可以在请求的业务事务提交后刷新历史记录。返回响应后，Tcl 不会自动把后续代码放到另一个线程。对于常见的单线程、事件驱动服务，刷新代码仍在处理 socket 事件的线程中执行；刷新期间，后续请求通常需要等待。

要区分两种情况：事件循环没有机会处理新请求，以及 SQLite 因数据库锁竞争返回 SQLITE_BUSY。前者不会自动触发后者。

返回响应后，刷新代码如何执行？

假设请求处理回调按以下顺序工作：

执行业务事务并提交。
向 socket 写入响应。
同步刷新历史记录。
回调结束，控制权交回事件循环。

第 3 步执行时，即使新请求已经到达 socket，普通的 Tcl 事件循环也不会自动中断刷新代码去处理它。请求可能暂存在通信缓冲区中，等回调结束后再被读取和执行。这个判断的前提是程序没有显式启动工作线程，也没有在回调中进入嵌套事件循环。Tcl 事件循环文档

向 socket 写入响应也不等于客户端已经收到响应。Tcl channel 可能仍有输出缓冲，阻塞式写入也可能等待。要让 UI 尽早获得结果，需要处理好 channel 的缓冲、非阻塞写入和错误处理。

如何安排事务后的刷新？

如果刷新很短，可以在提交业务事务后用 after idle 安排刷新，让当前回调先结束。after idle 会在事件循环没有其他待处理事件时执行回调。刷新仍在当前线程中运行，执行期间仍会占用事件循环。Tcl after 文档

下面只展示调用顺序。假设 db 是已经打开的 SQLite 连接，applyRequest、sendResponse 和 refreshHistorySql 是应用提供的过程：

proc handleRequest {sock request} {
    set result {}

    db transaction {
        set result [applyRequest $request]
    }

    # 应用负责响应编码、发送和 channel 错误处理。
    sendResponse $sock $result

    after idle refreshHistory
}

proc refreshHistory {} {
    if {[catch {
        db transaction {
            refreshHistorySql
        }
    } message]} {
        puts stderr "History refresh failed: $message"
    }
}

db transaction 在脚本正常完成时提交，在脚本出错时回滚。示例中的历史记录刷新使用自己的事务，刷新失败不会回滚已经提交的业务事务。SQLite Tcl 接口文档

示例要求 handleRequest 不处于另一个尚未结束的外层事务中，否则不能把这段代码结束理解为业务已经独立提交。业务事务失败时，也应由请求处理层返回相应错误。

after idle 依赖事件循环持续运行。持续有请求到来时，空闲回调可能推迟很久；如果刷新必须及时完成，需要采用定时调度或任务队列。

什么情况下会出现 SQLITE_BUSY？

同一线程顺序使用同一个连接时，新请求通常还没有开始执行 SQL，因此不会仅仅因为刷新尚未结束，就收到 SQLITE_BUSY。

SQLITE_BUSY 主要涉及其他连接造成的锁竞争，例如另一个线程或进程正在写同一个数据库。即使启用 WAL，SQLite 也仍然只允许一个写事务同时进行。SQLite 错误码说明、WAL 并发说明

Tcl 接口提供 db timeout 毫秒数 设置锁等待时间，但等待仍发生在调用 SQLite 的线程中。等待时间设得很长，会延长该线程无法处理 socket 事件的时间；设置超时也不保证所有锁冲突都会等待到超时才失败。SQLite Tcl timeout 文档

需要重试时，应识别具体错误，只对可恢复的锁冲突安排有限次数的重试。可以用带回调的 after 延迟重新提交刷新任务，并先结束当前回调。不要使用不带回调的 after 100 作为异步等待，因为这种写法会直接阻塞当前线程。

如果刷新可能耗时较长，怎么处理？

可以根据刷新工作的规模选择以下方式：

分批执行：每次处理少量历史记录，用短事务提交，再安排下一批，让事件循环有机会处理请求。单条耗时 SQL 也需要优化，仅在它外面加 after 无法缩短阻塞时间。
显式使用工作线程或独立进程：让工作端创建并使用自己的 Tcl 解释器和 SQLite 连接，通过任务队列接收刷新请求。这样能避免刷新计算直接占用 socket 线程，但仍需处理数据库写锁竞争。
合并重复任务：多次业务操作都要求刷新历史记录时，可以合并待处理任务，避免每个请求都排入一次完整刷新。

不要为了在刷新过程中响应请求，就在事务内部随意调用 update。这会进入嵌套事件处理，使其他请求有机会在当前操作尚未完成时重入，增加连接状态和事务边界的管理难度。

如何保证延迟刷新的业务安全？

既然历史记录允许短暂过期，读取时就应能处理目标已经移动或删除的情况。刷新也应尽量具备幂等性，并根据当前数据或版本条件执行，避免延迟任务用旧状态覆盖新变化。

如果希望程序退出或崩溃后仍能继续刷新，可以在业务事务中同时记录待刷新标记，再由后续任务处理并清除。仅保存在 after 队列中的任务不会跨进程重启保留。

业务事务结束后的写操作仍然涉及 SQLite 事务。多条更新需要一起成功或失败时，应把它们放进一个独立的刷新事务，明确控制失败后的状态。