[
https://issues.apache.org/jira/browse/HIVE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550877#comment-13550877
]
Ashutosh Chauhan commented on HIVE-3537:
----------------------------------------
Also, seems like it won't be easy to write a test case for this. One
possibility I can think of is to write a junit test-case (instead of .q) which
tests for the lock data in ZK and asserts that lock data is wiped out of ZK,
after query doing multi-insert finishes.
> 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
