[
https://issues.apache.org/jira/browse/HBASE-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510139#comment-13510139
]
Enis Soztutar commented on HBASE-5991:
--------------------------------------
Backporting this (HBASE-5991) and HBASE-5494 to trunk.
The rational for the read-write lock is that the master-initiate operations
(enable/disable, modify, add/remove column) and region splits should not happen
in parallel. However, multiple region splits can happen concurrently, so using
a read/write lock for the table makes sense. All the table operations initiated
from the master take a write lock. And the region splits take a read lock.
In this patch, we will only be doing the master write lock parts. I'll open
another issue to track the read locks for region splits.
One discussion that happened offline in todays HBase hackaton was to use the
curator library from netflix, which already has (supposedly) correct
implementations for many zookeeper recipes
(https://github.com/Netflix/curator). The 89-fb patch already contains a
read/write zk lock that is implemented from the zk recipe in pseudo-code, so we
have to chose one way or the other.
I can go ahead and rebase this patch with the Curator's version to see whether
we can go with it. If we want to continue the discussion on whether to go with
curator or not, we can alternatively create a separate jira.
> Introduce sequential ZNode based read/write locks
> --------------------------------------------------
>
> Key: HBASE-5991
> URL: https://issues.apache.org/jira/browse/HBASE-5991
> Project: HBase
> Issue Type: Improvement
> Reporter: Alex Feinberg
> Assignee: Alex Feinberg
> Fix For: 0.89-fb
>
>
> This is a continuation of HBASE-5494:
> Currently table-level write locks have been implemented using non-sequential
> ZNodes as part of HBASE-5494 and committed to 89-fb branch. This issue is to
> track converting the table-level locks to sequential ZNodes and supporting
> read-write locks, as to solve the issue of preventing schema changes during
> region splits or merges.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
