我对hive比较陌生，但对rdbms有相当丰富的经验。我的问题基本上是在Hive里写饥饿。我有一些重读（未分区）的配置单元表，需要每天覆盖一次（它们是来自mysql的sqooped实体数据，所以不是特别大）。i、 许多共享锁和一天一次独占锁需要一个窗口来写。周期性地，写锁从不发生，需要人为干预来强制解锁表，从而允许写锁成功。
我对配置单元表锁的理解是，如果锁获取失败，它只会休眠一段时间 hive.lock.sleep.between.retries 和重试 hive.lock.numretries 在放弃之前。换句话说，它是否会在没有其他读取活动的情况下命中一个窗口并获得一个成功的锁，这似乎是一个完全的机会。
相反，我对rdbms的经验是锁请求是以fifo（ish）方式排队和处理的，这意味着独占锁最终会得到一个机会。我发现很难相信有人还没有想到类似的东西已经Hive，所以我觉得有一个很好的理由，这是不可能的。。。。？
我的群集正在使用 hive.lock.manager=org.apache.hadoop.hive.ql.lockmgr.zookeeper.ZooKeeperHiveLockManager 据我所知，这是我寻求澄清的逻辑的守护者，但我发现关于它如何工作的文档非常稀少，所以我只是偏离了我所观察到的。
我的问题：
在配置单元中是否存在排队的锁请求？
如果是的话，我该怎么做？
如果没有，为什么不呢？
还有什么办法解决这个问题吗？
谢谢！