[
https://issues.apache.org/jira/browse/HBASE-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177899#comment-13177899
]
Lars Hofhansl commented on HBASE-5108:
--------------------------------------
To be very precise, what happens (ICV, increment, append) is that the WAL is
written with the lock held, but the sync request is issued after the lock is
released.
So what could happen is that the other clients see the updated value in the
memstore (in fact they do see it right away - see HBASE-4583). Now, if the
region server dies before the sync was executed the clients might have based
their logic upon uncommitted state.
We cannot roll back the memstore state for ICVs because the operation is not
idempotent (and for various other reasons also explained in HBASE-4583, all
client scanners see the updates immediately).
I am somewhat torn on this one. This failure scenario is pretty rare, and the
performance implication of doing 100% correct would be significant. Maybe for
ICVs there should be three different options: (1) write WAL synchronously, (2)
don't write WAL, a new option (3) do a "best effort" WAL write.
> ICV puts memstore before writing WAL first -- by default; make the default be
> 'correct' and let better perf be optional
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-5108
> URL: https://issues.apache.org/jira/browse/HBASE-5108
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Priority: Critical
>
> See this thread up on the list and Lars' note on the end:
> http://search-hadoop.com/m/Y6xTRp6sxq1/%2522Help+regarding+RowLock%2522&subj=Help+regarding+RowLock
> I thought it was just ICV that did the memstore put first. This issue is
> about making it so the described behavior is optional and that the default
> out of the box goes for correctness -- i.e. write WAL first and then memstore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
