[
https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605930#comment-13605930
]
Sergey Shelukhin commented on HBASE-7305:
-----------------------------------------
What I had in mind in the comments in HBASE-5487 was a persistent central state
machine + "version" per region (in ZK or a table), and per table. It should
allow multiple operations to proceed in parallel as long as it's logically
feasible (e.g. if split is opening daughters and alter table comes you just
bump the version on the node and server has to reopen, etc.).
For table-wide ops like alters I am +1 on locking (it could be done via
versions too though, e.g. why not allow parallel alter-s during region opening
- but this is not important probably).
> 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
>
>
> 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
