Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Users List" <lucene-user@jakarta.apache.org>
To: lucene-user@jakarta.apache.org
From: Leos Literak <literakl@centrum.cz>
Subject: Re: potential synchronization problem
Date: Fri, 30 Apr 2004 14:10:04 +0200
Lines: 19
Message-ID: <c6tflg$rn5$1@sea.gmane.org>
References: <1083306765.18579.12.camel@localhost.localdomain>
 <20040430115130.99677.qmail@web12703.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
In-Reply-To: <20040430115130.99677.qmail@web12703.mail.yahoo.com>
Sender: news <news@sea.gmane.org>

Otis Gospodnetic wrote:
> Yes.
> I suggest you devise a 'index request queue' mechanism to handle
> situations like this.  This can probably be made quite generic (i.e.
> not Lucene and not indexing specific).  How you go about implementing
> this is up to.

I handle this with script, which
1\ generates new index to temporary directory
2\ removes directory with old index
3\ renames temporary directory to standard location

unfortunatelly this doesn't garantee atomicity, so
I can find in logs exceptions, when user performed
search in 2\ or 3\ steps. Because step 1\ takes
ten minutes, while 2\ and 3\ several seconds at most,
I am happy with this solution.

Leos


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