[jira] [Commented] (HBASE-5373) Table level lock to prevent the race of multiple table level operation
[ https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267667#comment-13267667 ] Liyin Tang commented on HBASE-5373: --- Sure. I am glad that Alex is working this jira right now and I will help on the code-review. > Table level lock to prevent the race of multiple table level operation > -- > > Key: HBASE-5373 > URL: https://issues.apache.org/jira/browse/HBASE-5373 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Assignee: Liyin Tang > > A table level lock can guarantee that only one table operation would happen > at one time for each table. The master should require and release these table > locks correctly during the failover time. One proposal is to keep track of > the lock and its corresponding operation in the zookeeper. If there is a > master failover, the secondary should have a way to check whether these > operations are succeeded nor not before releasing the lock. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5373) Table level lock to prevent the race of multiple table level operation
[ https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205120#comment-13205120 ] Liyin Tang commented on HBASE-5373: --- Cool! Sounds like what I try to do here. I will take a look over Accumulo. > Table level lock to prevent the race of multiple table level operation > -- > > Key: HBASE-5373 > URL: https://issues.apache.org/jira/browse/HBASE-5373 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Assignee: Liyin Tang > > A table level lock can guarantee that only one table operation would happen > at one time for each table. The master should require and release these table > locks correctly during the failover time. One proposal is to keep track of > the lock and its corresponding operation in the zookeeper. If there is a > master failover, the secondary should have a way to check whether these > operations are succeeded nor not before releasing the lock. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5373) Table level lock to prevent the race of multiple table level operation
[ https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205108#comment-13205108 ] Todd Lipcon commented on HBASE-5373: Over in Accumulo land they have a neat framework called "FATE" (FAult Tolerant Execution or something?) Basically, they put up a znode in ZK for any master-coordinated action, and it acts as an "intent log" of the idempotent steps. If there's a failover, the new master will finish off any already-running FATE transaction. > Table level lock to prevent the race of multiple table level operation > -- > > Key: HBASE-5373 > URL: https://issues.apache.org/jira/browse/HBASE-5373 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Assignee: Liyin Tang > > A table level lock can guarantee that only one table operation would happen > at one time for each table. The master should require and release these table > locks correctly during the failover time. One proposal is to keep track of > the lock and its corresponding operation in the zookeeper. If there is a > master failover, the secondary should have a way to check whether these > operations are succeeded nor not before releasing the lock. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
