jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <andy.seabo...@epimorphics.com>
Subject Re: TDB in a unit test -- or -- when is a close not a close?
Date Thu, 03 Feb 2011 09:22:08 GMT
Ah - good old 4724038 [1].  Currently #4 in the Java RFE hit parade [2] 
despite the fact most people call it a bug.

Summary: It's a Windows-ism to do with "deleting" memory mapped files. 
They are still mapped by the OS.

I've not tried the GC/loop dance. The cleaner workaround does not look 
like it will work on other JVMs which will concern some users.

There is an in-memory TDB version.  Good for testing, not a performant 
replacement for memory models - the TDB memory dataset uses a 
copy-in/copy-out RAM disk for true disk semantics.

The magic location name is "--mem--" or there are TDBFactory operations 
that take no location.

	Andy

[1] http://bugs.sun.com/view_bug.do?bug_id=4724038
[2] http://bugs.sun.com/top25_rfes.do

On 03/02/11 02:47, Benson Margulies wrote:
> We can't get a unit test on Windows to delete a temporary TDB.
>
> Now, on the one hand, I saw some code that suggests that with the
> right assembly descriptor I could have a completely in-memory TDB and
> avoid this.
>
> But, on the other hand, I would think that with a System.gc() and a
> sleep, we could do this, in spite of Java's annoying lazyiness about
> closing the backing files of memory mapped files.
>
> How confident are you that all the channels and streams get closed?

As confident as I can be.

There is a known problem deleting datasets on Windows 64 bit because of 
the memory mapped file issue.  FileMode.direct works.


Mime
View raw message