hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12751) Allow RowLock to be reader writer
Date Tue, 24 Mar 2015 20:24:54 GMT

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

Enis Soztutar commented on HBASE-12751:

Makes sense. From my notes from 1 year ago: 
Different strategies for transactions depending on the type: 

 Read-only    (get, scan)
 Write-only    (put)
 Read-Write  (increment, append, row processor)

Current transaction models
Current model for write only transactions
1. lock the rows 
2. update latest timestamps
3. get mvcc number
  3.1. sync writeQueue
  3.2. increment write number
  3.3. add trx to the writeQueue
4. Insert to memstore (with mvcc number)
5. AppendNoSync() to WAL
  5.1. obtain seq_num
  5.2. append entry to pendingWrites (our own linked list buffer)
6. Release row locks
7. sync WAL
  7.1. hlogflush (append pending writes to hdfs buffer)
  7.2. increase sync point
8. Complete memstore insert
  8.1. sync writeQueue
  8.2. mark write completed.
  8.3. advanceMvcc number as much as possible (from the writeQueue). Notify all waiters
  8.4. wait for mvcc read number to advance past our mvcc write number

Current model for read only transactions
1. Obtain mvcc read number
2. Perform scans with that mvcc number 

Current model for read-write transactions (increment)
1. lock the row 
2. get an mvcc number, wait for all transaction to finish before this number 
3. get mvcc number
4. Do the reads for the transaction, compute writes for the transaction. Always use current
5. Insert to a temporary memstore
6. AppendNoSync() to WAL
7. Insert to memstore
8. Release row locks
9. sync WAL
10. Complete memstore insert

Current model for read-write transactions (processRowsWithLocks)
1. lock the rows
2. Do the reads for the transaction, compute writes for the transaction (RowProcessor)
3. get mvcc write number
4. Insert to memstore
5. AppendNoSync() to WAL
6. Release row locks
7. sync WAL
8. Complete memstore insert

Note, there is no waiting for all trx to finish after acquiring row locks (bug?)

  - Write-only trxs do not need the row lock. Pure writes can be serialized with mvcc or seq_num’s.

  - Read-only trxs should be kept as is for performance (use mvcc) 
  - Read-write trxs can conflict with other read-write trx / or write trasactions

We do not need row locks for conflict resolution for write-only transactions, but we still
need locking for conflicts between read-write and read-write/write only transactions. Doing
shared locks should help with this. We are optimizing for write-only transactions at the expense
of read-write transactions (which today have to wait for ALL transactions that started before
its start time to finish). 

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

View raw message