通过网络与 Derby 进行嵌入式连接有哪些缺陷？
我们有一个 Java 桌面应用程序，它访问位于网络共享驱动器而不是本地的 Derby 数据库。
虽然应用程序的多个实例共享数据库，但只有一个实例具有实时连接。
两年多以来，这种方法一直运行良好，但有时我们会遇到数据库损坏，我们无法确定这是由于软件错误还是由于应用程序和远程数据库之间的网络造成的。
我们意识到 Derby 文档指出嵌入式数据库只能用于本地持久性，但是任何人都可以建议我们通过此配置可能会遇到的一些特定陷阱吗？
提前致谢！
吉姆
We have a Java desktop application that accesses a Derby database located on a network shared drive rather than locally.
While multiple instances of the application share the database, only one instance ever has a live connection.
This has been working quite well for over two years now but on occasion we encounter database corruption, which we are unable to determine is a result of a software bug or due to the network between the application and the remote database.
We realize the Derby docs state that embedded databases should be used for local persistence only, but can anyone suggest some specific pitfalls we could expect to encounter through this configuration?
Thanks in advance!
Jim
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
特别是关于数据库损坏，我认为将数据库放在网络共享存储上（至少）存在两个基本问题：（1）当 Derby 尝试通过增长文件来分配空间时，文件系统可能会报告分配成功即使实际上磁盘已满； (2) 当 Derby 尝试确保磁盘写入实际上完全写入磁盘时，文件系统可能会报告数据正在写入磁盘，即使实际上它仍然只写入内存。
上述任何一个问题，如果在适当的时间发生，都可能导致数据库损坏。
Specifically regarding the database corruption, I believe there are (at least) two fundamental problems with having the database on network-shared storage: (1) when Derby is attempting to allocate space by growing a file, the filesystem may report the allocation as successful even though in fact the disk is full; (2) when Derby is attempting to ensure that a disk write is in fact fully written to disk, the filesystem may report the data as being written to disk even though in fact it is still only written to memory.
Either of the above problems, if they occur at just the right time, can cause a database corruption.
我想说你应该注意文档的内容。开发 Derby 的人不太可能在没有充分理由的情况下提出限制 Derby 的适用性的建议。
（我可以理解为什么共享嵌入式 Derby 数据库的多个应用程序实例会出现问题。Derby 会假设它不需要担心多个实例的读取和更新，并且可能不会按照允许其工作所需的顺序刷新数据安全地，这样的刷新应该是没有必要的......除非您以不应该的方式使用 Derby。）
此外，为什么您不采取使用 网络服务器 版本的 Derby？
I'd say that you should pay attention to what the documentation says. The folks who developed Derby are unlikely to give advice that limits Derby's applicability without good cause.
(And I can understand why multiple application instances sharing a embedded Derby db would be problematic. Derby would assume that it didn't need to worry about multiple instances reading and updating, and may not flush data in the order needed to allow this to work safely. Such flushing should not be necessary ... unless you are using Derby in a way that you are not supposed to.)
Besides, why would you not take the approach of using the Network Server version of Derby?