Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 1509 invoked from network); 31 Jan 2002 01:32:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 31 Jan 2002 01:32:00 -0000 Received: (qmail 22060 invoked by uid 97); 31 Jan 2002 01:32:07 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 22043 invoked by uid 97); 31 Jan 2002 01:32:06 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 22032 invoked from network); 31 Jan 2002 01:32:06 -0000 Message-ID: <3C589EF9.7020607@earthlink.net> Date: Wed, 30 Jan 2002 18:33:45 -0700 From: Dmitry Serebrennikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Lucene Developers List Subject: Re: DO NOT REPLY [Bug 6140] New: - Delete is not multi-thread safe References: <20020131011101.15362.qmail@nagoya.betaversion.org> 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 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N bugzilla@apache.org wrote: >Here is a pseudo-code > >writer.open() >writer.add(documentA); >writer.close() // this creates segment1 with 1 document > >reader.open() // this reader can be opened by another process >writer.open() // this creates segment2 with one document >reader.delete(documentA) // using unique term // here delete is done in-memory >writer.add(documentB) >writer.close() // writer will merge two segments, delete segment2 > // and will mark segment1 for deletion because > // reader holds files to segment1 open > >reader.close() // reader writes out .del file, but that is too > // late > >searcher.open() >searcher.search("term_common_to_docA_and_docB") // returns both docA and docB > > >It seems that either a) deletes should be write-through, or b) deletes should >be done by the writer, or c) writer should not optimize non-RAM segments unless >asked to. As a client, I like option b) the best, though, this is not the >easiest option to implement. My $0.02 > Or maybe d) when merging, a writer should share an in-memory image of segment1 and prohibit any deletes on segment one while merge is in progress? Personally, I would also like to see deletion moved into the writer. Another $0.02 -- To unsubscribe, e-mail: For additional commands, e-mail: