[
https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483469#comment-14483469
]
Elliott Clark commented on HBASE-12751:
---------------------------------------
bq.When we come back from an append, the WALEdit has its seqid? Good.
Not always but normally the append happens fast enough that it's instant.
However walkey.getSequenceId has a count down latch. So getting the mvccNum
waits to make sure that the cells are at least appended.
bq.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.
That would be pretty radical. Let me think on that for a little bit.
bq.This looks like nice ironing out of some of the chicanery we have going on
in our write path.
I think there is still some more to iron out around the Mvcc write entry.
> 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)
