[
https://issues.apache.org/jira/browse/LUCENE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512249
]
Steven Parkes commented on LUCENE-938:
--------------------------------------
Easy first: there's a comment in the code about cloning the buf delete term
hash with a clear vs. copying the reference and creating a new hash. I've gone
back and forth. I don't have a strong opinion.
I did notice that every call to startTransaction had flushed the deletes ahead
but I didn't see that it was required to be so. I can go either way on this,
too. I'd vote for making startTransaction safer. I think, in theory, it could
be opened to users at some point, if it were to help people trying to use
Lucene in certain transactional contexts.
Of course, that violates YAGNI.
But I hadn't looked at the ram segments. Does look like if there are any at the
start of a trans. and they get flushed, they would/might get lost? Since that
touches on the index file deleter, it strikes me as more complex.
> I/O exceptions can cause loss of buffered deletes
> -------------------------------------------------
>
> Key: LUCENE-938
> URL: https://issues.apache.org/jira/browse/LUCENE-938
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Steven Parkes
> Assignee: Steven Parkes
> Fix For: 2.3
>
> Attachments: LUCENE-938.take2.patch, LUCENE-938.txt, LUCENE-938.txt
>
>
> Some I/O exceptions that result in segmentInfos rollback operations can cause
> buffered deletes that existed before the rollback creation point to be
> incorrectly lost when the IOException triggers a rollback.
--
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]
