[ 
https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607245#comment-13607245
 ] 

ramkrishna.s.vasudevan commented on HBASE-7305:
-----------------------------------------------

[~jmhsieh]
Your concern on region assignment obtaining a lock seems very much valid.  I 
remember Enis asking about the same thing long back.
If you take a look at HBASE-8133 actually a table was getting DISABLED but the 
Region znode was having it in OPENING or OPENED.
This happens when a balancer and disable table happens parallely.  
Pls refert 
https://issues.apache.org/jira/browse/HBASE-8133?focusedCommentId=13604868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13604868,
 from Rajesh which explains this scenario.
Just saw this discussion going on here so thought it would help in 
understanding the problem.
So basically on a high level if balancing is going on we need to obtain locks 
for the tables of those regions that are currently getting assigned and the 
same should be checked before staring balancer if suppose Disable table or any 
such operation is going on to avoid this problem.
                
> 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.95.0
>
>         Attachments: 130228-zkrwlocks.pdf, 7305-v11.txt, hbase-7305_v0.patch, 
> hbase-7305_v10.patch, hbase-7305_v13.patch, hbase-7305_v14.patch, 
> hbase-7305_v15.patch, hbase-7305_v1-based-on-curator.patch, 
> hbase-7305_v2.patch, hbase-7305_v4.patch, hbase-7305_v9.patch, 
> HBaseTableLocks.pdf, HBaseTableLocks_v2.pdf
>
>
> 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

Reply via email to