[
https://issues.apache.org/jira/browse/HBASE-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269110#comment-13269110
]
Phabricator commented on HBASE-5494:
------------------------------------
khemani has commented on the revision "[jira] [HBASE-5494] [89-fb] Table-level
locks for schema changing operations.".
INLINE COMMENTS
src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:294
Should you check the return value of this method to ensure that the node still
exists?
Say checkExistsAndCreate set the watch because the znode existed.
Now the watch fires because the lock-owner changes the znode data.
By the time you reset the watch here the owner releases the lock.
watchAndCheckExists() will return false and you should then trigger the latch.
src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWrapper.java:1336
The zookeeper disconnect error should be specially handled - because the znode
might have already been created.
src/main/java/org/apache/hadoop/hbase/zookeeper/DistributedLock.java:112 Will
lockZNodeVersion always be 0 because this znode has just been created?
Why should release() need lockZNodeVersion? it should be OK to blindly delete
the znode?
REVISION DETAIL
https://reviews.facebook.net/D2997
BRANCH
table_level_ddl_locks
> 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, D2997.4.patch, D2997.5.patch,
> D2997.6.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
