[jira] [Commented] (HIVE-23724) Hive ACID Lock conflicts not getting resolved correctly.

["Peter Vary (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-23724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139985#comment-17139985 ] 

Peter Vary commented on HIVE-23724:
-----------------------------------

[~aditya-shah]: Thanks for reporting the issue. HIVE-22888 might fix this issue. What do you think?

> Hive ACID Lock conflicts not getting resolved correctly.
> --------------------------------------------------------
>
>                 Key: HIVE-23724
>                 URL: https://issues.apache.org/jira/browse/HIVE-23724
>             Project: Hive
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 3.1.2
>            Reporter: Aditya Shah
>            Assignee: Aditya Shah
>            Priority: Major
>         Attachments: HIVE-23724.1.branch-3.1.patch
>
>
> Steps to reproduce:
> 1. `Drop database temp cascade`
> 2. Parallelly (after 1. but while 1. is running) fire a `create table temp.temp_table (a int, b int) clustered by (a) into 2 buckets stored as orc TBLPROPERTIES ('transactional'='true')`
> 3. Parallelly (after 2. but while 2. is running) fire a `insert overwrite table temp.temp_table values (1,2)`
> note: The above could be easily reproduced by a unit test in testDbTxnManager.
> Observation: Exclusive lock for Table in 3. is granted although exclusive lock for DB acquired in 1. is still acquired and shared read lock on DB for 2. is waiting.
> Cause of issue: while acquiring a lock if we choose to ignore a conflict between the desired lock and one of the existing locks we immediately allow the desired lock to be acquired without checking against all the existing locks. The above-mentioned scenario was one such ignore conflict condition in 2. and 3. There could be other possible combinations where this may occur. Like for example when we request a lock with the same txn ids. Although hive guarantees that this scenario will not occur due to all lock requests related to a txn are asked at the same and failure of one guarantees failure of all, we in future will have to be extra careful with it.
> Resolution: Whenever we ignore conflict we should keep looking against all the existing locks and only then allow the lock to be acquired.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)