jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: TDB in a unit test -- or -- when is a close not a close?
Date Thu, 03 Feb 2011 14:07:29 GMT
OK, fine. I don't need speed in the unit tests, and I don't need to
close down and delete databases in production. Thanks.

On Thu, Feb 3, 2011 at 4:22 AM, Andy Seaborne
<> wrote:
> 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]
> [2]
> 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. works.

View raw message