hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-17924) Consider sorting the row order when processing multi() ops before taking rowlocks
Date Fri, 14 Apr 2017 19:13:41 GMT
Andrew Purtell created HBASE-17924:
--------------------------------------

             Summary: Consider sorting the row order when processing multi() ops before taking
rowlocks
                 Key: HBASE-17924
                 URL: https://issues.apache.org/jira/browse/HBASE-17924
             Project: HBase
          Issue Type: Improvement
            Reporter: Andrew Purtell


When processing a batch mutation, we take row locks in doMiniBatchMutation in whatever order
the mutations were added to the multi op by the client.
 
{noformat}
RSRpcServices#multi -> RSRpcServices#mutateRows -> HRegion#mutateRow -> HRegion#mutateRowsWithLocks
-> HRegion#processRowsWithLocks
{noformat}

Or

{noformat}
RSRpcServices#multi -> RSRpcServices#doNonAtomicRegionMutation ->
      HRegion#get 
    | HRegion#append 
    | HRegion#increment 
    | HRegionServer#doBatchOp -> HRegion#batchMutate -> HRegion#doMiniBatchMutation
{noformat}
 
multi() is fed by client APIs that accept a RowMutations object containing actions for multiple
rows. The container for ops inside RowMutations is an ArrayList, which doesn't change the
ordering of objects added to it.

We should discuss sorting the order of ops by row key when processing multi() ops before taking
row locks. Does this make lock ordering more predictable for server side operations? Yes,
but potentially surprising for the client, right? Is there any legitimate reason we should
take locks out of row key sorted order because the client has structured the request as such?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message