jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kiehl <ki...@subshell.com>
Subject Re: Jackrabbits own FileSystem and unit tests
Date Thu, 31 Aug 2006 11:59:50 GMT
Marcel Reutegger wrote:
> Christoph Kiehl wrote:
>>> in the long term I would like to put the index in the repository 
>>> itself. but that means that the repository (at least internally) has 
>>> to support random access on its binary resources.
>> Hm, sounds interesting, but wouldn't this only work with file system 
>> based persistence managers?
> no, the index would simply store its files as jcr resource nodes and any 
> persistence manager must be able to handle binary properties.

Okay ;) I didn't mean technical limitations, more practical limitations.

> Jackrabbit already does some optimization. when a binary property is 
> read it is either copied into memory if it is smaller than 64k or 
> spooled to a temp file. Further access to that property is then either 
> directly from memory or a local file.
> finally, what is it good for?
> - jackrabbit does not need a separate location for the index anymore, 
> it's all in the repository itself.
> - the index will be fully transactional. See issue JCR-204

I like the idea of having a transactional index but I don't think it's a good 
idea to read this index from a binary property in a database, because in our 
case we've got a fairly large repository where we got index files with a size of 
40MB. As far as I understand you have to transfer 40MB to the database on every 
index change that gets committed. Am I right?


View raw message