[jira] [Commented] (HBASE-5373) Table level lock to prevent the race of multiple table level operation

2012-05-03 Thread Liyin Tang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2012-02-09 Thread Todd Lipcon (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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




[jira] [Commented] (HBASE-5373) Table level lock to prevent the race of multiple table level operation

2012-02-09 Thread Liyin Tang (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-5373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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