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 Wed, 14 Jan 2009 15:02:40 GMT
>> 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.

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