[
https://issues.apache.org/jira/browse/HIVE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554781#comment-13554781
]
Ashutosh Chauhan commented on HIVE-3537:
----------------------------------------
Before HIVE-3106, for a multi-insert case, if query failed it was possible that
some partitions gets inserted while others don't inspite of acquiring table
level locks. HIVE-3106 fixed that by introducing a fake dependency task which
was added at the end of the plan because of which partitions will be added only
after all the MR jobs are finished and data is generated for all tables. This
jira fixes the issue where a lock on table is released as soon as partition
addition on that particular table is completed. This ensures consistency for
that table as in no other updates could be made on that table until lock is
released. Atomicity you are referring to in your previous comment is when users
want either all of the tables are changed or none at all. Are all these
statements correct? Wants to make sure I understood all the nuances here.
> release locks at the end of move tasks
> --------------------------------------
>
> Key: HIVE-3537
> URL: https://issues.apache.org/jira/browse/HIVE-3537
> Project: Hive
> Issue Type: Bug
> Components: Locking, Query Processor
> Reporter: Namit Jain
> Assignee: Namit Jain
> Attachments: hive.3537.1.patch, hive.3537.2.patch, hive.3537.3.patch,
> hive.3537.4.patch, hive.3537.5.patch, hive.3537.6.patch, hive.3537.7.patch,
> hive.3537.8.patch, hive.3537.9.patch
>
>
> Look at HIVE-3106 for details.
> In order to make sure that concurrency is not an issue for multi-table
> inserts, the current option is to introduce a dependency task, which thereby
> delays the creation of all partitions. It would be desirable to release the
> locks for the outputs as soon as the move task is completed. That way, for
> multi-table inserts, the concurrency can be enabled without delaying any
> table.
> Currently, the movetask contains a input/output, but they do not seem to be
> populated correctly.
--
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
