[
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267948#comment-13267948
]
Phabricator commented on HBASE-5494:
------------------------------------
mbautin has commented on the revision "[jira] [HBASE-5494] [89-fb] Table-level
locks for schema changing operations.".
A few more comments, but everything looks good in general. I will accept once
all major comments are addressed.
INLINE COMMENTS
src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1353 Maybe checking
if the table exists before trying to get the lock might provide more useful
feedback to the user. Obviously, this will need to be checked again with the
lock held.
src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:129
Might be useful to use EnvironmentEdgeManager.currentTimeMillis() for
testability.
src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:143 The
same here
src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:123
javadoc: return value (false on timeout?)
src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:38 More
method javadocs in this class would be nice
src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java:1321 We
could also set the watch before trying to create the node.
src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java:75
@Kannan: are you talking about using wait/notify on the Long object in
eventToDelayTimeMs instead of using a CountDownLatch?
src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java:57
Is it possible to wait for an event more than once? As it is currently
implemented, once we count down the latch, all subsequent awaitEvent() calls
will return instantly, because the old latch will still be in the map. How
would we wait for another occurrence of the same event type?
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
