[
https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263468#comment-14263468
]
Elliott Clark commented on HBASE-12751:
---------------------------------------
Yeah that's my thought. Puts for the same cell are already ordered by sequence
number. So it shouldn't matter the order that they are applied to the memstore
as long as the memstore correctly orders them there. There will be a slight
change in behavior. Right now it's not possible for two puts to come in and
have timestamps generated on the regionserver that don't order the same as the
sequence id. However as long as the memstore correctly orders cells by
timestamp then by sequence id it shouldn't be a behavioral change. We've never
made any guarantees about the relationship of TS to seqid since TS is user
setable.
Cells that are the same row but totally different cells can't have ordering
issues. So they aren't an issue however right now they are paying the same cost
as if they could. It's a reasonable trade off in order to keep the number of
bytes that need to be compared to get a lock down.
However any check and mutate type action still needs to be able to say that
nothing else changes the value concurrently. For that a write lock is needed.
Seems like row locks were initially put in to be exposed to the client
(HBASE-798). That was a bad idea because of region movement. And so it was
removed. However by that time incrementColumnValue had been committed and that
needed row locks; so did check and put and the later check and mutate.
> Allow RowLock to be reader writer
> ---------------------------------
>
> Key: HBASE-12751
> URL: https://issues.apache.org/jira/browse/HBASE-12751
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Elliott Clark
>
> Right now every write operation grabs a row lock. This is to prevent values
> from changing during a read modify write operation (increment or check and
> put). However it limits parallelism in several different scenarios.
> If there are several puts to the same row but different columns or stores
> then this is very limiting.
> If there are puts to the same column then mvcc number should ensure a
> consistent ordering. So locking is not needed.
> However locking for check and put or increment is still needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
