[jira] [Comment Edited] (HBASE-18474) HRegion#doMiniBatchMutation is acquiring read row locks

["Andrew Purtell (JIRA)" <ji...@apache.org>]

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

Andrew Purtell edited comment on HBASE-18474 at 7/30/17 10:34 PM:
------------------------------------------------------------------

Thanks Stack. I filed this for discussion because we ran into problems because exclusive row locking for some coprocessor upcalls in 0.98 went away with this change, and doMiniBatchMutation with all of its change history is a beast. Information provided here has been very helpful, thank you.

I've resolved this as Not A Problem. 


was (Author: apurtell):
Thanks Stack. I filed this for discussion because I don't claim to understand everything that has happened to doMiniBatchMutation since 0.98. Information provided here has been very helpful, thank you.

I've resolved this as Not A Problem. 

> HRegion#doMiniBatchMutation is acquiring read row locks
> -------------------------------------------------------
>
>                 Key: HBASE-18474
>                 URL: https://issues.apache.org/jira/browse/HBASE-18474
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Andrew Purtell
>
> 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
(v6.4.14#64029)