jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Müller" <thomas.muel...@day.com>
Subject Re: Temp File Semantics
Date Wed, 14 Jan 2009 10:22:29 GMT
Hi,

>> copyWhenReading: The the copy setting, enabled by default. If enabled,
>> a stream is always copied to a temporary file when reading a stream,
>> so that reads can be concurrent. If disabled, reads are serialized.
>
> why is a file necessary for concurrent access? I thought Jackrabbit's architecture was
fundamentally copy-on-write with respect to concurrent modification.

There is a connection pool (3 connections) so if 4 sessions
concurrently read from the DbDataStore one of them has to wait. This
is not a problem if the 3 sessions read quickly, however it is a
problem if they read slowly, not completely read the object (without
closing): in that case the 4th session would be blocked. With a
temporary file, we can guarantee nobody is blocked for a long time.

> Sounds like you have something in an inputstream implementation to detect when you're
at the last byte or close was called. How about some code in the finalize method to delete
the temp file if the stream is garbage-collected?

Yes, that's probably the best solution. There is a small performance
penalty, but the advantage of deleting the file earlier is bigger in
my view. I created a new issue:
https://issues.apache.org/jira/browse/JCR-1934

Regards,
Thomas

Mime
View raw message