[
https://issues.apache.org/jira/browse/LUCENE-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609456#action_12609456
]
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...
https://issues.apache.org/jira/browse/LUCENE-743?focusedCommentId=12534123#action_12534123
...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: https://issues.apache.org/jira/browse/LUCENE-1314
> 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
> http://www.nabble.com/IndexReader.reopen-issue-td18070256.html. 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 behavior.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
