hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Clark (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12751) Allow RowLock to be reader writer
Date Tue, 07 Apr 2015 16:43:13 GMT

    [ 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)

Mime
View raw message