[
https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483381#comment-14483381
]
stack commented on HBASE-12751:
-------------------------------
[~jleach] FYI
Skimmed.
When we come back from an append, the WALEdit has its seqid? Good.
bq. 3092 doRollBackMemstore = true; // If we have a failure, we
need to clean what we wrote
Dang, I suppose we still need above.... pity couldn't push the insert to
memstore out past the sync.. so could do without the rollback stuff.
Fix step numbering order in processRowsWithLocks
This looks like nice ironing out of some of the chicanery we have going on in
our write path.
> 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
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Attachments: HBASE-12751-v1.patch, HBASE-12751-v2.patch,
> HBASE-12751-v3.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)
