[
https://issues.apache.org/jira/browse/HBASE-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990683#comment-12990683
]
Jonathan Gray commented on HBASE-3504:
--------------------------------------
bq. Out of order edits though could be a problem in case where we got a new
value and a delete of that same value coming in at around the same time. Out of
order could change result seen on other side of the log split.
This would only be an issue if it is the _exact_ same time (same timestamp).
The same potential issue would exist with two Put operations of the same
row/col/ts (we expect the later one to win). However, in this case, it's not
actually an issue because the row lock ensures that these two things (even if
at the same ms timestamp) will happen serially from POV of HLog... even without
the update lock, the writes will happen in order because they are done under
the row lock.
So the guarantee is that for a given row, it is always increasing seqids.
Across rows, it mostly will be but there is no guarantee. In my code
inspection, it doesn't seem like this is a problem
> HLog performance improvement
> ----------------------------
>
> Key: HBASE-3504
> URL: https://issues.apache.org/jira/browse/HBASE-3504
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
>
> The HLog.updateLock protects the rolling of logs with concurrent writes to
> the HDFS log file. This is a scalability bottleneck for a workload that
> comprises mostly of counter-increments.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
