Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 4 May 2012 04:17:05 +0000 (UTC)
From: "Alex Feinberg (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1586677802.25614.1336105025598.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=13268107#comment-13268107 ] 

Alex Feinberg commented on HBASE-5494:
--------------------------------------

.bq You thought this overkill for your case? http://zookeeper.apache.org/doc/r3.1.2/recipes.html#Shared+Locks That is fine. Do you think we could backfill it later underneath the patch attached here?

I went down the non-sequential route (as you said, thinking it was over-kill and simple "create if not exist" approach would work), although I later realized that some of the potential race conditions would likely not happen if I went with their approach. I think we could backfill it later once we create read-write locks. 

I do like the idea of a new master coming up to finish previous work. If we make the ZNode data more machine parseable (e.g., convert it to protobuf in trunk) than this would be feasible to do (when a new master is brought up, the master scans the lock to see if there were any operations in progress when the previous master died). 

I agree that lock and unlock shouldn't really be public APIs (in the sense of being directly accessible to end developers) -- I'll make lockTable() and unlockTable() be package-local methods then, to that end. 
                
> 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
>
>
> 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