hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-7305) ZK based Read/Write locks for table operations
Date Sat, 08 Dec 2012 00:29:21 GMT

     [ 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

View raw message