lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (LUCENE-1314) IndexReader.reopen(boolean force)
Date Tue, 01 Jul 2008 05:11:45 GMT


Hoss Man commented on LUCENE-1314:

I haven't really been following this issue, but this comment caught my eye...

bq. So unless we try to track this, when there are N clones out there, any one of them will
be allowed to grab the write lock when a change (deletion or setNorm) is attempted, thus preventing
all the other clones (and all readers open on previous commits) from making changes.

...and gave me an erie sense of deja vu.  looking back at LUCENE-743, the original approach
for reopen was based on cloning and prompted this comment from me...

...which led to some interesting discussion about what the semantics of cloning an IndexReader
should be (even though ultimately cloning wasn't used).

> IndexReader.reopen(boolean force)
> ---------------------------------
>                 Key: LUCENE-1314
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>    Affects Versions: 2.3.1
>            Reporter: Jason Rutherglen
>            Assignee: Michael McCandless
>            Priority: Minor
>         Attachments: lucene-1314.patch, lucene-1314.patch, lucene-1314.patch, lucene-1314.patch
> Based on discussion 
The problem is reopen returns the same reader if there are no changes, so if docs are deleted
from the new reader, they are also reflected in the previous reader which is not always desired

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message