[
https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530197#comment-13530197
]
Sergey Shelukhin commented on HBASE-7305:
-----------------------------------------
After cursory look at the patch, I have two questions...
1) I think I saw an article about standard zk primitives library, and iirc even
discussed it with Enis. Is it the curator library meant above? If so we should
probably switch to it. Especially if it's easy to modify :)
2) More broadly, I wonder about the scalability impact of this. At the minimum,
locks need to be write-preference to prevent region servers on large clusters
from starving the clients and master forever (separate problem is what to do
with stray region servers stuck with lock (ZK will take care of that?), but
many servers can starve master/clients by sheer force of numbers).
> ZK based Read/Write locks for table operations
> ----------------------------------------------
>
> Key: HBASE-7305
> URL: https://issues.apache.org/jira/browse/HBASE-7305
> Project: HBase
> Issue Type: Bug
> Components: Client, master, Zookeeper
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 0.96.0
>
> Attachments: hbase-7305_v0.patch
>
>
> This has started as forward porting of HBASE-5494 and HBASE-5991 from the
> 89-fb branch to trunk, but diverged enough to have it's own issue.
> The idea is to implement a zk based read/write lock per table. Master
> initiated operations should get the write lock, and region operations (region
> split, moving, balance?, etc) acquire a shared read lock.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
