Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.9.0
-
None
-
None
Description
If locking is enabled, the acquireReadWriteLocks() method in org.apache.hadoop.hive.ql.Driver iterates through all of the input and output entities of the query plan and attempts to acquire the appropriate locks. In general, it should acquire SHARED locks for all of the input entities and exclusive locks for all of the output entities (see the Hive wiki page on locking for more detailed information).
When the query involves dynamic partitions, the situation is a little more subtle. As the Hive wiki notes (see previous link):
in some cases, the list of objects may not be known - for eg. in case of dynamic partitions, the list of partitions being modified is not known at compile time - so, the list is generated conservatively. Since the number of partitions may not be known, an exclusive lock is taken on the table, or the prefix that is known.
After HIVE-1781, the observed behavior is no longer consistent with the behavior described above. HIVE-1781 appears to have altered the logic so that SHARED locks are acquired instead of EXCLUSIVE locks whenever the query involves dynamic partitions.