[
https://issues.apache.org/jira/browse/HIVE-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462023#comment-16462023
]
Alexander Kolbasov commented on HIVE-17166:
-------------------------------------------
This looks rather strange. Essentially you propose to introduce a configuration
that makes locking useless - the holder of the lock can no longer assume that
invariants hold true since holding the lock doesn't mean anything.
> Break Locks On Timeout
> ----------------------
>
> Key: HIVE-17166
> URL: https://issues.apache.org/jira/browse/HIVE-17166
> Project: Hive
> Issue Type: New Feature
> Components: HiveServer2
> Affects Versions: 1.2.2, 2.1.1, 3.0.0
> Reporter: BELUGA BEHR
> Assignee: Janaki Lahorani
> Priority: Major
>
> Hive supports table and partition locks by utilizing ZooKeeper to keep track.
> There are several configurations related to this, including:
> {{hive.lock.sleep.between.retries}} and {{hive.lock.numretries}}.
> I'd lile to propose a new boolean configuration that, when set, would alter
> the behavior of a lock timeout failure. Instead of failing the query with an
> error, the configuration would direct Hive to break the lock and allow the
> query try to obtain a new one and proceed.
> This is useful in cases where locks are leaked and erroneously left behind.
> Such scenarios create permanent blocking on future queries. This break-lock
> mechanism would alleviate this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
