[ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
|