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