hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Feinberg (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 Fri, 04 May 2012 04:17:05 GMT

    [ 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


View raw message