hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-3509) Exclusive locks are not acquired when using dynamic partitions
Date Fri, 19 Apr 2013 05:23:20 GMT

     [ https://issues.apache.org/jira/browse/HIVE-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Phabricator updated HIVE-3509:
------------------------------

    Attachment: HIVE-3509.D10065.3.patch

MattMartin updated the revision "HIVE-3509 [jira] Exclusive locks are not acquired when using
dynamic partitions".

  Committing two minor changes and one partially implemented major change. The two minor changes
are: 1) ZookeeperHiveLockManager returns database level locks and 2) handling the case when
the default db is not being used (lock5.q handles this case).  The major change illustrates
why it is probably not a good idea to change the "lock ..." and "unlock ..." commands to automatically
acquire locks across the whole hierarchy.  Users can still acquire locks across the entire
hierarchy if they need to/want to.

Reviewers: JIRA

REVISION DETAIL
  https://reviews.facebook.net/D10065

CHANGE SINCE LAST DIFF
  https://reviews.facebook.net/D10065?vs=31563&id=32433#toc

AFFECTED FILES
  data/conf/hive-site.xml
  ql/src/java/org/apache/hadoop/hive/ql/Driver.java
  ql/src/java/org/apache/hadoop/hive/ql/exec/DDLTask.java
  ql/src/java/org/apache/hadoop/hive/ql/hooks/HookContext.java
  ql/src/java/org/apache/hadoop/hive/ql/lockmgr/HiveLockObject.java
  ql/src/java/org/apache/hadoop/hive/ql/lockmgr/zookeeper/ZooKeeperHiveLockManager.java
  ql/src/test/org/apache/hadoop/hive/ql/hooks/PreExecutePrinter.java
  ql/src/test/queries/clientnegative/lockneg1.q
  ql/src/test/queries/clientnegative/lockneg2.q
  ql/src/test/queries/clientnegative/lockneg3.q
  ql/src/test/queries/clientnegative/lockneg4.q
  ql/src/test/queries/clientnegative/lockneg5.q
  ql/src/test/queries/clientpositive/lock1.q
  ql/src/test/queries/clientpositive/lock2.q
  ql/src/test/queries/clientpositive/lock3.q
  ql/src/test/queries/clientpositive/lock4.q
  ql/src/test/queries/clientpositive/lock5.q
  ql/src/test/results/clientnegative/lockneg1.q.out
  ql/src/test/results/clientnegative/lockneg2.q.out
  ql/src/test/results/clientnegative/lockneg3.q.out
  ql/src/test/results/clientnegative/lockneg4.q.out
  ql/src/test/results/clientnegative/lockneg5.q.out
  ql/src/test/results/clientpositive/lock1.q.out
  ql/src/test/results/clientpositive/lock2.q.out
  ql/src/test/results/clientpositive/lock3.q.out
  ql/src/test/results/clientpositive/lock4.q.out
  ql/src/test/results/clientpositive/lock5.q.out

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
>
>
> 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

Mime
View raw message