You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Enis Soztutar (JIRA)" <ji...@apache.org> on 2012/12/08 01:29:21 UTC

[jira] [Updated] (HBASE-7305) ZK based Read/Write locks for table operations

     [ https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Enis Soztutar updated HBASE-7305:
---------------------------------

    Attachment: hbase-7305_v0.patch

Attaching a v0 patch which just ports HBASE-5494 and HBASE-5991. There are still some things to do: 
 - PB the zookeeper content
 - Master should invalidate the table locks on recover
 - Move to Netflix curator lib?

Some points:
 - Should we expose lock/unlock table to the clients. I think we should not do that unless we have a valid reason. 
 - Should the lock checking even timeout? If the prev operation cannot continue, then it means that it has not finished / or cannot finish. Should we wait indefinitely?
 - The lock is acquired in the async handlers not part of the rpc, and there is no generic way for the client to track the status and get the result of master operations. 
 - This patch just does write lock from master to disable/enable/delete/create/addColumn/deleteColumn. I think we can do the shared lock in a follow up issue. 

                
> 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