[
https://issues.apache.org/jira/browse/HBASE-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583818#comment-13583818
]
Enis Soztutar commented on HBASE-7546:
--------------------------------------
Thanks Ted, I've addressed your comments in the next patch.
bq. What's your plan for above situation ?
This is a bit tricky. The difference between local locks and distributed locks
is that, release() can fail in a distributed setup. In this case, and in
master's operations, if delete() fails, the lock will be left as acquired until
the zookeeper session expires (lock znodes are EPHEMERAL). The assumption here
is that if we fail to delete (using RecoverableZooKeeper), we will probably
abort anyway due to session expiry from other events. Curator has a nice delete
guarantee, that it queues up the deletes, and as long as there is session, it
tries the deletes. We don't have that right now, and I think we can live with
best effort for now. If we encounter lingering locks, we can fix it separately,
wdyt?
bq. The lock manager can also be used for write locking, right ?
Yes, but we are only using it to acquire read locks for splits for now. Changed
the comment to reflect that.
> Obtain a table read lock on region split operations
> ---------------------------------------------------
>
> Key: HBASE-7546
> URL: https://issues.apache.org/jira/browse/HBASE-7546
> Project: HBase
> Issue Type: Bug
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Attachments: hbase-7546_v1.patch, hbase-7546_v2.patch
>
>
> As discussed in the parent issue HBASE-7305, we should be coordinating
> between splits and table operations to ensure that they don't happen at the
> same time. In this issue we will acquire shared read locks for region splits.
--
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
