1

根据h2 features page ，我在 H2 文档中看到了一些不一致之处

数据库文件锁定

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

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

第二种方法是 SOCKET 并打开一个服务器套接字。套接字方法不需要每秒读取锁定文件。只有当数据库文件只能由一台（并且总是相同的）计算机访问时，才应使用套接字方法。

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

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

从上面看来，在不同计算机之间共享远程文件系统上的数据库似乎是不可能在编写时不手动关注并发性的。然而，在高级页面中，他们添加了第五个方法文件锁定序列化，它应该允许：

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

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

4

1 回答 1

2

序列化文件锁定是作为实验实现的，如文档所述：“此功能相对较新。在将其用于生产时，请确保您的用例经过良好测试（如果可能使用自动化测试用例）。” 这就是为什么它从未添加到常规文档中的原因。

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

于 2013-09-20T15:15:35.320 回答