[ https://issues.apache.org/jira/browse/HBASE-17924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Allan Yang reassigned HBASE-17924: ---------------------------------- Assignee: Allan Yang > 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 > Assignee: Allan Yang > Attachments: HBASE-17924.v0.patch > > > When processing a batch mutation, we take row locks 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. The > protobuf implementation of the messages for multi ops do not reorder the list > of actions. When processing multi ops we iterate over the actions in the > order rehydrated from protobuf. > 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)