What are the pitfalls of an embedded connection to Derby over a network?

Question

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

Answer 1

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.

Answer 2

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?

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?