[HBASE-18474] Document how HRegion#doMiniBatchMutation is acquiring read row locks

• Type: Bug
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Fix Version/s: 3.0.0-beta-2
• Component/s: documentation
• Assignee: Unassigned
• Reporter: Andrew Kyle Purtell
• Created: 28/Jul/17 20:10
• Updated: 16/Dec/23 09:45

Description

Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in step 1.

        // 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);
        }

Other code paths that apply mutations are acquiring write locks.

In HRegion#append

    try {
      rowLock = getRowLockInternal(row, false);
      assert rowLock != null;
...

In HRegion#doIn

    try {
      rowLock = getRowLockInternal(increment.getRow(), false);
...

In HRegion#checkAndMutate

      // 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();

In HRegion#processRowsWithLocks

      // 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));
      }

and so on.

What doMiniBatchMutation is doing looks wrong.

Issue Links

• is related to: PHOENIX-4053 Lock row exclusively when necessary for mutable secondary indexing