>> 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 even though you are spooling the file to disk, you will be holding one of the pooled connections for the duration of the copy from the DB to the disk. In this case, a large file requested by multiple threads can still exhaust the pool. In our scenario, we stream the data directly to the client as fast as possible, so the only performance gain is the difference in speed between streaming from DB to the disk and streaming from the disk to the client which can be negligible in most cases (corporate intranet environment). Since we have a very fast pipe to the DB, it sounds like increasing the pool size may be a better alternative. Can you confirm? Also, is it possible to use a container-managed pool or control the behavior of the built-in pool at a more granular level (e.g. - validation, max/min size)? >> 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 Excellent! Thanks.
