[jira] [Commented] (HBASE-7305) ZK based Read/Write locks for table operations

["stack (JIRA)" <ji...@apache.org>]

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

stack commented on HBASE-7305:
------------------------------

bq. Should we expose lock/unlock table to the clients. I think we should not do that unless we have a valid reason.

Agreed (Only reason to do otherwise is if we have a hanging lock and we want to be able to give an admin a means of cleaning up hung over locks -- but we ain't going to have stuck locks -- smile -- so no need)

bq. Should the lock checking even timeout? If the prev operation cannot continue, then it means that it has not finished / or cannot finish. Should we wait indefinitely?

I don't think so.  If you fail to get lock, then exception..... and the procedure cannot start.  That makes sense.  That we have procedures that can get stuck should not be the determinant on whether waiting on a lock has a timeout I'd say.

bq. The lock is acquired in the async handlers not part of the rpc, and there is no generic way for the client to track the status and get the result of master operations.

Can you say more.  This is interesting.

bq. This patch just does write lock from master to disable/enable/delete/create/addColumn/deleteColumn. I think we can do the shared lock in a follow up issue.

Agreed.


                
> 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