[
https://issues.apache.org/jira/browse/HBASE-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869946#action_12869946
]
Michael Dalton commented on HBASE-2332:
---------------------------------------
One issue with implementing row locks client-side with CAS is that row locks
have leases. So if a client holds a lock, blocks for some reason (swapping,
etc) that is taking an indeterminate amount of time, and then loses its lock
lease, the next lock holder is guaranteed that all future actions taken by the
previous holder using the expired lock will fail. This is very useful when
performing rename-type operations (e.g., moving a value from row A to row B)
where you want the deletion of the source and the creation of the destination
value to appear atomic (and you must recover from mid-rename failures). I
currently use row locks for a few rename-style operations, and
rename-failure-recovery.
This could be emulated in CAS by requiring each row to hold a generation count
or some equivalent, and then incrementing a generation count using CAS every
time the row is mutated as a form of optimistic concurrency control. However,
this would require each row to maintain persistent generation counts even for
deleted rows in the general case, causing deleted rows to consume storage
space.
Is there an objection to just making row lock acquisition non-blocking and
implementing all the blocking/retry/backoff client-side? This should be
backwards compatible with existing APIs. I've started work on this at
[HBASE-2584|https://issues.apache.org/jira/browse/HBASE-2584]. If there is
interest I would expand further on the patch as needed. Otherwise, advisory
locks will solve the generation count issue I outlined above, at least for all
of my needs, as long as they use leases and that they ensure all operations
performed using a lease-expired lock automatically fail.
> Remove client-exposed row locks from region server
> --------------------------------------------------
>
> Key: HBASE-2332
> URL: https://issues.apache.org/jira/browse/HBASE-2332
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: client, regionserver
> Reporter: Todd Lipcon
> Fix For: 0.22.0
>
>
> Discussion in HBASE-2294 has surfaced that the client-exposed row lock
> feature in the HBase API may not be scalable/necessary. Additionally there
> are some benefits we can reap by removing the feature (or pushing it into the
> client).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
