[
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
