lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <reng...@ix.netcom.com>
Subject Re: [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Tue, 13 Nov 2007 05:55:52 GMT
True. It seems that the Lucene code might be a bit more resilient  
here though, using the following:

1. open the segments file exclusively (if this fails, updates are  
prohibited, and an exception is thrown)
2. write new segments
3. write segments.new including segments hash & sync
4. update segments file including hash
5. delete segments that you can

Then if it crashes in step 4, it is easy to know segments is bad (out  
of date) and use segments.new
If it crashes in steps 3, then segments.new is easily detected as  
being corrupt (hash does not match), so you know segments is valid.

if there are segments that cannot be deleted in 5, every open can  
check if it can delete them...

A similar technique can be used if using lockless commits, just need  
to make it segments.XXX.new, etc.

On Nov 12, 2007, at 7:21 PM, Yonik Seeley wrote:

> On Nov 12, 2007 7:19 PM, robert engels <rengels@ix.netcom.com> wrote:
>> I would still argue that it is an incorrect setup - almost as bad as
>> "not plugging the computer in".
>
> A user themselves could even go in and look at the index files (I've
> done so myself)... as could a backup program or whatever.  It's a fact
> of life on windows that a move or delete can fail.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message