Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 33425 invoked from network); 1 Sep 2006 15:08:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Sep 2006 15:08:58 -0000 Received: (qmail 15964 invoked by uid 500); 1 Sep 2006 15:08:57 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 15930 invoked by uid 500); 1 Sep 2006 15:08:57 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 15921 invoked by uid 99); 1 Sep 2006 15:08:57 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Sep 2006 08:08:57 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 01 Sep 2006 08:08:57 -0700 Received: (qmail invoked by alias); 01 Sep 2006 15:08:35 -0000 Received: from adsl-84-227-8-208.adslplus.ch (EHLO [192.168.0.102]) [84.227.8.208] by mail.gmx.net (mp002) with SMTP; 01 Sep 2006 17:08:35 +0200 X-Authenticated: #894343 Message-ID: <44F84CF0.4090905@gmx.net> Date: Fri, 01 Sep 2006 17:08:32 +0200 From: Marcel Reutegger User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: Jackrabbits own FileSystem and unit tests References: <510143ac0608270703h78e4863bm8a2040aca36455c4@mail.gmail.com> <90a8d1c00608300308w73ff275cp987296f40f3fe924@mail.gmail.com> <90a8d1c00608300910h72d77267uf1813bcc2e91f2b0@mail.gmail.com> <44F6888B.7070202@gmx.net> <44F6C6F6.8090704@gmx.net> <44F718A7.6080303@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N lots of answers... Christoph Kiehl wrote: > Ok. To get this working, you have to create at least one segment per > transaction, right? not necessarily. as an optimization the current implementation uses the redo.log to keep track of index modifications that were only done in memory. this means that at the end of a transaction there won't necessarily be a new index segment on disk. > And index merging could be done in background? index merging *is* already done in the background. > Sounds really interesting. But if the blob values are cached locally > they have to be downloaded on startup first before the index starts to > be fast. correct. > Or does the blob cache survive restarts? no, it doesn't. regards marcel