You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Ashutosh Chauhan (JIRA)" <ji...@apache.org> on 2018/06/10 06:35:00 UTC

[jira] [Updated] (HIVE-19382) Acquire locks before generating valid transaction list for some operations

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

Ashutosh Chauhan updated HIVE-19382:
------------------------------------
       Resolution: Fixed
    Fix Version/s: 3.1.0
           Status: Resolved  (was: Patch Available)

Pushed to master and branch-3. Thanks, Jesus!

> Acquire locks before generating valid transaction list for some operations
> --------------------------------------------------------------------------
>
>                 Key: HIVE-19382
>                 URL: https://issues.apache.org/jira/browse/HIVE-19382
>             Project: Hive
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 3.0.0
>            Reporter: Jesus Camacho Rodriguez
>            Assignee: Jesus Camacho Rodriguez
>            Priority: Major
>             Fix For: 3.1.0
>
>         Attachments: HIVE-19382.01.patch, HIVE-19382.02.patch, HIVE-19382.03.patch, HIVE-19382.04.patch, HIVE-19382.05.patch, HIVE-19382.patch
>
>
> To ensure correctness, in particular for operations that require exclusive ({{INSERT OVERWRITE}}) and semishared ({{UPDATE}}/{{DELETE}}) locks.
> This is a temporary fix till lock acquisition is moved before analyze in HIVE-18948.
> With this fix, system proceed as follows. The driver will acquire the snapshot, compile the query wrt that snapshot, and then, it will acquire locks. If snapshot is still valid, it will continue as usual. But if snapshot is not valid anymore, it will recompile the query.
> This is easier to implement than full solution described in HIVE-18948 because we do not need to move the logic to extract the read/write entities from a query before compilation (actually while parsing).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)