hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7305) ZK based Read/Write locks for table operations
Date Wed, 12 Dec 2012 02:07:22 GMT

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

Enis Soztutar commented on HBASE-7305:

bq. Can you say more. This is interesting.
Most of the client -> master operations are async. On the RPC code path, the Handler objects
are created, and some basic checks are performed in the c.tor. Then the rpc returns without
waiting for the operation to finish. But we don't expose any generic mechanism to the client
so that it can check the status or the request (like whether it finished/succeeded/exception).
The client can only check the side effects of the request (if enable table, whether the table
is enabled yet, HBaseAdmin.createTable(), etc). 
If we do HBASE-5487, or keep request id's around in the handlers, we can fix that by exposing
some submit task / query status / get exception API from the master to the client. I think
we need to start working on that after this.
In this patch though, we do not acquire the table lock in the rpc path, but only on EventHandler.process().
The client rpc never waits for the table lock. But now thinking about it, I think I will change
it so that the table lock is acquired in the RPC handler, and released from the table event
> ZK based Read/Write locks for table operations
> ----------------------------------------------
>                 Key: HBASE-7305
>                 URL: https://issues.apache.org/jira/browse/HBASE-7305
>             Project: HBase
>          Issue Type: Bug
>          Components: Client, master, Zookeeper
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 0.96.0
>         Attachments: hbase-7305_v0.patch
> This has started as forward porting of HBASE-5494 and HBASE-5991 from the 89-fb branch
to trunk, but diverged enough to have it's own issue. 
> The idea is to implement a zk based read/write lock per table. Master initiated operations
should get the write lock, and region operations (region split, moving, balance?, etc) acquire
a shared read lock. 

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

View raw message