[
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
