[jira] [Updated] (HBASE-18474) HRegion#doMiniBatchMutation is acquiring read row locks
[ https://issues.apache.org/jira/browse/HBASE-18474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18474: --- Description: 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(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. was: 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} What doMiniBatchMutation is doing looks wrong. > HRegion#doMiniBatchMu
[jira] [Updated] (HBASE-18474) HRegion#doMiniBatchMutation is acquiring read row locks
[ https://issues.apache.org/jira/browse/HBASE-18474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18474: --- Description: 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} What doMiniBatchMutation is doing looks wrong. > 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} > What doMiniBatchMutation is doing looks wrong. -- This message was sent by Atlassian JIRA (v6.4.14#64029)