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 22:46:50 GMT

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

Phabricator commented on HBASE-5494:

avf has commented on the revision "[jira] [HBASE-5494] [89-fb] Table-level locks for schema
changing operations.".

  @stack Thanks for the comments! If we convert ZNode contents for this to protobufs, we should
also add a commands to the HBase shell (I'll be willing to help with that) to list currently
held locks (who they are held by, for what purpose, and by whom) and delete them -- the reason
they're in plain text in the current code is to allow operations to use the ZK CLI to do so.

  I agree that using protobufs would be more appropriate for this purpose, as long as there's
a way for operators to view this data without having to write code.

  src/main/java/org/apache/hadoop/hbase/master/HMaster.java:1315 Right now locking is not
exposed in the client APIs, so essentially if locks are disabled schema changes (the only
part where locks are currently used) behave as they would prior to the patch.

  Should I, perhaps, add a warning in this case? ("warning: schema modification locks are
disabled, concurrent schema changes may result in corruption")
  src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java:67 No, in this case I
enforce (with an IllegalStateException) that locks can only be released by their owners. Currently,
stale locks (locks after a "hard" server crash) would be removed using the ZooKeeper CLI.

  It would probably make sense to add a command to the HBase shell to list all locks currently
held (and when they acquired), and then release them.
  src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java:111 Thanks, will do.
  src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java:137 I am using an IllegalStateException
to enforce this as an invariant (if a lock was acquired in ZooKeeper, it should not be in
acquiredTableLock -- and vice versa).


> 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