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
