hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5494) Introduce a zk hosted table-wide read/write lock so only one table operation at a time
Date Thu, 03 May 2012 23:42:48 GMT

    [ 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.

  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?


> 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


View raw message