lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wettin <>
Subject Re: Lockless read-only deletions in IndexReader?
Date Wed, 22 Aug 2007 12:19:26 GMT
Thanks Mike, I'll dig around a bit and report back what I did.

20 aug 2007 kl. 14.33 skrev Michael McCandless:

> "karl wettin" <> wrote:
>> I want to set documents in my IndexReader as deleted, but I will
>> never commit these deletions. Sort of a filter on a reader rather
>> than on a searcher, and no write-locks.
>> Perhaps I can pass down a IndexDeletionPolicy to my IndexWriter that
>> ignores deletions from the IndexReader(s) to avoid the lock?
> I don't think this will easily work.  The IndexDeletionPolicy just has
> control on which commits should be deleted.  So if you open a reader,
> do deletes, and close it, a new commit (segments_N+1) is created.
> You could have your deletion policy at this point preserve the
> previous commit, but then there's no way to tell IndexWriter on
> opening the index to open the previous commit (it always opens the
> most recent commit).
> I guess if IndexWriter/IndexReader could open old commits, and if your
> app could separately keep track of which commits should be ignored
> (because they were from readers), then you could do it?
> The problem is the reader will still write the commit into the
> directory on close...
>> Changing the directory lock factory it will effect the IndexWriter
>> locks too? So that would not be an option, or?
> Could you just use a NullLockFactory on the reader?  This way when you
> do deletes in the reader and it acquires a write lock it doesn't in
> fact acquire the write lock (as seen by IndexWriter which would
> presumably be using a "real" LockFactory)?
> But, the reader will still write into the directory and stomp on any
> IndexWriter that was also committing ....
>> I could go hacking in IndexReader, definalizing it for decoration of
>> deleteDocument(int), or something like that, but would really
>> prefere not to.
> Yeah I think it may just be cleanest to modify IndexReader to not
> acquire the write lock nor commit its changes to the Directory on
> close.
>> This is for a transactional layer on top of Lucene, where I combine
>> the system index with a transactional index. Updated documents that
>> are represented in the transaction index must be filtered out from
>> the system index at IndexReader level without creating
>> write-locks. undeleteAll() would be an option if there was no locks
>> -- more than one transaction could be updating documents at the same
>> time.
> Sounds wild!
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message