[
https://issues.apache.org/jira/browse/HBASE-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510937#comment-13510937
]
Enis Soztutar commented on HBASE-5991:
--------------------------------------
@Alex thats for the pointers and the feedback. jcommons seems interesting, but
one motivator for curator was that it already has reentrant read/write lock,
barriers (for hbase snapshots), and queues (for log splitting?). I did not see
those recipes in jcommons.
With your patch already having locks, John's barrier implementation, and the
rest of the stuff, there is definitely less reason to switch, but agreed with
Stack in that this is the perfect time to switch, if we chose to :)
bq. One approach could be to just implement the interfaces with curator and
then run this through the unit tests.
Agreed. That was my intention as well.
> 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
