lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless" <>
Subject Re: Lockless read-only deletions in IndexReader?
Date Mon, 20 Aug 2007 12:33:46 GMT

"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

> 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!


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

View raw message