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)
