[
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268102#comment-13268102
]
stack commented on HBASE-5494:
------------------------------
bq. I think it makes sense to have a separate JIRA (or perhaps another patch
for the same JIRA?) to address this...
Yes. Would be a separate JIRA. I'm just trying to have it so it is a
continuation of the work done here rather than a different table locking
facility that runs beside this one because we need read/writes and that there
can be multiple read locks outstanding at anyone time; one per region currently
splitting/merging.
On region-level locks, we do not need this I'd say (Already, region changes go
via zk and there'll be failed transitions if concurrent operators try
manipulate a single region given we usually check znode sequence id before we
go forward moving a region to a new state).
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?
On the lock being left in place on master crash, whats wrong w/ that? Thats
sort of what we want I'd say. Or more, what we really want is that when the
new master comes up, he finishes off what the previous master was at. To that
end, should lock and unlock be public apis on the master at all, but rather
just internal primitives used by the master doing disable/enable? If you
disable a table, the first think you do is obtain a lock and then when done,
you let it go on completion. A new master that comes up after a previous
master has crashed and sees a table in disabling state should go ahead and
complete the disable moving the table state to disabled and when done, then it
undoes the unlock to finish the schema change transaction; you'd have to let
the second master be able to undo the lock (Over in accumulo they have a system
where they allow describing a macro change in terms of distinct steps; the
steps are posted to zk and then acted on. We don't have to be that smart just
yet... we can hardcode disable/enable for now).
Good stuff Alex.
> 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
