SQLite与OpenAFS锁定兼容吗？

我已经使用SQLite已经有一段时间了，并且已经有了处理一些锁定问题的“财富”。我很确定SQLite默认在Unix文件系统上使用字节范围锁。 更确切地说，它包含一些替代锁定方法的代码（例如使用

flock()

和dotlock样式的整个文件锁）。使用

SQLITE_ENABLE_LOCKING_STYLE

选项编译时，它会尝试自动检测底层文件系统的正确锁定方法。 自动检测代码包含一些硬编码的情况（例如“ufs”，“nfs”和“smbfs”），其中没有一个是AFS。如果没有硬编码的大小写匹配，SQLite会尝试使用

fcntl()

获取文件的字节范围锁定。然后假设如果

fcntl()

调用成功，则可以使用字节范围锁。 这是OpenAFS的用武之地。显然（[1]，[2]，[3]）OpenAFS对于用户空间应用程序有关字节范围锁定的悠久历史。来自

openafs-1.4.14

源代码：

/* next line makes byte range locks always succeed,
 * even when they should block */
if (af->l_whence != 0 || af->l_start != 0 || af->l_len != 0) {
    DoLockWarning();
    afs_PutFakeStat(&fakestate);
    return 0;
}

一句话：哎哟！ 它允许字节范围锁无论如何都能成功。在Linux上，可以想象更糟糕的是：它使用内核基础结构在同一系统的进程之间提供字节范围锁。这意味着应用程序不能只是分叉一个新进程并测试锁定机制 - 字节范围锁似乎工作正常，同时失败可怕地保护文件免受远程进程的影响。 简而言之：您无法使用OpenAFS可靠地使用未修改的SQLite。大多数其他网络文件系统也存在问题，因此建议完全避免使用网络文件系统。 一些可能的解决方法没有特定的顺序： 使用适当的DBMS，例如PostgreSQL。如果可以做到这一点，从长远来看，你会更好。 如果一个成熟的DBMS过度使用，请为您的应用程序实现自己的服务器。 在OpenAFS上将SQLite源代码修改为默认为

flock()

。我不确定这是否会正常工作，因为OpenAFS有很长的历史记录（[1]，[2]）即使使用普通的

flock()

也存在锁定问题，但在测试之前你不会知道。 使用OpenAFS用户空间实现您自己的OpenAFS VFS for SQLite，而不是通过内核。 试试你的运气与另一个网络文件系统。 无论您做什么，如果以任何方式涉及SQLite3和共享数据库文件，您都必须执行大量测试。 编辑： 一位意见提供者建议使用dotlock文件机制。我没有太多深入研究OpenAFS源代码，但乍一看它似乎支持创建SQLite使用的dotlock文件的

open(O_CREAT|O_EXCL)

方法。如果它按预期工作，那么如果强制它使用dotlock方法，则SQLite可能确实可用于OpenAFS。 也就是说，dotlocks足以解决常规本地文件系统的问题，而不会将网络文件系统的复杂性引入混合中 - 这就是为什么我首先没有提出它的原因。