[
https://issues.apache.org/jira/browse/LUCENE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474924
]
Doron Cohen commented on LUCENE-808:
------------------------------------
[ moving discussion back to JIRA ]
Ning Li wrote:
> On 2/21/07, Doron Cohen (JIRA) <[EMAIL PROTECTED]> wrote:
> > Imagine the application and Lucene could talk, with the current
> > implementation we could hear something like this: ...
>
> However, there could be multiple threads updating the same index. For
> example, thread 1 deletes the term "id:5" twice, thread 2 inserts a
> document with "id:10". The following two are among the possible
> execution sequences:
> Sequence 1:
> thread 1 deletes "id:5"
> thread 1 deletes "id:5"
> thread 2 inserts document "id:10"
> Sequence 2:
> thread 1 deletes "id:5"
> thread 2 inserts document "id:10"
> thread 1 deletes "id:5".
>
> They should return the same numBufferedDeleteTerms, not different ones.
Nice example Ning!
Mmmm... I am still not convinced... :-)
Assume the inserts were with "id:5", then after sequence 1 there
would be a doc with "id:5" in the index, but after sequence 2
there would not be such a doc. NumDocs() would be different
in the two sequences. Why should numBufferedDeleteTerms be the same?
Anyhow, even if we would agree that this is a problem, I think it
is a minor one, and I am ok with deciding to leave things as they
are. Writing this piece from start, you may see internal logic that
I don't see.
Let's give it a few days, perhaps get comments from others,
(perhaps change our mind about it :-) ). If nothing changes
I think I will set "won't fix".
Regards,
Doron
> bufferDeleteTerm in IndexWriter might flush prematurely
> -------------------------------------------------------
>
> Key: LUCENE-808
> URL: https://issues.apache.org/jira/browse/LUCENE-808
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.1
> Reporter: Doron Cohen
> Assigned To: Doron Cohen
> Attachments: successive_bufferDeleteTerm.patch
>
>
> Successive calls to remove-by-the-same-term would increment
> numBufferedDeleteTerms
> although all but the first are no op if no docs were added in between. Hence
> deletes would
> be flushed too soon.
> It is a minor problem, should be rare, but it seems cleaner to fix this.
> Attached patch also fixes TestIndexWriterDelete.testNonRAMDelete() which
> somehow
> relied on this behavior. All tests pass.
--
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]
