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 Mon, 27 Jul 2015 05:20:06 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642275#comment-14642275
] 

Elliott Clark commented on HBASE-12751:
---------------------------------------

bq.Would it be better if mvcc didn't know anything about memstore? Should we be asking mvcc
to advance memstore...
Yeah that's pretty bad wording. Something like advanceReadPoint? Some other wording for sure.

bq.We dropped an optimization when we let go of the below and instead just say true for getRowLock..
Or was it something that just didn't work? (Or looks like the semantic changed from waitFor
to whether a read or write lock?)
The hope is that since we won't be blocking for any normal puts there is no need for the added
complexity.


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

Mime
View raw message