[
https://issues.apache.org/jira/browse/HBASE-13531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523486#comment-14523486
]
Jonathan Hsieh commented on HBASE-13531:
----------------------------------------
To elaborate on Anoop's comment, I don't think the mob hfiles are involved --
the refs in the normal cells are only written once and only ever point to one
mob hfile. This would imply maybe a acid-violating race at the CF level.
Maybe something with when the cf's flushing and scanners are being created?
Cells with the same row/cf/cq/ts should have a last written wins policy. I'm a
little fuzzy on how this is guaranteed in the implementation. This is relevant
because in the particular example in the early comment, the conflicting cf data
both have the same ts.
> After 4/18/15 merge, flakey failures of
> TestAcidGuarantees#testMobScanAtomicity
> -------------------------------------------------------------------------------
>
> Key: HBASE-13531
> URL: https://issues.apache.org/jira/browse/HBASE-13531
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Affects Versions: hbase-11339
> Reporter: Jonathan Hsieh
> Fix For: hbase-11339
>
>
> After the merge of master from 4/18/15 with hbase-11339 branch, we encounter
> some atomicity violations. We want to fix before calling merge to trunk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
