[
https://issues.apache.org/jira/browse/HIVE-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636551#comment-13636551
]
Phabricator commented on HIVE-3509:
-----------------------------------
MattMartin has commented on the revision "HIVE-3509 [jira] Exclusive locks are
not acquired when using dynamic partitions".
For the record, I'm planning to roll back the "major change" in my last
revision which acquires and releases the whole hierarchy of locks on explicit
"lock ..." and "unlock ...".
INLINE COMMENTS
ql/src/java/org/apache/hadoop/hive/ql/lockmgr/HiveLockObject.java:144 This
change should only affect locks. In particular, this would make sure the lock
paths are consistent for dummy partitions and non-dummy partitions.
Without this change, I think a case could arise where a write query with
dynamic partitions tries to acquire an exclusive lock on "<base dir in
zookeeper>/db@table@partns" while a read query simultaneously tries to acquire
a shared lock on "<base locking dir in zookeeper>/db/table/partns". In this
case the reader and writer would not block each other even though they should.
I'll try to add a test case to illustrate this point.
REVISION DETAIL
https://reviews.facebook.net/D10065
To: JIRA, MattMartin
Cc: njain
> Exclusive locks are not acquired when using dynamic partitions
> --------------------------------------------------------------
>
> Key: HIVE-3509
> URL: https://issues.apache.org/jira/browse/HIVE-3509
> Project: Hive
> Issue Type: Bug
> Components: Locking
> Affects Versions: 0.9.0
> Reporter: Matt Martin
> Assignee: Matt Martin
> Attachments: HIVE-3509.1.patch.txt, HIVE-3509.D10065.1.patch,
> HIVE-3509.D10065.2.patch, HIVE-3509.D10065.3.patch, HIVE-3509.D10065.4.patch
>
>
> 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|https://cwiki.apache.org/confluence/display/Hive/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):
> {quote}
> 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.
> {quote}
> After [HIVE-1781|https://issues.apache.org/jira/browse/HIVE-1781], the
> observed behavior is no longer consistent with the behavior described above.
> [HIVE-1781|https://issues.apache.org/jira/browse/HIVE-1781] appears to have
> altered the logic so that SHARED locks are acquired instead of EXCLUSIVE
> locks whenever the query involves dynamic partitions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
