[
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
