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. Comments? Regards, Shaun. -----Original Message----- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: 28 July 2007 07:16 To: [email protected] Subject: Re: JCR Drawback Thoughts Hi, On 7/28/07, Phillip Rhodes <[EMAIL PROTECTED]> 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. BR, Jukka Zitting
