[
https://issues.apache.org/jira/browse/HBASE-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706274#comment-13706274
]
Elliott Clark commented on HBASE-8927:
--------------------------------------
bq.The hardware clocks themselves do not go back, but if two updates come with
seq_num X and seq_num X+1, then X+1 might get a smaller ns because the hardware
thread might observe a different clock than the other thread.
That can happen now if the mutations are not on the same row:
* [Thread 1] Mutation A comes in to thread
* [Thread 1] Wal edit A gets seq id.
* [Thread 1] Thread Context Switches
* [Thread 2] Mutation B comes in
* [Thread 2] Wal edit B gets seq id.
* [Thread 2] Mutation B gets timestamp.
* [Thread 1] Wakes up
* [Thread 1] Mutation A gets time stamp.
A.id < B.id && A.ts > B.ts
Locks ensure this isn't an issue on the same row.
> Use nano time instead of mili time everywhere
> ---------------------------------------------
>
> Key: HBASE-8927
> URL: https://issues.apache.org/jira/browse/HBASE-8927
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Attachments: 8927.txt
>
>
> Less collisions and we are paying the price of a long anyways so might as
> well fill it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
