[
https://issues.apache.org/jira/browse/HBASE-20847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16538623#comment-16538623
]
stack commented on HBASE-20847:
-------------------------------
bq. For table lock this should not happen, as region assign can happen at any
time if there is a server crash as it needs to hold the shared lock, so if we
hold the exclusive lock for the whole life of a table procedure then it will
hurt the availability...
You are arguing we should never take an exclusive lock on a table? For a
modifytableprocedure?
bq. ....as region assign can happen at any time if there is a server crash
Assign can only proceed after WAL logs have been split... so if an SCP and a
ModifyTableProcedure at same time, MTP should wait until SCP has finished log
splitting before proceeding.... SCP should wait till MTP has done
assigning/unassiging before it tries assigning?
bq. But for other procedures, such as peer related procedures, we will hold the
lock for the whole life time.
Post-crash, how does this lock get reinstated? Currently there is no means,
right? Scheduling the parent to run before the sub-procedure would go against
the Pv2 grain. Does this mean that as part of the load process we should be
re-instituting locks? (Is this what HBASE-20846 is supposed to be doing? Sounds
like it. If so, great)
> The parent procedure of RegionTransitionProcedure may not have the table lock
> -----------------------------------------------------------------------------
>
> Key: HBASE-20847
> URL: https://issues.apache.org/jira/browse/HBASE-20847
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2, Region Assignment
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Major
> Attachments: HBASE-20847-v1.patch, HBASE-20847-v2.patch,
> HBASE-20847.patch
>
>
> For example, SCP can also schedule AssignProcedure and obviously it will not
> hold the table lock.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
