hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12751) Allow RowLock to be reader writer
Date Sun, 26 Jul 2015 21:59:04 GMT

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

stack commented on HBASE-12751:
-------------------------------

Studying the patch more, I have better idea what is going on. It seems mvcc is carrying what
was sequenceid in HRegion now so my comment above on two counters is off. Also deleted a comment
that wasn't helping.

Would it be better if mvcc didn't know anything about memstore? Should we be asking mvcc to
advance memstore...
{code}
    mvcc.advanceMemstore(key.getWriteEntry());
{code}
... though I see that mvcc used to know about memstore so this is nit (I just saw we used
to have completeMemstoreInsertWithSeqNum)

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?)
{code}
        boolean shouldBlock = numReadyToWrite == 0;
{code}

For sure memstoreCells (removed) is same as...
{code}
        for (int j=0; j<familyMaps.length;j++) {
          for(List<Cell> cells:familyMaps[j].values()) {
...
{code}

No chance that what is passed to Store to add gets filtered or ends up being subset for any
reason?

The comment below no longer applies? It is dropped in the patch.

{code}
        // there may be some in-flight transactions, but they won't be made visible since
they are
        // either greater than flush seq number or they were already dropped via flush.
        // TODO: If we are using FlushAllStoresPolicy, then this can make edits visible from
other
        // stores while they are still in flight because the flush commit marker will not
contain
        // flushes from ALL stores.
        getMVCC().advanceMemstoreReadPointIfNeeded(flush.getFlushSequenceNumber());
{code}

In mvcc it is memstoreRead for the read point. The name seems to say it applies to memstore
only. It does not apply to hfiles? HFiles carry sequenceids on edits and in metadata.

Will be back to do final 1/3rd of patch.





> 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