From ab@getopt.org Mon Aug 11 20:28:46 2003 Return-Path: Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 5121 invoked from network); 11 Aug 2003 20:28:46 -0000 Received: from smtp.acn.pl (HELO mail1.astercity.net) (212.76.33.20) by daedalus.apache.org with SMTP; 11 Aug 2003 20:28:46 -0000 Received: from getopt.org (75-mo3-2.acn.waw.pl [62.121.105.75]) by mail1.astercity.net (sendmail) with ESMTP id 7F8552623B1 for ; Mon, 11 Aug 2003 22:28:49 +0200 (CEST) Message-ID: <3F37FCEE.8000805@getopt.org> Date: Mon, 11 Aug 2003 22:30:38 +0200 From: Andrzej Bialecki User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Developers List Subject: Re: Adding lock timeouts to write.lock References: <3F340378.3020301@etapestry.com> <3F37E7EE.8010301@lucene.com> <3F37F39F.7000503@etapestry.com> <3F37F53F.40104@lucene.com> In-Reply-To: <3F37F53F.40104@lucene.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Doug Cutting wrote: > Scott Ganyo wrote: > >> Thanks, Doug. Unfortunately, as you know, IndexWriter isn't the only >> one using these locks: >> >> 1) IndexReader uses the "commit.lock" when opening. >> >> 2) IndexReader needs to create a "write.lock" during the delete process. >> >> So, although perhaps not a perfect solution, it seems to me that Lock >> is still at least a common place to define these and less confusing >> than putting them on IndexWriter -- which is only one of the classes >> that use then contants. > > > Yes, I realize that multiple classes use these constants. But they're > only used in the index package, so I thought they'd be better off there. > They're not used by anything in the storage package. IndexWriter uses > them the most, so it seems like the best place to me. On a somewhat related note... The issue of creating locks (and having some central place to manage them) is related to read-only environment. I was trying the other day to come up with an easy solution for opening index in read-only mode. Short of rewriting FSDirectory I couldn't find any solution. Even this wasn't perfect, because some operations (like IndexReader.delete()) are cached, and don't report immediately that they will ultimately fail... Any ideas here? -- Best regards, Andrzej Bialecki ------------------------------------------------- Software Architect, System Integration Specialist CEN/ISSS EC Workshop, ECIMF project chair EU FP6 E-Commerce Expert/Evaluator ------------------------------------------------- FreeBSD developer (http://www.freebsd.org)