通过应用程序级别重试避免sqlite vacuum“数据库被锁定”

Question

我使用简单的sqlite DB作为进程之间的持久msg排队机制。为了在超过某个限制后减小文件大小，我想使用“vacuum”命令。通常所有这一切都很好用，只有那时我不时会在吸尘时出现“数据库被锁定”错误。

在阅读了网络上的各种资源后，我明白在sqlite级别上我无能为力。

然而，除了侧面问题“为什么会这样？使用常规busyHandler机制重试获取所需锁定会出现什么问题？”我提出了在应用程序级别实现完全相同的busyHandler机制的想法。

现在基本问题：这有什么问题吗？

很多人!!

Answer 1

使用SQLite的built-in retrying mechanism并自己实现它并没有多大区别。 但是，编写不需要编写的代码是无用的工作，并增加了引入错误的机会。

Answer 2

在完成另一个工作之后，我通过完全取消吸尘来改变我的应用程序逻辑，而是使用“pragma max_page_count”来限制数据库大小。唯一需要注意的是，这似乎是特定于会话的，即必须在每次DB连接后再次设置pragma。

关于原始问题：我发现@CL大部分都是正确的 - 吸尘确实涉及标准忙处理程序。在Linux上，这也可以很好地工作，只是在Windows上它不可靠（虽然可能是偶然的，而不是由系统速度引起的......）。在我的自定义busyHandler中使用一点printf（）我可以看到它在大多数情况下被调用，但有时它不是，而“pragma vacuum”只返回“DB locked”。 可能是由同时进行真空吸尘的并发过程引起的（？）......无论如何，重新设计的设计更加清洁/更容易。