[jira] [Commented] (HBASE-7305) ZK based Read/Write locks for table operations

["Jonathan Hsieh (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605746#comment-13605746 ] 

Jonathan Hsieh commented on HBASE-7305:
---------------------------------------

The doc is great -- I'm really the most curious about why different operations get the read or the write aspects of the lock guard what they protect.  I'm trying to justify this to myself now based on the docs.  So, do I have this right?

Affected operations:
* create, delete, disable, enable, alter, modify table (add/del/mod col, mod table), splits
* Other candidates: merge, snapshot, ... balancer, am, ssh, hbck

current rationale: 
* want to allow safe table mods (disable, enable, alter)
* want to allow concurrent splits
* want snapshots operations to be "safe"

Implementaiton:
* Read locks on splits.  
* Exclusive write lock on all other table mods.

Questions/Observations:
* This primarily protects operations that clash with table level enable/disable/alter, but not region level operations, right?.
* This doesn't guard meta from individual changes, right?  It only protects meta from bulk adds (create/delete table).  Thus this shouldn't affect region moves or region closes/opens.
* Protecting split with a read table lock only prevents alter/enable/disable table ops from happening.  If an overlapping merge and split were issued, some other mechanism is in place to keep this sane right? This doesn't protect multiple merge requests with overlapping regions right? 
* Merges will likely want the read lock? (allowing multiple concurrent merges, and assuming some overlap sanity protection from a different mechanism).
* With snapshots, this mechanism doesn't prevent regions from moving so it only protects snapshots from concurrently happening with enable/disable/alter table ops. Snapshot will still fail if it gets caught while the balancer is running.
* These locks don't really help hbck -- except for the cases where enable/disable/alter operations are going on as hbck repairs things.  (It wouldn't "protect" hbck from the balancer").

As a strawman (for follow on work), I'm thinking for Assignemnt dependent operations (splits/balancer/ssh/snapshots/merge) we might want another lock (I believe regions-in-transition kind of serve this purpose already).  

* Does having a table lock (and then having individual region locks that require a table read lock being held) make sense?  Maybe this makes sense for merges and splits?


                
> 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