[
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
