jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sbarriba" <sbarr...@yahoo.co.uk>
Subject RE: JCR Drawback Thoughts
Date Sun, 29 Jul 2007 10:03:44 GMT
Hi Jukka et al,

I've always preferred to avoid putting binaries in the database put to ensure high availability
of our JackRabbit deployment we're using clustering with a database journal with binaries
in the database (clustering requires that binaries are stored in the database).

Zukka wrote:
"unfortunately always makes a temporary copy of the value when the node containing it is accessed"

Zukka, am I right in concluding from your statement that every time a query result set includes
an object with binary field that binary data is retrieved from the database and stored locally?
Or is there some caching which ensures this is done only once?

If this is the case for every query then I foresee problems for our application which stores
100's of binaries in the 10's of MBs size.



-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com] 
Sent: 28 July 2007 07:16
To: users@jackrabbit.apache.org
Subject: Re: JCR Drawback Thoughts


On 7/28/07, Phillip Rhodes <spamsucks@rhoderunner.com> wrote:
> Much of my application consists of 1) Search 2) display search results 3) view search
> result. If I perform a search, and I get a hit on a PDF document, I do not need to load
> the pdf byte array (jcr:data) into the node in order to display my search results.

Are you storing the binary values in the database? In that case
Jackrabbit unfortunately always makes a temporary copy of the value
when the node containing it is accessed. You can avoid that by having
the binary values stored on the file system in the first place.

The problem with temporary copies should be completely solved by
Jackrabbit 1.4, when we get the data store feature that is currently
being developed. Then only references to large binary values are
handled in normal operations, and the binary stream is only accessed
if explicitly requested by the client.


Jukka Zitting

View raw message