On an side note here (and hence, may be ignored the the majority)... On Thu, May 17, 2012 at 2:59 PM, Simon Helsen <[email protected]> wrote: > We run only on 64 bit, but always in direct mode > because mapped mode does not allow us to remove the index (as a reindex > operation) because of the infamous JVM bug which holds a lock on the > involved files, at least on Windows.
It's not a bug. It's necessary in order to maintain memory integrity in Java. Java has no documented way to force an object to be garbage collected, and if the file is closed before the mapping object is collected then a get() or put() will give a GPF/segfault (depending on Windows/Linux). get/put doesn't check if the file is still there, since the whole point of mapping is to avoid overhead. These problems CAN be avoided... even on Windows. Mulgara has it and uses it in order to truncate mapped files. Andy, does Jena care about this? > Moreover, it is unstable under system > crashes since the actual flush may not have taken place after a close. > That too is probably more a problem on Windows. Well, a system crash can lead to unstable files no matter the access type. However, if you're ever relying on data in a mapped file being in a stable state, then you MUST call flush on it before closing. Otherwise the OS will only write the data out when it has time. There are some conditions when this will be too long. In fact, you shouldn't be calling flush before closing, but rather, call flush before writing any data structures that expect the modified portions of that file to be in a consistent state. Regards, Paul Gearon
