hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (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 Thu, 03 May 2012 23:54:50 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267958#comment-13267958

Phabricator commented on HBASE-5494:

avf has commented on the revision "[jira] [HBASE-5494] [89-fb] Table-level locks for schema
changing operations.".

  src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java:57 Good question.
One drawback to adding a CountDownLatch for each event might be:

  1) Thread A waits for CountDownLatch, for the same event. Thread B comes along and counts
its down.

  2) Thread C also wants to wait for the instance of the event -- but in this case, the CountDownLatch
will be incremented and thread C will have to wait for the next version of the event.

  Essentially we should make a call if we allow multiple threads to wait for the same event
*or* if we allow a thread to wait for multiple instance of the same event.

  I am actually leaning in favour of the latter now, and can change this (in our case, we
only have one thread waiting for an event).
  src/test/java/org/apache/hadoop/hbase/util/DelayInducingInjectionHandler.java:75 @mbautin
I discussed this offline with Kannan, and he agreed with my use of this structure, but just
asked me to use the "create CountDownLatch if one doesn't exist and then call .countDown"
inside the if loop (if eventToDelayTimeMs contains the key).

  Wait/notify would work, but might be more cumbersome to implement than just using CountDownLatch.


> 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
> 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