[
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267833#comment-13267833
]
Phabricator commented on HBASE-5494:
------------------------------------
stack has commented on the revision "[jira] [HBASE-5494] [89-fb] Table-level
locks for schema changing operations.".
This is great stuff. I can help port to trunk (will need to add test size on
new tests, annotations to classes for audience, and zk persistence needs to be
protobuf'd -- I can help here np).
One thing we'd like to prevent is a table being disabled while splits (or
merges) are going on. How hard would it be to add this facility (in another
jira?). One way of doing it would be that a regionserver before splitting,
it'd take out the table lock. That would prevent the table from being
disabled. But what about the case if two regionservers try to split a region
from the same table at the one time? Or, what if the regionserver dies
mid-split; the lock will be stuck in place.
Do you see our extending this system to deal w/ the above or do you think
that another system altogether?
Good stuff A.
INLINE COMMENTS
src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1315 If client asks
to lock a table on cluster where this feature is not enabled, they get same
response as when they successfully lock a table? Should they be different?
src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1322 ditto
src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1353 Would a
tryLock make a difference here?
When no trylock, the second thread through will fail with table already
created.
With trylock, client will get "Failed to get lock" which is pretty useless.
It might have the client return faster which could be good but these events are
rare so probably something we don't need to sweat.
src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java:67 This is
not exclusive, right? The lock taker does not have to be the lock undoer?
src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java:111 Add
content of acquiredTableLocks to help debug?
REVISION DETAIL
https://reviews.facebook.net/D2997
> Introduce a zk hosted table-wide read/write lock so only one table operation
> at a time
> --------------------------------------------------------------------------------------
>
> Key: HBASE-5494
> URL: https://issues.apache.org/jira/browse/HBASE-5494
> Project: HBase
> Issue Type: Improvement
> Reporter: stack
> Attachments: D2997.3.patch
>
>
> I saw this facility over in the accumulo code base.
> Currently we just try to sort out the mess when splits come in during an
> online schema edit; somehow we figure we can figure all possible region
> transition combinations and make the right call.
> We could try and narrow the number of combinations by taking out a zk table
> lock when doing table operations.
> For example, on split or merge, we could take a read-only lock meaning the
> table can't be disabled while these are running.
> We could then take a write only lock if we want to ensure the table doesn't
> change while disabling or enabling process is happening.
> Shouldn't be too hard to add.
--
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
