[ 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]