[
https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702198#comment-14702198
]
Elliott Clark commented on HBASE-12751:
---------------------------------------
bq.Should be 'for the region'?
Yep.
bq.Any chance at unification in a follow-on in your opinion?
Totally. There are still some weird things in the write path that need to be
polished up.
bq.We run through all edits twice, once to set OperationStatus.SUCCESS and then
later to do postPut/postDelete on CP. Could these be combined?
I would think that it's ok. Though I don't have much experience with CP use
cases.
bq.How is this addressed?
It's not and I shouldn't have removed it.
bq.Why this long currentSeqId = mvcc.readPoint.get(); and not mvcc.getReadPoint?
I should make it getReadPoint.
bq.Ain't this done already for you higher up when you come in for a region
operation?
That was there before. At FB we're still seeing an error every once in a while
about row out of range for replication traffic. It would be great to remove it
or make it happen less frequently.
bq.writeCompactionMarker and writeRegionEventMarker in WALUtil are hard to
follow
Yeah they haven't had enough attention from me on cleaning that code up. It was
mostly done by a quick pass where the rest of the mvcc stuff got some more love.
bq.Let me see why all the test failures.
What I've been seeing is a deadlock on taking down a regionserver. Running
only one method in the class that errors out means that everything passes.
> Allow RowLock to be reader writer
> ---------------------------------
>
> Key: HBASE-12751
> URL: https://issues.apache.org/jira/browse/HBASE-12751
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 2.0.0, 1.3.0
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-12751-v1.patch, HBASE-12751-v10.patch,
> HBASE-12751-v10.patch, HBASE-12751-v11.patch, HBASE-12751-v12.patch,
> HBASE-12751-v13.patch, HBASE-12751-v14.patch, HBASE-12751-v15.patch,
> HBASE-12751-v16.patch, HBASE-12751-v17.patch, HBASE-12751-v18.patch,
> HBASE-12751-v19 (1).patch, HBASE-12751-v19.patch, HBASE-12751-v2.patch,
> HBASE-12751-v3.patch, HBASE-12751-v4.patch, HBASE-12751-v5.patch,
> HBASE-12751-v6.patch, HBASE-12751-v7.patch, HBASE-12751-v8.patch,
> HBASE-12751-v9.patch, HBASE-12751.patch
>
>
> Right now every write operation grabs a row lock. This is to prevent values
> from changing during a read modify write operation (increment or check and
> put). However it limits parallelism in several different scenarios.
> If there are several puts to the same row but different columns or stores
> then this is very limiting.
> If there are puts to the same column then mvcc number should ensure a
> consistent ordering. So locking is not needed.
> However locking for check and put or increment is still needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
