[
https://issues.apache.org/jira/browse/HBASE-25975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17358967#comment-17358967
]
Andrew Kyle Purtell commented on HBASE-25975:
---------------------------------------------
Some discussion copied from parent
The basic idea is this:
First, check if the clock has advanced, atomically. If it has, then clear
the row set, also atomically, with respect to the clock advance check.
Get a reference to the row set for the current tick. Run through all of the
rows involved in the pending mutation. The check adds each row to the set, but
allows the pending mutation as long as each row did not exist in the set when
it was added.
If the pending mutation is going to be allowed to go forward, return the
time where we did the atomic clock advance check as the time we will make
timestamp substitutions with.
Otherwise, yield the thread, and try again, which will keep the handler in
queue until the row set is finally disjoint from any other (per the check logic
described above)
One thing I realized I'm missing while typing this up is some kind of rollback
if we added rows to the set for something which overlaps elsewhere, and so
might block some other pending operation on rows for this mutation that is
going to yield instead of go forward. That's what I was alluding to above...
what I have right now is too simple.
Edit: The straightforward thing to do is a synchronized section that does all
of the existence tests with the set but doesn't mutate the set until we have a
pass or yield decision, at which point the result is merged to the set or not.
Hmm,..
> Row commit sequencer
> --------------------
>
> Key: HBASE-25975
> URL: https://issues.apache.org/jira/browse/HBASE-25975
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0
>
>
> Use a row commit sequencer in HRegion to ensure that only the operations that
> mutate disjoint sets of rows are able to commit within the same clock tick.
> This maintains the invariant that more than one mutation to a given row will
> never be committed in the same clock tick.
> Callers will first acquire row locks for the row(s) the pending mutation will
> mutate. Then they will use RowCommitSequencer.getRowSequence to ensure that
> the set of rows about to be mutated do not overlap with those for any other
> pending mutations in the current clock tick. If an overlap is identified,
> getRowSequence will yield and loop until there is no longer an overlap and
> the caller's pending mutation can succeed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
