[
https://issues.apache.org/jira/browse/HBASE-25913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356996#comment-17356996
]
Andrew Kyle Purtell commented on HBASE-25913:
---------------------------------------------
Draft PR: https://github.com/apache/hbase/pull/3352
> Introduce EnvironmentEdge.currentTimeAdvancing
> ----------------------------------------------
>
> Key: HBASE-25913
> URL: https://issues.apache.org/jira/browse/HBASE-25913
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0
>
> Attachments: HBASE-25913_Multithreaded_Benchmarks.pdf,
> JMH-HBASE-25913.pdf, jmh-HBASE-25913.tar.gz
>
>
> Introduce new {{EnvironmentEdge#currentTimeAdvancing}} which ensures that
> when the current time is returned, it is the current time in a different
> clock tick from the last time the {{EnvironmentEdge}} was used to get the
> current time.
> When processing mutations we substitute the {{Long.MAX_VALUE}} timestamp
> placeholder with a real placeholder just before committing the mutation. The
> current code gets the current time for timestamp substitution while under row
> lock and mvcc. We will simply use {{EnvironmentEdge#currentTimeAdvancing}}
> instead of {{EnvironmentEdge#currentTime}} at this point in the code to
> ensure we have seen the clock tick over. When processing a batch of mutations
> (doMiniBatchMutation etc) we will call {{currentTimeAdvancing}} only once.
> This means the client cannot bundle cells with wildcard timestamps into a
> batch where those cells must be committed with different timestamps. Clients
> must simply not submit mutations that must be committed with guaranteed
> distinct timestamps in the same batch. Easy to understand, easy to document,
> and it aligns with our design philosophy of the client knows best.
> It is not required to handle batches as proposed. We could guarantee a
> distinct timestamp for every mutation in a batch. Count the number of
> mutations, call this M. Acquire all row locks and get the current time. Then,
> wait for at least M milliseconds. Then, set the first mutation timestamp with
> this value and increment by 1 for all remaining. Then, do the rest of
> mutation processing as normal. I don't think this extra waiting to reserve
> the range of timestamps is necessary. See reasoning in above paragraph.
> Mentioned here for sake of discussion.
> It will be fine to continue to use {{EnvironmentEdge#currentTime}} everywhere
> else. In this way we will only potentially spin wait where it matters, and
> won't suffer serious overheads during batch processing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
