[
https://issues.apache.org/jira/browse/HBASE-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849062#action_12849062
]
Todd Lipcon commented on HBASE-2332:
------------------------------------
bq. So it would be strictly between the clients and a coordinator like
zookeeper, not involving the RS side at all.
I think my response to that comment still applies - the locking has to be
located at the storage layer to be useful (otherwise you don't know if you will
still have the ZK lock by the time your mutation hits the RS).
One thought is that we would provide the locking as an optional flag on
single-row mutations - ie I can advisory-lock a row, and then do a get/put on
that row with a flag that says "only succeed this put if I still own the lock
on the row." So the use case of "lock, get, put, unlock" is still possible,
assuming all users of the row are using this API. We can just skip providing
this API for bulk puts due to the issues raised in [this
comment|https://issues.apache.org/jira/browse/HBASE-2353?focusedCommentId=12849009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12849009]
> 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.21.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.
