在使用Tcl与 SQLite时，当数据库请求通过套接字到达Tcl，若在请求的事务之外执行额外的数据库操作，并在结果返回给请求方后再执行，会发生什么？

我的场景是，用户在UI上执行某些操作，需要在一个原子事务中把数据写入数据库；这些数据变动会导致数据库中的其他数据变得“过时”。我想更新这些过时数据，以便未来的请求更快；但不希望让用户在UI端等待它完成。如果这一步刷新失败，不会破坏数据库或让它处于不完整状态，而只是可能在稍后告诉用户，某些东西不再位于原来的位置，而是已被移动或删除；因为这一步刷新会更新UI历史中的路径位置，并从历史中移除不再存在的条目。

如果在请求的事务结果一完成就返回后，立即启动这个刷新过程，应该发生什么？Tcl会在不同的线程中完成这项工作，还是同一个套接字上的UI的后续请求必须等待直到进程完成？我怀疑这个过程不会花费很长时间，以至于用户在它完成前就能再次发出请求，但如果确实如此，那么SQLite会否向Tcl返回busy，以便在Tcl中处理在短暂的间隔后重试，或取消并把busy返回给请求方？

解决方案

如果数据库处于WAL模式（在这种场景下非常推荐），并且你把事务保持尽可能短，那么大多数情况基本上能正常工作。尤其是如果你还为获取数据库锁设置了超时。每个工作线程使用一个连接，切勿在没有工作线程的情况下尝试进行复杂的多路复用。

—

每一次对SQLite数据库的变更都是在一个事务中完成的（除了像 VACUUM 之类的极少数情况）。如果你没有显式地启动一个事务，SQLite会为你创建一个事务，在底层 sqlite3_stmt 仍然处于有意义的活动状态时持续保持它。Tcl的接口只是对C API的一个薄封装，通常实现也最直观。默认情况下，如果在需要时未能立即获得事务锁（在你请求它时并不总是能立即获得，尤其是当事务是 DEFERRED 的默认类型时），语句执行会失败。如果在连接上已设置了 busy_timeout，那么获取事务锁将会等待最多给定的时间量，直到可以获取锁为止。

读锁是 共享锁。写锁是 排它锁，在WAL模式下情况会更宽松一些。（写事务仍然是可序列化的。）

综合起来，如果你让并行连接处于不同的连接（在不同的线程中），并使用WAL模式且设置了合适的超时，那么在某些条件下并行性会相当不错：

1. 将写事务保持短小。这本来就是一个好主意；大型写事务最好离线处理（然后你需要考虑把写入分组在一起之类的）。
2. 不要将读事务打开得太久；尽管在WAL模式下它们并不直接阻塞每一个写事务，但它们仍然会产生影响。
3. 如果某个事务可能需要从只读事务升级为写事务，务必从一开始就使用排他或立即事务，否则可能导致线程之间的死锁。

你可以使用 sqlite3 shell或第三方工具在同一时间访问数据库，前提是你遵循上述事务规则。不幸的是，许多工具默认并非如此操作（许多对SQLite的语言包装在事务上引入额外语义，严重干扰并行使用），但这完全是可能的。请注意，SQLite的 Tcl封装默认不会长期保留事务；我们预计用Tcl编写的工具（也许是你自己）通常都能工作。