0

This seems to be the most reliable in-process data store I found. I tried a few things locally (sig kill, sig term, System.exit(), etc. in the middle of a transaction) and xodus could pick up from where its last good state was.

I'm interested to know whether xodus supports store data over NFS (using an NFS folder as the environment)? Is it possible to corrupt the datastore if the file locking may not work well, like in the case of some NFS, when multiple processes open the same folder from different hosts?

I took a quick look at the lock file (xd.lck, well, at least it looks like a lock file to me), which seems to include pid, host name, and a call stack for the LockingManager. However, I'm not sure how this lock file works with xodus. I found that this file is not removed after the environment closes. Nor does its content change.

Vin
  • 559
  • 2
  • 18

1 Answers1

0

It's not recommended to use any kind of remote or removable storage for hosting database files. The database can easily be corrupted - not only on attempt of shared access, but also due to possible connectivity issues. In upcoming versions (released after 1.3.232), an attempt to use remote or removable storage would fail if and where it can be reliably detected.

Vyacheslav Lukianov
  • 1,913
  • 8
  • 12