Paul,
Do you have a pointer to the Mulgara code? It would be great to fix this.
It's not truncation nor access after closing though: it's deletion of
the files that's the issue. close(), no use whatsoever then file delete
does not delete the file. The files are held by the JVM until exit.
http://bugs.sun.com/view_bug.do?bug_id=4724038
Works just fine on Linux, does not work on MS Windows. maybe it's
because open files count to the reference count in Linux but not on MS
windows.
The 25-MAR-2011 comment may work ... on Sun JVMs.
Andy
On 17/05/12 21:34, Paul Gearon wrote:
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
