H2 的文件锁定方法“序列化”

Question

根据h2 features page，我在 H2 文档中看到了一些不一致的地方

数据库文件锁定

[...] 实现了以下文件锁定方法：

默认方法是 FILE 并使用看门狗线程来保护数据库文件。看门狗每秒读取一次锁定文件。

第二种方法是 SOCKET 并打开一个服务器套接字。套接字方法不需要每秒读取锁定文件。插座 仅当仅由以下人员访问数据库文件时才应使用方法 一台（并且始终是同一台）计算机。

第三种方法是FS。这将使用 FileChannel.lock 使用本机文件锁定。

也可以不锁定文件打开数据库；在这种情况下，由应用程序来保护数据库文件。 否则将导致数据库损坏。

从上面看来，如果在编写时不手动关注并发性，就不可能在不同计算机之间共享远程文件系统上的数据库。 然而，在高级页面中，他们添加了第五种方法file locking serialized，它应该允许：

这种锁定模式允许打开多个连接到同一个 数据库。可以从多个进程打开连接，并且 来自不同的计算机。写入数据库时​​，访问是 内部自动同步。

我是否正确地理解了存在矛盾？还是我误解了文件锁定序列化？

Answer 1

serialized file locking was implemented as an experiment，如文档所述：“此功能相对较新。将其用于生产时，请确保您的用例经过良好测试（如果可能的话，使用自动化测试用例）。”这就是为什么它从未添加到常规文档中的原因。

我不建议在远程文件系统上共享数据库。与 H2 无关，我在 NFS 实现方面有过不好的经历。在一种情况下，文件锁定被破坏（在崩溃和重新启动后，文件仍然被锁定）。在一种情况下，由于 NFS 实现中的错误，并发访问被破坏（一个客户端没有看到另一个客户端所做的更改）。在多种情况下，由于网络连接不可靠，文件不时被关闭。在许多情况下，性能很差。对于某些用例（例如共享办公文件、图片或电影）来说，所有这些都可能没问题。但是对于数据库来说，这并不好。