[
https://issues.apache.org/jira/browse/HBASE-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870055#action_12870055
]
Todd Lipcon commented on HBASE-2332:
------------------------------------
bq. 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
Only on that particular row, though, since the leases are per-regionserver.
bq. Is there an objection to just making row lock acquisition non-blocking and
implementing all the blocking/retry/backoff client-side?
I definitely agree that this solves much of the scalability issue. Some of the
other issues above still remain, though - for example, we don't currently
persist lock acquisition/release in the HLog, so if the region moves to a new
server, everyone loses their locks.
Regarding the use case of moving rows, what does your lock based algorithm look
like? Will it proceed correctly in the case of RS failure, loss of lease at
arbitrary points, and failure of client?
> 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.
