jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattheis, Erik W." <Erik.W.Matth...@espn.com>
Subject Re: Temp File Semantics
Date Fri, 09 Jan 2009 14:28:28 GMT
>>> - When reading, if the DbDataStore property copyWhenReading is enabled.
>>
>> We didn't have this property set in our configuration. Looks like the
>> default is true.
>
> Sorry, I didn't notice that... the setting is "Enabled by default to support
> concurrent reads".

Does this mean concurrent reads are not possible with the property set to false? Are requests
for the content pipelined automatically or will there be threading issues?

> The temp file is only deleted when closing the input stream, or when read()
> returns -1. Maybe your application doesn't call close()? A workaround would
> be to close the input stream using finalize(). I'm not sure if this is the
> best solution is however.

That sounds like it matches the behavior we noticed. When the reads complete normally, there
is no problem - the file is deleted immediately - but when an error occurs the file lingers
because the stream was never closed. I think closing the stream in a finally block should
be a best practice anyway. Perhaps an enhancement to the datastore code would be to mark the
temp file for delete when the JVM terminates as a fail-safe against deficient client code?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message