You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2018/04/30 17:38:04 UTC

[jira] [Updated] (HBASE-18474) Document how HRegion#doMiniBatchMutation is acquiring read row locks

     [ https://issues.apache.org/jira/browse/HBASE-18474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-18474:
--------------------------
    Fix Version/s:     (was: 2.0.0)
                   3.0.0

> Document how HRegion#doMiniBatchMutation is acquiring read row locks
> --------------------------------------------------------------------
>
>                 Key: HBASE-18474
>                 URL: https://issues.apache.org/jira/browse/HBASE-18474
>             Project: HBase
>          Issue Type: Bug
>          Components: documentation
>            Reporter: Andrew Purtell
>            Assignee: stack
>            Priority: Major
>             Fix For: 3.0.0
>
>
> Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in step 1. 
> {code}
>         // If we haven't got any rows in our batch, we should block to                                                                           
>         // get the next one.                                                                                                                     
>         RowLock rowLock = null;
>         try {
>           rowLock = getRowLockInternal(mutation.getRow(), true);
>         } catch (TimeoutIOException e) {
>           // We will retry when other exceptions, but we should stop if we timeout .                                                             
>           throw e;
>         } catch (IOException ioe) {
>           LOG.warn("Failed getting lock in batch put, row="
>             + Bytes.toStringBinary(mutation.getRow()), ioe);
>         }
>         if (rowLock == null) {
>           // We failed to grab another lock                                                                                                      
>           break; // stop acquiring more rows for this batch                                                                                      
>         } else {
>           acquiredRowLocks.add(rowLock);
>         }
> {code}
> Other code paths that apply mutations are acquiring write locks.
> In HRegion#append
> {code}
>     try {
>       rowLock = getRowLockInternal(row, false);
>       assert rowLock != null;
> ...
> {code}
> In HRegion#doIn
> {code}
>     try {
>       rowLock = getRowLockInternal(increment.getRow(), false);
> ...
> {code}
> In HRegion#checkAndMutate
> {code}
>       // Lock row - note that doBatchMutate will relock this row if called                                                                       
>       RowLock rowLock = getRowLockInternal(get.getRow(), false);
>       // wait for all previous transactions to complete (with lock held)                                                                         
>       mvcc.await();
> {code}
> In HRegion#processRowsWithLocks
> {code}
>       // 2. Acquire the row lock(s)                                                                                                              
>       acquiredRowLocks = new ArrayList<RowLock>(rowsToLock.size());
>       for (byte[] row : rowsToLock) {
>         // Attempt to lock all involved rows, throw if any lock times out                                                                        
>         // use a writer lock for mixed reads and writes                                                                                          
>         acquiredRowLocks.add(getRowLockInternal(row, false));
>       }
> {code}
> and so on.
> What doMiniBatchMutation is doing looks wrong. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)