Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 6 May 2012 04:04:01 +0000 (UTC)
From: "Phabricator (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <248815397.31465.1336277041775.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1493578728.4919.1330550759114.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5494) Introduce a zk hosted table-wide
 read/write lock so only one table operation at a time
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Phabricator commented on HBASE-5494:
------------------------------------

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

  Hi Prakash.

  Thanks for the comments! I'll chat with you on Monday about the potential issue around handling connection loss (I was under impression that RecoverableZookeeper handles that).

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java:1336 Isn't this handled by RecoverableZooKeeper?
  src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:112 This is to verify that we are only releasing a lock that we ourselves acquire, and that code doesn't (accidentally) release lock acquired by other threads/processes.
  src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:294 Good catch, will handle this.

REVISION DETAIL
  https://reviews.facebook.net/D2997

BRANCH
  table_level_ddl_locks

                
> 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, D2997.4.patch, D2997.5.patch, D2997.6.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